作者 | dbLenis
责编 | 郭芮
出品 | CSDN 博客
当今数据库供应商风头正茂的，要数这三家公司：Amazon、Google、Microsoft。没错，他们都是云计算提供者。火热的三款看家产品分别是：Amazon RDS，Google Cloud SQL，Azure Database for PostgreSQL。
A厂CTO说，AWS最火的产品是什么呢？是 Aurora 数据库，它同时兼容 PostgreSQL 与 MySQL。他还指出，Hadoop 也好，Spark、Kafka 也罢，都在极力推动 SQL 接口来让更多的服务 API 暴露给程序员。
从 A 厂产品的销量来说，企业比较青睐于这些有标准 SQL 接口的产品，而对于各类只能用编程语言，比如Java才能正常取数的产品，显得声音大，却雨点小，少有肯买帐的。
我举个 ElasticSearch 的例子，你感受下为什么 ES 的 DSL 会让人望而却步：
POST crm_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"}
}
}
}
}
}
再比如，我们存日志的 MongoDB，它的官方语言是 JavaScript：
看上去，这比 ElasticSearch 好看一些，每个字段都加了一个 $ 符号，请问为什么 total 就不用加呢？
原本这些数据（搜索用的 ElasticSearch, 日志用的 MongoDB)都存在 SQL 数据库中，使用 SQL 一劳永逸的搞定所有查询。但现在要花点时间熟悉 ES 和 MongoDB 的古怪语法了，还要搞清楚，数据在流转过程中是否有丢失——带来的复杂度不仅仅是一点点。
什么，你说程序员不就是应该拼命学的嘛？这是福报。嗯，这样的福报谁爱要，谁拿去，反正我不！
让我们一起回忆下SQL关系型数据库的起源。这要追溯到IBM发表关系型数据库论文的那个年代，1970年。1970年时，关系型数据计算已经非常火热了。但这种关系运算的查询，只掌握在少数天才人的手里。普通人只能看着眼馋。
事实证明，哪里有黑盒，哪里就会产生魔法师，总有天才领袖为劳苦大众着想。Donald Chamberlin 和 Raymond Boyce 就是这样的天才！他们发明了 System R（关系型数据库原型），又在自然语言的研究方向上，发明了结构化英语查询语言（Structured English Query Lanuage, SEQUEL, 这也是为什么大家经常会把SQL读成 see-ku-er的原因）。后因商标之争，SEQUEL更名为 SQL。
那么 SQL 相比上面的数学表达式有啥好处？感受下：
前后两个运算都是在找出薪水比自己经理还高的那些员工。前者是关系数据表达式，只有数学大师才懂的符号；后者是 SQL 表达式，任何人在一星期绝对可以掌握的技术。
后来的事情，相信只要你不是00后，应该都有所耳闻了。IBM DB2、Oracle、SQL Server、MySQL 都如雨后春笋般地出来了。有了 System R 这般的磐石，有了 SQL 这代新型武器，各自造就了兵工厂，开疆扩土。
如果不是因为 ARPANET 这位默默在墙角自习的好青年，恐怕拉里森这位Oracle家长还要嘚瑟个好多年。经过多年的沉寂修炼，ARPANET终于在我们这个时代成长成一个壮实的大小伙了——也就是今天的互联网！
来，见识下当年那一小撮默默地在加利福尼亚学习的小伙伴：
革命不成功，壮士不歇息。尽管有这么多人兢兢业业的付出，但撼动关系型数据库的江山还远不够实力，也不到时候——直到这位哥们的出现。你看，任何历史性的转折都要依靠一位伟人来带动，说不定下一位就是你，努力吧少年！
这位 Tim 老兄在1989年，发明了万维网，一下子把数据的洪荒世界之门给打开了。数据以前所未有的体量和速度冲了进来，此时的关系型数据库也就慢慢有了吃力和老态的迹象。
历史再一次证明, 不被人胖揍，永远不知道自己几斤几两。
怪兽冲了进来，总要有奥特曼来对付吧。没错，这时候两位英雄人物出场了，一位是 Google，一位是 Amazon。Google 的 MapReduce（2004）和 BigTable（2006）打破了分布式计算和存储的瓶颈。A厂在整个云计算时代都有它的份儿，闪亮的光芒甚是耀眼。它的 Dynamo 数据库，采用了键值对存储，集合了各种眼花缭乱的云计算技术，号称能保障高可用服务。
磐石有了，兵工厂就不会远了。跟 SQL 的发展很像，之后很快各个公司就有了 Hadoop、Hive、Cassandra、MongoDB，也玩起了 MapR。又是一番你追我赶的厮杀，历史是何等的相像。
而这一波厮杀，不仅仅是在堂兄弟、表兄弟之间展开，还要去抢叔叔伯伯们的地盘。这不，蚂蚁金服的OceanBase前两天还动了一下Oracle大叔的地盘，抢掉了它2010年打下的TCP-C排行榜榜首的位置。
年轻人始终有着一股子血气方刚，认为凭着自己年富力强，无所畏惧就要去动大人的奶酪。打仗光靠蛮力怎么可以，它还需要致胜的最本质基础，那就是群众的支持。
每个年轻人都有自己的魅力，有自己的武器都很好，很酷。乾坤圈、金箍棒看着都炫酷，但在如来的眼里，他代表的可是天地万物，说一句代替苍生治治你，分分钟就把你给秒了。那可是群众的力量代表。
上面的 ElasticSearch、MongoDB给我们的感觉都很棒，全文搜索极快，日志存储不费劲，但要去拿起来用，你得好好的去顺顺他们的脾气，要不就给你枣子吃。就如现在很多年轻人，做事情是要哄着做，哪像那些无产阶级革命前辈，都是抢着做。
如果说 OLTP 产品，我们摸索一下 Redis、MongoDB、Kafka 也就算了，能忍就忍吧，毕竟一次投入，永久使用。但 OLAP 产品，Impala、Hive、Presto、Kylin 等都互不连通，还要整一套 ETL 来打通，这谁的脾气能好咯。我做一个报表，还要用 Spark 去每家每户报信，搞不好哪家那天脾气特别大，不待见，数据都取不出来。典型的就是 JOIN 信使，经常吃闭门羹。
当然，被群众（市场）教训过后，年轻人也开始反思。Cloudera 与 Hortonworks 就是典型代表，他俩选择联起手来一块干点事儿。推出了 SQL 级的方言，用来封装自己复杂的外表，原理就是 SQL ON Hadoop。
Hadoop 负责存储，而 SQL 负责计算，存储引擎与计算引擎分离开来，拉拢了不少 SQL 群众，开始铺设广泛的群众基础。
第一次小弟们像大佬妥协，就是推出自己的 SQL-On-Hadoop 产品。虽然嘴上说着是 Not Only SQL， 那也不过是年轻人在坚持他们最后的傲娇而已。
接着，历史又再一次重演。只要一个现象被认可，一群现象就跟风而来。H-Store、Spanner、CockroachDB，最出众的还要数 Postgre，在历经关系数据库、NoSQL之后，尽在旁边捡漏，好东西都往自己身上加，像 Json、FullText Search、MPP、JIT 等特性。
当然，整个历史的转变，总要有人总结陈词。NoSQL的运动者是谁？还记得嘛？没错就是 Google 的三驾马车。那么终结它也只能由Google来官宣，搬起石头砸自己的脚，疼不您咧？
G 厂在2017年的 Spanner 论文中怎么说的？精简一下，“我们 Google 要从 Nosql 转到 SQL 阵营来，SQL 即将成为一切数据访问的基础，就酱”！
声明：本文为CSDN博主「dbLenis」的原创文章，版权归作者所有。
今晚8点直播，扫码报名！
主题：《医疗影像小数据场景中的前沿技术与实践》
介绍：目前腾讯优图涉及眼底、宫颈、脑出血病因分析等多个落地项目，使用的数据格式也不太一样，眼底和宫颈是2D的RGB图像，脑出血是3D CT图像，相比起来，标注 3D 数据的难度比 2D 数据高不少。腾讯优图是如何针对3D CT / MRI 数据提出自监督研究的？研究成果是如何落地于工程中？如何应用在脑出血病因分类和脑肿瘤分割案例中？
热 文 推 荐
☞
☞
