经过多年的积累，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这方面的人才，运维上可能会有一定难度，出于实际情况考虑，可先用关系型数据库顶一阵子
所以，如果不考虑实际情况，虽然合适有些存储引擎更加合适，但是强行使用反而适得其反，总而言之，适合自己的才是最好的。
