为什么 SQL 正在击败 NoSQL，数据的未来是什么？

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

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

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

第一章：新希望

为了理解为什么 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 成功地完成了它的任务。但后来互联网诞生了。

第二章：NoSQL 的反击

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

阿帕网的一些创造者，最终演变成今天的互联网（来源） 

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

发明万维网的物理学家（来源） 

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

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

然后，两个新的互联网巨人取得了突破，并开发了他们自己的非关系型分布式系统来帮助解决这一新的数据冲击：由谷歌发布的 MapReduce（2004 年发表）和 Bigtable（2006 年发表），以及亚马逊的 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。但这常常会使问题变得更糟。如果使用跟别的东西完全一样的界面，如果越常见，实际上会导致心理产生更多的疑问：工程师压根就不知道支持什么，不支持什么。 

类 SQL 的查询语言就像《星球大战》假日特别节目。不接受模仿（而且总是绕过《星球大战》的特别节日）

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

第三章：SQL 的回归 

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

首先是 Hadoop 上的 SQL  接口（Spark 之后也是），导致该行业重新阐述 NoSQL 为“不只是 SQL”（Not Only SQL）（耶，干的不错！）。

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

与此同时，PostgreSQL 社区开始复苏，添加了一些关键的改进，比如 JSON 数据类型（2012），以及 PostgreSQL 10 中的新特性的集锦：更好的原生支持分区和复制，支持对 JSON 的全文搜索，以及其它更多的特性（定于今年晚些时候发布的版本）。其他如 CitusDB（2016）以及鄙公司（今年发布的 TimescaleDB）找到了针对特定数据任务来扩展 PostgreSQL 的新方法。 

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

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

信谷歌，得永生

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

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

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

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

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

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

本文还描述了 SQL 的采用是如何没有止步于 Spanner，而是实际上扩展到了谷歌的其余部分，这里的多个系统现在共享一个通用的 SQL 方言:

Spanner 的 SQL 引擎共享一个共同的 SQL 方言，称为“标准 SQL”，包括几个谷歌内部的系统如 F1 和 Dremel （其中之一），以及如 BigQuery 这样的外部系统…

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

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

考虑到谷歌首先帮助发起了 NoSQL 运动，很值得注意的是，它现在正在接受 SQL。（导致一些人最近想：“谷歌过去 10 年给大数据产业做的都是假象吗？”）

这对数据的未来意味着什么：SQL 将变成细腰

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

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

 

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

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

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

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

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

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

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

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

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

SQL 回归

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

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

数据科学家尤达大师 

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