85

在研究了大规模数据存储解决方案之后，我差一点就来到了 Cassandra。但它普遍认为 Hbase 是大规模数据处理和分析的更好解决方案。

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

我还在 http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/找到了关于两者的详细信息

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

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

4

3 回答 3

117

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

  • Cassandra 的扩展性更好。众所周知，Cassandra 可以扩展到集群中的 400 多个节点；当 Facebook 在 HBase 上部署 Messaging 时，他们必须将其分片到100 个节点的 HBase 子集群中。
  • Cassandra 支持数百甚至数千个 ColumnFamilies。“ HBase 目前不能很好地处理超过两三个列族的任何内容。”
  • 作为一个没有“特殊”节点或进程的完全分布式系统，Cassandra更易于设置和操作，更容易排除故障，并且更健壮。
  • Cassandra 对多主复制的支持意味着您不仅可以获得多个数据中心的明显功能——地理冗余、本地延迟——而且还可以将实时和分析工作负载分成不同的组，在它们之间进行实时、双向复制。如果您不将这些工作负载分开，它们将进行激烈的竞争。
  • 由于每个 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 尚不支持透明数据压缩。（这已为 Cassandra 1.0 添加，将于 10 月初发布，但今天这对 HBase 来说是一个真正的优势。）HBase 还可以更好地针对 Hadoop 批处理完成的范围扫描进行优化。

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

希望有帮助！

于 2011-08-30T04:48:05.997 回答
91

尝试确定哪个最适合您实际上取决于您将使用它的目的，它们各有优势，如果没有更多细节，它就更像是一场宗教战争。你引用的那篇文章也有一年多的历史，从那时起都经历了很多变化。还请记住，我不熟悉 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看起来很有趣，虽然我自己没有使用过，但我听说了一些好东西。

于 2011-08-31T02:14:07.413 回答
23

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

于 2011-08-30T17:13:20.520 回答