译：为什么使用 NoSQL 数据库

原文链接：Why NoSQL Database?

向数据时代的转变正在推动 NoSQL

随着各行各业朝着数据时代转变，商业世界正在经历巨大的变革。这是由互联网以及其他二十一世纪新技术——云计算、移动应用、社交媒体和大数据驱动的经济模式。每一项数据时代业务的核心都是它的 Web、移动和物联网应用。如今，这是企业用于与用户进行互动的首要方式，同时也是企业如何扩大经营的方式。这些应用的使用体验很大程度上决定了用户的满意度和忠诚度。

这些应用与传统企业应用——如 ERP、HR 和财务会计软件等，有什么不同呢？如今的 Web、移动、物联网应用大都具备如下的特性：

• 支持大量并发用户（数万，甚至数百万量级）
• 为全球范围内的用户提供高质量的交互体验
• 高可靠性
• 支持处理半结构化数据和非结构化数据
• 快速适应不断变化的需求

构建和运营这些 Web、移动、物联网应用，实际上已经创建了一套新的技术要求。新的企业技术架构需要比以往更加敏捷，并要求有一种实时的数据管理方法，以适应这个在规模、速度和数据多样性上都属于前所未有的水平。关系型数据库无法满足这些新的要求，因此企业正在转向采用 NoSQL 数据库技术。

NoSQL 是十年前由一些领先的互联网公司（包括谷歌，亚马逊，Facebook 和领英）开创的，用于克服现代Web应用程序在使用 Oracle 和 MySQL 等关系型数据库时受到的局限。当这些早期的先驱证明了 NoSQL 的优势和高效时，企业开始逐渐采用 NoSQL：

• 基层实验：第一阶段（2010 年左右开始），企业开发人员开始在边缘项目和非关键任务应用上尝试使用NoSQL。他们的核心要求是，对于一些概念验证和小型应用的敏捷开发可以得到灵活的支持。

• 关键任务部署：在第二阶段（2013 年左右开始），企业开始在关键任务应用上采用 NoSQL。此阶段的核心要求是，开发和迁移目标服务时的性能、可扩展性和可用性。

• 广泛地重建：在第三阶段（2015 年底开始），开发人员和企业双方都需要一个通用的数据库，以便被企业广泛地采用，来重新搭建数据时代中所有关键任务应用和服务。在这个阶段，对 NoSQL 数据库的要求包括灵活性、性能、可扩展性、可用性，以及综合的查询语言和强大的索引功能。

NoSQL 关注五大趋势衍生出的新技术挑战

在更细粒度的水平，企业正在采用 NoSQL，以应对五大趋势带来的新一轮技术挑战和要求：

1. 更多的用户使用线上方式

越来越多的客户开始在线上完成更多的事情，无论是在家里、工作中，还是在旅途中。他们在线上完成订单支付、预定酒店、日常用品采购，而不是在当地的银行、旅行社或杂货店。

向线上转移带来的技术挑战包括：

• 扩大规模，以支持数以千/万计的用户
• 以一致的高性能表现满足用户体验要求
• 维持 7X24 小时的可用性

2. 互联网正在连接一切

不只人们的生活工作方式逐渐迁移到线上。今天，越来越多的“物体”开始连接到互联网——“物联网”，而且它们都会使用和产生数据。它们可以是消费品，如电器、手表、汽车等等。它们可以是工业产品，如飞机引擎、风力发电机、石油钻机和管道等。它们可能很大，也可能很小，可能在本地，也可能在远端。

物联网带来的技术挑战包括：

• 支持众多不同的（常常是新生的）物体，意味着需要不同的数据结构
• 支持可能会导致数据结构改变的软硬件更新
• 支持连续的实时数据流

3. 大数据变得越来越庞大

现在，用户通过线上方式处理越来越多的事务，机器产生的数据也日益增长。因此，许多企业正在利用大数据来提高运营、应用程序、服务等方面的效率和有效性。

大数据带来的技术挑战包括：

• 存储用户生成的半结构化和非结构化数据
• 将来自不同来源不同类型的数据存储在一起
• 存储由数千/万个用户和物体产生的数据

4. 应用程序正在向云端迁移

