Cassandra Vs HBase

阅读更多

Cassandra vs HBase
By Vaibhav Puranik Translated By Jametong

我们是一家广告网络公司.我们需要存储展示与点击信息.我们在为我们的新项目评估多个不同的大批量数据(或nosql,或任何你喜欢的称呼)系统.过去8个月中,我们一直在一个测试产品上使用HBase,并且满意它的表现,但是,最近Cassandra的风头很高,因此,我们决定对它做个测试.我认为,从某些角度讲,Cassandra团队的推广做的很不错.你将发现,在Santa Monica，哪怕是非技术人员(诸如风险投资商、CEO以及产品经理)也会相互推荐使用Cassandra.

Cassandra给人的第一印象很好.它们的首页看上去比HBase更加专业也更加友好.安装并运行它也很简单.这个网站的文档很丰富.说实在话,安装并让其工作只花费了我5分钟的时间.

真正的挑战是理解Cassandra的数据模型,并尝试在我们的使用场景中实现它.我们很清楚如何在HBase中实现它,因为我们对HBase有相当不错的使用经验.虽然Cassandra也是从BigTable出继承了同样的数据模型,Cassandra与HBase之间还是有一些根本性的不同的.我试图用表格整理了两个系统之间的差异,如下:
            
                               

Cassandra HBase

缺少类似于表的概念.所有的文档都告诉你,有多个Keyspace的情况不常见.这意味着你必须在一个集群中共享同一个key space.另外,新增keyspace需要重启集群才能生效.	存在表相关的概念.每个表都有它自己的key space. 这一点对我们来说很重要.添加/删除表都很容易,跟在RDBMS中一样.
使用字符串的Key.通常使用uuid作为Key.如果希望你的数据按照时间排序,可以使用TimeUUID.	使用二进制Key.通常将三个不同的项目组合在一起来构建一个Key.这意味着你可以搜索一个给定表中的多个键.
即使使用TimeUUID,也不会发生热点问题,因为Cassandra会对客户端请求做负载均衡.	如果Key的第一部分是时间或者序列数,就会发生热点问题.所有新的Key都会被插入同一个区域,一直到此区域被塞满(因而导致出现热点问题).
支持列排序	不支持列排序
超列(Super Column)概念使得你可以设计非常灵活也非常复杂的表结构.	不支持超列.不过可以设计一个类似与超列的结构,不过列名称与值都是二进制的.
没有便捷的方法来自增长一个列的值.实际上,最终一致性的不同特性使得更新/写入一条记录并在更新后立即读出非常困难.必须确保使用R+W>N来实现强一致性.	由于设计上就是一致性.提供了一个非常便捷的方法来自增计数器.非常适合做数据汇总.
刚开始支持Map Reduce接口.还需要有一个hadoop集群来运行它.需要将数据从Cassandra集群迁移到Hadoop集群.不适合对大型数据运行map reduce任务.	对Map Reduce的支持是原生的.HBase构建在Hadoop集群上.数据不需要做迁移.
如果不需要Hadoop的话,维护相对简单.	由于包含多个诸如Zookeeperr、Hadoop以及HBase本身的可活动组件，维护相对复杂.
到目前为止,还没有本地化的Java Api支持.没有Java文档.虽然是使用Java编写的,你还是必须用Thrift接口来与集群进行通讯.	有友好的本地Java API.比Cassandra更像是Java系统.由于我们的应用是基于Java的,这一点对我们很重要.
没有主节点,因此也没有单点故障.	虽然在概念上有一个主节点服务,HBase本身对它的依赖并不严重.即使在主节点宕机的情况下,HBase集群仍然可以正常提供数据服务.Hadoop的Namenode是一个单点故障.

在按照这种方式比较过数据模型与相关特性后,对我们来讲,HBase是明显的优胜者.我的看法是,如果你确实需要一致性,HBase是一个明显的选择.更进一步,本地化的Map Reduce支持、表概念以及可修改而且不用重启集群的简单的表结构是你不可忽略的加分项.HBase是一个更加成熟的平台.当人们说Twitter、Facebook在使用Cassandra时,他们忘记了这些公司同时也在使用HBase.实际上,Facebook最近雇用了一个HBase的代码提交者(Commiter),这清楚地表明Facebook对HBase的兴趣.

总之,我们全力支持HBase!!