Hbase vs Cassandra的大规模数据处理

作者: 春风助手
发布时间: 2024-01-05 05:47:15 (4月前)

2 条回复

1#
回复此人
只怕再见是故人 | 2020-08-13 18-34

试图确定最适合您的方法实际上取决于您要使用它的目的，它们各有优势，而没有任何更多细节，这更像一场宗教战争。您引用的帖子也已有一年多的历史了，从那以后都经历了许多变化。也请记住，我不熟悉Cassandra的最新发展。话虽如此，我将解释HBase提交人Andrew Purtell，并添加一些我自己的经验： HBase处于较大的生产环境（1000个节点）中，尽管仍处于Cassandra约400个节点安装的范围之内，所以它的确是微不足道的。 HBase和Cassandra都支持群集/数据中心之间的复制。我相信HBase的暴露给用户更多，因此看起来更加复杂，但同时您也可以获得更大的灵活性。如果您的应用程序需要强大的一致性，那么HBase可能更合适。它是从头开始设计的，目的是保持一致。例如，它允许原子计数器（我认为Cassandra刚得到它们）和Check and 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看起来很有趣，尽管我自己没有使用过它，但我听到了很多好消息。

编辑

登录后才能参与评论