[转载] HBase vs Cassandra：咱们迁移系统的缘由

转载自http://www.csdn.net/article/2010-11-29/282698

个人团队近来正在忙于一个全新的产品——即将发布的网络游戏www.FightMyMonster.com。这让咱们得以奢侈地去构建一个全新的NOSQL数据库，也就是说，咱们能够把恐怖的MySQL sharding和昂贵的可伸缩性抛在脑后了。最近有不少人一直在问，为何咱们要把注意力从HBase上转移到Cassandra上去。我确认，确实有这样的变化，实际上咱们基本上已经把代码移植到了Cassandra上了，这里我将给出解释。

为了那些不熟悉NOSQL的读者，后面的其余文章中，我会介绍为何咱们将会在将来几年中看到地震式的从SQL到NOSQL的迁移，这正和向云计算的迁移同样重要。后面的文章还会尝试解释为何我认为NOSQL可能会是贵公司的正确选择。不过本文我只是解释咱们选择Cassandra做为咱们的NOSQL解决方案的选择。

免责声明——若是你正在寻找一个捷径来决定你的系统选择，你必需要明白，这可不是一个详尽而严格的比较，它只是概述了另外一个初创团队在有限时间和资源的状况下的逻辑。

Cassandra的血统是否预言了它的将来

我最喜欢的一个工程师们用来找bug的谒语是“广度优先而非深度优先”。这能够可能对那些解决技术细节的人来讲很恼人，由于它暗示着若是他们只是看看的话，解决方法就会简单不少（忠告：只对那些可以原谅你的同事说这个）。我造出这个谒语的缘由在于，我发现，软件问题中，若是咱们强迫咱们本身在进入某行代码的细节层面以前，先去看看那些高层次的考虑的话，能够节省大量时间。

因此，在谈论技术以前，我在作HBase和Cassandra之间的选择问题上先应用一下个人箴言。咱们选择切换的技术结论可能已经能够预测了：Hbase和Cassandra有着迥异的血统和基因，而我认为这会影响到他们对咱们的业务的适用性。

严格的说，Hbase 和它的支持系统源于著名的Google BigTable和Google文件系统设计（GFS的论文发于2003年，BigTable的论文发于2006年）。而 Cassandra 则是最近Facebook的数据库系统的开源分支，她在实现了BigTable的数据模型的同时，使用了基于Amazon的Dynamo的系统架构来存储数据（实际上，Cassandra的最初开发工做就是由两位从Amazon跳槽到Facebook的Dynamo工程师完成的）。

在我看来，这些不一样的历史也致使Hbase更加适合于数据仓库、大型数据的处理和分析（如进行Web页面的索引等），而Cassandra则更适合于实时事务处理和提供交互型数据。要进行系统研究来证实这个观点超出了本文的范畴，但我相信你在考虑数据库的时候总能发现这个差别的存在。

注意：若是你在寻找一个简单的证实，你能够经过主要committer的关注点来进行验证：大部分HBase的committer都为Bing工做（M$去年收购了他们的搜索公司，并容许他们在数月以后继续提交开源代码）。与之对应，Cassandra的主要committer来自Rackspace，用来能够自由得到的支持先进的通用的NOSQL的解决方案，用来和Google, Yahoo, Amazon EC2等提供的那些锁定在专有的NOSQL系统的方案相抗衡。

Malcolm Gladwell会说只是根据这些背景的不一样就能够简单地选择了Cassandra。不过这是小马过河的问题。但固然，闭着眼睛就进行一个商业选择是至关困难的......

哪一个 NOSQL数据库风头更劲?

另外一个说服咱们转向Cassandra的缘由是咱们社区中的大风向。如你所知，软件平台行业里，大者恒大——那些被广泛看好的平台，会有更多人汇集在这个平台周围，因而，从长远看，你能够获得更好的生态系统的支持（也就是说，大部分支持的软件能够从社区中得到，也有更多的开发者能够雇佣）。

若是从HBase开始时，个人印象就是它后面有巨大的社区力量，但我如今相信，Cassandra更增强大。最初的印象部分来源于StumpleUpon和Streamy的两位CTO的两个很是有说服力的出色的讲演，他们是Web行业中两个在Cassandra成为一个可选系统以前的HBase的两个重要的贡献者，同时也部分来源于快速阅读了一篇名为“HBase vs Cassandra：NoSQL战役！”的文章（大部份内容都被普遍证明了）。

势头是很难确证的，你不得不本身进行研究，不过我能够找到的一个重要的标志是IRC上的开发者动向。若是你在 freenode.org 上比较#hbase和#cassandra的开发这频道，你会发现Cassandra差很少在任什么时候候都有两倍的开发者在线。