按需扩展和规模经营对灵活性也有要求，因为企业出于成本、灵活性、性能优化的考虑，逐渐转向分布式软件和商用硬件。这导致了对云基础设施的采用，无论是公有的、私有的、混合的、虚拟的、容器的还是裸机。

向云端迁移带来的技术挑战包括：

• 按需扩展，以支持更多客户和存储更多数据
• 在全球范围内运营应用程序，向全球用户提供服务
• 最大限度地减少基础设施成本，实现更快的市场推广

5. 世界已进入移动化浪潮

越来越多的客户正在通过移动平台进行互动——无论是智能手机、平板电脑、手表还是其他设备。企业不仅将应用程序和服务拓展到移动平台，而且他们正在评估一种“移动为主”，现在应该称之为“离线为主”的解决方案。

向移动平台迁移带来的技术挑战包括：

• 创建不需要网络连接的“离线为主”的应用程序
• 同步移动数据与云中的远程数据库
• 支持具有单个后端的多个移动平台

为什么关系型数据库有短板

几十年来，企业一直依赖于 Oracle、SQL Server、DB2、MySQL 等关系型数据库。那么为什么关系型技术不能满足当今 Web、移动和物联网应用的要求呢？

关系型数据库诞生于大型机和商业应用的时代，早在互联网、云计算、大数据、移动化和数据时代之前。事实上，第一款商业实现由 Oracle 在 1979 年发布。这些数据库被设计为在单个服务器上运行，服务器越大越好。增加这些数据库容量的唯一方法是对服务器进行升级，也就是要对处理器、内存和硬盘进行升级。

NoSQL 数据库的出现，可以看做是当今互联网呈指数级增长和 Web 应用快速兴起的必然结果。谷歌在 2006 年发布了关于 Bigtable 的研究，亚马逊在 2007 年发布了关于 Dynamo 的研究。这些数据库被设计出来，以满足新一代的企业要求——敏捷开发需求以及高扩展性。

敏捷开发

为了在高速发展的数据时代保持竞争力，企业需要坚持创新，而现在他们必须比以前做的更快。因为这些创新多数集中在 Web、移动和物联网应用的开发过程，开发人员必须比以往任何时候都要更加快速地交付应用程序和功能服务。速度和敏捷性至关重要，因为这些应用程序的演进速度远远超过传统应用程序，如 ERP。关系型数据库是敏捷性的主要障碍，它们对敏捷开发的支持并不友好，原因在于其固定不变的数据模型。

提高开发速度的灵活性

敏捷开发的一个核心原则是适应不断变化的应用需求：当需求变化，数据模型也要随之改变。而对于关系型数据库来说，这是一个问题。因为关系型数据库的数据模型由静态架构所定义，是固定不变的。所以，为了改变数据模型，开发人员不得不改变架构。这样就减慢甚至停滞了开发进程，不仅因为这是需要人工操作的、耗时的过程，更因为这会影响其他应用程序和功能服务。

图1：RDBMS——固定的架构中无法按需添加新的属性

相比之下，NoSQL 文档型数据库完全支持敏捷开发，因为它是无架构的并且不对数据模型进行静态定义。恰恰相反，它的数据模型遵循于应用程序和功能服务，这样就相当于遵循了开发人员的想法。应用 NoSQL 时，数据模型由应用模型定义，应用程序和功能服务的模型数据被当作对象。

应用文档型数据库时，应用程序和功能服务只需要简单的读写文档即可——通过将一个对象序列化为一个 JSON 文档的方式写入数据，或者通过相反的过程读取数据。因为 JSON 文档是自描述的，不需要外部架构。所以，通过这种修改对象来添加或移除属性的方式，开发人员可以在不改变数据库的情况下更改数据模型。显然，这对于提高开发人员的生产力和敏捷性，起到了巨大的帮助作用。

图2：JSON——数据模型随着添加新属性而变化

降低开发难度的简易性

文档数据库的另一个利于企业快速创新的优势是，具备应用程序直接读取文档的能力，而在应用程序模型和数据之间不需要对象关系映射层。

应用程序和功能服务构建数据模型时，是将数据作为对象，多值数据作为集合，相关数据作为嵌套对象或嵌套集合。然而，在关系型数据库中，数据通过包含行和列的表进行组织。相关数据在不同的表中，多值数据在同一个表中。关系型数据库的问题在于，数据读写过程中，需要分解或分割对象，然后再重新组合它们。对此，变通方案是对象关系映射框架，这样做的理想情况无非是不够高效，而最坏的情况是会导致出现错误。

