090 Cassandra和DataStax的故事

Cassandra是大数据时代中非常具有影响力的一个开源项目,DataStax则是背后支持开源Cassandra并将其商业化的公司。今天我们就来聊一下Cassandra和Datatax的故事。

我们都知道,在大数据发展历史上,谷歌的“三驾马车”:谷歌文件系统、 MapReduce、 BigTable。三者都曾经扮演了非常重要的角色,Hadoop开源生态圈里也有对应的Hadoop文件系统,Hadoop MapReduce和HBase。

但是在大数据发展史上,还有一篇影响力几乎等同于谷歌“三驾马车”的论文。它讲的就是亚马逊发布的Dynamo系统。

2008年,Dynamo系统的作者之一阿维纳什·拉克希曼(Avinash Lakshman),跳槽去了Facebook。跳槽的阿维纳(Avinash)和Facebook网站的另外一个工程师普拉桑特·马利克(Prashant Malik),一起开发了Cassandra,一个Dynamo的开源山寨版。

Cassandra开发出来之后很快就被开源了。早期Facebook对于开源这件事还是非常支持的,但是它开源的Cassandra很快就受到了一次重大的打击,这个打击可以说是十分致命的。

早年的Facebook对于谷歌技术非常崇拜,但对于亚马逊的技术却缺乏信心。于是Facebook准备开发移动App“Messenger”的时候,决定使用谷歌的技术架构。更明确一点说就是,Facebook抛弃了自己开发的Cassandra,选择了当时在Hadoop系统里山寨了BigTable的HBase。

亲儿子被自己的公司抛弃,开发人员也没什么兴趣继续开发了。与被众心捧月的HBase状态比起来,Cassandra当时就是一种被众人嫌弃的状态,不过,如果故事到此为止的话,那么Cassandra估计也就不会活到今天了。

我们把时光回溯到2010年,当时在Rackspace工作的乔纳森·艾利斯(Jonathan Ellis)和马特·皮菲尔(Matt Pfeil),这两个和Cassandra无关的人,决定离开Rackspace,自己创业。

Rackspace在工业界里最为著名的是OpenStack那一套体系,做的是数据中心云计算的基础架构。算起来和Cassandra这套NoSQL的东西多少也有点关系。

他们创业的故事非常有意思,同时也跟Cassandra有着千丝万缕的联系,公开的说法是这样的。

乔纳森是个很牛的工程师,决定结束碌碌无为的工作状态,辞职创业去。马特代表公司去挽留这个人才,于是两个人约了去吃午餐;然而结局却颇为戏剧化,马特没有说服乔纳森继续为Rackspace工作,而杰纳森却说服了马特和他一起创业,并让他出任自己公司的CEO。
公司同年成立,最初公司的名字叫Riptano。创业需要有方向,乔纳森和马特看好开源社区商业化的模式,但是他们并没有打算成为Hadoop的发行商,所以环顾四周之后他们挑中了Cassandra,并打算将它做为核心,开启他们的创业之旅。
大概就是因为选取了Cassandra,公司的定位就比较明确了,也就是选择了云端数据处理的方向。于是他们觉得Riptano这个公司的名字不太适合公司的定位,就把公司名字改成了DataStax。这个故事就是DataStax的由来。

自从2010年选中了Cassandra之后,DataStax就开始了全力以赴开发Cassandra的历程。在很长一段时间里,DataStax对Cassandra贡献的代码量,占据了整个代码提交量的85%以上。

可以说,正是因为DataStax的介入,才最终让Cassandra活了下来,并且在2011年成为了Apache基金会的顶级开源项目。DataStax推出的主打产品,是一个叫做DataStax Enterprise的东西。这是一个以Cassandra为核心,整合了诸多开源项目的产品。

DataStax Enterprise提供了两种模式,一种是卖软件和服务给企业,企业再装到自己的机器上去运行。另外一种是托管云服务“DataStax Managed Cloud”,这是一个运行在亚马逊云服务(AWS)上的云托管服务,用户无需购买和维护自己的机器。

从产品完整性和盈利模式来看,DataStax提供的是相对来说比较完整的一套产品体系。但是以Cassandra为核心的主要问题是,Cassandra的技术相对冷门,优点和缺点也都很明显,这导致的结果是:适用于Cassandra的应用也是有一定限制的。

DataStax的产品也因为选择了Cassandra作为核心,和其他公司的同类产品就有很明显的不一样。

具体来说,Cassandra是一个写入非常快、吞吐量很大、延时很低的系统;同时,这个系统的处理能力伴随容量的增长,也呈现出线性的增强。这些都是Cassandra的优势。尤其是做云端部署时,这个系统可以很灵活地根据工作负载来加减机器。

2012年,多伦多大学一篇论文比较研究了6个不同的NoSQL数据库的优劣,得出的结论是Cassandra是当之无愧的赢家。这篇论文被DataStax广泛引用,以此来证明这个系统比其他更为优质。

但是凡事都有两面性,Cassandra的缺点也很明显。首先是Cassandra有一个十分令人讨厌的问题:这个系统没办法保证一条记录行级别的一致性。

简单来说,如果A操作改变了行里面的一个列,B操作改变了同一行里面的另外一列,那么很有可能就得到了一条四不像的行。

这对应用程序来说是一件非常糟糕的事,虽然现实来说这种错误的概率不是特别高,但是只要不是0概率的话,很多应用程序都不可能使用这样的系统。

还有一个缺点是Cassandra普遍适用的场景非常有限,Cassandra虽然对于单行操作非常快,但是对于多行操作就会非常慢;而且不仅仅慢,很可能同时消耗的资源也会很高。

Cassandra对范围查询的能力比起HBase要差了很多。因此,通常来说Cassandra应用的场景适合只访问单行记录的,但是在单行记录的时候却不能保证行级别的一致性。这就是Cassandra适用场景的瓶颈所在。

不过,DataStax发展到了今天,它的主打产品DataStax Enterprise也是经过了多年的演进,并且在以Cassandra为核心的基础上,进行了全面的整合。

例如它通过对Spark和Solr的整合,提供了数据分析和搜索的功能。它还在自我完善中提供了对多种语言和开发平台的支持,比如说Java、Python、Ruby、 C++、Javascript等等。

此外,DataStax Enterprise还提供了给管理员用来做系统监控和操作的OpsCenter,以及给开发者提供的IDE环境 DataStax Studio。

从产品的完善程度来讲,DataStax Enterprise是非常完善的,它是一套整合了开源以及自主开发产品的系统,并提供了开发、运行、部署和监控几乎全方位的支持。这些都是这套系统的优势。

然而,DataStax的发展相对来说不温不火,在业界也只是名气平平。我想,它选择了Cassandra,既给了DataStax足够多的辨识度和区分度,也让DataStax的产品受到了各种限制。至于这样的选择到底是好是坏,对DataStax的发展是否有利,可能只有时间才能说清楚了。

不管怎么样,Cassandra仍然需要感谢DataStax的救命之恩和鼎力支持。可以说没有DataStax,就不会有今天的Cassandra。