《NoSQL For Mere Mortals》书评与作者问答录-InfoQ

由 Addison-Wesley Professional 出版的新书《NoSQL for Mere Mortals》介绍了各种主要类型的 NoSQL 数据库，并讲解了每一种数据库功能的优势与不足之处。InfoQ 有幸与本书作者 Dan Sullivan 进行了一次对话。

本书的开头部分介绍了数据库的 ACID（原子性、一致性、隔离性与持续性）与 BASE（基本可用、软状态与最终一致性）范式，为 NoSQL 与 SQL 数据库之间的比较划定了一个分析的框架。本书随后详细地介绍了 NoSQL 数据库的四种特性（BASE）的细节，而对于不同的 NoSQL 数据库在确保最终一致性方面所选择的不同做法，本书也以一种引人入胜的方式进行了全面的讲解。

本书随后分别介绍了四种主要类型的 NoSQL 数据库：健值数据库、文档数据库、列族数据库以及图形数据库，为每种数据库进行了简明扼要的介绍，包括它们的主要特性以及与其它 NoSQL 数据库的区别性特性。随后用一个完整的章节介绍了设计这种类型的数据库所需考虑的因素，包括以下内容，例如：

如何为键值数据库定义正确的键，以及如何在其中表现结构化的信息；
在文档数据库中，如何处理范式与反范式之间的平衡，以及如何最高效地进行表连接操作；
如何为列族数据库设计表结构、进行反范式化以及处理索引等操作；
如何在图形数据库中查询一个图、使用索引以及定义图形边界等操作；

本书的最后一部分将分析如何为某个应用程序选择正确的数据库，书中列举了一系列指导，以帮助读者进行抉择。

总体来说，本书的亮点在于它以一种简明的、高度结构化的方式展示了各种 NoSQL 数据库。此外，本文还进一步提供了一些在商业应用中使用 NoSQL 数据库的案例研究，让全书的论点显得更实际、更有说服力。InfoQ 借此机会与本书的作者 Dan Sullivan 进行了一次访谈。

InfoQ：是什么原因促使你编写了这样一本书？本书与市面上有关 NoSQL的其它书籍又有何不同之处呢？

Dan：人们对于数据库这一领域的研究与实践目前正处在一个高速发展的时间点。近几十年来，关系型数据库基本统治了这一领域。对数据库方面的发展主要关注于如何改善关系型数据库的性能，这也带来了一些重要的发展，例如列存储（columnar storage）等等。NoSQL 数据库的兴起是因为像 Google、Yahoo 以及 Facebook 这些大公司已经无法通过使用关系型数据库的方式满足各种用例越来越高的的需求。因此，我无法压抑一鼓冲动，下定决心要编写一本关于数据库技术近期发展的书籍。本书与其它 NoSQL 书籍的不同之处在于，它并没有专注于某一个具体的 NoSQL 数据库，而是分别描述了这四种主要类型的 NoSQL：即键值数据库、文档数据库、列族数据库与图形数据库。此外，本书深入地解释了在实现某种 NoSQL 数据库时需要了解的技术细节。有些 NoSQL 方面的书籍专注于为商业用户解释 NoSQL 的高层原理，当然这些资源也是非常有价值的。但《NoSQL for Mere Mortals》选择了一种不同的途径，它适合于那些必须选择一种 NoSQL 平台、使用某种 NoSQL 数据库设计应用程序、或将 NoSQL 数据库的微调与维护作为日常工作的开发者。

InfoQ：读者可以从阅读《NoSQL for Mere Mortals》一书中学到哪些知识？

Dan：读者可以通过快速地阅读介绍部分的内容，了解 NoSQL 数据库兴起的背景，以及它们在广泛的数据库应用技术中扮演着怎样的角色。本书的主体内容可以分四个部分，每一部分专门针对一种主要类型的 NoSQL 数据库。每一部分介绍了一种 NoSQL 模型，例如文档数据库，对它的关键概念与术语进行了详细的讲解，并在总结部分提供了一些设计指导与提示。本书的最后一章将为你选择符合你的应用需求的最佳数据库提供一些帮助。

本书始终强调的另外一个观点是：NoSQL 数据库是对关系型数据库的补充，而不是它们的替代者。自从上世纪 70 年代以来，关系型数据库已经成功地满足了越来越多的应用程序的需求，而这一点即使现在也不会产生变化。NoSQL 数据库将丰富我们的工具库，但不会取代其它的工具。

InfoQ：关系型数据模型已经为程序员们服务了许多个年头，既然如此，程序员为什么又要寻求其它的数据模型呢？

