Cassandra，

Cassandra

利用点对点模型，其消除了单点故障可能性，从而帮助我们在机架故障甚至是网络整体下线的情况下得以幸存。我们能够在无需影响用户体验的情况下，顺利处理整体数据中心故障。只有能够应对故障的分布式系统才是一套拥有出色设计水平的分布式系统，而在Cassandra的帮助下，我们能够承受各类意外状况，并将应对机制纳入数据库架构及功能当中。

Cassandra使用的数据模型对于关系数据库管理员来说并不陌生，我们同样使用表进行数据建模，并通过CQL——Cassandra查询语言——查询数据库。不过与SQL不同，Cassandra支持更为复杂的数据结构，例如嵌套与用户定义类型。例如，相较于为某张图片创建独立的存储表，我们可以直接将该数据存储在集合中以实现更为快速的查询速度。这种作法在CQL当中非常自然，而对应的图片表中则包含其名称、URL以及用户信息。

在高性能系统当中，毫秒级别的差异可能决定用户的实际体验与去留。然而，资源成本高昂的JOIN操作限制了我们的向外扩展通彻。通过对数据进行非规范化处理，我们能够尽可能降低请求数量，从而大幅降低磁盘空间成本并实现可预测的高性能应用。

高可靠性

Cassandra采用gossip作为集群中结点的通信协议，该协议整个集群中的节点都处于同等地位，没有主从之分，这就使得任意节点的退出都不会导致整个集群失效。

Cassandra和HBase都是借鉴了Google BigTable的思想来构建自己的系统，但Cassandra另一重要的创新就是将原本存在于文件共享架构的p2p(peer to peer)引入了NoSQL。P2P的一大特点就是去中心化，集群中的所有节点享有同等地位，这极大避免了单个节点退出而使整个集群不能工作的可能。与之形成对比的是HBase采用了Master/Slave的方式，这就存在单点失效的可能。

高可扩性

随着时间的推移，集群中原有的规模不足以存储新增加的数据，此时进行系统扩容。Cassandra级联可扩，非常容易实现添加新的节点到已有集群，操作简单。

最终一致性

分布式存储系统都要面临CAP定律问题，任何一个分布式存储系统不可能同时满足一致性(consistency)，可用性(availability)和分区容错性(partition tolerance)。Cassandra是优先保证AP，即可用性和分区容错性。

高效写操作

写入操作非常高效，这对于实时数据非常大的应用场景，Cassandra的这一特性无疑极具优势。

数据读取方面则要视情况而定：
1. 如果是单个读取即指定了键值，会很快的返回查询
2. 如果是范围查询，由于查询的目标可能存储在多个节点上，这就需要对多个节点进行查询，所以返回速度会很慢
3. 读取全表数据，非常低效。

结构化存储

Cassandra是一个面向列的数据库，对那些从RDBMS方面转过来的开发人员来说，其学习曲线相对平缓。Cassandra同时提供了较为友好CQL语言，与SQL语句相似度很高。

维护简单

从系统维护的角度来说，由于Cassandra的对等系统架构，使其维护操作简单易行。如添加节点，删除节点，甚至于添加新的数据中心，操作步骤都非常的简单明了