class="topic_img" alt=""/>
随着计算机的日益普及，各种应用每天产生的数据量呈指数级增长。如何存储这些数据，有效处理分析这些数据，并从中提取有价值的信息，是当下迫切需要解决的问题。在过去的十年里，NoSQL 在软件工程师阵营里越来越受欢迎，其中最重要的实现是 MapReduce ，Bigtable,Cassandra，MongoDB,等产品。 它主要用于解决 SQL 的可扩展性问题。
然而今天 SQL 开始回归。几乎所有的云计算服务提供商都在提供备受青睐的关系型数据库管理服务：例如 Amazon RDS，Google Cloud SQL，Azure 的 PostgreSQL 数据库（Azure 今年推出）。在亚马逊看来，其 PostgreSQL 和 MySQL 兼容的数据库产品 Aurora 一直是 AWS 历史上增长最快的服务。Hadoop 和 Spark 之上的 SQL 接口继续迅猛发展。就在上个月，Kafka 推出了 SQL 支持。
在这篇文章中，我们将研究 SQL 备受青睐的原因以及这对未来的数据社区工程和分析意味着什么。
第 1 部分：新希望的崛起
想要了解 SQL 为什么回归，让我们先了解他最初的设计初衷。
故事始于 20 世纪 70 年代初的 IBM 研究院，其中关系型数据库诞生了。那时候，查询语言依赖于复杂的数学逻辑和符号。Donald Chamberlin 和 Raymond Boyce 两位博士对关系型数据模型造诣颇深，看到查询语言将成为其主要瓶颈。他们开始设计一种新的查询语言（以他们自己的话来说）：“ 用户使用更容易，不需要再参加数学或计算机程序设计方面的正规培训 ”。
回想在互联网之前，在 PC 出现以前，当程序设计语言C首次被引入世界时，两名年轻的计算机科学家意识到，“计算机行业的成功很大程度上依赖于培养一种除了训练有素的计算机专家以外的用户。“他们渴望一种与英文一样容易阅读的查询语言，包括数据库管理和操作。
结果是 SQL 在 1974 年首次被引入世界，成了关系型数据库的最主要语言。在接下来的几十年里，SQL 被证明也是很受欢迎的。作为关系型数据库，如 System R，Ingres，DB2，Oracle，SQL Server，PostgreSQL，MySQL（等等）在软件行业里的发展壮大，SQL 也成为了与数据库进行交互的首选语言，成为了一个日益拥挤、竞争激烈的生态系统的通用语言。。
（不幸的是，Raymond Boyce 从来没有机会见证 SQL 的成功，他只做了一个早期的 SQL 演讲，1 个月后他便死于脑动脉瘤，当时他只有 26 岁，留下了一个妻子和一个年轻的女儿。）
有一段时间，似乎 SQL 已经成功地履行了它的使命。接着互联网出现了。
第 2 部分：NoSQL 反击
虽然 Chamberlin 和 Boyce 正在开发 SQL，但他们没有意识到的是，加利福尼亚州的另一批工程师正在开展另一个新兴项目，该项目逐渐成熟后，明显威胁到 SQL 的存在。该项目就是 ARPANET，诞生于 1969 年 10 月 29 日。
但是此前 SQL 发展一直很好，直到 1989 年，另一位工程师的出现并发明了万维网。
互联网和 Web 的蓬勃发展正在改变着我们的世界，但是对于数据社区来说，也是很让人头痛的：数据以大的量级和更快的速度爆炸式增长。
随着互联网的不断发展和壮大，软件社区发现当时的关系数据库无法应对新的负载压力，就好像一百万个数据库突然过载让人抓狂一般。
然后两家新的互联网巨头取得突破，并开发了自己的非关系型分布式系统来应对这种新的数据冲击：Google 的 MapReduce（2004 年发布）和 Bigtable（2006 年发布）以及亚马逊的 Dynamo（2007 年发布）。这些开创性论文导致出现了更多的非关系型数据库，包括 Hadoop（基于 MapReduce 论文，2006），Cassandra（Bigtable 和 Dynamo 的深度解析，2008 ）和 MongoDB（2009））。因为这些都是从零开始大量编写的新系统，避开了 SQL，导致了 NoSQL 运动的兴起。
开发者社区的软件工程师们逐渐地也接受了 NoSQL，相较于 SQL 当时的出现，被越来越多的工程师所接受。这个原因非常容易理解：NoSQL 是现在流行的；它承诺了规模和权力；这似乎是项目通往成功的捷径。但后来问题出现了。
开发人员很快发现，不用 SQL 的局限性。每个 NoSQL 数据库都提供了自己独特的查询语言，这意味着：要学习更多的语言（并向同事教授）; 将这些数据库连接到应用程序的难度增加，导致大量胶水代码的出现（代码之间有很强的耦合性）;缺乏第三方生态系统，要求企业必须开发自己的操作和可视化工具。
这些 NoSQL 语言是新的，也没有完全开发。例如，关系型数据库已经运行很多年了，为 SQL 添加必要的功能（例如 JOIN）也早都已经完成了，NoSQL 语言的不成熟意味着在应用程序级别就会有更多的复杂性。缺乏 JOIN 也导致了非规范化，导致数据膨胀和僵化。
一些 NoSQL 数据库添加了自己的“类 SQL”的查询语言，如 Cassandra 的 CQL。但这往往使问题更糟。使用几乎相同的界面，却让内心更纠结：工程师不知道什么是支持的，什么不是。
社区中的一些人在早期就看到了 NoSQL 的问题（例如，DeWitt 和 Stonebraker 在 2008 年就看到了）。经过时间的实战检验，以及使用过程中的经验积累，越来越多的软件开发人员也看到了这一点。
第 3 部分：回归 SQL
经历了黎明前的黑暗，软件社区看到了曙光，那就是回归 SQL。
首先是 Hadoop（之后的 Spark）之上的 SQL 接口，引导业界兴起了 NoSQL ,NoSQL“不仅仅是 SQL”。
然后，NewSQL 的兴起：新的可扩展性数据库，完全支持 SQL。来自于麻省理工学院(MIT)和布朗大学(Brown)研究人员的H-Store （2008 年发布）是第一个可扩展 OLTP 数据库之一。Google 在发布的第一份 Spanner 论文（2012 年发布）（其作者包括最初的 MapReduce 作者）中揭示这是基于 SQL 的查询语言，可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性，从而开创了可地理复制的 SQL 界面的数据库，接着是 CockroachDB（2014）这样的先驱者。
与此同时，PostgreSQL 社区开始复苏，增加了 JSON 数据类型（2012），以及 PostgreSQL 10 的新特性：对分区和复制更好的本地支持，JSON 的全文搜索支持等（今年晚些时候发布）。其他像 CitusDB（2016）和其他的公司(今年发布的 TimescaleDB)发现了新的方法从而针对特定数据工作负载的扩展 PostgreSQL。
事实上，我们开发 TimescaleDB 的过程与业界的发展轨迹密切相关。早期的 TimescaleDB 内部版本使用了我们自己的类 sql 查询语言“ioQL”。是的，我们正是被困难驱动着：构建我们自己的查询语言才能更强大。但是，虽然看似简单，但我们很快意识到，我们必须做更多的工作：例如，决定语法，构建各种连接器，培训用户等。我们还发现自己需要不断地去查找合适的语法，去查询那些已经可以用 SQL 进行查询的内容。
有一天，我们意识到建立自己的查询语言是没有意义的。关键还是要拥抱 SQL。这是我们做出的最好的决策之一。同时也开启了一个全新的世界。今天，即使我们的数据库才问世 5 个月，但我们的用户完全可以使用我们的产品，并获得各种各样支持：可视化工具（Tableau），通用 ORM 连接器，各种工具和备份选项，大量的在线教程和语法说明等。
但是不要把我们的话放在心上，看看谷歌
Google 已经十多年来一直处于数据工程和基础设施的领先地位。我们应该密切关注他们正在做什么。
看看谷歌的第二大 Spanner 论文，仅在四个月前发布（Spanner：成为一个 SQL 系统，2017 年 5 月），你会发现它支持我们的发现成果。
例如，Google 开始在 Bigtable 之上开发，但是后来发现缺少 SQL 产生了一系列问题（在下面的所有引号中有强调）：
“虽然这些系统提供了数据库系统的一些优势，但它们缺乏应用程序开发人员常常依赖的许多传统数据库功能。一个关键的例子是强大的查询语言，这意味着开发人员必须编写复杂的代码来处理和聚合应用程序中的数据。因此，我们决定将 Spanner 变成一个功能齐全的 SQL 系统，其查询执行与 Spanner 的其他架构功能（如强一致性和全局复制）紧密集成。
在本文的后面，他们进一步了解从 NoSQL 转换到 SQL 的理由：Spanner 的原始 API 提供了为单个和交叉表的点查找和范围扫描的 NoSQL 方法。虽然 NoSQL 方法提供了启动 Spanner 的简单路径，并且在简单的检索方案中继续有用， 但 SQL 在表达更复杂的数据访问模式并将计算推送到数据方面提供了重要的附加价值。
本文还介绍了如何在 Spanner 上使用 SQL 并不会停止，哪怕某一个数据中心停止运转，仍然可用。但实际上扩展到 Google 的其余部分，其中多个系统共享一个通用的 SQL 语言：
Spanner 的 SQL 引擎与 Google 的其他几个系统共享一个称为“标准 SQL”的常见 SQL 语言，包括内部系统，如 F1 和 Dremel（以及其他）以及外部系统，如 BigQuery 。
对于 Google 用户，这会降低跨系统的工作障碍。对 Spanner 数据库编写 SQL 的开发人员或数据分析师可以将他们对语言的理解转移到 Dremel，而不用担心语法，NULL 处理等方面的微妙差异。
这就是这种方法的成功奥秘。当“潜在云客户对 SQL 有浓厚兴趣”时，Spanner 已经成为 Google 主要系统的根基（包括 AdWords 和 Google Play） 。
考虑到 Google 最先启动了 NoSQL 的运动，这是非常显著的，它今天正在回归 SQL。（引起一些人反思：“ Google 10 年前挺进大数据市场就是个大忽悠吗”？）
这对数据的未来意味着什么：SQL 将变成窄腰
在计算机网络中，有一个叫做“窄腰”的概念。
这个概念的出现解决了一个关键问题：在任何给定的网络设备上，想象一个堆栈，底层硬件层和顶层软件层。中间可能会存在各种网络硬件;类似地，也存在各种软件和应用程序。需要一种方法来确保无论硬件如何，软件仍然可以连接到网络; 无论软件如何，网络硬件都知道如何处理网络请求。
在网络中，窄腰的角色由互联网协议(IP)扮演，它是为局域网设计的底层联网协议和更高级别的应用程序和传输协议的公共接口。(这是一个很好的解释。)而且（在一个广泛的过度简化）中，这个公共接口成为了计算机的通用语言，使网络互连，设备进行通信，而这个“网络网络”可以发展成为今天丰富多样的互联网。
我们认为，这等同于 SQL 已成为数据分析的“窄腰。
我们生活在一个数据正在成为“世界上最宝贵资源”的时代（”
“经济学人”，2017 年 5 月）。我们看到了 Cambrian 的专业数据库（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。一切都遵循能量守恒定律。
相关文章
