为什么 SQL 正在击败 NoSQL，这对未来的数据意味着什么？

自从可以利用计算机做事以来，我们一直在收集的数据以指数级的速度在增长，因此对于数据存储、处理和分析技术的要求也越来越高。在过去的十年里，由于 SQL 无法满足这些要求，软件开发人员就抛弃了它，NoSQL 也就因此而渐渐发展起来：MapReduce，Bigtable，Cassandra，MongoDB 等等。

然而，如今 SQL 正在重新复出。云端的主要供应商们现在都提供了广受大众欢迎的托管关系型数据库服务：例如 Amazon RDS，谷歌 Cloud SQL，Azure 的 PostgreSQL 数据库 (Azure 将于今年发布)。用亚马逊自己的话来说就是 Aurora 数据库结合了 PostgreSQL 和 mysql 数据库，因此该产品一直是 “AWS 历史上增长最快的服务”。在 Hadoop 和 Spark 之上的 SQL 接口继续蓬勃发展。就在上个月，Kafka 推出了 SQL 支持。

在这篇文章中，我们将研究 SQL 现在复出的原因，以及这对未来的数据社区工程和分析意味着什么。

1

  第一章：

新希望

为了理解为什么 SQL 会卷土重来，让我们先了解一下最初设计它的原因。

好的故事都是起源于 20 世纪 70 年代

我们的故事始于 20 世纪 70 年代早期的 IBM 研究，那时关系型数据库就诞生了。当时的查询语言依赖于复杂的数学逻辑和符号。Donald Chamberlin 和 Raymond Boyce 两个人刚刚完成哲学博士学位，对关系型数据模型印象深刻，但是发现查询语言将成为其发展的一个主要瓶颈。于是他们便开始设计一种新的查询语言 (用他们自己的话说)：“让那些没有接受过数学和计算机编程方面正规训练的用户更容易使用”。

两个查询语言的比较

仔细想想这件事。在互联网出现之前，在个人电脑出现之前，当编程语言 C 首次被引入世界时，两位年轻的计算机科学家意识到，“计算机行业的成功很大程度上依赖于培养一种除了训练有素的计算机专家以外的用户。” 他们想要的是一种像英语一样易于阅读的查询语言，这也将包括数据库管理和操作。

其结果就是在 1974 年首次将 SQL 引入世界。在接下来的几十年里，SQL 将被证明是非常受欢迎的。随着诸如 System R、Ingres、DB2、Oracle、SQL Server、PostgreSQL、MySQL(等等) 关系型数据库接管了软件行业，SQL 也成为了与数据库交互的卓越语言，成为了一个日益拥挤、竞争激烈的生态系统的通用语言。

（遗憾的是，Raymond Boyce 从来没有机会见证 SQL 的成功。1 个月后他便死于脑动脉瘤，只做了一个最早的 SQL 演讲，当时他只有 26 岁，留下了一个妻子和一个年轻的女儿。）

有一段时间，似乎 SQL 成功地完成了它的任务。但后来互联网诞生了。

2

第二章：

NoSQL 的反击

在 Chamberlin 和 Boyce 都在开发 SQL 的同时，令他们没有想到的是在加州的第二组工程师正在研究另一个正在萌芽的项目，该项目后来会广泛扩散并威胁到 SQL 的存在。这个项目就是阿帕网，1969 年 10 月 29 日，它诞生了。

ARPANET 的一些创造者，最终演变成今天的互联网

SQL 一直发展的都很好，但是直到 1989 年，另一个工程师出现并发明了万维网。

发明网络的物理学家

像那些茂密的野草一样，互联网和网络蓬勃发展，极大地扰乱了我们的世界，但对于数据社区来说，它还造成了一个特别的麻烦: 跟以前相比，新的数据源以更高的数量和速度生成数据。

随着互联网的不断发展，软件社区发现，当时的关系型数据库无法处理这一新的负载。因此出现了一阵骚动的力量，就好像一百万个数据库突然过载了。

然后，两个新的互联网巨人取得了突破，并开发了他们自己的非关系型分布式系统来帮助解决这一新的数据冲击：由谷歌发布的 MapReduce(2004 年出版) 和 Bigtable(2006 年出版)，以及亚马逊 (Amazon) 发布的 Dynamo (2007 出版)。这些开创性的论文导致出现了更多的非关系数据库，包括 Hadoop(基于 MapReduce 文件，2006)，Cassandra(受 Bigtable 和 Dynamo 文件的启发，2008 年) 和 MongoDB(2009)。因为这些新系统基本上都是从零开始编写的，所以它们也没有使用 SQL，导致了 NoSQL 运动的兴起。

开发者社区的软件工程师们也接受了 NoSQL，而且跟 SQL 当时的出现相比，接受的群众范围更广了。这个原因很容易理解：NoSQL 是现在流行的；它承诺了规模和权力；这似乎是项目通往成功的捷径。但后来出现了问题。

