SQL正在击败NoSQL吗?这对数据的未来意味着什么

随着计算机的日益普及,各种应用每天产生的数据量呈指数级增长。如何存储这些数据,有效处理分析这些数据,并从中提取有价值的信息,是当下迫切需要解决的问题。在过去的十年里,NoSQL在软件工程师阵营里越来越受欢迎,其中最重要的实现是MapReduce ,Bigtable,Cassandra,MongoDB,等产品。 它主要用于解决SQL的可扩展性问题。

SQL正在击败NoSQL吗?这对数据的未来意味着什么

然而今天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也导致了非规范化,导致数据膨胀和僵化。