我们为什么选择了Cassandra而没有用Hbase

前不久，我们决定用一款分布式的Nosql来存储一些频繁访问的用户数据，数据量较大。速度最快的是Redis，然而Redis由于集群的部署需要做额外的工作来保证数据的持久化，而单机数据量又不够大，所以我们最终把目标定位到了其它的数据库。如MongoDB,Hbase,Cassandra。下面总结一些我们选择Cassandra的原因。

1.读写速度最快。

这些数据库都能满足我们的需求，至于最终选择哪个，综合一下应该从性能，稳定性上进行取舍。而从一些网上的对比报告看出，Cassandra的读写性能最好。写自然不必说，Cassandra的设计就是为了提升写的效率，写入内存（并且记录日志，周期性的刷入或者必须记录）就返回成功，然后才持久化。读也很快，硬盘中是顺序读，另外又有多级缓存，例如KeyCache,RowCache,Key Filter。

2.稳定性高。

稳定性上主要是考虑的是某个节点挂了怎么办，出现故障怎么办，Cassandra是没有单点故障的，出现故障后，本该写入这个节点的数据会平均的分配到其它节点，并在该节点回复后，写回对应的数据。多重机制保证了某个节点出现故障后，不会对其它节点有太大的影响，不会让集群受不了。

3.绯闻和社区

Cassandra是闹过绯闻的，08年 由Facebook开源，然后11年facebook, twitter宣布停用Cassandra，由于Cassandra的最终一致性模型不适合Message类型应用的处理，当时不少公司考虑到它缺少海量并发的案例，所以也不敢将其使用在主要业务上。不过好东西是最经得起考验的，经过这么4,5年的发展，Cassandra有Datastax的推广，目前已经有好多公司在使用Cassandra，如Instagram按照DBEngine上面的数据库排名，Cassandra已经成为列簇类型的Nosql中用户最广的产品。如下图：



当然Cassandra本身也擅长于绯闻，内部就是使用Gossip这种类似绯闻传播的技术来进行节点间通讯。

4.一致性。

Cassandra是满足最终一致性的。一致性里面有强一致性，就是说数据更新后，访问到的都是最新的数据。弱一致性，可以访问到不是最新的数据。最终一致性是指，用户访问到最终的数据的时候需要一段时间，最终一致性可以理解为有时间间隔的强一致性，那么在这个时间间隔内，数据是不一致的。而Cassandra到底是强一致性还是弱一致性的，网上普遍的说法是弱一致性的，但是Cassandra是可以通过参数来配置成强一致性和弱一致性的。例如，读和写都用Quorum策略，即都读写一半以上的节点才算成功，则是强一致性的。

5.待续。