Dan：关系型数据库的设计目的是为了应对早期的数据管理系统的局限性，例如层次型数据库以及块存储系统。关系型数据库的范式规则能够帮助我们避免数据的异常，这一点对于许多商业应用，尤其是财务系统来说是至关重要的。随着 Web 的兴趣，开发者开始创建各种新型的应用程序，例如搜索引擎，他们不得不开始面对可伸缩性的问题。虽然关系型数据库对于成千上万的企业用户来说表现良好，但它们很难满足几十万、乃至上百万 Web 用户的需求。随着可伸缩性成为了关键的考量，其它的一些因素，例如即时一致性以及 ACID 的事务性就变得不那么重要了。这样一来，NoSQL 设计者就得到了更大的空间去探索新型的数据库模型，以求满求 Web 应用、而不是企业应用所带来的新型需求。

InfoQ：那么，从另一方面来说，开发者将能够从使用 NoSQL数据库中得到哪些优势呢？

Dan：使用 NoSQL 数据库的一个最明显的优势在于，它能够让开发者选择一种最符合他们的问题领域的数据模型。在对运输系统或社交网络应用进行建模时可以选用图形数据库，当需要仅通过键实现高性能的读写操作时可以选用键值数据库。文档数据库很适合需要灵活的模式、并且支持半结构化数据的应用。而列族数据库则非常适合于需要灵活模式的大数据应用。

InfoQ：如果开发者远离了关系型模型这个具有优秀理论基础的避风港，他们会面临哪些缺陷？

Dan：他们会面临大量的缺陷。NoSQL 数据库通常不支持在 RDBMS 中常见的强制性约束，此外，应用程序可以动态地为文档数据库添加属性，而无需数据建模者对模式进行更新，以及将变更提交至生产环境，这一点或许会让数据建模者感到畏惧。毕竟，如果不存在一种主控模式，又有谁能够负责它的管理呢？对这个问题的答案是：我们都要对它负责。为了追踪这些灵活模式、以及无模式的数据模型，我们需要设计一些新的过程。

InfoQ：当决定从关系型模型转为 NoSQL模型时，主要的挑战是什么？

Dan：首先要回答的一个问题在于，你是否真的需要迁移至某个 NoSQL 数据库？如果你的团队在关系型数据库方面经验丰富，并且对于维护关系型数据库已经有了现成的管理流程，那么你应当问问你自己，迁移至 NoSQL 究竟能够带来什么好处？

如果你的关系型模型为了查询的性能进行了大量的反范式设计，那么可以考虑使用 NoSQL 数据库。

如果你所面临的情况是将为升级数据库服务器付出极大的成本，那么是时候考虑一下使用 NoSQL 数据库了。多数 NoSQL 数据库在设计时就考虑到可以使用普通规格的硬件对数据库进行横向扩展。

如果你试图在关系数据库中实现某些高效的查询时遇到很大的困难，例如对某种网状数据进行递归式的搜索，那么你可以考虑使用 NoSQL 数据库。

InfoQ：你能否大致描述一下本书所涵盖的各种 NoSQL数据库的主要特性？

Dan：本书涵盖了四种主要类型的 NoSQL 数据库：键值数据库、文档数据库、列族数据库与图形数据库。

键值数据库采用了最简单的数据模型，通过某个索引或键对数据进行保存与引用。这种类型的数据库提供了一些类似于 Dictionary 的查找功能，但缺少对 SQL 风格查询功能的支持。键值数据库的代表有 Redis 和 Riak，它们所适合的应用程序对于读写操作有较高的性能需求，而其数据结构又是相对比较原子性的。Riak 还加入了一些搜索功能，为应用程序提供更灵活的数据获取方式。

文档数据库大概是最流行的 NoSQL 数据库了，每个文档都是键值对的集合。键值对的集合有点类似于数据库中的一行，只是每个文档的键或者属性都可以是不同的。文档中还支持非原子性的结构，例如数组与内嵌文档。如果你需要一种比起键值数据库更灵活的模式，以及更高级的查询支持，那么文档数据库是一个不错的选择。通常在文档数据库中会避免进行连接操作，但如果你确实需要这种功能，那么可以计划在应用层中自己实现这一操作。

列族数据库的代表有 HBase 和 Cassandra，它们都是基于 Google 的 BitTable 而设计的。列族数据库在表面上看起来与关系型数据库有些相似，但它们的实现方式完全不同。列族数据库通过使用 map 数据结构以实现一种类似于稀疏矩阵（sparse matrix）的结构。列族数据库的设计目标是支持百万级的列以及几十亿级的行。毫无疑问，它为我们带来了在传统的关系型数据库中无法实现的一些新的设计技术。

InfoQ**：在设计过程中，你如何描述设计一个基于 RBDMS的系统与一个基于 NoSQL的系统的不同之处呢？**

