大规模数据处理Hbase vs Cassandra

Question

在研究大规模数据存储解决方案后，我几乎落在了Cassandra。但它普遍认为Hbase是大规模数据处理和分析的更好解决方案。

虽然两者都是相同的键/值存储，并且两者都是/可以运行（最近的Cassandra）Hadoop层，然后在大数据需要处理/分析时，Hadoop成为更好的候选者。

我也发现两者都有很好的细节 http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

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

虽然我对Cassandra更有信心，因为它简单易用，无需添加节点和无缝复制，也没有故障点功能。它还保留了二级索引功能，因此它是一个很好的加分。

Answer 1

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

• 卡珊德拉更好。众所周知，卡桑德拉可以扩展到over 400 nodes in a cluster;当Facebook在HBase上部署Messaging时，他们必须在100-node HBase sub-clusters上对其进行分片。
• Cassandra支持数百甚至数千个ColumnFamilies。 “HBase currently does not do well with anything above two or three column families”。
• 作为一个没有"special" nodes or processes的完全分布式系统，Cassandra为simpler to set up and operate，更容易排除故障，并且更加强大。
• Cassandra对多主复制的支持意味着您不仅可以获得多个数据中心的明显功能 - 地理冗余，本地延迟 - 而且您还可以将实时和分析工作负载分成不同的组，{{3} }。如果你不将这些工作量分开，他们就会非常激烈地竞争。
• 由于每个Cassandra节点都管理自己的本地存储，因此Cassandra具有显着的性能优势，不太可能显着缩小。 （例如，将Cassandra commitlog放在一个单独的设备上是标准做法，这样它就可以不受读取请求中随机i / o的阻碍而进行顺序写入。）
• Cassandra允许您选择您希望它在每个操作基础上要求一致性的强度。有时这被误解为“Cassandra不会给你强烈的一致性”，但这是不正确的。
• Cassandra提供RandomPartitioner以及更像Bigtable的OrderedPartitioner。 RandomPartitioner不太容易出现热点。
• Cassandra提供的堆内或堆外缓存性能与memcached相当，但没有缓存一致性问题或需要额外移动部件的复杂性
• 非Java客户不是二等公民

据我所知，HBase目前的主要优势（HBase 0.90.4和Cassandra 0.8.4）是Cassandra尚不支持透明数据压缩。 （这已经是realtime, bidirectional replication between them，将于10月初发布，但今天这对HBase来说是一个真正的优势。）HBase也可以针对Hadoop批量处理完成的范围扫描进行更好的优化。

还有一些事情不一定更好，或更糟，只是不同。 HBase更严格地遵守Bigtable数据模型，其中每列都是隐式版本化的。 Cassandra删除了版本控制，并添加了SuperColumns。

希望有所帮助！

Answer 2

试图确定哪一个最适合你真的取决于你将要使用它，它们各自都有自己的优势，没有任何更多的细节它变得更像宗教战争。你引用的帖子也超过一年，从那时起都经历了很多变化。还请记住，我不熟悉最近的Cassandra开发。

话虽如此，我会解释HBase提交者Andrew Purtell，并补充一些我自己的经历：

• HBase处于较大的生产环境（1000个节点），尽管这仍然是Cassandra的~400个节点安装的基础，所以它实际上是微不足道的。

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

• 如果您的应用程序需要强一致性，那么HBase可能更适合。它从一开始就设计为一致的。例如，它允许更简单地实现原子计数器（我认为Cassandra只是得到它们）以及检查和放置操作。

• 写作表现非常好，据我所知，这是Facebook与HBase一起使用的原因之一。

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

• Cassandra和HBase都很复杂，Cassandra只是隐藏得更好。 HBase通过使用HDFS进行存储会更多地暴露它，如果你看一下代码库，Cassandra就像分层一样。如果你比较Dynamo和Bigtable论文，你会发现Cassandra的操作理论实际上更复杂。

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

• 所有Cassandra RPC都是Thrift，HBase有Thrift，REST和原生Java。 Thrift和REST只提供总客户端API的一个子集，但如果你想要纯粹的速度，原生Java客户端就在那里。

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

• HBase与传统HDFS无关，您可以根据需要更改底层存储。 MapR看起来非常有趣，虽然我自己没有使用它，但我听到了很好的东西。

Answer 3

使用100个节点hBase群集的原因并不是因为HBase不能扩展到更大的大小。这是因为在不降低整个服务的情况下，以滚动方式进行hBase / HDFS软件升级更容易。另一个原因是防止单个NameNode成为整个服务的SPOF。此外，HBase被用于各种服务（不仅仅是FB消息），谨慎的做法是采用千篇一律的方法来设置基于100节点pod方法的众多HBase集群。数字100是adhoc，我们没有关注100是否是最佳的。