Cassandra适合写入和少读取，HBASE随机读写

Question

Cassandra是否适合写入和较少阅读，而HBASE是否适合随机读写？听说facebook用HBASE取代Cassandra

Answer 1

是的：fb开始构建Cassandra，将其放入OpenSource，稍后迁移到HBase。 我不确定为什么，但Cassandra和HBase都是很好的解决方案。

Cassandra有好处 + HA（没有SPOF）， +具有可调整的一致性，以及 +写入比读取更快（两者都相当快） - 但是，当协调节点必须与目标节点通信时，Cassandra可能会增加网络流量。 - Cassandra自己创建数据存储，而HBase默认使用HDFS。我强烈认为这是切换的原因，因为fb有大量数据，而HBase用较少的开销分析它 - 但是单点故障。

HBase擅长 +当强烈一致性是强制性的时候 + Hadoop集成 - 但是HMaster是SPOF

是的：Cassandra可以非常快速地按顺序写入批量数据并按顺序读取它们。由于HDFS，HBase非常擅长随机IO。在性能比较中，Cassandra的吞吐量通常略快一些; HBase的延迟时间稍快一些。 从运营的角度来看，Cassandra非常易于维护，因为它非常可靠且系统架构非常强大。由于HMaster和常备的Zookeeper集群需要，HBase很难设置并且不太健壮。

所以最终完全取决于你的问题。我从来没有心中任何人避开卡桑德拉;所以我认为HBase更好。

Answer 2

HBase使用LSM树并提供标准的插入/写入速率。由于LSM树，随机不会进入常规写入的图像。如果您正在进行批量上传，则可以绕过预写日志（WAL）并直接进入内存存储。如果您愿意，可以使用hadoop或其他数据工具直接写入HDFS以进行大量批量上传。如果增加区域服务器的数量，则可以提高写入性能，因为这将导致更多的WAL。但是，像往常一样，它会咬你到别的地方。所以，要小心。

对于随机读取，如果块大小足够小，HBase将能够为您提供更好的性能。它将轻松找到包含数据的块，然后按顺序处理该块以获取数据。因此，用于随机读取的较小块和用于顺序读取的较大块。随着索引块大小的增加，较小的块会略微影响空间约束。

还在学习卡桑德拉。所以没有评论。