为什么是NoSQL数据库？

 

为什么是NoSQL数据库？

 

 

向数字经济的转变正在推动NoSQL的采用

随着工业向数字经济转变，商业世界正在经历着巨大的变化。这是一个由互联网和其他21世纪的技术-云、移动、社交媒体和大数据-推动的经济。每一个数字经济业务的核心都是其网络、移动和物联网(物联网)应用程序：它们是当今公司与客户互动的主要方式，也是企业如何经营越来越多的业务。公司通过这些应用提供的体验在很大程度上决定了客户的满意度和忠诚度。

 

这些应用程序与ERP、HR和财务会计等遗留企业应用程序有何不同？今天的网络、移动和物联网应用程序共享以下一个或多个特性(如果不是全部的话)。它们需要：

 

• 支持大量并发用户(数万，甚至数百万)
• 向全球分布的用户群提供高度响应的体验
• 随时可用-没有停机时间
• 处理半结构化和非结构化数据
• 快速适应频繁更新和新特性的不断变化的需求。

 

构建和运行这些Web、移动和物联网应用程序创造了一套新的技术需求。新的企业技术体系结构需要比以往任何时候都更加灵活，并且需要一种能够适应前所未有的规模、速度和数据可变性水平的实时数据管理方法。关系数据库无法满足这些新的需求，因此企业正在转向NoSQL数据库技术。

 

仅举几个全球2000企业为关键任务应用程序部署NoSQL的例子，这些应用程序在最近的新闻报道中已经讨论过：

 

• 乐购，欧洲第一大零售商，为电子商务、产品目录和其他应用程序部署NoSQL
• 瑞安航空世界上最繁忙的航空公司，使用NoSQL为其移动应用程序供电，为300多万用户提供服务
• 万豪正在为每年380亿美元的预订系统部署NoSQL
• 甘尼特，这家美国第一大报纸发行商使用NoSQL作为其专有内容管理系统Presto
• 葛氏正在将NoSQL部署到其PredixPlatform中，以帮助管理工业互联网

 

五大趋势带来新的技术挑战

在更细粒度的层面上，企业正在采用NoSQL，以应对五大趋势带来的新的技术挑战和需求：

 

数字经济趋势	所需
#1：越来越多的顾客上网	扩展以支持数千(如果不是数百万)用户 以一致的高性能满足用户体验需求 每周7天，每天24小时保持可用性
#2：互联网把一切都连接起来了	用不同的数据结构支持许多不同的事物 支持硬件/软件更新，生成不同的数据 支持连续的实时数据流
#3：大数据越来越大	存储客户生成的半结构化/非结构化数据 存储来自不同源的不同类型的数据 存储成千上万/百万客户/事物生成的数据
#4：应用程序正在向云移动	按需扩展以支持更多客户，存储更多数据 全球范围内的应用程序-全球客户 降低基础设施成本，缩短上市时间
#5：世界移动了	创建“脱机优先”应用程序-不需要网络连接 将移动数据与云中的远程数据库同步 支持具有单个后端的多个移动平台

 

关系数据库为何不足

关系数据库诞生于大型机和商业应用的时代-早在互联网、云、大数据、移动和现在的数字经济之前。事实上，第一个商业实现是由Oracle在1979年发布的。这些数据库被设计成在一台服务器上运行-越大越好。增加这些数据库容量的唯一方法是升级服务器-处理器、内存和存储-以扩大规模。

 

NoSQL数据库是Internet指数增长和Web应用程序兴起的结果。谷歌在2006年发布了BigTable研究，亚马逊在2007年发布了Dynamo研究论文。这些数据库是为满足新一代企业需求而设计的：

 

需要敏捷发展向任何规模的操作。

 

敏捷发展

为了在数字经济中保持竞争力，企业必须创新-现在他们必须比以往任何时候都更快地创新。由于这一创新集中在现代网络、移动和物联网应用程序的开发上，开发人员必须比以往任何时候都更快地交付应用程序和服务。速度至关重要，但敏捷性也很重要，因为这些应用程序的发展速度远远快于ERP这样的遗留应用程序。关系数据库是敏捷性的主要障碍，因为它们不支持敏捷开发，因为它们的数据模型是固定的。

 

