NoSQL 英文原文：The NoSQL Ecosystem

和本书中其它大部分项目不同，NoSQL不是一个工具，而是由若干互相之间具有互补和竞争关系的工具组成的一个生态系统。这些工具都冠以NoSQL系统这么个名称，都是用来存储数据的，但在存储方式上提供了同基于SQL的关系型数据库完全不同的另一种方案。为了理解NoSQL，我们必需先对现有的这些工具的总体情况有所了解，然后再来看看其中每种工具的设计思路是如何开拓出不同的数据存储方案的。

如果你正在考虑使用一种NoSQL存储系统，你就应该先广泛了解一下整个NoSQL系统所提供的大量不同的解决方案。NoSQL系统摒弃了传统的关系型数据库所提供的大量令人感到便利的功能，而且一般应该在数据库系统之内完成的一些任务在NoSQL系统中也完全留给了应用程序设计者来完成。这就要求你承担起系统架构师的角色，对NoSQL系统的架构有相当深度的理解才行。

其它翻译版本 (1) 加载中

13.1. NoSQL这个名称的含义

要弄清楚NoSQL提供了哪些解决方案，我们就应该先试着给NoSQL这个名字下个定义。按照字面意思的理解，NoSQL系统向用户呈现的查询接口是非SQL型的。 NoSQL社区所持的观点普遍更加宽泛，认为NoSQL系统提供了传统的关系型数据库之外的另一种解决方案，这种系统使得用户无需局限于SQL接口。在应用程序的开发中，有时你完全可以用NoSQL来取代关系型数据库，而在需要的情况下，你也可以混合使用这两种方式解决你所遇到的不同问题。

在深入了解NoSQL的世界之前，下面先来看看基于SQL的关系模型和NoSQL系统各自适用在哪种场合之下吧。

其它翻译版本 (1) 加载中

13.1.1. SQL以及关系模型

SQL是一种用于查询数据的声明式语言（a declarative language）。程序员使用声明式语言来指定想让系统为他们做什么，而不是给出过程性的定义告诉系统应该如何做。举几个SQL能干什么事情的例子： 找出39号员工所对应的记录、仅仅列出包含于整个记录之中员工的名字和电话号码， 过滤出所有的财会工作人员、计算出每个部门的员工总数、对员工表和管理人员表做一个联合查询等。

可以初步得出一个结论，SQL允许我们在提出上述的那些问题时，无需考虑这些问题：数据在磁盘上的物理存储格式是什么、查询这些数据需要使用哪些索引以及处理数据需要使用什么算法。绝大多数关系型数据库架构中一个非常重要的组成部分是查询优化器（query optimizer），它可以在所有逻辑对等的查询方案中找出哪个方案执行起来可以最快地给出查询结果。查询优化器往往可以胜过一般的数据库用户，但有时优化器所掌握的信息不够或者说系统的模型过于简单从而无法产生出最有效的查询执行方案。

其它翻译版本 (1) 加载中

关系型数据库是实践中最常见的一种数据库，它所遵循的是 关系数据模型（relational data model）。在这种模型下，现实世界中不同的实体（entity）要保存于不同的表（table）中。例如，所有的员工可能都要保存在员工表中，而所有的部门可能都要保存在部门表之中。表中的每一行记录具有多个属性，每个属性对应于一个列（column）。例如，员工可以具有员工id、工资、生日以及姓/名等属性。这其中的每一个属性都保存在员工表的一个列之中。

关系模型同SQL的关系密不可分。简单的SQL查询，比如进行过滤操作，可以找出某些字段满足某些条件（例： employeeid = 3或者salary > $20000）的所有记录。越复杂的SQL语句就会让数据库做越多的工作，比如进行多表联合查询（例： 找出ID为3的员工所在部门的部门名称）还有一些复杂的SQL语句，比如聚集（aggregation）语句（例： 求员工的平均工资），可能会导致全表数据扫描。

其它翻译版本 (1) 加载中

