Py学习  »  NoSql

为什么 SQL 正在与 NoSQL 开战?这对未来的数据科学意味着什么?

Python程序员 • 6 年前 • 831 次点击  

Python部落(python.freelycode.com)组织翻译,禁止转载,欢迎转发。

经过多年的沉寂,如今 SQL 即将强势回归。如何回归?它的回归又会对数据社区产生什么样的影响呢?

随着计算机性能的提升,我们收集的数据量正以指数级的形式增长着,这就不断地对我们的数据存储技术,数据处理技术和分析技术提出更高的要求。在过去的十年里,数据量的快速增长也使得软件开发人员抛弃了 SQL,因为它不能处理如此快速增长的数据量,从而导致了 NoSQL 的崛起,例如: MapReduce、Bigtable、Cassandra 和 MongoDB 等等。

但是,如今 SQL 正在逐渐回归,所有的主要云服务供应商都提供流行的托管关系型数据库服务,例如:Amazon RDS、Google Colud SQL、Azure Database for PostgreSQL(Azure 是今天上线的)。用亚马逊自己话来说,他们的 Aurora 数据库是在 AWS 云服务中增长速度最快的服务,并且还与 Postgre SQL 和 MySQL 兼容。 Hadoop 和 Spark 框架上的 SQL 接口正在不断更新发展。并且就在上个月, Kafka 也上线了他们的 SQL 接口服务。我本人也是一个 TimescaleDB 的开发人员,这个数据库完全兼容 SQL。

第一部分:新的曙光

为了理解为什么 SQL 数据库正在强势回归,我们需要从 SQL 的最初设计讲起。

我们的故事要从上个世纪七十年代的 IBM 研究院讲起,这里是关系型数据库诞生地。在那个年代,查询语言还需要依靠复杂的数学逻辑和数学表达式。有两个新的博士生,Donald Chamberlin 和 Raymond Boyce,他们对这种复杂的查询语言记忆深刻,同时他们也看到了查询语言距离被大众接受还有一个瓶颈。于是乎他们就自己着手设计一种新的查询语言,用他们自己的话来说就是:“就算你没有受过专业的数学或者计算机编程培训,你也可以理解并接受它”。

想想互联网建立之前、个人电脑还没问世、C 语言才刚刚发明的那个年代,两个年轻的计算机科学家就意识到:计算机产业的成功将取决于大众而不是计算机专家。他们想要创造一种能够像英语一样易读的查询语言,将数据库的管理与操作统统容纳。

其结果就是 1974 年 SQL 的问世。在接下来的几十年的时间里, 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 创造者合影,  ARPANET 最终演变为互联网

SQL 真正被广泛接受并应用是发生在 1989 年万维网问世之后。

发明网络的物理学家

互联网和万维网就像野草般疯狂的成长着,打破了这个世界上很多事情运作的原本方式,但是对于数据社区而言,它们带来了一个令人头疼的问题:新数据的收集速度远超过之前的速度。

随着互联网的不断发展,人们发现当时的关系型数据库的处理无法满足要求。军队中首先出现了问题,因为有成百万的数据库突然过载了。

正所谓乱世出英雄,值此关键时刻,有两位互联网新晋巨头作出了突破,他们分别开发自己的分布式非关系型系统来处理数据过载问题,他们分别是谷歌的MapReduce 系统(published 2004) 和 Bigtable 系统(published 2006),以及亚马逊的 Dynamo (published 2007) 系统。这几篇开山之作成就了往后的非关系型数据库,其中就包括了:Hadoop(基于 MapReduce,2006)、Cassandra(基于 Bigtabel 和 Dynamo,2008)以及 MongoDB(2009)。因为这些新系统在很大程度上是从零开始编写的,并且避开了SQL,从而导致的 NoSQL 的兴起。

那些做软件开发的社区也很认可 NoSQL,甚至比谷歌、亚马逊这些初始的开发者都热情。很容易理解这是为什么,因为 NoSQL 崭新而又有前途,小巧而又强大,是通往成功的快车道。但是,一大波问题却正在袭来。

传统的软件开发者都被 NoSQL 吸引。不要成为上面这个小家伙。

但是,开发人员很快就发现没有了 SQL 很多事情都举步维艰。每一个 NoSQL 数据库都有自己独特的查询语言,这就意味着,我们需要学很多种语言(并教会你的同事),这也使得不同数据库应用之间数据交换的困难程度增加,从导致了成千上万行的无用代码;同时 NoSQL 数据库缺乏第三方支持,这就要求公司自己必须开发自己的操作工具与可视化工具。