例如，假设有一个管理简历的应用程序。它需要与简历进行交互，简历作为用户对象，包含一个记录技能数据的数组和一个记录工作经验数据的集合。将一份简历写入关系型数据库，应用程序需要将用户对象分割成数据片段才能完成。

存储简历时，要求应用程序将六行数据插入到三个表中：

图3：RDBMS——应用程序将对象分割成多行数据存储在多个表中

读取简历时，要求应用程序从三个表中读取六行数据：

图4：RDBMS——查询结果包含冗余的数据，应用程序需要对其进行过滤。

作为对比，文档型的 NoSQL 数据库读取和写入 JSON 格式的数据，这已经成了 Web、移动、物联网应用使用和产生数据过程中事实上的标准。它消除了对象关系映射的瓶颈，并且简化了应用程序开发过程，因为读取写入对象的时候，不需要再对其进行分割，一个对象可以作为一个文档来进行读取或者写入。

图5：JSON——应用程序可以将含有嵌套数据的对象存储为一个文档

NoSQL对查询和SQL的支持性

NoSQL 代表“Not Only SQL”，这一点非常重要。SQL 是一种成熟的查询技术，大部分的开发人员都正在使用这种技术。实际上，任何一种编程语言和框架，以及几乎所有的BI和报表工具都支持 SQL。因此，开发人员在使用 NoSQL 数据库进行开发时，能够最大限度的利用他们已掌握的SQL技能和工具，是非常重要的。

DDBS 引入了 N1QL，这是一种强大的查询语言，它在 SQL 的基础上扩展了 JSON 的特性，使开发人员能够充分利用 SQL 的强大能力和 JSON 的灵活性。它不仅支持标准的 SELECT/FROM/WHERE 语句，还支持聚合（GROUY BY）、排序（SORT BY）、连接（LEFT OUTER/INNER），以及查询嵌套的数组和集合。

SQL

SELECT		breweries.name AS brewery,
			count(*) AS cnt
FROM		beers
INNER JOIN	breweries
ON			beer.brewery_id = breweries.id
WHERE		beers.type = "beer" AND
			breweries.type = "brewery" AND
			beers.style = "American-Style Imperial Stout"
GROUP BY	breweries.name
HAVING		count(*) > 2
OEDER BY	cnt DESC;

N1QL

SELECT		breweries.name AS brewery,
			count(*) AS cnt
FROM		`beer-sample` beers
INNER JOIN	`beer-sample` breweries
ON			beer.brewery_id
WHERE		beers.type = "beer" AND
			breweries.type = "brewery" AND
			beers.style = "American-Style Imperial Stout"
GROUP BY	breweries.name
HAVING		count(*) > 2
OEDER BY	cnt DESC;

任意规模下皆可运行

Web、移动和物联网应用所使用的数据库，必须具备能够在任意规模下运行的能力。虽然扩展关系型数据库（如 Oracle，可使用 Oracle RAC 扩展）是可行的，但这样的扩展，通常既复杂又花费高昂，并且不完全可靠。例如，使用 RAC 技术扩展 Oracle 需要很多的组件，并且出现单点故障时会危及可用性。相比之下，NoSQL 分布式数据库——设计有横向扩展架构且不会出现因单点故障造成的服务失效，具备显著的优势。

规模上具有弹性

应用程序和功能服务必须支持持续增长的用户和数据。同时，企业要扩展规模以维持性能表现，这些必须快速有效的完成。

数据库必须支持读写操作次数和存储容量的提升。而对于关系型数据库来说，这是问题所在，即规模扩展存在上限。例如，向单个物理服务器增加处理器、内存和储存空间，是有限制的。因此，在规模上按需、高效的扩展，是一个很大挑战。这会导致越来越大开销，因为企业必须采购更大型服务器以适应更多用户和数据。而且，执行硬件升级时，如果需要将数据库下线，会导致应用程序和功能服务的不可用。

这样造成的另外一个问题是，扩展的规模会低于或高于实际需求值。如果服务器扩展的过大，富余的能力就变成了不必要的浪费。如果扩展的不够大，下降的性能表现将会导致用户体验变差。