关系数据模型定义高度结构化的实体，并在它们之间拥有严格的关系约束。使用SQL查询这种模型，允许复杂的数据遍历，不需要很多自定义的开发。但是，这种复杂的模型和查询也有它的限制：

• 复杂导致不可预测。SQL的表现形式导致难于知道每个查询的代价的原因，还有负载的代价。而简单的查询语言可以导致复杂的应用逻辑，这样就可以容易的预估数据存储空间，单只限于简单的请求。
• 对于一个问题的建模有多种方法。关系数据模型是严格的：每个表定义的模式限制了这个表的中每一行。如果你保存了非格式化数据，或者那些拥有不同列的行数据，那么关系模型就会拒绝这些数据。类似的，应用开发人员并不能一定能找到每一种数据的关系模型。例如，很多应用逻辑都是通过面向对象语言编写的，包括高层次的概念，例如列表，队列，集合，还有一些编程人员希望持久层会建模成他们需要的类型。
• 如果数据增长超过了服务器的容量，那么这个表需要在不同的服务器中分区存储。为了避免JOIN在跨网络中使用来获取不同表的数据，我们需要使它标准化。标准化是把需要即刻被查询的数据从不同的表保存到一个地方。这样导致我们的数据库编程了一个类似键值查询的存储系统，让我们疑惑到底有没有其他模型更适合这种数据。

随意丢弃这么多年的设计理念并不是明知的选择。当你考虑到在数据库中的数据的时候，考虑通过过去几十年的研究和发展的SQL和关系模型的时候，提供丰富的建模能力，还有提供承诺容易理解的复杂操作。当你碰到这样的问题的时候，NoSQL是一个很好的选择，例如大数据，大负载，和难于通过SQL和关系数据来建模的数据。

其它翻译版本 (2) 加载中

13.1.2. NoSQL启示录

NoSQL的发展很大程度上是受到了来自研究界的许多论文的启示。 虽然NoSQL系统中的核心设计决策来自于多篇论文，但其中有两篇尤其重要。

来自Google的BigTable [CDG+06]提出了一种非常引人注目的数据模型，对有序（sorted）多列型历史数据的存储提供了很大的帮助。BigTable采用了层次型基于范围的分区方案（a hierarchical range-based partitioning scheme），将数据以分布式的方式存储于多台服务器之上；数据的更新也按照比较严格的一致性（这个概念我们将会在13.5中）中进行定义）。

来自Amazon的Dynamo [DHJ+07]采用了一种不同的面向键（key-oriented）的分布式数据存储系统。Dynamo的数据模型比较简单，只是将键影射为同应用程序相关的blob数据。它的分区模型对故障具有更大的抗干扰性，但为了实现这样的抗干扰性，Dynamo不得不采用了一种叫做最终一致性的不太严谨的数据一致性方法。

在下文中我们将会对这些概念逐一进行深入讲解，但有一点比较重要，就是它们当中的大部分概念都是可以结合在一起进行使用的。有些NoSQL系统，比如HBase¹，非常严格的遵循了BigTable的设计思想； Voldemort²重现了Dynamo的许多特性。但是，还有一些NoSQL系统同时借鉴了BigTable和Dynamo，比如Cassandra³就是借鉴了BigTable的数据模型，同时也借鉴了Dynamo 的分区方案以及数据一致性方案。

其它翻译版本 (1) 加载中

13.1.3. 特性及其考量

NoSQL系统摒弃了强大的SQL标准，提供了一种更加简单而渐进式的数据存储系统架构的解决方案。构建这些系统的理念是，通过简化数据库对数据的操作方式，架构师就能够更好的预测每个查询的性能。在许多NoSQL系统中，负载的查询逻辑是留个应用程序来完成的。这么做之后，由于查询的复杂度方面没有大的波动，所以这样的数据存储系统执行查询的效率具有比较高的可预测性。

