SQL开始打败NoSQL？

Posted 2021-05-01 21CTO

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SQL开始打败NoSQL？相关的知识，希望对你有一定的参考价值。

导读：在本文中，将讨论为什么时钟的钟摆开始回到SQL，这对数据工程和数据分析社区的未来意味着什么？各位看官，详情一看究竟。

经过多年的“沉默”和“忍让”，SQL如今正在酝酿着卷土重来。这到底是何种情况？这会对大数据社区产生什么影响？

自从云计算开始流行以来，人们一直在收集数据——指数级增长的数据，也不断在数据存储，处理和分析技术中获取有价值的信息。主要是由于SQL无法随着不断增长的数据量做横向扩展，所以引发NoSQL的兴起：MapReduce和Bigtable，Cassandra，MongoDB等工具和产品。

是的，种种迹象已经表明SQL正在复苏。

当今的主流云提供商都提供流行的关系数据库托管：例如Amazon RDS，Google Cloud SQL，Azure，阿里云的RDS等云数据库产品。用亚马逊CTO的话说，他们的PostgreSQL和mysql兼容的数据库Aurora数据库产品，近年来一直是“ AWS历史上发展最快的服务 ”。而Hadoop，Spark和Kafka上的SQL接口也在持续蓬勃发展。

新的希望

为了理解SQL为什么正卷土重来，我们先了解数据库设计的起源。像所有的好故事的开始一样，故事开始于20世纪70年代。

在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演示文稿后一个月死于脑动脉瘤，年仅26岁，留下了妻子和小女儿。

事实上，在后来的一段时间，SQL似乎也已经成功完成了它的使命，静静的无人关心。

但是随后，互联网出现了。

NoSQL的反击

在Chamberlin和Boyce正在开发SQL的时候，他们没有意识到在加利福尼亚州的另一批工程师正在研究另一个新兴项目，这个项目后来被广泛传播并威胁到SQL的存在。

该项目就是ARPANET，它在1969年10月29日诞生。众所周知，ARPANET最终演变成今天的国际互联网。

在1989 年另一位工程师发明了WWW万维网之前，SQL是软件开发界标准的查询语言。随着互联网的蓬勃发展，以无数种方式大规模流量扰乱了数字世界。对于数据社区来讲，它造成了一串令人特别头痛的问题：新的数据源比以前有更高的数据和更快的速度生成大规模数据。

伴随着互联网的不断发展壮大，开发者们发现此时的关系数据库无法处理这种新的负荷。这只SQL部队受到了严重干扰，仿佛一下子有数百万个数据库大声喊叫超负载。

在之后，有两个新晋互联网巨头取得了重大技术突破，它们开发了自己的分布式与非关系数据库系统，以实现这新的大数据冲击。

这两家巨头和产品分别是：谷歌的MapReduce（2004年发布）和Bigtable（2006年发布）以及亚马逊的Dynamo（2007年发布）。

这些创新性的产品带来了更多的非关系型数据库产品，包括Hadoop（基于MapReduce，2006年），Cassandra（受Bigtable和Dynamo的启发，2008年发布）和MongoDB（2009年））。这些都是从头开始编写的新系统，它们避开了SQL，同时引发了NoSQL运动的兴起。

一下子开发者社区仿佛被NoSQL全部攻占，它的应用场合比原来的谷歌/亚马逊的设计目标要广泛得多。NoSQL是最新技术，有大公司光环，还可以承受真实的数据规模，这似乎变成了软件工程成功的唯一捷径。

在随后的时间中，软件开发人员无一不受到NoSQL的诱惑，问题遂不断地涌现。

开发人员很快发现，没有SQL在应用程序上十分设限。每个NoSQL数据库都有自己特殊的查询语言，这需要花时间学习，然后还要向同事传授，将数据库连接到应用程序的难度增加，还导致大量脆弱的胶水代码，缺乏第三方生态系统，公司自己需要开发操作界面和可视化工具等。

主要原因是NoSQL语言都很新，有的甚至还没开发完全。例如，在关系数据库中已经有成熟的功能（例如，JOIN），NoSQL没有; NoSQL的不成熟意味着在应用程序层增加了更多的复杂性，缺乏JOIN也导致非规范化，导致数据的膨胀和僵化。

一些NoSQL数据库还发明了自己的“类SQL”查询语言，如Cassandra的CQL。这看起来很强大，但往往使问题变得更糟，它制造了更多的精神与技术复杂度，软件工程师不知道支持什么和不支持什么。类SQL查询语言就像星球大战假日特别版，不接受任何模仿。

回到SQL，离开黑暗诱惑看到光明

首先是在Hadoop（以及后来的Spark）之上的SQL接口，引领业界将“back-cronym”的NoSQL改为“Not Only SQL”（是的，这是相当不错的尝试）。

