译者注：经过多年的沉寂，今天的SQL正在卷土重来为什么？这对数据社区有什么影响？查看本文中的分析。下面是翻译。自从我们能够使用计算机做事以来，我们收集的数据量就呈指数增长，需要越来越多的数据存储、处理和分析技术。在过去的十年里，因为SQL不能满足这些要求，软件开发者放弃了它，NoSQL逐渐发展起来：MapReduce、Bigtable、Cassandra、MongoDB等。然而，今天，SQL正在卷土重来。现在主要的云提供商提供流行的托管关系数据库服务：例如AmazonRDS、GoogleCloudSQL、Azure的PostgreSQL数据库（Azure将在今年发布）。用亚马逊自己的话说，Aurora数据库结合了PostgreSQL和mysql数据库，因此该产品一直是“AWS历史上增长最快的服务”。基于Hadoop和Spark的SQL接口继续蓬勃发展。就在上个月，Kafka引入了SQL支持。在本文中，我们探讨了SQL现在卷土重来的原因，以及这对数据社区工程和分析的未来意味着什么。第1章：新希望要理解SQL卷土重来的原因，让我们首先了解一下设计它的原因。好故事始于1970年代我们的故事始于IBM在70年代初期的研究，当时关系数据库诞生了。当时的查询语言依赖于复杂的数学逻辑和符号。刚刚完成博士学位的DonaldChamberlin和RaymondBoyce对关系数据模型印象深刻，却发现查询语言会成为他们发展的一大瓶颈。因此，他们着手设计一种新的查询语言（用他们自己的话说）“对于没有接受过正规数学和计算机编程培训的用户来说更容易使用”。两种查询语言的比较?这个问题想一想。在互联网出现之前，在个人电脑出现之前，当编程语言C***被介绍给世界时，两位年轻的计算机科学家意识到“计算机行业的成功很大程度上取决于培养计算机专家以外的用户。“他们想要的是一种像英语一样易于阅读的查询语言，其中还包括数据库管理和操作。结果是1974年向世界介绍了SQL。在接下来的几十年里，SQL将被证明是非常流行。随着SystemR、Ingres、DB2、Oracle、SQLServer、PostgreSQL、MySQL（以及其他）等关系数据库接管软件行业，SQL也成为与数据库交互的卓越语言，成为一个日益拥挤和竞争激烈的生态系统。（遗憾的是，RaymondBoyce从未有机会见证SQL的成功。他在1个月后死于脑动脉瘤，只给出了最早的SQL演讲之一，当时他只有26岁，留下了一个妻子和一个年幼的女儿。）有一段时间，SQL似乎成功地完成了它的任务。但后来互联网发生了。第2章：NoSQL在Chamberlin和Boyce中反击当他们都在开发SQL时，他们没有做什么我没有意识到加利福尼亚州的第二组工程师正在从事另一个萌芽项目，该项目后来广泛传播并威胁到SQL的存在。这个项目就是Arpanet，1969年10月29日，它诞生了。ARPANET的一些创建者最终演变成今天的Internet，SQL一直表现良好，直到1989年另一位工程师出现并发明了万维网。发明网络的物理学家像那些茂盛的野草一样，互联网和网络已经蓬勃发展并极大地扰乱了我们的世界，但对于数据社区来说，它也造成了一个特别的麻烦：新数据源的输入速度比以往任何时候都快.数据以体积和速度生成。随着Internet的不断发展，软件社区发现当时的关系数据库无法处理这种新的负载。于是一股汹涌的力量涌了上来，仿佛百万数据库突然超载。然后，两个新的互联网巨头突破并开发了自己的非关系分布式系统来帮助应对这种新的数据冲击：谷歌的MapReduce（2004年发布）和Bigtable（2006年发布），以及亚马逊的Dynamo（2007年发布）。这些开创性论文导致了更多非关系数据库的出现，包括Hadoop（基于MapReduce论文，2006年）、Cassandra（受Bigtable和Dynamo论文的启发，2008年和2009年）和MongoDB（2009年）。因为这些新系统基本上是从头开始编写的，所以它们也没有使用SQL，从而导致了NoSQL运动的兴起。开发者社区中的软件工程师也接受了NoSQL，并且接受了比当时SQL更广泛的受众。原因很容易理解：NoSQL现在很流行；它承诺规模和力量；这似乎是项目成功的最短路径。但后来出了点问题。被NoSQL诱惑的典型软件开发人员。不要学这种人开发人员很快发现，如果没有SQL，它实际上非常有限。.每个NoSQL数据库都提供自己独特的查询语言，这意味着：学习更多的语言（并在同事之间传播知识）；增加了应用程序连接数据库的难度，导致代码之间的耦合性强；缺乏第三方生态系统需要公司开发自己的运营和可视化工具。这些NoSQL语言是新的，但还没有完全发展。例如，关系型数据库已经存在多年，并且已经完成了向SQL添加必要功能（例如JOIN）的工作；NoSQL语言的不成熟意味着在应用层面存在更多的复杂性。缺少JOIN也会导致非规范化，进而导致数据膨胀和僵化。一些NoSQL数据库添加了自己的“类SQL”查询语言，例如Cassandra的CQL。但这往往会使问题变得更糟。如果和其他东西一样使用相同的接口，如果再普通一些，其实会导致更多的心理疑惑：工程师根本不知道支持什么，不支持什么。类SQL的查询语言就像是《星球大战》的节日特惠。接受而不是模仿。社区中的一些人很早就发现了NoSQL的问题（例如2008年的DeWitt和Stonebraker）。随着时间的推移，通过亲身体验使用它的努力，越来越多的软件开发人员认同。第三章：SQL的回归最初被黑暗势力勾引的软件社区开始重见天日，SQL也上演了英雄归来的一幕。首先是Hadoop上（以及Spark之后）的SQL接口，导致了业界NoSQL的兴起，意思是“NotOnlySQL”。然后是NewSQL：一个完全包含SQL的新的可伸缩数据库。来自麻省理工学院(MIT)和布朗大学(Brown)的研究人员的H-Store（2008年出版）是最早的扩展OLTP数据库之一。谷歌再次引领潮流，根据他们的Spanner论文（2012年发表）（其作者包括原始MapReduce作者），开创了具有地理重复SQL接口的数据库，其次是CockroachDB(2014)等其他先驱。与此同时，PostgreSQL社区开始复苏，增加了一些关键的改进，例如JSON数据类型（2012年），以及PostgreSQL10中新特性的大杂烩：更好的原生支持分区和复制，支持全-基于JSON的文本搜索，以及更多功能（计划于今年晚些时候发布）。CitusDB(2016)和其他人（今年发布的TimescaleDB）等其他人已经找到了针对特定数据工作负载扩展PostgreSQL的新方法。事实上，我们开发TimescaleDB的过程与这个行业的发展轨迹息息相关。早期的TimescaleDB内部使用我们自己的类似SQL的查询语言“ioQL”。是的，我们也无法抗拒阴暗面的诱惑：我们觉得能够构建我们自己的查询语言应该是非常强大的。然而，虽然这似乎是一条简单的道路，但我们很快意识到还需要做更多的工作。我们还发现自己一直在寻找正确的语法来查询已经可以使用SQL查询的内容。有一天，我们意识到构建自己的查询语言毫无意义。最关键的是接受SQL。这是我们做过的最重大的设计决策之一。顿时，一个全新的世界出现了。现在，即使我们的数据库只有5个月大，用户也可以在生产环境中使用我们的数据库，还有很多其他好东西：可视化工具(Tableau)、通用ORM的连接器、各种工具和备份选项、广泛的在线教程和语法解释，等等。相信谷歌，得不朽十多年来，谷歌一直在数据工程和基础设施领域处于领先地位。我们应该密切关注他们在做什么。看看四个月前发布的Google第二大Spanner论文（Spanner：BecominganSQLSystem，2017年5月），您会发现它支持我们的发现。例如，谷歌开始在Bigtable上构建，但发现不使用SQL会产生很多问题（我们在下面的所有引述都被强调）：虽然这些系统提供了数据库系统的一些好处，但它们缺乏许多应用程序开发传统人们经常依赖的数据库功能。一个关键的例子是健壮的查询语言，这意味着开发人员必须编写复杂的代码来处理和聚合应用程序中的数据。因此，我们决定将Spanner变成一个完整的SQL系统，查询执行与Spanner的其他架构特性（例如强一致性和全局复制）紧密集成。在本文的后面，他们进一步阐述了从NoSQL过渡到SQL的基本原理：Spanner的原始API提供了用于单表和交叉表的点查找和范围扫描的NoSQL方法。虽然NoSQL方法提供了一种启动扳手的简单方法，并在简单的检索场景中继续发挥作用，但SQL在表达更复杂的数据访问模式和将计算推向数据方面提供了重要的附加值。本文还描述了SQL的采用并没有在Wrench停止，而是实际上传播到Google的其他部分，其中多个系统现在共享一个通用的SQL方言：Wrench的SQL引擎共享一个通用的SQL方言，称为“标准SQL”，钻取Google与其他几个系统，包括F1和Smallhole（等）等内部系统以及BigQuery等外部系统……这降低了Google用户跨系统工作的障碍。针对Spanner数据库编写SQL的开发人员或数据分析师可以将他们对该语言的理解转移到Dremel，而不必担心语法、空值处理等方面的细微差异。这种方法的成功不言而喻。Spanner已经成为包括AdWords和GooglePlay在内的主要谷歌系统的“真实来源”，同时“潜在的云客户对使用SQL非常感兴趣”。考虑到Google首先帮助启动了NoSQL运动，值得注意的是它现在正在接受SQL。（最近引得一些人疑惑：“Google是不是在10年内送走了大数据行业？”）这对数据的未来意味着什么：SQL将变得细腰在计算机网络中，有一个概念叫做“细腰结构””。这个想法是为了解决一个关键问题：在任何给定的网络设备上，想象一个堆栈，具有底层硬件层和顶层软件层。中间可能有各种网络硬件；同样，将有各种软件和应用程序。需要有某种方式来确保无论硬件发生什么情况，软件仍然可以连接到网络；以同样的方式确保无论软件发生什么情况，网络硬件都知道如何处理网络请求。在网络中，互联网协议(IP)发挥了瘦腰的作用，这是一种为局域网设计的低级网络协议，也是更高级别应用程序和传输协议的通用接口。（这是一个很好的解释。）并且（在广泛的简化中），这个通用接口成为计算机的通用语言，使网络能够相互连接，使设备能够通信，并且这个“网络的网络”发展成为今天丰富和多样化的互联网。我们认为SQL已经成为数据分析的腰杆。我们生活在一个数据正在成为“世界上最有价值的资源”的时代（《经济学人》，2017年5月）。因此，我们看到专业数据库（OLAP、时间序列、文档、图表等）、数据处理工具（Hadoop、Spark、Flink）、数据总线（Kafka、RabbitMQ）等呈现寒武纪大爆发。我们还有更多的应用程序需要依赖这些数据基础设施，无论是第三方数据可视化工具（Tableau、GrafanaPowerBI、Superset）、Web框架（Rails、Django）还是自定义的数据驱动应用程序。像网络一样，我们也有一个复杂的堆栈，基础设施在上面，应用程序在上面。通常，我们最终会编写大量胶水代码来完成这项堆栈工作。但是胶水代码可能很脆弱：需要小心操作。我们需要的是一个通用接口，允许堆栈的各个部分相互通信。理想情况下，行业已经标准化。它最大限度地减少了不同层之间的通信障碍。这就是SQL的强大之处。和IP一样，SQL也是一个公共接口。但是SQL其实比IP要复杂得多。因为数据还需要支持人工分析。此外，SQL的创建者最初为其设定的目标之一是具有高可读性。SQL是最好的吗？不，但社区中的大多数人已经知道该语言。虽然工程师们已经在研究更自然的语言界面，但这些系统最终会连接到哪里呢？SQL。所以在栈顶多了一层。那一层就是我们人类。SQL回来了SQL回来了。不仅仅是因为在组装NoSQL工具时编写胶水代码的做法令人厌恶。而且不仅仅是因为学习各种新语言很困难。不仅仅是因为标准带来的优势。也因为世界充满了数据。它包围着我们，束缚着我们。起初，我们依靠人类的感觉神经系统来处理它。现在，软件和硬件系统也足够智能，可以帮助我们。随着越来越多的数据被收集以便我们更好地了解世界，系统、存储、处理、分析的复杂性以及可视化这些数据的需求只会继续增长。数据科学家尤达大师我们可以生活在这样一个世界，街道上到处都是像纸一样脆弱的系统，有数百万个接口。或者我们可以重新选择SQL，我们生活的世界也可能会变得越来越强大。
