【发布时间】：2014-06-18 18:52:11
【问题描述】：
Cassandra 好写少读，HBASE 好随机读写对吗？听说 facebook 用 HBASE 代替 Cassandra
【问题讨论】：
【发布时间】：2014-06-18 18:52:11
【问题描述】：
是的：fb 开始构建 Cassandra，将其开源，然后迁移到 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 更好。
【讨论】：
-
这是一篇很好的文章。我已经与 HBase 和 Cassandra 一起工作了几年。 HBase/Zookeeper 是一个开发和 DevOps 的难题：不要将其用于大规模数据问题之外的任何事情。
HBase 使用 LSM 树并提供标准的插入/写入速率。由于 LSM 树，随机不会出现在常规写入中。如果您正在进行批量上传，则可以绕过预写日志 (WAL) 并直接命中内存存储。如果您愿意，可以使用 hadoop 或其他数据工具直接写入 HDFS 以进行大量上传。如果增加区域服务器的数量，则可以提高写入性能，因为这将导致更多的 WAL。但是，像往常一样，它会在其他地方咬你。所以，要小心。
对于随机读取，如果您的块大小足够小，HBase 将能够为您提供更好的性能。它将轻松找到包含您的数据的块，然后按顺序处理该块以获取您的数据。因此，较小的块用于随机读取，较大的块用于顺序读取。随着索引块大小的增加，较小的块会略微影响空间限制。
仍在学习 Cassandra。所以没有 cmets 。
【讨论】：