经过多年的积累,SQL正在卷土重来。这对数据社区产生什么影响?
自从计算机出现以来,我们一直在收集成倍增长的数据,不断地从我们的数据存储、处理和分析技术中要求更多的数据。在过去的十年中,很多软件开发人员因为SQL不能随着数据量的增长而扩展,所以放弃了SQL,那个时期就产生了NoSQL:MapReduce和BigTable、Cassandra、MongoDB等数据库。
不久后的今天,SQL又一次被大家青睐。主要的云提供商会提供流行的托管关系数据库服务:例如,亚马逊RDS, GoogleCloudSQL, PostgreSQL Azure数据库..用Amazon CTO自己的话就是:Aurora数据库与PostgreSQL和MySQL兼容,一直是AWS历史上市场最好的,也是Hadoop、SPark和Kafka之上的SQL数据库。
在这篇文章中,我们将研究为什么SQL又一次被大家接受,以及SQL对数据库行业和数据分析社区的影响。
第一部分:新希望
要理解SQL为何会卷土重来,先从为什么设计SQL开始。
像所有美好的故事一样,我们的故事始于1970年。
我们的故事始于20世纪70年代初的IBMResearch,也就是关系数据库诞生的地方。当时,查询语言依赖于复杂的数学逻辑和符号。两个新当选的博士,DonaldChamberlin和RaymondBoyce,对关系数据模型印象深刻,他们认为查询语言是最主要的部分。于是他们开始设计一种有利于非数学专业、非计算机专业的用户容易接受的新的查询语言。
SQL(a,b)与SQL(C)之前的查询语言(来源).
早在互联网之前,当编程语言C首次被引入时,两位年轻的计算机科学家意识到,计算机工业的成功很大程度上取决于培养一批新用户,而不是经过培训的计算机专家。他们想要一种像英语一样容易阅读的查询语言,而且还包括数据库管理和操作。所以SQL来了,在1974年首次出现在大众视野。在接下来的几十年里,SQL越来越受欢迎。随着R、Ingres、DB2、Oracle、SQLServer、PostgreSQL、MySQL等关系型数据库接管了软件业,SQL成为数据库交互语言。
(遗憾的是,雷蒙德·博伊斯从来没有机会见证SQL的成功。他在做了最早的SQL演示后一个月死于脑动脉瘤,当时他只有26岁,留下了一个妻子和一个年幼的女儿。)
第2部分:NoSQL的回击
当Chamberlin和Boyce在开发SQL时,加利福尼亚的第二组工程师正在从事另一个项目,这个项目后来会广泛扩散,并威胁到SQL的存在。那个项目是ARPANET,1969年10月29日,它诞生了。ARPANET最终演变成了今天的互联网,而且另一位工程师在1989年发明了万维网。
在此之后,互联网和网络蓬勃发展,大批进入大众的视野,但对于数据社区来说,它造成了一个特别令人头疼的问题:新的数据来源会更快更多地生成数据。
随着Internet的不断增长,软件社区发现当时的关系数据库无法处理这种新的负载。
随后,两个新的互联网巨头取得了突破,并开发了自己的分布式非关系系统,来应对这个新的数据攻击:地图推理 (2004年出版)和大表 (2006年出版)由谷歌(Google)提供,以及迪纳摩 (2007年出版)亚马逊的。这些开创性的论文衍生了很多非关系数据库,包括Hadoop(根据地图推理的文件,2006), 卡桑德拉(深受“大表”和“发电机”两篇论文的启发,2008)和MongoDB (2009)。因为这些系统基本上都是从头开始编写的,所以避开了SQL,导致了NoSQL运动的兴起。
但开发人员很快发现,没有SQL实际上很局限。每个nosql数据库都提供了自己独特的查询语言,这意味着需要学习更多语言(并向同事传授),增加了将这些数据库连接到应用程序的难度,导致大量脆弱的胶水代码,缺乏第三方生态系统,要求公司开发自己的操作和可视化工具。
这些NoSQL语言是新的,也没有得到充分开发。例如,关系数据库多年来一直在为SQL添加必要的特性(如Union)。
一些NoSQL数据库添加了自己的“类似SQL”的查询语言,比如Cassandra的CQL。但这可能使问题变得复杂,工程师们不知道什么是支持的,什么是不支持的。
第3部分:SQL的回归
首先是Hadoop之上的SQL接口(然后是Spark),它引领业界将“Back-cronym”NoSQL转换为“不仅仅是SQL”。
然后是NewSQL的兴起:完全采用SQL的新的可伸缩数据库。麻省理工学院和布朗的研究人员是第一批规模扩大的OLTP数据库之一。google再次引领了地理复制sql接口数据库的第一次出现。
同时,PostgreSQL社区开始恢复活力,增加了一些重要的改进,比如JSON数据类型,以及一系列新特性PostgreSQL 10(对分区和复制的更好的本机支持,对JSON的全文搜索支持等等)和PostgreSQL 11(增加了并行化数据定义功能,引入了及时完成等功能),还有更多的功能要做。PostgreSQL 12..其他公司如CitusDB (2016,现在由微软拥有)和你的真正的(TimereseDB, 2017年释放)找到了为专用数据工作负载扩展PostgreSQL的新方法。
有一天,我们意识到构建自己的查询语言是没有意义的。关键是要拥抱SQL。在2017年正式发布几个月后,用户就可以在生产中使用我们,并将各种奇妙的东西都拿出来:可视化工具、普通Orms的连接器、各种工具和备份选项、丰富的在线教程和语法解释等等。
总结:数据库与NoSql及各种NoSql间的对比
何时选用关系型数据库,何时选用非关系型数据库?选用非关系型数据库,使用哪种非关系型数据库?
首先是第一个话题,关系型数据库与非关系型数据库的选择,在我理解里面无非就是两点考虑:
第一点,不多解释应该都理解,非关系型数据库都是通过牺牲了ACID特性来获取更高的性能的,假设两张表之间有比较强的一致性需求,那么这类数据是不适合放在非关系型数据库中的。
第二点,核心数据不走非关系型数据库,例如用户表、订单表,但是这有一个前提,就是这一类核心数据会有多种查询模式,例如用户表有ABCD四个字段,可能根据AB查,可能根据AC查,可能根据D查,假设核心数据,但是就是个KV形式,比如用户的聊天记录,那么HBase一存就完事了。
经验得知,非核心数据尤其是日志、流水一类中间数据千万不要写在关系型数据库中,这一类数据通常有两个特点:
· 写远高于读
· 写入量巨大
一旦使用关系型数据库作为存储引擎,将大大降低关系型数据库的能力,正常读写QPS不高的核心服务会受这一类数据读写的拖累。
接着是第二个问题,如果我们使用非关系型数据库作为存储引擎,那么如何选型?其实上面的文章基本都写了,这里只是做一个总结(所有的缺点都不会体现事务这个点,因为这是所有NoSql相比关系型数据库共有的一个问题):
但是这里特别说明,选型一定要结合实际情况而不是照本宣科,比如:
· 企业发展之初,明明一个关系型数据库就能搞定且支撑一年的架构,搞一套大而全的技术方案出来
· 有一些数据条件查询多,更适合使用ElasticSearch做存储降低关系型数据库压力,但是公司成本有限,这种情况下这类数据可以尝试继续使用关系型数据库做存储
· 有一类数据格式简单,就是个KV类型且增长量大,但是公司没有HBase这方面的人才,运维上可能会有一定难度,出于实际情况考虑,可先用关系型数据库顶一阵子
所以,如果不考虑实际情况,虽然合适有些存储引擎更加合适,但是强行使用反而适得其反,总而言之,适合自己的才是最好的。