NoSQL精粹

世界级软件开发大师和软件开发“教父”Martin Fowler与Jolt生产效率大奖图书作者Pramod J. Sadalage新力作，毋庸置疑
全方位比较关系型数据库与NoSQL数据库的异同，详细讲解4大主流NoSQL数据库的优劣势、用法和适用场合，深入探讨实现NoSQL数据库系统的各种细节

海报：

《NoSQL精粹》为考虑是否可以使用和如何使用NoSQL数据库的企业提供了可靠的决策依据。它由世界软件开发大师和软件开发“教父”Martin Fowler与Jolt生产效率大奖图书作者Pramod J. Sadalage共同撰写。书中全方位比较了关系型数据库与NoSQL数据库的异同；分别以Riak、MongoDB、Cassandra和Neo4J为代表，详细讲解了键值数据库、文档数据库、列族数据库和图数据库这4大类NoSQL数据库的优劣势、用法和适用场合；深入探讨了实现NoSQL数据库系统的各种细节，以及与关系型数据库的混用。
全书分为两部分，共15章：一部分（第1～7章）主要讲述NoSQL的核心概念。其中第1章解释了NoSQL发展迅速的原因；第2章描述了在NoSQL领域的三种主要的数据模型中如何体现“聚合”这一概念；第3章介绍了聚合的缺点；第4章描述了数据库如何在集群中分布数据；第5章论及了更新与读取操作对一致性的影响；第6章讨论了版本戳；第7章描述了适合用在NoSQL系统中的“映射-化简”操作。第二部分（第8～15章）讲述了如何实现NoSQL数据库系统。其中第8章～第11章每章各以一种NoSQL数据库为例，演示了如何实现一部分介绍的概念；第12章解释了数据如何在强模式系统与无模式系统之间迁移；第13章着眼于混合持久化领域的趋势；第14章探讨了在混合持久化领域中会考虑到的其他一些技术；第15章提供了选择数据库时可以参考的一些建议。

Pramod J. Sadalage，ThoughtWorks公司首席顾问，致力于消弭数据库专业人员与应用程序开发者之间的鸿沟，他在这一鲜有人问津的领域中独享其乐。Sadalage先生经常接受客户咨询，为他们所面临的那些依赖新工艺、新科技，且极有挑战性的数据需求出谋划策。他研发出一项前沿技术，以受版本控制的数据迁移操作渐进地设计关系型数据库。Sadalage先生与Scott Ambler先生合著的《数据库重构》一书荣获2007年Jolt生产效率大奖。

Martin Fowler，世界软件开发大师，软件开发“教父”，敏捷开发方法的创始人之一，在面向对象分析与设计、UML、模式、极限编程、重构和DSL等领域都有非常深入的研究，并为软件开发行业做出了卓越贡献。他乐于分享，撰写了《企业应用架构模式》（荣获2003年Jolt生产效率大奖）、《重构：改善既有代码的设计》、《分析模式：可复用的对象模型》、《UML精粹：标准对象建模语言简明指南》、《领域特定语言》等在软件开发领域颇负盛名的著作。

译者简介
爱飞翔，资深软件开发工程师，擅长Web开发、移动开发和游戏开发，有10余年开发经验，曾主导和参与了多个手机游戏和手机软件项目的开发，经验十分丰富。他是手机软件开发引擎AgileMobileEngine的创始人兼项目经理，同时也是CatEngine手机游戏开发引擎的联合创始人兼代码维护员。他对极限编程、设计模式、重构、测试驱动开发、敏捷软件开发等也有较深入的研究，目前负责敏捷移动开发网（http：//www.agilemobidev.com/）的运营。业余爱好文学和历史，有一定的文学造诣。翻译并出版了《Android游戏开发实践指南》、《测试驱动的iOS开发》、《HTML5 Canvas核心技术：图形、动画与游戏开发》和《JavaScript应用开发实践指南》等书。

译者序
前言

第一部分概 念

第1章为什么使用NoSQL
1.1关系型数据库的价值
1.1.1获取持久化数据
1.1.2并发
1.1.3集成
1.1.4近乎标准的模型
1.2阻抗失谐
1.3“应用程序数据库”与“集成数据库”
1.4蜂拥而来的集群
1.5NoSQL登场
1.6要点