NoSQL 虽然新但是还没有完全发展起来。例如,对于关系型数据库,人们花费了好些年的时间来不断完善 SQL 语言所需要的特征,例如 JOINs。所以,对于不成熟的 NoSQL 语言,离大规模应用还有很长一段路要走。NoSQL 缺少 JOINs 从而导致了非规范化的问题,这个导致了数据冗余性以及非普适性。

有一些数据库,例如 Cassandra 的 CQL,会添加类似于 SQL 的查询语言。但是这个常常会导致问题的恶化。使用一个与以往软件具有相同界面的软件会让客户感到膈应:工程师们会不知道新的软件支持什么,不支持什么。

类似 SQL 的查询语言就想星球大战假日特别版。不接受模仿!

早在 2008 年就可以在一些社区中可以看到 NoSQL 的问题(例如 DeWitt 和 Stonebraker 在 2008 年发布的文章)。如今时过境迁,一代又一代人的前赴后继,如今已经有越来越多的开发人员加入了 NoSQL 的开发工作中。

第三部分: SQL 的回归

尽管以往人们只看到了 SQL 的缺点,但是如今人们开始发现了 SQL 的优点,并重新重视。

首先是 Hadoop 上添加了 SQL 接口(后来 Spark 也如此),从而使得整个行业将 NoSQL 理解为 Not Only SQL (还挺不错的)。

然后是 NewSQL 的崛起:新型可扩展数据库,完全兼容 SQL。H-Store(2008 发布)由麻省理工学院(MIT)和布朗大学研究人员研发,是第一种大规模 OLTP 数据库之一。谷歌依旧独领风骚,发布了一种应用于地理的 SQL 接口数据库,并第一时间发布了Spanner 的论文(2012 年发布,其作者包含了 MapReduce 的原始作者)。接下来呢,CockroachDB 于 2014年发表了相应的文章。

与此同时, PostgreSQL 社区开始复兴并对 JSON 数据格式作出一些重要的改进(2012),并在 PostgreSQL 10 后添加了新的特征:对分区与复制更好的支持,支持在 JSON 中进行文本检索以及其他功能(今年晚些时候发布)。其他的公司,例如 CitusDB (2016 年发布)和 TimescaleDB (今年发布)都针对特殊的数据负载类型找到了新的方法来规模化 PostgreSQL。

事实上,我们自己开发的 TimescaleDB 一直紧随行业发展脚步。TimescaleDB 的早期内部版本中就包含了我们自己的类似于 SQL 的查询语言,我们称之为:ioQL。当然开发的过程中我们也走过岔路,我们建立了自己的查询语言,并自我感觉良好。这个看起来是一条容易的捷径,但是我们很快就发现并不是这样的,我们必须做很多额外的工作,例如定义语法,构建各种连接器,指导用户等等。我们同样发现我们不断的在寻找一种已经存在于 SQL 中的查询语法,从而编写我们自己的查询语言。

直到一天,我们恍然大悟,建立我们自己的查询语言根本没有意义。我们需要做的是兼容 SQL。这是我们做的最好的决定之一。然后,我们就开启了新世界的大门。如今尽管我们的数据库产品仅仅上线 5 个月,但是我们的用户却可以使用我们的产品得到他们所想要的一切东西:可视化工具(Talbleau),常见的对象关系映射连接器,多种多样的工具以及备用工具,丰富的教程以及在线语法解释等等。

信谷歌,得“永生”


谷歌是数据行业的领头羊,并在此领域深耕十年之久。我们理应关注它的一举一动。

让我们小小的看一眼四个月前,谷歌 spanner 发表的重要论文: Spanner: Becoming a SQL System,我们就可以发现,它恰恰是支持我们上述的观点的。

举个例子:谷歌已经开始着手基于 Bigtable 来创建其他的数据库,但是很快就发现了由于 SQL 的缺失所带来的问题。

“虽然这些系统提供一部分数据库系统的特性,但是它们仍旧欠缺很多传统数据库的特性,而这些特性恰恰是一些应用开发人员所依赖的。一个重要的例子就是鲁棒性很好的查询语言,没有这个就意味着开发人员不得不自己写一堆复杂的代码以便在他们的应用中实现数据的处理与聚合。于是乎,我们决定让 Spanner 数据库完全兼容 SQL 系统,从事使得查询语句的执行与 Spanner 数据库的其他架构紧密联系(例如强一致性与全局复制)。”

在这篇文章的后面,作者们进一步地阐述了从 NoSQL 到 SQL 的转变的理论基础。

Spanner 数据库的初始 API 用的是 NoSQL 的方法来表示数据查找和基于单个表格和交叉表格的范围扫描。虽然 NoSQL 方法为 Spanner 提供了一种简单的方法,并在简单的检索方案上非常有用,但是 SQL 对复杂情况下的数据访问模式和推进数据计算效率方面具有很重要的附加价值。

