大规模数据处理Hbase vs Cassandra

在我对大规模数据存储解决方案进行研究后，我几乎登陆Cassandra。但是它一般说Hbase是更好的大规模数据处理和分析解决方案。大规模数据处理Hbase vs Cassandra

虽然两者都是相同的键/值存储和均为/可运行（卡桑德拉最近）的Hadoop层然后是什么使Hadoop的更好的候选时，需要对大量的数据处理/分析。

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

良好的细节，但我仍然在寻找HBase的具体优势。

虽然我更加坚信有关卡桑德拉，因为它添加节点和无缝复制和没有一点破坏特征简单。它还保留了二级索引功能，所以它是一个很好的补充。

来源

2011-08-29 Gary Lindahl

试图确定哪个最适合你，这取决于你将要使用它的原因，他们每个人都有自己的优势，没有更多的细节，它变得更像是一场宗教战争。你引用的这篇文章也超过了一年，从那以后都经历了许多变化。请记住，我不熟悉最近的Cassandra开发。

话虽如此，我会转述HBase的提交者安德鲁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看起来很有趣，我听说过好东西，虽然我没有用过它自己。

来源

2011-08-31 02:14:07 cftarnas

112

作为卡桑德拉开发者，我在回答这个问题的另一面更好：

卡桑德拉更好地伸缩。已知Cassandra的规模为over 400 nodes in a cluster;当Facebook在HBase之上部署消息传递时，他们不得不在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的多主复制的支持，意味着你不仅获得多个数据中心的明显的权力 - 地理冗余，当地的延迟 - 但你也可以实时和分析工作负载分成不同的组，与realtime, bidirectional replication between them。如果你不将这些工作量分开，他们将会非常激烈地竞争。
因为每个Cassandra节点都管理自己的本地存储，所以Cassandra具有显着的性能优势，不太可能显着缩小范围。（例如，它是标准的做法，把卡桑德拉commitlog一个单独的设备上，因此它可以做它的随机I /读取请求畅通Ø顺序写。）
卡桑德拉允许你选择你想有多强，它要求一致性以每个操作为基础。有时候这会被误解为“Cassandra不会给你强大的一致性”，但这是不正确的。
Cassandra提供RandomPartitioner以及更类似Bigtable的OrderedPartitioner。 RandomPartitioner不太容易出现热点。
卡桑德拉提供与性能堪比memcached的现场或非堆缓存，但没有高速缓存一致性问题或需要额外的移动部件
非Java客户端的复杂性不是二等公民

据我所知，HBase现在的主要优势（HBase 0.90.4和Cassandra 0.8.4）是Cassandra尚不支持透明数据压缩。（这已经是added for Cassandra 1.0，将在10月初发布，但今天这对HBase来说是一个真正的优势。）对于Hadoop批处理完成的各种范围扫描，HBase也可能会得到更好的优化。

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

希望有帮助！

来源

2011-08-30 04:48:05 jbellis

+13

我很确定Facebook会因为与模块化软件堆栈相关的其他原因在100个节点HBAse群集中分片。在最近的一次演讲中，来自Cloudera的Todd Lipcon提到[1PT 1000节点HBase簇]（http://www.slideshare.net/cloudera/sf-nosql2011/58），并且我已经提到了700多个节点的HBase簇。 – cftarnas

好点。这也可能是特定工作负载。 – jbellis

上面有很多Cassandra的优点。但为什么Facebook最终选择HBase而不是Cassandra？ –

使用100个节点hBase集群的原因并不是因为HBase不能扩展到更大的大小。这是因为以滚动方式进行hbase/HDFS软件升级更容易，而不会降低您的整个服务。另一个原因是阻止单个NameNode成为整个服务的SPOF。此外，HBase正在用于各种服务（不仅仅是FB消息），并且在基于100节点pod方法的基础上设置大量HBase集群的方法是谨慎的。数字100是adhoc，我们没有专注于100是否是最优的。

来源

2011-08-30 17:13:20 dhruba

大规模数据处理Hbase vs Cassandra

回答

相关问题