更快发展的灵活性

敏捷开发的一个核心原则是适应不断变化的应用需求：当需求发生变化时，数据模型也会发生变化。这对于关系数据库来说是个问题，因为数据模型是由静态模式固定和定义的。因此，为了更改数据模型，开发人员必须修改模式，或者更糟的是，请求数据库管理员进行“模式更改”。这会减慢或停止开发，这不仅是因为它是一个手工、耗时的过程，而且还影响到其他应用程序和服务。

 

图1：RDMBS-一个显式模式防止按需添加新属性。

 

相比之下，NoSQL文档数据库完全支持敏捷开发，因为它没有模式，并且不静态地定义数据必须如何建模。相反，它服从于应用程序和服务，因此也适合于开发人员如何对数据进行建模。使用NoSQL，数据模型由应用程序模型定义。应用程序和服务将数据建模为对象。

 

图2：json-数据模型随着新属性的添加而发展。

 

简单易用

应用程序和服务将数据建模为对象(例如Employee)，多值数据作为集合(例如，角色)，相关数据作为嵌套对象或集合(例如管理器)。但是，关系数据库将数据建模为行表，与列相关的数据建模为不同表中的行，多值数据建模为同一表中的行。关系数据库的问题是，数据是通过反汇编或“分解”和重新组装对象来读取和写入的。这就是对象关系的“阻抗失配”。解决方法是对象关系映射框架，它充其量是低效的，在最坏的情况下是有问题的。

 

例如，考虑一个用于管理简历的应用程序。它以对象的形式与简历交互，用户对象。它包含技能数组和职位集合。但是，将简历写入关系数据库需要应用程序“分解”用户对象。

 

存储此简历需要应用程序将六行插入三个表，如下所示：

 

图3：RDMBS-应用程序“分解”了存储在多个表中的数据行。

 

读取此配置文件需要应用程序从三个表中读取六行：

 

图4：RMDBS-查询返回重复的数据，应用程序必须过滤掉它。

 

相反，面向文档的NoSQL数据库读取和写入以JSON格式的数据-JSON是Web、移动和物联网应用程序使用和生成数据的事实上的标准。它不仅消除了对象-关系阻抗不匹配，还消除了ORM框架的开销，并简化了应用程序开发，因为对象是在没有“分解”对象的情况下读取和编写的-也就是说，可以将单个对象读入或写入单个文档，如下所示：

 

图5：json-应用程序可以将带有嵌套数据的对象存储为单个文档。

 

查询和SQL怎么办？

CouchBaseServer4.0引入了N1QL，这是一种强大的查询语言，它将SQL扩展到JSON，使开发人员能够利用SQL的强大功能和JSON的灵活性。它不仅支持标准SELECT/FROM/WHERE语句，还支持聚合(组BY)、排序(排序)、联接(左外部/内部)以及嵌套数组和集合的查询。此外，还可以通过组合、部分、覆盖索引等方法来提高查询性能。

 

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 ORDER BY cnt DESC;

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

 

以任何规模运作

支持网络、移动和物联网应用程序的数据库必须能够在任何规模上运行。虽然可以扩展像Oracle这样的关系数据库(例如使用Oracle RAC)，但是这样做通常是复杂的、昂贵的，而且不完全可靠。例如，在Oracle中，使用RAC技术进行扩展需要大量组件，并且会造成单个故障点，从而危及可用性。相比之下，NoSQL分布式数据库-采用扩展的体系结构，没有单一的故障点-提供了引人注目的操作优势。

 

规模性能弹性

应用程序和服务必须支持越来越多的用户和数据-数百到数千到数百万用户，以及千兆至兆字节的操作数据。同时，他们必须扩大规模以保持业绩，并且必须有效地做到这一点。

 

数据库必须能够缩放读写，和储藏室。

 

对于仅限于扩展的关系数据库来说，这是一个问题-即向单个物理服务器添加更多的处理器、内存和存储。因此，有效地按需扩大规模的能力是一项挑战。它变得越来越昂贵，因为企业不得不购买越来越大的服务器来容纳更多的用户和更多的数据。此外，如果数据库必须脱机以执行硬件升级，则可能导致停机。

 

