随着计算机的日益普及，各种应用程序产生的数据量每天都在呈指数级增长。如何存储这些数据，对这些数据进行有效的处理和分析，并从中提取有价值的信息，是当前亟待解决的问题。在过去的十年中，NoSQL越来越受到软件工程师的青睐，最重要的实现是MapReduce、Bigtable、Cassandra、MongoDB等产品。主要用于解决SQL的可扩展性问题。然而，今天SQL开始回归。几乎所有的云计算服务商都在提供流行的关系型数据库管理服务：例如AmazonRDS、GoogleCloudSQL、Azure的PostgreSQL数据库（Azure今年推出）。在亚马逊看来，其与PostgreSQL和MySQL兼容的数据库产品Aurora一直是AWS历史上增长最快的服务。Hadoop和Spark之上的SQL接口继续快速发展。就在上个月，Kafka引入了SQL支持。在本文中，我们探讨了SQL如此流行的原因，以及这对数据社区工程和分析的未来意味着什么。第1部分：新希望的兴起要理解SQL为何回归，让我们先看看它最初的设计意图。故事始于70年代初期的IBMResearch，关系数据库诞生于此。那时，查询语言依赖于复杂的数学逻辑和符号。DonaldChamberlin和RaymondBoyce两位博士在关系数据模型方面有着深厚的造诣，他们看到查询语言将成为他们的主要瓶颈。他们着手设计一种新的查询语言（用他们自己的话说）“用户无需接受正规的数学或计算机编程培训就可以轻松使用”。回想在互联网出现之前，在PC之前，当编程语言C***被介绍给世界时，两位年轻的计算机科学家意识到“计算机行业的成功很大程度上取决于培养计算机专家以外的用户”。他们渴望一种像英语一样易于阅读的查询语言，包括数据库管理和操作。结果是SQL于1974年首次面世，并成为关系数据库的主导语言。在接下来的几十年里，SQL也证明很流行。随着SystemR、Ingres、DB2、Oracle、SQLServer、PostgreSQL、MySQL等关系型数据库在软件行业的发展壮大，SQL也成为了与数据库交互的首选语言和通用语。一个日益拥挤和竞争激烈的生态系统。.（不幸的是，RaymondBoyce从未有机会见证SQL的成功，他只是做了一个早期的SQL演讲，1个月后他因脑动脉瘤去世，当时他年仅26岁，留下妻子和年幼的女儿.)有一段时间，SQL似乎已经成功完成了它的使命。然后是互联网。第2部分：NoSQL的反击当Chamberlin和Boyce正在开发SQL时，他们没有意识到加利福尼亚的另一组工程师正在从事另一个初出茅庐的项目，该项目已经成熟，对SQL的存在构成了明显的威胁。该项目是ARPANET，诞生于1969年10月29日。但SQL一直表现良好，直到1989年，另一位工程师出现并发明了万维网。互联网和Web的蓬勃发展正在改变着我们的世界，但对于数据界来说，同样令人头疼的是：数据正在以更大规模、更快的速度呈爆炸式增长。随着互联网的不断发展壮大，软件界发现当时的关系型数据库已经无法应对新的负载压力，仿佛百万个数据库突然超载，令人抓狂。然后两个新的互联网巨头突破并开发了自己的非关系分布式系统来应对这种新的数据冲击：谷歌的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的新的可扩展性数据库。H-Store（2008年发布）由麻省理工学院(MIT)和布朗大学(Brown)的研究人员开发，是最早的可扩展OLTP数据库之一。Google在第一篇Spanner论文（发表于2012年）（其作者包括MapReduce原作者）中透露，这是一种基于SQL的查询语言，可以将一段数据复制到全球多个数据中心，并保证数据的一致性，因此开创了地理可复制的SQL接口数据库，其次是CockroachDB(2014)等先驱。与此同时，PostgreSQL社区开始复苏，加入了JSON数据类型（2012），以及PostgreSQL10的新特性：对分区和复制更好的原生支持，对JSON的全文搜索支持等（稍后发布）年）。CitusDB(2016)和其他人（今年发布的TimescaleDB）等其他人已经找到了针对特定数据工作负载扩展PostgreSQL的新方法。事实上，我们开发TimescaleDB的过程与行业的发展轨迹息息相关。早期的TimescaleDB内部使用我们自己的类似SQL的查询语言“ioQL”。是的，我们被困难所驱使：构建我们自己的查询语言会更强大。然而，虽然这看起来很简单，但我们很快意识到我们必须做更多的工作：例如，决定语法、构建各种连接器、培训用户等。我们还发现自己一直在寻找正确的语法来查询已经可以查询的内容用SQL查询。有一天我们意识到构建我们自己的查询语言没有意义。关键是拥抱SQL。这是我们做过的最糟糕的决定之一。也打开了一个全新的世界。今天，尽管我们的数据库只有5个月的历史，但我们的产品已完全可用并得到用户的支持：可视化工具(Tableau)、常用ORM连接器、各种工具和备份选项、大量在线教程和语法解释等。计算机网络中，有一个概念叫“窄腰”。这个概念的出现解决了一个关键问题：在任何给定的网络设备上，想象一个堆栈，底层硬件层和顶层软件层。中间可能有各种网络硬件；同样，各种软件和应用程序。需要一种方法来确保无论硬件如何，软件仍然可以连接到网络；无论软件如何，网络硬件都知道如何处理网络请求。在网络中，窄腰带的角色是由互联网协议（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。一切都遵循能量守恒定律。
