大规模数据处理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是否是最优的。
