大规模数据处理Hbase vs Cassandra

Gar*_*hl 83 hadoop hbase data-processing cassandra nosql

在研究了大规模数据存储解决方案之后,我几乎落在了卡桑德拉.但它普遍认为Hbase是大规模数据处理和分析的更好解决方案.

虽然两者都是相同的键/值存储,并且两者都是/可以运行(最近的Cassandra)Hadoop层,但是当大数据需要处理/分析时,Hadoop是更好的候选者.

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

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

虽然我更加信服Cassandra,因为它简单易用,无需添加节点和无缝复制,也没有故障点功能.它还保留了二级索引功能,因此它是一个很好的优点.

jbe*_*lis 116

作为Cassandra开发人员,我更擅长回答问题的另一面:

  • 卡桑德拉鳞片更好.众所周知,Cassandra可扩展到集群中的400多个节点 ; 当Facebook在HBase上部署Messaging时,他们不得不在100节点的HBase子集群中对其进行分片.
  • Cassandra支持数百甚至数千个ColumnFamilies." HBase目前对两个或三个色谱柱系列的产品效果不佳."
  • 作为一个没有"特殊"节点或进程的完全分布式系统,Cassandra 更易于设置和操作,更易于排除故障,并且更加强大.
  • Cassandra对多主复制的支持意味着您不仅可以获得多个数据中心的明显功能 - 地理冗余,本地延迟 - 而且您还可以将实时和分析工作负载分成不同的组,并在它们之间进行实时双向复制.如果你不将这些工作量分开,他们将会非常激烈地抗衡.
  • 由于每个Cassandra节点都管理自己的本地存储,因此Cassandra具有显着的性能优势,不太可能显着缩小.(例如,将Cassandra commitlog放在一个单独的设备上是标准做法,这样它就可以不受读取请求中随机i/o的阻碍而进行顺序写入.)
  • Cassandra允许您选择您希望它在每个操作基础上要求一致性的强度.有时这被误解为"Cassandra不会给你强烈的一致性",但这是不正确的.
  • Cassandra提供RandomPartitioner以及更像Bigtable的OrderedPartitioner.RandomPartitioner不太容易出现热点.
  • Cassandra提供堆栈或堆外缓存,其性能可与memcached相媲美,但没有缓存一致性问题或需要额外移动部件的复杂性
  • 非Java客户端不是二等公民

据我所知,HBase目前的主要优势(HBase 0.90.4和Cassandra 0.8.4)是Cassandra尚不支持透明数据压缩.(这已经在10月初的Cassandra 1.0中添加,但今天这对HBase来说是一个真正的优势.)HBase也可以针对Hadoop批量处理完成的范围扫描进行更好的优化.

还有一些事情不一定更好,或更糟,只是不同.HBase更严格地遵守Bigtable数据模型,其中每列都是隐式版本化的.Cassandra删除了版本控制,并添加了SuperColumns.

希望有所帮助!

  • 由于与模块化软件堆栈相关的其他原因,我非常肯定Facebook会对100个节点HBAse群集进行分片.在最近的一次谈话中,来自Cloudera的Todd Lipcon提到[1PT 1000节点HBase集群](http://www.slideshare.net/cloudera/sf-nosql2011/58),我已经看到提到700多个节点HBase集群. (13认同)
  • (a)消息传递团队的人员已经熟悉Hadoop和HBase,(b)对Cassandra的一致性模型了解不足,(c)没有联系Ap​​ache Cassandra社区寻求(b)的帮助.最近,像Instagram和Parse这样的Facebook部门选择了卡桑德拉:http://planetcassandra.org/blog/post/instagram-making-the-switch-to-cassandra-from-redis-75-instasavings http:// planetcassandra.组织/博客/后/卡桑德拉 - 来 - 家庭 - Facebook的 - 解析 - 据法权产卡桑德拉换移动应用开发平台 (5认同)
  • 上面说了这么多 Cassandra 的优点。但为什么 Facebook 最终选择了 HBase 而不是 Cassandra!? (2认同)

cft*_*nas 90

试图确定哪一个最适合你,取决于你将要使用它,它们各自都有自己的优势,没有任何更多的细节,它变得更像是一场宗教战争.你引用的帖子也超过一年,从那时起都经历了很多变化.请记住,我不熟悉最近的Cassandra开发.

话虽如此,我会解释HBase提交者Andrew Purtell并添加我自己的一些经验:

  • HBase处于较大的生产环境(1000个节点),尽管这仍然是Cassandra的~400节点安装的基础,所以它真的是一个微小的差异.

  • HBase和Cassandra都支持集群/数据中心之间的复制.我相信HBase更多地暴露给用户,因此它看起来更复杂但是你也获得了更多的灵活性.

  • 如果您的应用程序需要强一致性,那么HBase可能更适合.它从一开始就设计为一致的.例如,它允许更简单的原子计数器实现(我认为Cassandra只是得到它们)以及Check和Put操作.

  • 写作表现很棒,据我所知,这是Facebook与HBase一起使用的原因之一.

  • 我不确定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看起来很有趣,虽然我自己没有使用它,但我听到了很好的东西.


小智 23

使用100个节点hBase群集的原因不是因为HBase不能扩展到更大的大小.这是因为在不降低整个服务的情况下,以滚动方式进行hBase/HDFS软件升级更容易.另一个原因是防止单个NameNode成为整个服务的SPOF.此外,HBase被用于各种服务(不仅仅是FB消息),谨慎的做法是采用千篇一律的方法来设置基于100节点pod方法的众多HBase集群.数字100是adhoc,我们没有关注100是否是最佳的.