第2章聚合数据模型
2.1聚合
2.1.1关系模型与聚合模型示例
2.1.2面向聚合的影响
2.2键值数据模型与文档数据模型
2.3列族存储
2.4面向聚合数据库总结
2.5延伸阅读
2.6要点

第3章数据模型详解
3.1关系
3.2图数据库
3.3无模式数据库
3.4物化视图
3.5构建数据存取模型
3.6要点

第4章分布式模型
4.1单一服务器
4.2分片
4.3主从复制
4.4对等复制
4.5结合“分片”与“复制”技术
4.6要点

第5章一致性
5.1更新一致性
5.2读取一致性
5.3放宽“一致性”约束
5.4放宽“持久性”约束
5.5仲裁
5.6延伸阅读
5.7要点

第6章版本戳
6.1“商业事务”与“系统事务”
6.2在多节点环境中生成版本戳
6.3要点

第7章映射-化简
7.1基本“映射-化简”
7.2分区与归并
7.3组合“映射-化简”计算
7.3.1举例说明两阶段“映射-化简”
7.3.2增量式“映射-化简”
7.4延伸阅读
7.5要点

第二部分实 现

第8章键值数据库
8.1何谓“键值数据库”
8.2键值数据库特性
8.2.1一致性
8.2.2事务
8.2.3查询功能
8.2.4数据结构
8.2.5可扩展性
8.3适用案例
8.3.1存放会话信息
8.3.2用户配置信息
8.3.3购物车数据
8.4不适用场合
8.4.1数据间关系
8.4.2含有多项操作的事务
8.4.3查询数据
8.4.4操作关键字集合

第9章文档数据库
9.1何谓文档数据库
9.2特性
9.2.1一致性
9.2.2事务
9.2.3可用性
9.2.4查询功能
9.2.5可扩展性
9.3适用案例
9.3.1事件记录
9.3.2内容管理系统及博客平台
9.3.3网站分析与实时分析
9.3.4电子商务应用程序
9.4不适用场合
9.4.1包含多项操作的复杂事务
9.4.2查询持续变化的聚合结构

第10章列族数据库
10.1何谓列族数据库
10.2特性
10.2.1一致性
10.2.2事务
10.2.3可用性
10.2.4查询功能
10.2.5可扩展性
10.3适用案例
10.3.1事件记录
10.3.2内容管理系统与博客平台
10.3.3计数器
10.3.4限期使用
10.4不适用场合

第11章图数据库
11.1何谓图数据库
11.2特性
11.2.1一致性
11.2.2事务
11.2.3可用性
11.2.4查询功能
11.2.5可扩展性
11.3适用案例
11.3.1互联数据
11.3.2安排运输路线、分派货物和基于位置的服务
11.3.3推荐引擎
11.4不适用场合

第12章模式迁移
12.1模式变更
12.2变更关系型数据库的模式
12.2.1迁移全新项目
12.2.2迁移既有项目
12.3变更NoSQL数据库的模式
12.3.1增量迁移
12.3.2迁移图数据库的模式
12.3.3改变聚合结构
12.4延伸阅读
12.5要点

第13章混合持久化
13.1各异的数据存储需求
13.2混用各类数据库
13.3将直接数据库操作封装为服务
13.4扩展数据库以增强其功能
13.5选用合适的数据库技术
13.6企业使用混合持久化技术时的考量
13.7部署复杂度
13.8要点

第14章超越NoSQL
14.1文件系统
14.2事件溯源
14.3内存映像
14.4版本控制
14.5XML数据库
14.6对象数据库
14.7要点

第15章选择合适的数据库
15.1程序员的工作效率
15.2数据访问性能
15.3继续沿用默认的关系型数据库
15.4抽离数据库策略以降低风险
15.5要点
15.6结语
参考资料