若是你用考虑HBase通常的时间来考察Cassandra，你就能发现Cassandra的背后确实有很是明显的加速势头。你可能还会发现那些逐渐出现的鼎鼎大名，如 Twitter，他们也计划普遍使用Cassandra（这里）。

注：Cassandra的网站看起来比HBase的好看多了，但认真的说，这可能不只是市场的趋势。继续吧。

深刻到技术部分:CAP和CA与AP的神话

对于分布式系统，有个很是重要的理论（这里咱们在讨论分布式数据库，我相信你注意到了）。这个理论被称为CAP理论，由Inktomi的联合创始人兼首席科学家Eric Brewer博士提出。

这个理论说明，分布式（或共享数据）系统的设计中，至多只可以提供三个重要特性中的两个——一致性、可用性和容忍网络分区。简单的说，一致性指若是一我的向数据库写了一个值，那么其余用户可以马上读取这个值，可用性意味着若是一些节点失效了，集群中的分布式系统仍然能继续工做，而容忍分区意味着，若是节点被分割成两组没法互相通讯的节点，系统仍然可以继续工做。

Brewer教授是一个杰出的人物，许多开发者，包括HBase社区的不少人，都把此理论牢记在心，并用于他们的设计当中。事实上，若是你搜索线上的关于HBase和Cassandra比较的文章，你一般会发现，HBase社区解释他们选择了CP，而Cassandra选择了AP——毫无疑问，大多数开发者须要某种程度的一致性（C）。

不过，我须要请你注意，事实上这些生命基于一个不彻底的推论。CAP理论仅仅适用于一个分布式算法（我但愿Brewer教授能够统一）。但没有说明你不能设计一个系统，在其中的各类操做的底层算法选择上进行这种。因此，在一个系统中，确实一个操做职能提供这些特性中的两个，但被忽视的问题是在系统设计中，实际是能够容许调用者来选择他们的某个操做时须要哪些特性的。不只如此，现实世界并不简单的划分为黑白两色，全部这些特性均可以以某种程度来提供。这就是Cassandra。

这点很是重要，我重申：Cassandra的优势在于你能够根据具体状况来选择一个最佳的折衷，来知足特定操做的需求。Cassandra证实，你能够超越一般的CAP理论的解读，而世界仍然在转动。

咱们来看看两种不一样的极端。好比我必须从数据库中读取一个要求具备很高一致性的值，也就是说，我必须100%保证可以读取到先前写入的最新的内容。在这种状况下，我能够经过指定一致性水平为“ALL”来从Cassandra读取数据，这时要求全部节点都有数据的一致的副本。这里咱们不具备对任何节点失效和网络分裂的容错性。在另外一个极端的方面，若是我不特别关心一致性，或仅仅就是但愿最佳性能，我可使用一致性级别“ONE”来访问数据。在这种状况下，从任意一个保存有这个副本的节点获取数据均可以——即便数据有三个副本，也并不在乎其余两个有副本的节点是否失效或是否有不一样，固然，这种状况下咱们读到的数据可能不是最新的。

不只如此，你没必要被迫生活在黑白世界中。好比，在咱们的一个特定的应用中，重要的读写操做一般使用“QUORUM”一致性级别，这意味着大部分存有此数据的节点上的副本是一致的——我这里是个简要描述，具体写你的Cassandra程序以前最好仍是仔细研究一下。从咱们的视角看，这这提供了一个合理的节点失效与网络分裂的耐受性，同时也提供了很高的一致性。而在通常状况下，咱们使用前面提到的“ONE”一致性级别，者能够提供最高的性能。就是这样。

对咱们来讲，这是Cassandra的一个巨大的加分项目。咱们不只能轻易地调整咱们的系统，也能够设计它。好比，当必定数量的节点失效或出现网络链接故障时，咱们的大部分服务仍然能够继续工做，只有那些须要数据一致性的服务会失效。HBase并无这么灵活，它单纯地追求系统的一个方面（CP），这让我再次看到了SQL开发者和查询优化人员们之间的那道隔阂——有些事情最好可以超越它，HBase！

In our project then, Cassandra has proven by far the most flexible system, although you may find your brain at first loses consistency when considering your QUORUMs.在咱们的项目以后，卡桑德拉已被证实是迄今为止最灵活的系统，虽然你可能发现一致性第一失去你的大脑在考虑您的法定人数。

在咱们的项目中，Cassandra 已经证实了它是有史以来最灵活的系统，虽然你可能在对这个问题进行投票（QUORUM）的时候发现的大脑失去了一致性。

何时单体会比模块化强？

