Chaos今天的数据库厂商风头正劲，这三个公司就是亚马逊、谷歌和微软。是的，他们都是云计算提供商。三大热门管家产品是：AmazonRDS、GoogleCloudSQL、AzureDatabaseforPostgreSQL。A厂CTO说，AWS最火的产品是什么？它是Aurora数据库，兼容PostgreSQL和MySQL。他还指出，Hadoop、Spark或Kafka都在推动SQL接口，以将更多服务API暴露给程序员。从A厂的产品销量来看，公司比较喜欢这些标准SQL接口的产品，但是对于各类只能使用Java等编程语言才能正常获取数据的产品，就显得比较吵了，但雨小，很少有人愿意购买。举个ElasticSearch的例子，大家就能体会为什么ES的DSL让人望而却步：POSTcrm_comment/_search{"size":0,"query":{"term":{"accountName":"apple"}},"aggs":{"count_over_time":{"date_histogram":{"field":"CREATED","interval":"month"},"aggs":{"sum_of_sales":{"sum":{"field":"salesamount"}}}}}}如果缺少一个括号，查询将不会运行。一个SQL，WHERE，GROUPBY，一堆Json表达式就能解决的问题。你能读一下吗？另一个例子是MongoDB，我们存储日志。它的官方语言是javascript：看起来比ElasticSearch好，每个字段都加了一个$符号。为什么不需要加总？本来这些数据（搜索用的是ElasticSearch，日志用的是MongoDB）都存储在SQL数据库中，所有的查询都可以用SQL来一劳永逸。但是现在，要熟悉ES和MongoDB的怪异语法，弄清楚数据是否在传输过程中丢失，还需要一些时间。带来的不仅仅是一点点的复杂性。什么，你说程序员要996好好学习？这是一种祝福。好吧，这样的福气谁要谁要，反正我不要！历史让我们一起回顾一下SQL关系数据库的起源。这要追溯到IBM发表关系数据库论文的时候，1970年。1970年，关系数据计算已经很火了。但这种关系运算的查询，却只掌握在少数天才手中。普通人只能眼巴巴地看着。来，让我们领略一下当时的关系计算：你看得懂吗？懂的请举手，pingCAP，蚂蚁金服在召唤你！事实证明，哪里有黑匣子，哪里就会有魔术师。总有为劳动人民着想的天才领袖。唐纳德·张伯伦和雷蒙德·博伊斯就是这样的天才！他们发明了SystemR（关系数据库原型），并在自然语言研究的方向上发明了StructuredEnglishQueryLanguage（SEQUEL，这也是为什么大家经常把SQL读成see-ku-er的原因），后来由于由于商标纠纷，SEQUEL更名为SQL。那么SQL相对于上面的数学表达式有什么优势呢？感觉：前后两个操作都是在寻找那些比他们的经理工资高的员工。前者是关系数据表达式，只有数学高手才看得懂的符号；后者是一个SQL表达式，一个任何人都可以在一周内完全掌握的技术。后来发生的事情，相信只要不是00后，都应该有所耳闻。IBMDB2、Oracle、SQLServer、MySQL都如雨后春笋般涌现。有了SystemR的磐石和SQL的新兵器，各自打造了一个兵工厂，开疆拓土。战争一直打到现在。如果不是阿帕网这个躲在角落里默默自学的好青年，拉里森这个甲骨文的母体估计还会骂人很多年。经过多年的默默耕耘，阿帕网终于成长为我们这个时代的强者。这就是今天的互联网！快来认识一下当年在加州默默读书的小伙伴们。革命不成功，强者不歇。虽然有这么多人在努力，但要撼动关系型数据库还远远不够，也不会到时候。直到这哥们出现。你看，任何一个历史的转折点，都必须是伟人推动的，说不定下一个就是你，努力吧，少年！这位蒂姆兄弟在1989年发明了万维网，一下子把数据的世界带到了世界。门开了。数据正以前所未有的数量和速度涌入。这个时候，关系型数据库慢慢出现了难度和老化的迹象。历史再次证明，不挨打，永远不知道自己有多大。怪物冲了进来，肯定有奥特曼在场应对。没错，这时候出现了两个英雄，一个是谷歌，一个是亚马逊。Google的MapReduce（2004）和BigTable（2006）打破了分布式计算和存储的瓶颈。后台回复“1024”即可获取这两篇论文。A厂在整个云计算时代都有它的份，闪耀的光芒非常耀眼。其Dynamo数据库采用键值对存储，融合了各种眼花缭乱的云计算技术，号称保证服务的高可用。有了岩石，武库也就不远了。它与SQL的开发非常相似。之后不久，各个公司都有了Hadoop、Hive、Cassandra，MongoDB也玩起了MapR。又是一场追逐战，历史何其相似。而这波打斗不仅发生在表兄弟之间，还有抢叔叔的地盘。这不，蚂蚁金服的OceanBase前两天把甲骨文大叔的地盘搬了一点，夺走了它在2010年创下的TCP-C排行榜榜首的位置。现实中，年轻人总有一种朝气蓬勃的感觉，认为因为他们的青春和力量，他们会毫不畏惧地触摸成年人的奶酪。单靠蛮力怎么能打仗呢？它还需要最根本的成功基础，那就是群众的支持。每个年轻人都有自己的魅力，拥有自己的武器是一件很酷的事情。天地之圈，金箍棒，酷酷的。但是在如来的眼里，他代表着世间万物，他要是说代表老百姓统治你，分分钟要你的命。这就是群众的力量。上面的ElasticSearch和MongoDB给我们的感觉非常棒，全文搜索速度极快，日志存储毫不费力，但是你要拿起来用，就得顺着他们的脾气，不然他们就给你约会。就像现在很多年轻人一样，他们想被哄着做事，不像那些无产阶级革命前辈那样急于做事。如果说OLTP产品，就Redis、MongoDB、Kafka探索一下，能忍就忍。毕竟，一次投入，终生受用。但是OLAP的产品，Impala、Hive、Presto、Kylin等之间是没有联系的，需要一整套的ETL才能打通。谁能有好脾气。我做报告，我要用Spark报告到每家每户。可能其中一个人那天脾气特别不好，数据都找不回来了。典型的就是JOINmessenger，经常被拒绝。当然，在受到群众（市场）的教训之后，年轻人也开始反思了。Cloudera和Hortonworks就是典型的代表。他们选择联手一起做某事。引入了SQL级别的方言来封装其复杂的外观。原理是SQLONHadoop。Hadoop负责存储，而SQL负责计算。存储引擎与计算引擎分离。质量基础。王者归来是小弟们第一次像大哥们一样妥协，也就是推出了自己的SQL-On-Hadoop产品。虽然说是NotOnlySQL，但也只是年轻人在坚持最后的狂妄。然后，历史再次重演。只要认清了一种现象，就会有一批现象相继出现。H-Store、Spanner、CockroachDB。Postgre是最杰出的。在经历了关系型数据库和NoSQL之后，他们正在观望中追赶，为自己添上好东西。像Json,FullTextSearch,MPP,JIT等特性。当然，整个改造的历史，总要有人来总结一下的说法。谁是NoSQL活动家？记住。没错，谷歌的三驾马车。那么它的结局只能由谷歌官方宣布。搬起石头砸自己的脚，痛不痛？看下G厂在2017年的Spanner论文中怎么说的：“虽然这些系统提供了数据库系统的一些好处，但它们缺乏许多传统的数据库功能开发商经常依赖。一个关键的例子是健壮的查询语言，这意味着开发人员必须编写复杂的代码来处理和聚合其应用程序中的数据。因此，我们决定将Spanner变成一个功能齐全的SQL系统，将查询执行与Spanner的其他架构特性（例如强一致性和全局复制）紧密集成。”Spanner的原始API提供了NoSQL方法，用于对单个表和交错表进行点查找和范围扫描。虽然NoSQL方法提供了启动Spanner的简单途径，并在简单的检索场景中继续发挥作用，但SQL在表达更复杂的数据访问模式和推动计算方面提供了重要的附加价值重刑的数据。Spanner的SQL引擎与Google的其他几个系统共享一种通用的SQL方言，称为“标准SQL”，包括F1和Dremel（以及其他）等内部系统，以及BigQuery等外部系统……对于Google内部的用户来说，这降低了门槛跨系统工作。针对Spanner数据库编写SQL的开发人员或数据分析师可以将他们对该语言的理解转移到Dremel，而无需担心语法、NULL处理等方面的细微差异。让我简化一下，“Google将从Nosql转向SQL阵营，SQL很快就会成为所有数据访问的基础，只是酱”
