大规模数据处理Hbase vs Cassandra

在我对大型数据存储解决scheme进行研究后,我几乎登上了Cassandra。 但一般来说,Hbase是更好的大规模数据处理和分析解决scheme。

虽然两者都是相同的键/值存储,并且都可以运行(Cassandra最近的)Hadoop层,那么当需要在大数据上进行处理/分析时,Hadoop是一个更好的select。

我也在http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/上find了关于这两方面的很好的细节。

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

虽然我对Cassandra更加确信,因为它增加了节点和无缝复制的简单性以及无故障function。 而且它也保留了二级索引function,所以它是一个很好的补充。

试图确定哪一个最适合你,这取决于你将要使用什么,他们每个人都有自己的优势,没有更多的细节,它更像是一场宗教战争。 你引用的post也是一年多了,从那以后都经历了很多变化。 请记住,我不熟悉最近的卡桑德拉发展。

话虽如此,我会解释一下HBase提交者Andrew Purtell并添加一些我自己的经验:

  • HBase处于较大的生产环境(1000个节点),尽pipe这仍然处于Cassandra的〜400节点的安装位置,所以它实际上是一个很小的差异。

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

  • 如果强大的一致性是您的应用程序需要的,那么HBase可能更适合。 它是从一开始就devise的一致。 例如,它允许更简单地实现primefaces计数器(我认为Cassandra刚刚得到它们)以及Check和Put操作。

  • 写出来的performance非常好,据我所知,这是Facebook与HBase的使者交往的原因之一。

  • 我不确定Cassandra的有序分区的当前状态,但过去需要手动重新平衡。 如果你愿意的话,HBase会为你处理。 有序分区对于Hadoop风格处理非常重要。

  • Cassandra和HBase都很复杂,Cassandra只是把它隐藏得更好。 如果你看看代码库,Cassandra就像分层一样,HBase通过使用HDFS来存储它。 如果你比较Dynamo和Bigtable的论文,你可以看到Cassandra的操作理论实际上更复杂。

  • HBase有更多的unit testingFWIW。

  • 所有Cassandra RPC都是Thrift,HBase有Thrift,REST和本地Java。 Thrift和REST只提供了整个客户端API的一个子集,但是如果您想要纯粹的速度,那么本地Java客户端就在那里。

  • 对等和主从两者都有优点。 主 – 从设置通常使得debugging变得更容易,并且降低了相当多的复杂性。

  • HBase并不仅限于传统的HDFS,您可以根据自己的需要更换底层存储。 MapR看起来很有趣,虽然我自己没有用过,但我听到了很好的东西。

作为Cassandra的开发者,我最好回答问题的另一面:

  • 卡桑德拉更好地扩展。 已知Cassandra可以扩展到集群中的400多个节点 。 当Facebook在HBase之上部署消息传递时,他们不得不将其分散在100个节点的HBase子集群中 。
  • Cassandra支持数百甚至数千个ColumnFamilies。 “ HBase目前对于两三列以上的任何产品都不太合适 。”
  • 作为一个没有“特殊”节点或进程的完全分布式系统,Cassandra的设置和操作更简单 ,更容易排除故障,并且更加健壮。
  • Cassandra对多主复制的支持意味着您不仅可以获得多个数据中心(地理冗余,本地延迟)的显着function,还可以将实时和分析工作负载分为不同的组,并在其间实时进行双向复制 。 如果你不把这些工作量分开,他们将会非常激烈地竞争。
  • 由于每个Cassandra节点都pipe理着自己的本地存储,所以Cassandra具有很大的性能优势,不太可能显着缩小。 (例如,将Cassandra提交日志放在一个单独的设备上是一种标准的做法,这样它就可以通过读取请求中的随机I / O来完成顺序写入操作。)
  • Cassandra允许你select你想要的一致性是多么强大,以每个操作为基础。 有时候这被误解为“卡桑德拉不能给你强大的一致性”,但这是不正确的。
  • Cassandra提供RandomPartitioner以及更多的Bigtable-like OrderedPartitioner。 RandomPartitioner不太容易出现热点。
  • Cassandra提供了可以与memcached相媲美的堆内或堆外caching,但没有caching一致性问题或需要额外移动部件的复杂性
  • 非Java客户不是二等公民

据我所知,HBase现在的主要优势(HBase 0.90.4和Cassandra 0.8.4)是Cassandra还不支持透明数据压缩。 ( Cassandra 1.0中已经添加了这个function,因为在10月初,但是现在这对于HBase来说是一个真正的优势)。对于Hadoop批处理完成的各种范围扫描,HBase也可能会得到更好的优化。

还有一些事情不一定更好,或者更糟糕,只是不同而已。 HBase更严格地遵守Bigtable数据模型,其中每列都隐含地版本化。 Cassandra删除版本,并添加SuperColumns。

希望有所帮助!

使用100个节点hBase集群的原因并不是因为HBase不能缩放到更大的大小。 这是因为以滚动方式进行hbase / hdfs软件升级更容易,而不会影响整个服务。 另一个原因是阻止单个NameNode成为整个服务的SPOF。 同时,HBase也被用于各种服务(不仅仅是FB消息),而且在基于100节点的pod方法的基础上设置大量的HBase集群,这是谨慎的。 数字100是adhoc,我们没有把重点放在100是否是最优的。