在理想情况下，不同的服务器节点会服务于不同的用户。每位用户只需与一台服务器通信，并且很快就能获得服务器的响应。网络负载相当均衡地分布于各台服务器上。比方说，如果有10台服务器，那么每台服务器只需分担10％的负载。
理想状况当然比较罕见。为了获得近乎理想的效果，必须保证需要同时访问的那些数据都存放在同一节点上，而且节点必须排布好这些数据块，使访问速度最优。
要解决这个问题，首先得考虑：怎样存放数据，才能保证用户基本上只需要从一台服务器中获取它。若使用面向聚合的数据库，那就非常方便了。之所以设计“聚合”这一结构，就是为了把那些经常需要同时访问的数据放在一起。因此，显然可以把聚合作为分布数据的单元。
在节点的数据排布问题上，有若干个与性能改善相关的因素。若是能够确定聚合的访问者基本上都处在某个地理范围内，那么就可以把数据放得离访问者近一些。如果查询订单数据的用户住在波士顿，那么可以把该用户所需的数据放在美国东部的数据中心。
另外一个因素就是要保持负载均衡。意思就是，要把聚合数据均匀地分布在各个节点中，让它们需要处理的负载量相等。负载分布情况可能会随着时间变化，例如某些数据的访问量可能集中在一周的某几天内。因此，可能需要使用一些“领域特定规则”（domain—specific rule）。
在某些情况下，可以把有可能需要依次读取的聚合放在一起。Bigtable论文[Chang，etc.]中说，可以按照“字典顺序”e排列表中的“行”，以“逆域名”（reverseddomain name，例如com.martinfowler）为序来排列网址。如果要同时访问跨越多个页面的数据，那么此方式有助于改善处理效率。
以前很多人都把分片工作放在应用程序的逻辑里实现。可以把姓氏首字母为A～D的客户放在一个分片，而把姓氏首字母为E～G的客户放在另一个分片。这就使编程模型变复杂了，因为应用程序的代码必须负责把查询操作分布到多个分片上。此外，若想重新调整分片，那么既要修改程序代码，又要迁移数据。很多NoSQL数据库都提供了“自动分片”（auto—sharding）功能，可以让数据库自己负责把数据分布到各分片，并且将数据访问请求引导至适当的分片上。