这篇论文还描述了 SQL 是如何在 Spanner 不但没有搁浅反而激流奋进地渗透到 Google 的其他产品,并且成为其他产品的通用语言:

Spanner 的 SQL 引擎提出了一种通用的 SQL 语言,称为:标准 SQL,并适用于 Google 的其他系统,包括了 F1 和 Dremel 的内部系统与 BigQuery 等的外部系统。

对于谷歌的用户而言,这降低了不同系统间的工作障碍。一个写 SQL 代码的开发人员或者数据分析师与一个 Spanner 数据工程师一样可以将他们对于这个标准语言的理解转化为 Dremel 系统语言而不用担心有任何的语法错误问题,也不用进行其他的处理。

这种方法的成功说明了一点,那就是 Spanner 已经是大部分谷歌系统的“真理之源”了,其中包括了 AdWords 和 Google Play;同时云服务的潜在客户也对 SQL 抱有很大的兴趣。

就和一开始谷歌掀起了 NoSQL 运动的浪潮一样,今日重回 SQL 也是一大壮举。(这也引起了一个新的讨论:谷歌是否在十年前误导了大数据产业?)

SQL 成为了通用语言,这对未来的数据行业意味着什么

在计算机网络中,有一个概念叫做 narrow waist。

这个概念的出现是为了解决一个重要的问题:在任意一个给定的联网设备上,想象一个堆栈结构,在底部有好几层硬件层,在顶部有好几层软件层。有着各式各样的硬件,同样也存在多种多样的软件和应用。人们需要一种方式可以确保,不论存在什么样的硬件,软件都可以连接网络;同样,不论存在什么样的软件,联网的硬件设备都知道如何去处理网络请求。

在网络中,网络协议(Internet Protocol, IP)就承担着 narrow waist 这样的角色,就像局域网的低级网络协议与高级应用的传输协议之间的公共接口一样。而这份公共接口就像是计算机之间的通用语一样,可以使得网络间进行链接,设备间进行通讯,而这种“网络的互联”就逐渐形成了如今丰富多彩的互联网。

我们相信, SQL 已经成为数据分析领域的通用语言。

我们生活在在一个“数据是最具价值的资源”的时代。在这个年代,我们看到了像寒武纪生命大爆发似的专业数据库(OLPA, time-seris, document, graph 等),数据处理工具(Hadoop, Spark, Flink),和数据商业(Kafka, RabbitMQ)等等和数据相关行业的快速增长。我们同样也有更多的应用需要依赖这些数据基础产业,例如第三方的数据可视化工具(Tableau, Grafana, PowerBI, Superset), web 应用框架(Rails, Django)或者 定制数据驱动应用。

和网络结构一样,我们同样有着复杂的堆栈结构,基础设施在下,应用设计在上。通常,我们需要写一堆胶水代码来使得这个堆栈结构运转起来,但是需要注意的是,胶水代码很脆弱,需要我们不断的维护与改进。

我们需要的是一个通用的接口,从而使得这个堆栈的每层之间进行通讯。在工业上一些东西已经实现了标准化,允许我们以最小的损失在各层之间进行信息的交换/输出。

这就是 SQL 的作用,和 IP 一样,SQL 就是一种通用接口。

事实上, SQL 要比 IP 更加重要,因为数据同样需要被人阅读分析。这和 SQL 的创建者的意图一致:SQL 对人来说是可读的。

SQL 是最完美的吗? 并不是,但是它是大部分人都知道的一种语言。虽然已经有工程师致力于开发一种更加自然易读的接口语言,但是这些系统最好都会被连接到哪里呢?SQL。

所有在堆栈的最上层仍旧有一层,而那一层就是人。

SQL 正在回归

SQL 正在回归。不仅是因为写一堆胶水代码将 NoSQL 工具组合在一起很烦人。不仅是是因为重新培训员工来学习一种新的语言很困难。同样也不仅是因为标准化是一件好事。

而是因为这个世界处处有数据。数据与我们形影不离。一开始,我们依靠自身的感觉和神经感知系统来处理数据。如今,我们依靠智能的软件和硬件系统来处理数据。当我们收集越来越多的数据来了解我们的世界时,我们的存储系统,处理分析系统和可视化系统的复杂度也会逐渐的提升。

要么我们生活在一个有一百万个接口的脆弱世界里,要么我们继续拥抱 SQL, 并重新平衡各方力量。


英文原文:https://ogmcsrgk5.qnssl.com/vcdn/1/优质文章长图/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a.png
译者:无



今天看啥 - 高品质阅读平台
本文地址:http://www.jintiankansha.me/t/FX9XPVFxfi
Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/4351
 
831 次点击