大规模数据处理Hbase vs Cassandra

时间:2011-08-29 23:46:12

标签: nosql hadoop cassandra hbase data-processing

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

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

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

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

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

3 个答案:

答案 0 :(得分:116)

作为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。

希望有所帮助!

答案 1 :(得分:91)

试图确定哪一个最适合你真的取决于你将要使用它,它们各自都有自己的优势,没有任何更多的细节它变得更像宗教战争。你引用的帖子也超过一年,从那时起都经历了很多变化。还请记住,我不熟悉最近的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看起来非常有趣,虽然我自己没有使用它,但我听到了很好的东西。

答案 2 :(得分:24)

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