接着是NewSQL的兴起：新的可扩展数据库完整包含SQL。麻省理工学院研究人员的H-Store （2008年发布）是首批横向扩展的OLTP数据库之一。谷歌凭借他们的第一篇Spanner论文（2012年出版，作者包括MapReduce原作者），以及其他先驱者如CockroachDB（2014），再次引领了SQL界面数据库的新潮流。

与此同时，老牌PostgreSQL社区亦开始复兴，它增加了JSON数据类型（2012）等重大改进，PostgreSQL 10中发布了大量新功能（更好的原生支持分区和复制，JSON全文搜索支持等）。）和PostgreSQL 11（增加了并行化数据定义功能，引入即时兼容等），还有更多功能在PostgreSQL 12。还有CitusDB（2016年被微软收购）和TimescaleDB（2017年发布）发布新的技术来扩展PostgreSQL的数据负载。

事实上，开发TimescaleDB的过程，就反映了该行业的发展方向。早期的内部TimescaleDB功能，其实就类似SQL语言。

最开始也有被黑暗诱惑的“ioQL”：团队开发者为建立自己的查询语言感到强大。看起来虽然很简单，但开发自己的查询语言，需要做很多的工作：例如语法结构，构建各种连接器，培训用户等等。而且还发现自己也要不断地查找正确的查询语法，而这一切在SQL中早已经表达完整了。

有一天，人们意识到开发自己的查询语言毫无意义，关键就是要拥抱SQL——这是团队做出的最佳设计决策之一，由此也便开启了一个全新世界。

2017年，TimescaleDB正式推出短短几个月，用户就可以在生产环境中使用开箱即用各种精彩的东西：可视化工具，常见ORM连接器，各种工具和备份选项，丰富的在线等教程和语法解析器等。

但还是不要太相信我的话，我们拿谷歌大公司举一个例子。

十多年来，谷歌显然一直位于大数据工程和基础设施的前沿，开发者也应该密切关注他们正在做的事情。

看看谷歌的第二篇主要的Spanner论文（Spanner：Becoming a SQL System，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已经成为Google主系统（包括AdWords和Google Play）的“真相来源”，而“潜在云计算客户对使用SQL也非常感兴趣”。

联想到谷歌最先发动了NoSQL运动，而今天它正在接受SQL是非常值得注意的事情。（这引发一些人怀疑：“ 谷歌是不是在十年前假冒大数据产业？ ”）

数据的未来意味着：SQL作为通用接口

在计算机网络中，有一种称为“ 窄腰 ” 的概念，这其实描述的是通用接口。

出现这个想法是为了解决一个关键问题：在任何指定的网络设备上，底层技术有硬件层和顶层软件层，存在各种网络硬件; 类似的，也可以存在各种软件或应用程序。人们需要一种通用方法来确保硬件、软件顺利连接到网络; 无论软件如何变化，网络硬件都知道如何处理网络请求，比如IP作为网络的通用接口。

在网络层中，通用接口的作用由互联网协议（IP）扮演，作为局域网设计的低级网络协议与更高级别的应用和传输协议之间的连接层。这个通用接口成为计算机的通用语言，使设备之间的网络互连互通，进而发展成今天丰富多彩的移动互联网。

所以，SQL已成为数据分析的通用接口。

如今的人们生活在一个数据正在成为“ 世界上最宝贵资源 ”的时代。结果，我们看到寒武纪时代的专业数据库（OLAP，实时，文档，图形等数据库），还有数据处理工具（Hadoop，Spark，Flink），数据总线（Kafka，RabbitMQ）等。还有更多需要依赖这种数据基础架构的应用程序，无论是第三方数据可视化工具（Tableau，Grafana，PowerBI，Superset），Web应用框架（Rails，Django，Laravel）还是定制的数据驱动应用程序。

与网络一样，我们还有一个复杂的技术栈，底层有基础设施，顶层有应用程序。通常情况下，人们最终还会编写大量的胶水代码来让这个产品先跑起来。但是胶水代码非常脆弱：很多人为的复杂度，需要大量的成本维护。

开发者需要一个通用接口，允许这个技术栈的各个部分相互通信。在理想的状态下，业内已经标准化的东西，能够以最小的成本交换各种层的数据。

这便是SQL的强大功能所在，与IP一样是一种通用接口。

但SQL实际上远远不止IP的功能范围。因为数据需要被人类分析，对于SQL创建者最初分配给它的目标而言，SQL具有很好的可读性。

SQL完美吗？肯定不是，但是技术社区中大多数人都了解的语言。虽然已经有工程师在开发更自然的面向语言的界面，但这些系统之间连接需要什么？还是SQL。

所以在堆栈的最顶层还有另一层，那一层就是我们。