大规模数据处理 Hbase vs Cassandra [关闭]

Posted 2023-02-16

【中文标题】大规模数据处理 Hbase vs Cassandra [关闭]

【英文标题】：Large scale data processing Hbase vs Cassandra [closed]

【发布时间】：2011-11-06 10:14:50

【问题描述】：

在完成对大规模数据存储解决方案的研究之后，我差点进入 Cassandra。但它普遍认为 Hbase 是大规模数据处理和分析的更好解决方案。

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

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

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

虽然我更相信 Cassandra，因为它可以简单地添加节点和无缝复制，并且没有故障点功能。而且它还保留了二级索引功能，所以它是一个很好的加分项。

【参考方案1】：

作为一名 Cassandra 开发人员，我更擅长回答问题的另一面：

Cassandra 可以更好地扩展。 Cassandra 可以扩展到over 400 nodes in a cluster；当 Facebook 在 HBase 之上部署 Messaging 时，他们必须将其分片到 100-node HBase sub-clusters。 Cassandra 支持数百甚至数千个列族。 “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 具有显着的性能优势，这种优势不太可能显着缩小。 （例如，标准做法是将 Cassandra 提交日志放在单独的设备上，这样它就可以不受来自读取请求的随机 i/o 的阻碍进行顺序写入。） Cassandra 允许您选择您希望它在每个操作基础上要求一致性的强度。有时这会被误解为“Cassandra 不会为您提供强一致性”，但这是不正确的。 Cassandra 提供了 RandomPartitioner 以及更类似于 Bigtable 的 OrderedPartitioner。 RandomPartitioner 不太容易出现热点。 Cassandra 提供堆内或堆外缓存，其性能与 memcached 相当，但没有缓存一致性问题或需要额外移动部件的复杂性 非 Java 客户端不是二等公民

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

还有一些事情不一定更好，或者更糟，只是不同而已。 HBase 更严格地遵守 Bigtable 数据模型，其中每列都隐式进行版本控制。 Cassandra 放弃了版本控制，而是添加了 SuperColumns。

希望有帮助！

【讨论】：

我很确定 Facebook 分片跨越 100 个节点 HBAse 集群，原因与他们的模块化软件堆栈相关。在 Cloudera 的 Todd Lipcon 最近的一次谈话中，提到了 1PT 1000 node HBase clusters，我看到提到了 700 多个节点 HBase 集群。

好点。它也可能是特定于工作负载的。

这么多Cassandra的优势。但为什么 Facebook 最终选择了 HBase 而不是 Cassandra！？

（a）消息传递团队中的人员已经熟悉 Hadoop 和 HBase，（b）对 Cassandra 的一致性模型了解不足，以及（c）没有联系 Apache Cassandra 社区帮助（b）。最近，像 Instagram 和 Parse 这样的 Facebook 部门选择了 Cassandra：planetcassandra.org/blog/post/…planetcassandra.org/blog/post/…

【参考方案2】：

尝试确定哪个最适合您实际上取决于您要使用它的用途，它们各有优势，如果没有更多细节，它就会变成一场宗教战争。你引用的那篇文章也有一年多的历史，从那时起都经历了很多变化。另请记住，我不熟悉 Cassandra 最近的发展。

话虽如此，我将解释 HBase 提交者 Andrew Purtell 并添加一些我自己的经验：

HBase 处于较大的生产环境（1000 个节点）中，尽管这仍处于 Cassandra 大约 400 个节点安装的范围内，因此它确实是一个微小的差异。

HBase 和 Cassandra 都支持集群/数据中心之间的复制。我相信 HBase 向用户展示了更多内容，因此它看起来更复杂，但您也获得了更大的灵活性。

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

写入性能非常好，据我了解，这也是 Facebook 选择 HBase 作为其 Messenger 的原因之一。

我不确定 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 看起来挺有意思的，虽然我自己没用过，但是听说过不错的东西。

【讨论】：

我们使用 MapR 作为 HBase 的替代品。我们煞费苦心地迁移到 MapR。 MapR 存在严重的性能问题。在 mapR 中按键查找有时需要 17 秒！支持团队超级没用

【参考方案3】：

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