分类：
2010-09-09 13:42:53
原文:
原作者：Dominic Williams
原文发布日期：February 24, 2010 at 7:27 pm
译者：王旭（http://wangxu.me/blog/ , @gnawux）
翻译时间：2010年3月21-25日
我的团队近来正在忙于一个全新的产品——即将发布的网络游戏 。这让我们得以奢侈地去构建一个全新的 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。
目前这些论文还是草稿，你可以从这里找到这些论文：
注意：这份报告中 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 中的数据不会有危险。