NoSQL系统摒弃的不仅仅是关系型数据只是的声明式查询语言。事务性语义（Transactional semantics）、一致性以及持久性在象银行这样的组织中是数据库必需具备的特性。 事务（Transaction）提供了在把多个可能比较复杂的操作合并为一个操作时的一种全都做或全不做的保证，比如，从一个账户中取出钱然后将取出的钱存入另外一个账户。 一致性（Consistency）用来确保当一个值在更新之后，所有后继的查询看到的都是更新后的值。持久性（Durabilit）y用来保证一个值一旦得到更新，那么该更新一定是保存到了稳定性的存储介质（比如硬盘）了，摒弃在数据库崩溃后可以复原。

NoSQL系统放宽了对以上几个特性的要求，如此一来，它就能够为许多非银行类应用程序提供还可以接受的具有一定可预测性的行为从而换取性能方面的提高。放宽了这部分要求，连带着在数据模型和查询语言方面的改变，NoSQL系统就能够在数据量超过了单机处理能力时，很容易地将数据库进行安全地分区处理，从而可将数据放置于多台机器之上。

NoSQL系统目前仍然处于非常初级的发展阶段。本章所给出的这些系统的架构的现状说明了的确存在着各种不同用户需求。对若干开源项目的架构进行总结所遇到的最大挑战在于，每个架构仍然都处于不断的变化之中。要记住的是，每个系统在细节方面会不断发生变化。当你正在决定到底选取哪个NoSQL系统好时，本章在思维方式上对你提供一定的指导意见，但决不能作为你按照每个系统的特性进行最终系统选择的依据。

对NoSQL系统进行考察时，下面几个要点一定要注意：

• 数据模型及其查询模型：你的数据可以以行、对象、结构化数据还是文档的形式呈现？你是否可以要求数据库系统对多条记录进行统计性计算？
• 持久性（Durability）：当你对一个值进行更新后，该更新是否会立即保存到稳定的存储介质之中？ 该更新是否会被存储到多台机器之上以防出现单机崩溃的情况？
• 可伸缩性（Scalability）：你的数据是否单机就能处理得了？读写操作的总量是否需要多个磁盘才能应付得了？
• 分区（Partitioning）：为了可伸缩性、可用性或持久性的原因，你的数据是否需要保存于多台服务器之中？你要通过何种方式才能知道那条记录保存于哪个服务器之上？
• 一致性（Consistency）：如果你已对数据进行分区处理了并将你的数据进行复制备份保存于多台服务器之中了，当一条数据需要更新时，服务器之间的协调过程是怎样的？
• 事务性语义（Transactional semantics）：当你要进行一系列的操作时，有些数据库允许你将这一系列的操作作为一个事务进行处理，并能为该事务以及并行的其它事务能够提供对ACID (原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability)）的某种程度的保证。你的业务逻辑是否需要这些通常要以性能损失为代价的保证？
• 单机性能（Single-server performance）：如果你想安全的将数据存放到磁盘之中，什么样的磁盘数据结构更加适合于读取操作为主型的负载或写入操作为主型负载？磁盘写操作是否为你的性能瓶颈？
• 分析型负载（Analytical workloads）：下文中我们主要说的是在运行注重用户响应的Web应用程序时经常碰到的以查询为主型的负载。很多时候你需要在整个数据集上做汇总报告，比如对多个用户进行汇总性的数据统计。你的应用场景以及工具链是否需要这一类功能？

这些要点我们都会进行讨论，最后三点虽然也很重要，但在本章对它们的讨论比较少。

13.2 NoSQL数据和查询模型

数据模型说明数据是在逻辑上是如何组织的。它的查询模型说明数据如何被获取和更新。常见的数据模型是关系模型，面向键值的存储模型，或者各种图模型。你所听说过查询语言，可能有SQL，键值查询，和MapReduce。NoSQL系统把不同的数据和查询模型结合起来，所以系统需要考虑各种不同的架构。

其它翻译版本 (2) 加载中 本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务