我们已经在企业级计算领域研究了20余年，编程语言、架构、平台、软件开发流程等技术都在改变，然而这期间有一件事却一直没变，那就是：大家依然使用关系型数据库来存储数据。虽说也出现了一些挑战关系型数据库的产品，而且有的还在某些领域成功了，但是总体来说，留给架构师的数据存储问题仍然是选择使用哪款关系型数据库的问题。
稳定性在此领域颇受重视。企业的数据比程序存储的时间要长很多（至少大家都是这么说的。当然啦，我们也见过许多非常老的程序）。拥有一个既稳定，又容易理解，而且还能让许多应用程序编程平台访问的数据库，是非常有价值的。
不过，关系型数据库现在碰上新对手了，它的名字叫NoSQL。由于我们需要处理的数据量越来越大，必须以商用服务器集群来构建大型硬件平台，因此NoSQL就应运而生了。这也使大家要再次考虑那个存在已久的难题，即代码如何才能同关系型数据库良好地结合起来。
“NoSQL”这个词的定义是非常不明确的。它泛指那些最近诞生的非关系型数据库，1诸如Cassandra、MongoDB、Neo4J和Riak等。它们主张使用无模式（schemaless）的数据，可以运行在集群环境中，并且能够牺牲传统数据库所具备的一致性，以换取另外一些有用的特性。NoSQL的倡导者声称，使用它们可以构建出性能更高、扩展度更好且更易编程的系统。
这会不会敲响了关系型数据库即将灭亡的第一声警钟呢？还是说NoSQL要抢走数据库领域的头把交椅？我们的回答是：“这两种情况都不会出现。”关系型数据库是一个非常强大的工具，我们希望能长时间使用下去；然而大家也要看到一场深远的变革，那就是：关系型数据库不再是唯一的选择了。我们认为，数据库领域正进入混合持久化（Polyglot Persistence）时代，由企业乃至个人研发的应用程序，可以使用多种技术来管理数据。因此架构师需要熟悉这些技术，并且能根据不同的需求做出适当的选择。若非如此，笔者怎会花那么多时间和精力来写这本书呢？
schema也译作“纲要”、“大纲”、“概要”等，本书统称其为模式，与表示“处理技术问题的固定范式”之“模式”（Pattern）一词不同。——译者注
本书给诸位读者提供足够多的信息，协助大家在以后的研发过程中思考：项目是否真的值得使用NoSQL数据库。每个项目都是不同的，我们不可能写出一个简单的决策树，用它来选出合适的数据存储方式。与之相反，本书力求讲解大量的背景知识，以便大家了解NoSQL的工作原理，这样的话，你不用在互联网上四处寻找，就能够做出适合自己项目的决定了。笔者刻意将本书写得很短，以便读者能够快速阅览它。虽说本书不会回答各种具体问题，但是，它可以帮你缩小考虑的范围，让你明白自己当前应该提出哪些问题。
NoSQL数据库为何引人关注
我们来看一下大家选用NoSQL数据库的两个主要原因。
●应用程序的开发效率。在很多应用程序的开发过程中，大量精力和时间都放在了内存（in-memory）数据结构和关系型数据库之间的映射上面。NoSQL数据库可以提供一种更加符合应用程序需求的数据模型，从而简化了数据交互，减少了所需编写、调试并修改的代码量。
●大规模的数据。企业所重视的是，数据库要能够快速获取并处理数据。他们发现，即便关系型数据库能达成这一目标，其成本也很高。主要原因在于，关系型数据库是为独立运行的计算机而设计的，但是现在大家通常使用由更小、更廉价的计算机所组成的集群来计算数据，这样更实惠些。许多NoSQL数据库正是为集群环境而设计，因此它们更适合大数据量的应用场景。
本书内容
本书分为两个部分。第一部分主要讲述核心概念，让读者能够判断出NoSQL数据库是否适合自己，并且了解各种NoSQL数据库之间的差别。第二部分更加专注于实现NoSQL数据库系统。
第1章解释了NoSQL发展如此迅速的原因：由于需要处理的数据量越来越多，所以大型系统的扩展方式，由原来在单一计算机上的纵向扩展，转变为在计算机集群上的横向扩展。这也印证了许多NoSQL数据库的数据模型所具备的一个重要特性，那就
是：可以把内容密切相关的数据组织成一种丰富的结构，并将其显式存储起来，以便作为一个单元（unit）来访问。本书中，我们将这种类型的结构称为聚合（aggregate）。
第2章描述了在NoSQL领域的三种主要数据模型中，如何体现“聚合”这一概念。这三种数据库模型是：“键值模型”（key-value，参见2.2节），“文档模型”（document，参见2.2节）和“列族模型”（column family，参见2.3节）。聚合为许多种应用提供了一个自然的交互单元，既改善了集群的运行状况，又使编写程序来访问数据库变得更为容易。第3章转到聚合的缺点上面：难以处理位于不同聚合的实体之间的关系（参见3.1节）。这自然就引出了图数据库（参见3.2节），它是一个不属于面向聚合（aggregated-oriented）阵营的NoSQL数据模型。我们也会讲到NoSQL数据库的共同特性：它们都是以“无模式”的形式来操作的（参见3.3节）。模式的这种特性确实提供了更大的灵活性，但是它并不像大家想象的那么万能。
在讲完NoSQL数据模型方面的内容之后，我们接下来要讲分布模型。第4章描述了数据库如何在集群中分布数据。这个问题又细分为“分片”（sharding，参见4.2节）和“复制”（replication），复制方式可以是“主从复制”（master-slave replication，参见4.3节）或者“对等复制”（peer-to-peer replication，参见4.4节）。了解完分布模型的概念后，接下来要讲“一致性”（consistency）问题。与关系型数据库相比，NoSQL数据库在一致性方面提供了更多选择，这么做是因为NoSQL要更好地支持集群。于是，第5章谈到了更新与读取操作对一致性的影响（分别参见5.1节和5.2节），如何在一致性与持久性之间进行仲裁（参见5.5节），以及如何放宽对持久性的约束以提升其他特性（参见5.4节）。如果之前听过NoSQL，那么就应该听过“CAP定理”（The CAP Theorem）。5.3节中介绍了CAP定理的相关知识，告诉大家如何根据该理论来权衡一致性与其他特性。
前面这些章节主要侧重于如何分布数据并保持其一致性，接下来的两章讨论了要完成这项工作所需的一些重要工具。第6章讲述了版本戳（version stamp），它用来记录数据库的内容变更，并且可以检测数据是否一致。第7章概述了“映射-化简”（Map-Reduce）操作，这种计算方式很适合在集群中组织并行计算，因而也适用于NoSQL系统。
讲完这些概念后，我们针对以下4种数据库各举一些例子，来演示如何实现上述概念。第8章使用Riak来演示“键值数据库”，第9章使用MongoDB作为“文档数据库”的示例，第10章选用Cassandra来探讨“列族数据库”，第11章选择了Neo4J作为“图数据库”的示例。此处必须强调：要想全面学习数据库，只依靠这些章节是不够的。因为除此之外还有很多内容，没办法写在这本书中，而且还有更多东西必须尝试之后才能学会。本书选择这些示例，并不是建议大家在工作中使用它们，其目的是让读者知道数据的各种存储方式，明白不同的数据库技术如何使用前面提到的概念。读者会看到这些数据库系统都需要何种程序代码，并且简单了解使用它们时所应遵循的开发思路。
有些人经常会觉得：因为NoSQL数据库没有模式，所以在应用程序的生命期中，可以毫无困难地改变其数据结构。本书不同意此观点，因为无模式的数据库其实隐含了一种模式，在实现数据结构变更时，也必须修改其规则。所以，第12章解释了数据如何在强模式与无模式系统之间迁移。
所有这一切都清楚地表明：NoSQL不是独立存在的，也不会取代关系型数据库。第13章着眼于混合持久化领域的发展趋势：多种数据存储方式将共存，有时甚至会存在于同一个应用中。第14章将大家的视野扩展至本书之外，在混合持久化领域中，考虑一些前面没有涉及的技术。
掌握了前面所讲的全部内容之后，读者就应该明白如何选择合适的数据存储技术了。所以最后一章（第15章）提供了一些选择数据库时可以参考的建议。笔者认为，有两个关键因素：找到一种高效的编程模型，其数据存储模型要非常符合待开发的应用程序，并且确保其获取数据的效率与弹性均符合开发者的需求。从NoSQL诞生之初，我们就担心没有一套定义明确的流程可以遵循，现在，你仍然需要结合自己的需求，来验证自己所选择的数据库技术是否合适。
本书只是个简要的概述，所以笔者一直在尽力压缩篇幅。我们精选了自己认为最重要的信息，这部分内容读者就不必再去找了。如果打算认真研究这些技术，那就需要进一步研读本书以外的知识了，不过，我们还是希望本书能为你的探索之路开个好头。
还需要强调的是：计算机领域中的这些技术是日新月异的，存储技术的某些重要方面在不断变化，每年都会出现新的特性与新的数据库。笔者投入了巨大的精力来专门讲述概念，因为就算底层技术变了，对这些概念的理解也依然有价值。我们非常确信，本书所讲的大部分概念都会历久绵长，但绝不能保证所有概念都会如此。
谁应该阅读本书
如果正在考虑选用某种形式的NoSQL数据库，那就应该阅读本书。选用NoSQL的原因可能是你打算做一个新的项目，也可能是既有项目遭遇瓶颈，所以要将其数据库迁移到NoSQL数据库上。
本书致力于给读者提供足够的信息，以判断自己所选的NoSQL技术是否符合需求，如果符合的话，应该深入研究哪些工具。我们设想本书的主要读者是架构师或技术主管，然而那些想大概了解这门新技术的软件管理人员也可以阅读本书。此外，对于想大概了解这项技术的开发人员来说，这也是本很好的入门读物。
本书不讲编程细节，也不去部署某个特定的数据库，那些内容留待更为专业的教材来写吧。我们还严格限制了本书的篇幅。笔者认为，这种书应该在坐飞机的时候读：它不会回答你提出的所有问题，但却会激发你提出一堆好问题来。
若是之前已经深入研究了NoSQL领域，那么本书可能不会增加你的知识储备。不过，它仍然有助于你将之前学到的东西解释给别人听。把围绕着NoSQL的争论理解清楚是很重要的，尤其当你要劝说别人在项目中也采用NoSQL技术时更是如此。
本书要讲的数据库类型
本书遵循常见的分类方式，也就是按照数据模型来划分各种NoSQL数据库。下表列出了4种数据模型，以及归属于每种数据模型的数据库。这份列表并不完整，其中只列出了较为常见的数据库。每个分类中，以斜体标出的数据库，都会在相关章节中作为范例来讲解。
数据模型 范例数据库 数据模型 范例数据库
键值（参见第8章） BerkeleyDB 文档（参见第9章） CouchDB
LevelDB MongoDB
Memcached OrientDB
Project Voldemort RavenDB
Redis Terrastore
Riak
列族（参见第10章） Amazon SimpleDB 图（参见第11章） FlockDB
Cassandra HyperGraphDB
HBase Infinite Graph
Hypertable Neo4J
OrientDB
这样划分的目的是从每一类数据库中，选出一个最有代表性的工具来讲。尽管每个分类下列出的那些数据库各不相同，不可像这样一概而论，但是，书中提到的那些具体示例，其实大多数情况下也适用于此分类中的其他数据库。我们会从“键值数据库”、“文档数据库”、“列族数据库”和“图数据库”这4类中各选一个作为范例，此外，在必要时，还会提到可以满足某个特定功能的其他产品。
按数据模型来分类是可行的，但却失之武断。不同数据模型之间的界限往往是模糊的，比如键值和文档数据库（参见2.2节）之间的区别就不是很明显。许多数据库并不能明确地归入某一类。例如，OrientDB称自己既是文档数据库又是图数据库。
致谢
首先感谢ThoughtWorks2的诸位同仁，在过去的几年中，很多同事在交付的项目中应用了NoSQL。笔者写作本书的动机主要来源于他们的经验，而这些经验亦是能印证NoSQL技术价值的实用信息。目前为止通过使用NoSQL数据存储积累了一些有益的经验，基于这些经验，我们认为：NoSQL是一项重要的数据存储技术，它正引发该领域内的一场重大变革。
我们也要感谢举办公开讲座、发表文章和博客来分享NoSQL使用心得的各种社群。若是大家都不愿意与同行分享研究成果的话，那么许多软件开发领域的发展就不为人知了。特别感谢谷歌及亚马逊的BigTable和Dynamo技术规范论文，它们对NoSQL的发展影响深远。也要感谢为开源NoSQL数据库的开发提供赞助及技术贡献的公司。这一次发生在数据存储领域的变革，与以往相比有一个较为有趣的差别：NoSQL的发展深度植根于开源工作。
ThoughtWorks是一家在全球诸多国家都有分公司的软件设计与定制领袖企业。主要业务模式是通过咨询来改善企业IT组织及软件开发方法，以软件带动企业业务发展。
特别感谢ThoughtWorks公司给予笔者时间来写作本书。我们两个大约同一时间加入ThoughtWorks，并且在这里工作了10余年。ThoughtWorks对我们来说一直是个非常友好的大家庭，同时也是知识和实践的来源。在这个良好的环境中，大家可以公开分享各自所学的知识，这与传统的系统交付公司（System Delivery Organization）非常不同。
Bethany Anders-Beck、Ilias Bartolini、Tim Berglund、Duncan Craig、Paul Duvall、Oren Eini、Perryn Fowler、Michael Hunger、Eric Kascic、Joshua Kerievsky、Anand Krishnaswamy、Bobby Norton、Ade Oshineye、Thiyagu Palanisamy、Prasanna Pendse、Dan Pritchett、David Rice、Mike Roberts、Marko Rodriquez、Andrew Slocum、Toby Tripp、Steve Vinoski、Dean Wampler、Jim Webber和Wee Witthawaskul审阅了本书初稿，并提出了改进建议。
此外，Pramod要感谢绍姆堡图书馆（Schaumburg Library）提供的一流服务和安静的写作空间；感谢爱女Arhana和Arula，你们知道爸爸到图书馆是为了写书，而没有带你们同去；感谢爱妻Rupali，你给了我巨大的支持和帮助，让我能够集中精力完成本书。