Cassandra和HBase的一个重要区别是，Cassandra 在每一个节点是是一个单Java进程，而完整的HBase解决方案却由不一样部分组成：有数据库进程自己，它可能会运行在多个模式；一个配置好的Hadoop HDFS分布式文件系统，以及一个Zookeeper系统来协调不一样的HBase进程。那么，这是否意味着HBase有更好的模块化结构呢？

虽然 HBase的这种架构可能确实能够平衡不一样开发团队的利益，在系统管理方面，模块化的HBase却没法视为一个加分项目。事实上，特别是对于一些小的初创公司，模块化却是一个很大的负面因素。

HBase的下层至关复杂，任何对此有疑惑的人应该读读Google的GFS和BigTable的论文。即便是在一个单一节点的伪分布式模式下来架设HBase也很困难——事实上，我曾经费力写过一篇快速入门的教程（若是你要试试HBase的话看看这里）。在这个指南里你能够看到，设置好HBase并启动它实际包含了两个不一样系统的手工设置：首先是Hadoop HDFS，而后才是HBase自己。

而后，HBase的配置文件自己就是个怪兽，而你的设置可能和缺省的网络配置有极大的不一样（在文章里我写了两个不一样的Ubuntu的缺省网络设置，以及EC2 里易变的Elastic IP和内部分配的域名）。当系统工做不正常的时候，你须要查看大量的日志。全部的须要修复的东西的信息都在日志里，而若是你是一个经验丰富的管理员的话，就能发现并处理问题。

可是，若是是在生产过程当中出现问题，而你又没有时间耐心查找问题呢？若是你和咱们同样，只有一个小的开发团队却有远大的目标，没有经历去7*24的进行系统监控管理会怎么样呢？

严肃地说，若是你是一个但愿学习NoSQL系统的高级DB管理员的话，那么选择HBase。这个系统超级复杂，有灵巧双手的管理员确定能拿到高薪。

可是若是大家是一个向咱们同样尽力去发现隧道尽头的小团队的话，仍是等着听听别的闲话吧

胜在 Gossip！

Cassandra是一个彻底对称的系统。也就是说，没有主节点或像HBase里的region server这样的东西——每一个节点的角色是彻底同样的。不会有任何特定的节点或其余实体来充当协调者的角色，集群中的节点使用称为“Cossip”的纯P2P通讯协议来协调他们的行为。

对Gossip的详细描述和使用Gossip的模型超过了本文的内容，但Cassandra所采用的P2P通讯模型都是论证过的，好比发现节点失效的消息传播到整个系统的时间，或是一个客户应用的请求被路由到保存数据的节点的时间，全部这些过程所消耗的时间都毫无疑问的很是的短。我我的相信，Cassandra表明了当今最振奋的一种P2P技术，固然，这和你的NOSQL数据库的选择无关。

那么，这个基于Gossip的架构究竟给Cassandra用户带来什么显示的好处呢。首先，继续咱们的系统管理主体，系统管理变得简单多了。好比，增长一个新节点到系统中就是启动一个Cassandra进程并告诉它一个种子节点（一个已知的在集群中的节点）这么简单。试想当你的分布式集群可能运行在上百个节点的规模上的时候，如此轻易地增长新节点简直是难以置信。更进一步，当有什么出错的时候，你不须要考虑是哪一种节点出了问题——全部节点都是同样的，这让调试成为了一个更加易于进行且可重复的过程。

第二，我能够得出结论，Cassandra的P2P架构给了它更好的性能和可用性。这样的系统中，负载能够被均衡地三步倒各个节点上，来最大化潜在的并行性，这个能力让系统面临网络分裂和节点失效的时候都能更加的无缝，而且节点的对称性防止了HBase中发现的那种在节点加入和删除时的暂时性的性能都懂（Cassandra 启动很是迅速，而且性能能够随着节点的加入而平滑扩展）。

若是你想寻找更多更多的证据，你会对一个原来一直关注Hadoop的小组（应该对 HBase 更加偏心）的报告很感兴趣......

一份报告赛过千言万语。我是指图表

Yahoo！进行的第一个NOSQL系统的完整评测。研究彷佛证明了Cassandra所享有的性能优点，从图表上看，很是倾向于Cassandra。

目前这些论文仍是草稿，你能够从这里找到这些论文：

http://www.brianfrankcooper.net/pubs/ycsb-v4.pdf

http://www.brianfrankcooper.net/pubs/ycsb.pdf