典型的被 NoSQL 诱惑的软件开发人员。不要学这家伙。

开发人员很快发现，没有 SQL 实际上是非常受限的。每个 NoSQL 数据库都提供了自己独特的查询语言，这意味着：学习更多的语言 (并在同事之间传播知识); 增加了将数据库连接到应用程序的难度，导致代码之间有很强的耦合性; 缺乏第三方生态系统，需要公司开发自己的操作和可视化工具。

这些 NoSQL 语言是新的，但也没有完全开发出来。例如，关系型数据库已经运行很多年了，像为 SQL 添加必要的特性 (例如 JOIN) 这些工作早都已经完成了; NoSQL 语言的不成熟意味着在应用程序级别就会有更多的复杂性。缺乏 JOIN 也导致了反规格化，从而又导致数据膨胀和僵化。

一些 NoSQL 数据库添加了自己的 “类 sql” 查询语言，比如 Cassandra 的 CQL。但这常常会使问题变得更糟。如果使用跟别的东西完全一样的界面，如果越常见，实际上会导致心理产生更多的疑问：工程师压根就不知道支持什么，不支持什么。

社区中的一些人在早期就看到了 NoSQL 的问题（例如德维特和斯通布雷克在 2008 年就发现了）。随着时间的推移，通过使用过程中个人经验的辛苦积累，越来越多的软件开发人员也同意了这一点。

3

   第三章：

SQL的回归

最初被黑暗势力所诱惑的软件社区开始看到了光明，SQL 也上演了英雄回归的一幕。

首先是 Hadoop 上的 SQL 接口 (Spark 之后也是)，导致该行业兴起了 NoSQL，NoSQL 表示 “不只是 SQL”(Not Only SQL)。

紧接着 NewSQL 兴起了：完全接纳了 SQL 的新的可扩展数据库。来自于麻省理工学院 (MIT) 和布朗大学 (Brown) 研究人员的 H-Store(2008 年出版) 是最早的扩展 OLTP 数据库之一。谷歌再次引领了风向标，根据他们的 Spanner 论文（出版于 2012 年）（其作者包括原始的 MapReduce 作者）开创了地缘重复的 SQL 界面的数据库，其次再是 CockroachDB（2014）这样的其他先驱者。

与此同时，PostgreSQL 社区开始复苏，添加了一些关键的改进，比如 JSON 数据类型 (2012)，以及PostgreSQL 10 中的新特性的 potpourri：对分区和复制更好的本地支持，支持对 JSON 的全文搜索，以及其它更多的特性 (定于今年晚些时候发布的版本)。其他如 CitusDB(2016) 以及其他的公司 (今年发布的 TimescaleDB) 找到了新方法从而针对特定数据工作负载的扩展 PostgreSQL。

事实上，我们开发 TimescaleDB 的过程与这个行业的发展轨迹是密切相关。早期的 TimescaleDB 内部版本使用了我们自己的类 sql 查询语言 “ioQL”。是的，我们也没能抵挡住黑暗一面的诱惑: 我们感觉能够构建自己的查询语言应该会非常强大。然而，尽管这似乎是一条简单的道路，但我们很快意识到其实需要做更多的工作。我们还发现自己需要不断地去查找合适的语法，去查询那些已经可以用 SQL 进行查询的内容。

有一天，我们意识到构建自己的查询语言毫无意义。最关键的还是要接受 SQL。这是我们做出的最好的设计决定之一。顿时，一个全新的世界出现了。现在尽管我们的数据库才问世 5 个月, 但是用户却可以在生产环境上使用我们的数据库，还有很多其他的美好事物: 可视化工具 (Tableau), 与常见的 ORM 的连接器, 各种工具和备份选项, 丰富的在线教程和语法解释等等。

4

信谷歌

得永生

谷歌已经在数据工程和基础架构领域领先了十多年了。我们应该密切关注他们正在做的事情。

看看谷歌的第二大 Spanner 论文，就在四个月前发布的 (Spanner: 成为一个 SQL 系统，2017 年 5 月)，你会发现它支持我们的发现成果。

例如，谷歌开始的时候是在 Bigtable 上面构建，但后来发现不用 SQL 会造成很多问题 (强调了我们下面的所有引用):

虽然这些系统提供了数据库系统的某些优点，但它们缺少许多应用程序开发人员经常依赖的传统数据库特性。举一个关键的例子就是一个健壮的查询语言，这意味着开发人员必须编写复杂的代码来处理和聚合应用程序中的数据。因此，我们决定将 Spanner 变成一个完整的 SQL 系统，查询执行与 Spanner 的其他架构特性紧密集成 (例如强一致性和全局复制)。

在论文的后面，他们进一步抓住了从 NoSQL 过渡到 SQL 的基本原理:

