（DDIA）SQL与NoSQL数据模型简介

翻译《Designing Data-Intensive Applications》
作者：Martin Kleppmann
译者：雨钓（有增改）

一、SQL与NOSQL起源与优劣对比

1.1、SQL

今天最著名的数据结构可能就是SQL了，一种基于Edgar Codd在1970年提出的关系模型： 数据被组织成关系(SQL中的表)，其中每个关系是一个无序的元组集合(SQL中的行)， 关系模型是一个理论上的建议，许多人当时怀疑它是否能有效地实现。 然而，到20世纪80年代中期，关系数据库管理系统(RDBMSes)和SQL已经成为大多数人的首选工具，他们需要存储和查询带有某种regular结构的数据。 关系数据库的主导地位持续了大约25-30年——这在计算历史上是绝无仅有的；

关系数据库的根源在于业务数据处理，主要是执行在上世纪六、七十年代的一种大型计算机上。它所针对的用例从今天的角度来看是很平常的，例如：典型的交易处理(销售或银行中转业务，航空公司预订，仓库库存)和批处理（ 用户的发票、工资、报告）。哪些当时与关系型数据库共存的其他数据库，由于其本身设计的问题，使得应用程序开发人员需要对数据库中数据的内部结构进行大量的思考和优化。而与之相反，关系模型的目标是将实现细节隐藏在一个更干净的接口后面。

多年来，针对于数据存储和查询的方法有很多。 20世纪70年代和80年代初，网络模型和层次模型是当时主要的选择。 但是伴随着关系模式的出现和快速发展，关系模型主键占据主导地位。 在上世纪80年代末和90年代初，Object数据库再次出现, XML数据库出现于本世纪初，但只出现了小众的采用。 关系模型的每个竞争对手在这段时间内都进行了大量的宣传和炒作但是仍然未能生存下来。

随着计算机变得更加强大和网络化，它们开始被用于越来越多样化的场景。值得注意的是，关系数据库在其原始的业务数据处理范围之外，非常好地推广到针对WEB的应用上。 你在web上看到的许多东西仍然是由关系数据库驱动的，比如在线发布、讨论、社交网络、电子商务、游戏、软件服务等等。

1.2、The Birth of No SQL

2010年 出现的NOSQL是推翻关系模型统治地位的一次最新尝试。“No SQL”这个名字是不准确的，因为它实际上并不是指任何特定的技术——它最初只是一个简单的Twitter在2009年提出的一个标签，主要关于分布式，非关系数据库，只后很快就传遍了业界。现在，许多有趣的数据库系统都与No SQL相关，并且它被重新定义为***NOT Only SQL***。

在NO SQL数据库的情况下，有几个驱动因素，包括:

• 比关系型数据库更好的扩展性，包括更大的数据集以及吞吐量。

• 更好的开源特性而不是商业化的。

• 拥有关系模型所不支持的特定查询操作

• 抛弃了关系模型中对schema的限制，支持更动态和更具代表性的数据模型

不同的应用程序有不同的需求，对于一个用例场景来说，最好的技术选择可能与另一个用例的最佳选择是不同。因此，在可预见的将来，关系数据库将继续与广泛的非关系数据存储共存，这一概念有时被称为***polyglot persistence***

二、The Object-Relational Mismatch

当今大多数应用程序开发都是在面向对象的编程语言中完成的，这导致了开发人员对SQL数据模型存在很多意见，因为如果数据存储在关系表中，那么在应用代码中的对象（面向对象的语言，如JAVA）和关系型模型中的表之间需要一个笨拙的转换层。 模型之间的讨论有时被称为***impedance mismatch***（ 从电子产品中借用的术语。每个电路的输入和输出都有一定的阻抗。当你将一个电路的输出连接到另一个电路的输入时，如果两个电路的输出和输入阻抗匹配，连接上的power transfer就会最大化。阻抗不匹配会导致信号反射和其他问题）

因此则常见的面向对象的开发中，如JAVA Web项目中通常会使用如Active Record和Hibernate等***对象-关系映射(ORM)框架***，以减少这个翻译层所需的样板代码量。但它们并不能完全隐藏这两个模型之间的差异。

例如，上图说明了在关系模式中如何表示一份简历(概要文件中的链接)。整个文件可以通过一个唯一一的标识符user_id来标识， 像first_name和last_name这样的字段恰好显示为每一个用户，因此它们可以被建模为users表上的列。 然而，大多数人在他们的职业(职位)中有不止一份工作，而且人们可能会有很多的教育时期和任何数量的联系信息，从用户和项目之间具有一对多的关系，可以用不同的方式表示:

• 1、在传统的SQL模型(在SQL:1999之前)中，最常见的标准化 的 表现是将位置、教育和联系信息放在不同的表中，并通过外键引用放在users表中，如图所示。

• 2、后来版本的SQL标准增加了对结构化数据类型和xml数据的支持；允许将多值数据存储在单个行中，并支持在这些文档中查询和索引。这些特性在Oracle、IBM DB2、MS SQL Server和Post‐gre SQL(6、7)进行了不同程度的实现。JSON数据类型也被几个数据库所支持，包括IBM DB2、SQL和Postgre SQL。

• 3、第三种选择是将工作、教育和联系信息作为JSON或XML Document进行编码，将其存储在数据库的文本列上，并让应用程序对其结构和内容进行优先处理。在这个设置中，通常无法使用数据库查询在编码列内的值。

对于像上面提到的类似简历这样的数据结构，它通常是一个自包含的文档，JSON可能非常合适：参见示例2-1。JSON相较于XML而言要简单得多，因此也更具吸引力。面向文档的数据库如Mongo DB、Rethink DB、Couch DB和Espresso都支持这个数据模型。

Example 2-1. Representing a Linked In profile as a JSON document