图6：RDBMS——服务器低于或高于实际需求值，导致低下的性能表现或不必要的浪费。

分布式 NoSQL 数据库利用商用硬件扩展规模，比如通过增加服务器来新增资源。这种可扩展能力能够使企业高效地进行扩展，在满足当前负载的情况下又不会过量部署硬件。

为了能够方便的进行扩展，分布式 NoSQL 数据库的安装和配置都非常简易。除了读写和存储的方式被设计成分布式的之外，所有的操作都可在任意规模下执行，包括管理和监视各种大大小小的集群。

图7：NoSQL——按需增加商用服务器，因此硬件资源与应用负载相匹配。

始终如一的可用性，支持全球化部署

随着通过 Web、移动应用接入的线上用户互动日益增加，可用性成为了主要值得关注的问题。这些关键任务型应用必须 7x24 小时保持在可用状态，不允许有异常情况发生。对于部署在单个物理服务器或基于共享存储的集群上的关系型数据库来说，交付 7x24 小时可用性是一个挑战。如果部署在单个服务器上并且服务器出现故障，或者部署在基于共享存储的集群上并且共享存储出现故障，关系型数据库就无法使用。

图8：RMDBS——服务器或存储设备故障导致整个数据库不可用

与关系型数据库相比，分布式 NoSQL 数据库不使用共享资源，将数据分组后分布地存储在多个数据库实例中。并且，数据可以从一个实例复制到其他实例中，从而提高可用性。Oracle 这样的关系型数据库要求使用另外的软件来进行复制，例如 Oracle Active Data Guard。NoSQL 数据库不需要，它的复制功能是内建的并且可以自动执行。此外，自动故障切换能够保障在一个节点失效的情况下，数据库可以通过向其他节点发送请求来实现不间断地执行读写操作。

图9：NoSQL——如果一个实例失效，应用程序可以向其他的节点发送请求。

由于用户互动逐渐迁移到线上，在不同的国家和地区保障可用性的需求变得至关重要。为多个数据中心建立一个数据库能够提高可用性，并且有助于灾难恢复。同时，还有益于提高性能表现，因为所有的读写操作都可以在最近的数据中心执行，所以减少了延时。

确保全球可用性对关系型数据库来说显得有些困难，因为需要额外使用其他软件，这增加了复杂性。而且，多个数据中心间的复制功能只能在故障切换的时候使用，因为在同一时间只有一个数据中心处于活动状态。以 Oracle 为例，它需要 Oracle GoldenGate 来进行容灾备份。在数据中心之间执行复制操作时，基于关系型数据库的应用程序会表现出性能下降或者数据中心彼此脱离同步状态的问题。

分布式 NoSQL 数据库具有数据中心之间的复制功能，这项功能是内建的，不需要使用额外的软件。此外，有些NoSQL数据库同时包含了单向和双向的复制功能，能够对数据中心实现充分的活动节点对活动节点的数据库部署。这使得数据库可以在不同国家和地区部署，并且提供本地数据给本地的应用程序和用户。这不仅提高了性能，并且通过硬件路由可以实现即刻故障切换，应用程序不必再等待数据库来发现故障以及后续的故障切换。

图10：RDBMS——要求使用另外的软件将数据复制到其他的数据中心

图11：NoSQL——数据中心间的复制功能是内建的并且可以是双向的

NoSQL更符合数据时代的要求

在云计算、移动化、社交媒体以及大数据这些技术的推动下，企业正在向数据时代迁移。开发人员和运营团队必须不断加快建立和维护 Web、移动和物联网应用的速度。而在支撑如今的 Web、移动和物联网应用方面，NoSQL 无疑是最具有优势的数据库技术。

全球 2000 强企业中已有几百家采用了 NoSQL 数据库，除此之外，还有上万家小型企业和创业公司也采用了 NoSQL。对于许多企业来说，刚开始只是将 NoSQL 用于缓存、概念验证或者小型应用程序，然后扩展到关键任务应用程序，到现在将 NoSQL 作为所有应用开发的基础。

在 NoSQL 的帮助下，企业在开发过程中能够更好地兼顾敏捷性和灵活性，最终提供所需的性能和可用性，以满足数据时代业务的要求。