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

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/bigmazhiyu/article/details/47127747

前不久,我们决定用一款分布式的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.待续。





展开阅读全文

没有更多推荐了,返回首页