注意：这份报告中HBase仅在对一个范围的记录进行扫描这一项上优于Cassandra。虽然Cassandra团队相信他们能够很快达到HBase的时间，但仍是值得指出，在一般的Cassandra配置中，区间扫描几乎是不可能的。我建议你能够无视这一点，由于实际上你应该在Cassandra上面来实现你本身的索引，而非使用区间扫描。若是你对区间扫描和在Cassandra中存储索引相关问题有兴趣，能够看个人这篇文章。

最后一点：这篇文章背后的Yahoo！研究团队正尝试让它们的评测应用经过法律部门的评估，并将它发布给社区。若是他们成功的话，我固然但愿他们成功，咱们将可以看到一个持续的竞争场面，不论HBase仍是Cassandra无疑都会进一步提升他们的性能。

锁和有用的模块性

毫无疑问，你会从HBase阵营听到这样的声音：HBase的复杂结构让它能够提供Cassandra的P2P架构没法提供的东西。其中一个例子可能就是Hbase提供给开发者行锁机制，而Cassandra则没有（在HBase中，由于数据副本发生在hadoop底层，行锁能够由region server控制，而在Cassandra的P2P架构中，全部节点都是平等的，因此也就没有节点能够像一个网管囊样负责锁定有副本的数据）。

不够，我仍是把这个问题返回到关于模块化的争论中，这实际是对Cassandra有理的。Cassandra经过在对称节点上分布式存储数据来实现了BigTable的数据模型。它完整地实现了这些功能，并且是以最灵活和高性能的方式实现的。但若是你须要锁、事务和其它功能的话，这些能够以模块的方式添加到你的系统之中——好比，咱们发现咱们可使用Zookeeper和相关的工具来很简单地为咱们的应用提供可扩展的锁功能（对于这个功能，Hazelcast等系统可能也能够实现这个功能，虽然咱们没有进行研究）。

经过为一个窄领域目的来最小化它的功能，对我来讲，Cassandra的设计达到了它的目的——好比前面指出可配置的CAP的折衷。这种模块性意味着你能够依据你的需求来构建一个系统——须要锁，那么拿来Zookeeper，须要存储全文索引，拿来Lucandra ，等等。对于咱们这样的开发者来讲，这意味着咱们没必要部署复杂度超出咱们实际须要的系统，给咱们提供了更加灵活的构建咱们须要的应用的终极道路。

MapReduce，别提MapReduce！

Cassandra作的还不够好的一件事情就是MapReduce！对于不精通此项技术同窗简单的解释一句，这是一个用于并行处理大量数据的系统，好比从上百万从网络上抓取的页面提取统计信息。MapReduce和相关系统，好比Pig和Hive能够和HBase一块儿良好协做，由于它使用HDFS来存储数据，这些系统也是设计用来使用HDFS的。若是你须要进行这样的数据处理和分析的话，HBase多是你目前的最佳选择。

记住，这就像小马过河！

所以，我中止了对Cassandra的优势的赞美，实际上，HBase和Cassandra并不必定是一对彻底的竞争对手。虽然它们经常能够用于一样的用途，和MySQL和PostgreSQL相似，我相信在未来它们将会成为不一样应用的首选解决方案。好比，据我所知StumbleUpon使用了HBase和hadoop MapReduce技术，来处理其业务的大量数据。Twitter如今使用Cassandra来存储实时交互的社区发言，可能你已经在某种程度上使用它了。

做为一个有争议的临别赠言，下面咱们进入下一个话题。

注意：在继续下一个小节以前，我要指出，Cassandra在0.6 版本会有hadoop支持，因此MapReduce 整合能得到更好的支持。

兄弟，我不能失去数据......

做为先前CAP理论争议的一个可能结果，可能有这样的印象，HBase的数据彷佛比Cassandra中的数据更安全。这是我但愿揭露的最后一个关于Cassandra的秘密，当你写入新数据的时候，它实际上马上将它写入一个将要存储副本的仲裁节点的commit log当中了，也被复制到了节点们的内存中。这意味着若是你彻底让你的集群掉电，只可能会损失极少数据。更进一步，在系统中，经过使用Merkle tree来组织数据的过度不一致（数据熵），更加增长了数据的安全性

事实上，我对HBase的状况并非很是确切——若是能有更细节的状况，我回尽快更新这里的内容的——但如今个人理解是，由于hadoop还不支持append，HBase不能有效地将修改的块信息刷入HDFS （新的对数据变化会被复制为多个副本并永久化保存）。这意味着会有一个更大的缺口，你最新的更改是不可见的（若是我错了，多是这样，请告诉我，我回修正本文）。

因此，尽管希腊神话中的Cassandra很是不幸（译注：Cassandra是希腊神话里，特洛伊的那个可怜的女先知的名字，若是你不知道详情的话，能够参考wiki），但你的Cassandra中的数据不会有危险。