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

作者：Ajay Kulkarni

随着计算机的日益普及，各种应用每天产生的数据量呈指数级增长。如何存储这些数据，有效处理分析这些数据,并从中提取有价值的信息,是当下迫切需要解决的问题。在过去的十年里，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。一切都遵循能量守恒定律。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。