Spanner 的原始 API 提供了对单个和交叉表的点查找和范围扫描的 NoSQL 方法。虽然 NoSQL 方法提供了一个简单的启动扳手的方法，并且在简单的检索场景中继续有用，但是 SQL 在表达更复杂的数据访问模式和将计算推到数据上提供了重要的附加价值。

本文还描述了 SQL 的采用是如何在扳手上不停止的，但实际上扩展到了谷歌的其余部分，这里的多个系统现在共享一个通用的 SQL 方言:

扳手的 SQL 引擎共享一个共同的 SQL 方言, 称为 “标准 SQL”, 与其他几个系统在谷歌上钻包括内部系统如 F1 和小孔 (等) 和外部系统如 BigQuery…

对于谷歌的用户来说，这降低了跨系统工作的障碍。一个开发人员或数据分析人员编写了针对 Spanner 数据库的 SQL，可以将他们对该语言的理解转移到 Dremel，而不必担心语法、空处理等细微的差异。

这种方法的成功不言自明。Spanner 已经成为主要谷歌系统的 “真相之源”，包括 AdWords 和谷歌游戏，而 “潜在的云客户对使用 SQL 非常感兴趣”。

考虑到谷歌首先帮助发起了 NoSQL 运动，很值得注意的是，它现在正在接受 SQL。(导致一些人最近想:“谷歌在 10 年的假时间里发送了大数据产业吗?”)

5

  这对数据的未来意味着什么: 

SQL将变成细腰

在计算机网络中，有一个概念叫做 “细腰结构”。

这个想法的出现解决了一个关键问题: 在任何给定的网络设备上，想象一个堆栈，底层的硬件层和顶部的软件层。中间可能会存在各种网络硬件; 同样，也存在存在各种各样的软件和应用程序。需要某种可以确保无论硬件发生了什么情况，软件仍然可以连接到网络的方法; 同样的也能确保无论软件发生什么，网络硬件都知道如何处理网络请求。

在网络中，细腰的角色由互联网协议 (IP) 扮演，它是为局域网设计的底层联网协议和更高级别的应用程序和传输协议的公共接口。(这是一个很好的解释。) 而且 (在一个广泛的简化中)，这个公共接口成为了计算机的通用语言，使网络能够相互连接，设备可以通信，而这种 “网络网络” 可以发展成为今天丰富多样的互联网。

我们认为 SQL 已经成为数据分析的细腰。

我们生活的时代，数据正在成为 “世界上最有价值的资源”(《经济学人》，2017 年 5 月)。因此, 我们看到了专业数据库 (OLAP、时间序列、文档、图表等)，数据处理工具 (Hadoop,Spark,Flink), 数据总线 (Kafka,RabbitMQ) 等呈现出了寒武纪大爆发式的情形。我们也有了更多需要依靠这些数据基础设施的应用程序, 无论是第三方数据可视化工具 (Tableau,Grafana PowerBI,Superset),web 框架 (Rails,Django) 或定制的数据驱动的应用程序。

像网络一样，我们也有一个复杂的堆栈，底层的基础设施和顶部的应用程序。通常，我们最终会编写大量的胶水代码来完成这个堆栈工作。但是胶水代码可能很脆弱: 需要精心的运维。

我们需要的是一个公共接口，允许堆栈的各个部分彼此通信。理想情况下，这个行业已经标准化了。它能让不同层之间的通信阻碍能够降到最小。

这就是 SQL 的力量。和 IP 一样，SQL 也是一个公共接口。

但 SQL 实际上比 IP 复杂得多。因为数据还需要支持人类分析。而且，SQL 创建者最初给它设定的目标之一就是可读性要高。

SQL 是完美的吗? 不，但社区中的大多数人都已经了解了这门语言。虽然已经有工程师在开发更自然的语言界面，但是这些系统最终会连接到哪里? 还是 SQL。

所以在堆栈的顶部还有一层。那一层就是我们人类。

SQL 回归

SQL 回来了。不只是因为在组装 NoSQL 工具时编写胶水代码的做法十分令人反感。不仅仅是因为学习各种各样的新语言是困难的。也不只是因为标准会带来各种优点。

也因为这个世界充满了数据。它包围着我们，束缚着我们。起初，我们依靠人类的感觉神经系统来处理它。现在，软件和硬件系统也变得足够智能，可以帮助我们。随着收集的数据越来越多，我们也可以更好地认识这个世界，系统的复杂性、存储、处理、分析以及对这些数据可视化的需求只会继续增长。

数据科学家尤达大师

我们可以生活在满大街的系统都是如纸一般脆弱，接口量达到数百万个的世界里。 或者我们可以再次选择 SQL，这样我们生活的世界也可能会变得越来越强大。

英文：Ajay Kulkarni，翻译：Vincent

原文：geek.csdn.net/news/detail/238939