Hbase与Cassandra的大规模数据处理

在对大规模数据存储解决方案进行研究之后，我差点就进入了Cassandra。但其普遍认为，Hbase是大规模数据处理和分析的更好解决方案。

尽管两者都是相同的键/值存储并且都可以运行（最近才是Cassandra），但是Hadoop层却使Hadoop在需要对大数据进行处理/分析时成为更好的选择。

我还在 http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

但我仍在寻找Hbase的具体优势。

虽然我对Cassandra更为确信，因为它具有添加节点和无缝复制的简便性，并且没有故障点功能。而且它还保留了二级索引功能，因此是一个不错的选择。

试图确定最适合您的方法实际上取决于您要使用它的目的，它们各有优势，而没有任何更多细节，这更像一场宗教战争。您所引用的帖子也已有一年多的历史了，从那以后都经历了许多变化。也请记住，我不熟悉Cassandra的最新发展。

话虽如此，我将解释HBase提交者Andrew Purtell，并添加一些我自己的经验：

• HBase处于较大的生产环境（1000个节点）中，尽管仍处于Cassandra约400个节点安装的范围之内，所以它的确是微不足道的。

• HBase和Cassandra都支持群集/数据中心之间的复制。我相信HBase的暴露给用户更多，因此看起来更加复杂，但同时您也可以获得更大的灵活性。

• 如果您的应用程序需要强大的一致性，那么HBase可能更合适。它是从头开始设计的，目的是保持一致。例如，它允许更简单地实现原子计数器（我认为Cassandra刚得到了它们）以及Check和Put操作。

• 据我了解，这是写性能出色的原因，这是Facebook选择HBase作为其使者的原因之一。

• 我不确定Cassandra的有序分区程序的当前状态，但过去需要手动重新平衡。如果需要，HBase会为您处理。有序分区程序对于Hadoop样式处理很重要。

• Cassandra和HBase都很复杂，Cassandra只是更好地隐藏了它。如果您查看代码库Cassandra的层次结构，则HBase通过使用HDFS对其存储进行更多公开。如果比较Dynamo和Bigtable的论文，您会发现Cassandra的运算理论实际上更为复杂。

• HBase具有更多的单元测试FWIW。

• 所有Cassandra RPC都是Thrift，HBase具有Thrift，REST和本机Java。Thrift和REST只提供全部客户端API的一部分，但是如果您想纯粹的速度，则可以使用本机Java客户端。

• 对等和主从均具有优势。主从设置通常使调试更容易，并降低了相当多的复杂性。

• HBase不仅限于传统的HDFS，还可以根据需要更改基础存储。MapR看起来很有趣，尽管我自己没有使用过它，但我听到了很多好消息。

作为Cassandra开发人员，我会更好地回答问题的另一面：

• Cassandra的缩放效果更好。众所周知，Cassandra可以扩展到集群中的400多个节点。当Facebook在HBase之上部署Messaging时，他们不得不将其分散到100个节点的HBase子集群中。
• Cassandra支持数百甚至数千个ColumnFamilies。“ HBase目前不能很好地处理两三列以上的系列。”
• 作为没有“特殊”节点或进程的完全分布式系统，Cassandra的设置和操作更简单，更易于故障排除且更可靠。
• Cassandra对多主机复制的支持意味着您不仅可以获得多个数据中心的强大功能-地理冗余，本地等待时间-而且还可以将实时和分析工作负载分为不同的组，并在它们之间进行实时双向复制。如果您不将这些工作负载分开，它们的竞争将非常激烈。
• 由于每个Cassandra节点都管理自己的本地存储，因此Cassandra具有实质性的性能优势，不太可能大幅缩小。（例如，标准做法是将Cassandra提交日志放在单独的设备上，这样它就可以不受读取请求的随机I / O限制地进行顺序写入。）
• Cassandra允许您根据每个操作选择所需的强度来要求一致性。有时，这可能会被误解为“ Cassandra无法为您提供强大的一致性”，但这是不正确的。
• Cassandra提供RandomPartitioner以及更像Bigtable的OrderedPartitioner。RandomPartitioner不太容易出现热点。
• Cassandra提供了堆内或堆外缓存，其性能可与memcached媲美，但没有缓存一致性问题或需要额外移动部件的复杂性
• 非Java客户端不是二等公民

据我所知，HBase目前具有的主要优势（HBase 0.90.4和Cassandra 0.8.4）是Cassandra尚不支持透明数据压缩。（已在10月初为Cassandra 1.0添加了此功能，但今天对HBase来说是一个真正的优势。）HBase还可针对Hadoop批处理完成的范围扫描进行更好的优化。

还有一些事情不一定更好，或更糟，只是有所不同。HBase更严格地遵循Bigtable数据模型，在该模型中，每个列都隐式地进行了版本控制。Cassandra删除版本控制，而是添加SuperColumns。

希望有帮助！

使用100个节点hBase群集的原因不是因为HBase不能扩展到更大的大小。这是因为以滚动方式进行hBase / HDFS软件升级比较容易，而不会降低您的整个服务。另一个原因是要防止单个NameNode成为整个服务的SPOF。同样，HBase被用于各种服务（不仅是FB消息），因此，基于100个节点的Pod方法，最好使用cookie切割器方法来设置大量HBase群集。数字100是即席，我们没有关注100是否为最优。