大数据那些事(18):亲儿子不如干儿子

这篇再填一下Key-Value Store的坑。

很多时候亲生的不如领养的事情一般不会发生。但是在大数据的世界里,什么都有可能。BigTable和Dynamo是两个最著名的Key-Value Store。它们的实现各有不同,功能各有差异。无论是BigTable还是Dynamo,开源都有对应的实现,分别是HBase和Cassandra。

我们简单回顾一下,BigTable是一个multi-dimension persistent sorted map。其基本核心思想是用chubby来做metadata discovery, Metadata使用一个类似BTree的结构,data则存成tablet,每个tablet的实现是个机遇LSM tree的SSTable。Dynamo本质上是一个distributed hash table,使用的是类似于Chord里面的Hash ring的思想。在这个上面引入了virtual node的概念,使用gossip协议来检测是不是有node活着,以及提供了同时支持strong consistency和eventual consistency的协议。

这两个Key-Value Store的开源产品都有对应的实现,前者是HBase,后者是Cassandra。HBase开始的时候是一个叫Powerset的公司,这个公司是做自然语言搜索的。公司为了能够实现高效率的数据处理,做了HBase。2008年的时候这个公司被卖给了微软。所以一度来说微软其实对HBase都有着很大的影响力。当然实际上以某软的尿性,在08年的时候肯定没把这个当回事。至于后来嘛,卖了公司的人,拿了钱又离开微软了。其实一度Cosmos的解决方案里面之一就考虑过用HBase作为自己的Key-Value Store来做。

Cassandra就更有意思一些,是由两个facebook的员工最开始开发出来的。其中一个还直接参与了Amazon的Dynamo的开发。所以无论从什么角度上来看都非常的根红苗正。只是当时Cassandra在facebook已经部署了,但是后来却被HBase取代了。具体做出决定的人好像是facebook当时的首席构架师。至于原因,据说私下里和其他人说过,他觉得Google的构架更值得信任而亚马逊的构架则不太靠谱。我想Facebook在这个方面可能是开了一个坏头。自己的亲儿子丢掉了不用,捧起了干儿子。

HBase很长一段时间就很受宠了,各大公司纷纷的都开始用HBase。当然应该说HBase是一个挺牛的系统,各方面也都不错。但是Cassandra的design上也有很多非常可取的地方,是HBase所不具备的。只是Facebook对于Google的体系架构的崇拜导致了Facebook开始在内部大规模推广HBase。这在后来无数次Cassandra和HBase到底谁比谁更强的论战里面成为了HBase阵营攻击Cassandra的强有力武器。自己的亲爹都用干儿子了,抛弃亲儿子了,如果亲儿子不是不行的话该怎么解释呢?

这个事情更为有意思的是当Google决定release它自己的BigTable作为Cloud service的时候,Google决定采用兼容HBase的API的方式。当然我们可以理解,这反应了两个方面:第一HBase的确和Google的BigTable基于了非常相似的理念,第二是Google在BigData的世界里事实上已经没有影响力,只能迁就实际的标准来卖自己的产品。无论如何,这既进一步坐实了HBase的江湖地位,也进一步显示了Google商业上的无能。

那么HBase到底有些什么优点呢,是不是全面可以取代Cassandra呢?回答当然是不是的。如果那么样牛13的话,现在已经都是HBase的天下了,根本不存在Cassandra在到处折腾的局面。应该说,这两年来,Cassandra是越来的越活跃了。

HBase的优点很大程度上是BigTable的优点,有strong consistency,写入速度快。是sorted所以对range query支持不错。HBase有很多缺点了,我想简单来说一是工程问题,HBase是一个部署起来非常复杂的系统,有很多的components,需要Zookeeper,需要很多的master和region server。Region Server基本上都是 single point failure。Region failure的迁移时间长等等。这一方面是体系架构的问题,另外一个方面其实也是JAVA作为开发语言带来的一些必然。所以部署和运行HBase都是需要很多投入的。

Cassandra的最大优点显然是因为它的P2P架构。这使得资源的加入和离开变得非常的容易。这其实特别适合在Cloud上用,workload多了就多加点机器,少了就减点。这方面HBase做起来要困难得多。Cassandra基本上不存在single point failure这样一回事。而且Dynamo的design决定了strong consistency和eventual consistency都支持。但是Cassandra对写的latency来说就没有那么的好的保证了。另外对于range query的支持也是基本上做不到有多好的。

这些年来Cassandra是受到越来越多了,尤其Uber开始大量使用以后。我想,究其本质来说还是P2P的结构更灵活。尤其是跨data center的replication这样的东西对Cassandra来说是非常自然的实现,而对HBase则非常的不容易。但是每每开始论战的时候,Facebook那个抛弃亲儿子而用干儿子的论断,就一直都像飘在Cassandra上面的阴影。所以抛弃自己儿子的事情,还是少做的好。
转自:飞总聊IT