图6：RDMBS-服务器太大或太小，导致不必要的成本或糟糕的性能。

 

然而，分布式NoSQL数据库利用普通硬件进行扩展-即仅仅通过添加更多的服务器来添加更多的资源。扩大规模的能力使企业能够更有效地扩大规模，办法是：(A)不部署比满足当前负载所需的硬件，(B)利用成本较低的硬件和/或云基础设施；(C)按需扩展，而且不需要停机时间。

 

图7：NoSQL-按需添加商品服务器，以便硬件资源与应用程序负载匹配。

 

除了能够有效和高效地扩展之外，分布式NoSQL数据库还易于安装、配置和扩展。它们被设计用来分发读、写和存储，它们被设计成可以在任何规模上运行-包括管理和监视集群的大小。

 

全局部署的可用性

随着越来越多的客户通过网络和移动应用进行在线交流，可用性成为一个主要的问题，如果不是主要的话。这些关键任务应用程序必须一天24小时、每周7天提供-无一例外。对于部署到单个物理服务器或依赖共享存储的集群的关系数据库来说，提供24x7可用性是一个挑战。如果部署为单个服务器而失败，或者作为群集和共享存储失败，则数据库变得不可用。

 

图8：RDBMS-服务器或存储设备的故障使整个数据库崩溃。

 

与关系技术不同，分布式NoSQL数据库分区并将数据分发给多个数据库实例，没有共享资源。此外，可以将数据复制到一个或多个实例中，以实现高可用性(群集间复制)。虽然像Oracle这样的关系数据库需要单独的软件来进行复制，例如Oracle活动数据保护，但NoSQL数据库不需要-它是内置的，而且是自动的。此外，自动故障转移确保如果节点失败，数据库可以通过向另一个节点发送请求来继续执行读和写操作。

 

图9：NoSQL-如果一个实例失败，应用程序可以向另一个实例发送请求。

 

随着客户参与向网上转移，需要在多个国家和(或)区域提供服务变得至关重要。虽然将数据库部署到多个数据中心可以提高可用性并有助于灾难恢复，但它也具有提高性能的好处，因为所有的读写都可以在最近的数据中心执行，从而减少延迟。

 

对于需要单独添加的关系数据库(这增加了复杂性)，或者在多个数据中心之间的复制只能用于故障转移的情况下，确保全局可用性是很困难的，因为一次只有一个数据中心处于活动状态。例如，Oracle需要Oracle GoldenGate。在数据中心之间进行复制时，构建在关系数据库上的应用程序可能会出现性能下降或发现数据中心严重不同步。

 

图10 RDMBS-需要单独的软件将数据复制到其他数据中心。

 

一个分布式的NoSQL数据库包括数据中心之间的内置复制-不需要单独的软件。此外，有些还包括单向复制和双向复制，从而能够对多个数据中心进行完全主动的部署-使数据库能够部署到多个国家和/或区域，并为本地应用程序及其用户提供本地数据访问。这不仅可以提高性能，还可以通过硬件路由器立即进行故障转移-应用程序不必等待数据库发现故障并执行自己的故障转移。

 

图11数据中心之间的NoSQL复制是完全内置的，并且可以是双向的.

 

NoSQL更适合数字经济的需求

随着企业转向由云、移动、社交媒体和大数据技术支持的数字经济，开发人员和运营团队必须更快、更大规模地构建和维护Web、移动和物联网(物联网)应用程序。NoSQL日益成为支持当今网络、移动和物联网应用程序的首选数据库技术。

 

数百家全球2000企业，以及数以万计的小型企业和初创企业，都采用了NoSQL。对许多人来说，NoSQL的使用始于缓存、概念证明或小型应用程序，然后扩展到目标任务关键应用程序，现在是所有应用程序开发的基础。

 

使用NoSQL，企业能够更好地进行敏捷开发和任何规模的操作，并提供满足数字经济业务需求所需的性能和可用性。

 

翻译自英文网站：https://www.couchbase.com/resources/why-nosql

想要看《为什么不是NoSQL数据库》白皮书（PDF格式英文）？

https://pan.baidu.com/s/14uwyZiD-Dzore8cGKBKAXQ