Dan：这两者之间主要的不同之处在于，我们在设计数据模型时所提出的问题不同。在关系型数据建模时，我们的问题是实体之间如何关联，以及它们具有哪些属性？而在设计 NoSQL 模型时，我们通常会从需要对数据库执行的查询开始。虽然看起来似乎没有很大的区别，但其隐含的意义是非常重要的。

在关系型建模时，我们首先要尽可能理解实体之间的关系，因为一旦掌握了这种关系，我们就知道如何回应对于实体的查询。这种特征会自然地促使我们对数据进行范式设计，以减少产生数据异常的风险。

而在 NoSQL 的设计中，不存在一种类似于关系代数的数学模型，因而无法从中得出设计原则。我们所考虑的是用例及查询模式，并设计出一种能够在性能与数据冗余之间达到平衡的结构。举例来说，当在诸如 MongoDB 这样的文档数据库中对一种主 - 从关系进行建模时，你既可以选择内嵌某个具体文档的引用，也可以选择将文档内容本身进行内嵌。内嵌引用的做法与关系型数据库中使用外键引用的方法相似，而内嵌具体文档的方式则是一种反范式的方式。那么哪一种方法更好呢？这一问题的答案取决于你的查询访问模式。如果你频繁地对主表的属性进行查询，而很少需要了解具体记录的属性，那么内嵌引用的方法更合适。而如果你对于主表与具体的属性都需要执行频繁的查询，那么内嵌具体文档或许是一个更好的选择。

InfoQ：能否请你分享一下对 NoSQL数据库未来的展望？

Dan：NoSQL 数据库正在飞速地发展中，并包含了许多额外的特性。它的发展体现在三个方面。

NoSQL 数据库正在引入关系型数据库的一些特性，例如对事务的支持。某些 NoSQL 数据库目前对事务只提供了有限的支持能力，但从趋势来看，它们将不断引入更为健壮的事务控制能力。这可能会带来一些性能上的压力，但应用程序的设计者至少可以选择在需要事务能力的时候使用它，而在需要避免因事务所带来的性能开销时关闭它。

NoSQL 数据库也在逐渐转向多模式，即支持不止一种的 NoSQL 数据模型。Amazon 所设计的 DynamoDB 最初只是一种键值数据存储系统，但如今也开始支持文档的存储了。OrientDB 是一种文档型数据库，同时也支持图形数据库。DataStax 原本是一家支持着 Cassandra 列族数据库的商业投资机构，但最近他们刚收购了 Titan 这个具有高伸缩性的图形数据库背后的开发团队。最终，我们将能够把数据保存在一个单一的数据库中，同时以图形或文档等方式访问这些数据，这取决于哪种方式对于特定的应用来说最有效。

云计算将降低 NoSQL 的准入门槛。Google 刚刚宣布了原始的列族数据库 BigTable 的一般可用性。Amazon 开发了 DynamoDB，而微软也推出了 DocumentDB。通过使用数据库即服务（DBaaS）平台，开发者就能够直接上手使用 NoSQL 数据库，而无需进行各种数据库管理以及调整工具，而这些工作在自管理的平台上是不可避免的。

InfoQ：你认为是否可能出现一种趋势，即使用 RDBMS保存无模式的数据？

Dan：是的，我想你已经看到了这一点。在关系型数据库中使用非关系型模型的模式并不是一种全新的想法。在上世纪 90 年代出现的对象数据库就是关系型数据库的一种替代方案，只是没有像如今的 NoSQL 这样发展起来。反倒是像 Oracle 这样的数据库在关系型模型中整合了一些对象数据库的特性。

实现这一目标的限制因素在于，关系型存储模型对于 NoSQL 数据库在性能方面的要求能够提供多大的支持。关系型数据库如今也可以用于保存键值、文档或图形数据，但它真的是最佳的选择吗？而列族数据库也并不使用在关系型数据库中常用的行、或列存储模型，而是使用 map 对表中的稀疏数据进行高效地保存，并能够潜在地支持百万级的属性以及几十亿级的行。

在某些用例中，把 NoSQL 数据结构保存在关系型数据库中的做法是有意义的，尤其是在处理数据量相对较小的情况下。而当你的关系型数据库服务器需要挣脱其能力的限制，进行纵向扩展时，就要考虑使用某种数据库，使它的存储模型更自然地切合你的数据模型。

关于本书作者

Dan Sullivan是一位数据架构师与数据科学家，他在商业智能、机器学习、数据挖掘、文本挖掘、大数据、数据建模以及应用程序设计方面已有超过20**** 年的经验。他最近的工作专注于生命科学领域的NoSQL 数据库建模、数据分析、云计算、文本挖掘以及数据集成等等。Dan 在关系型数据库设计方面具有丰富的经验，同时也经常使用 NoSQL 数据库开展工作。