SQL 已死，NoSQL才是王道？醒醒吧，别瞎说八道了

 

 

 

 

乱象

 

 

当今数据库供应商风头正茂的，要数这三家公司，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 的古怪语法了，还要搞清楚，数据在流转过程中，是否有丢失。带来的复杂度不仅仅是一点点。

 

什么，你说程序员不就是应该 996，拼命学的嘛？这是福报。嗯，这样的福报谁爱要，谁拿去，反正我不！

 

 

 

历史

 

 

 

让我们一起回忆下SQL关系型数据库的起源。这要追溯到IBM发表关系型数据库论文的那个年代，1970年。（这篇论文我在以往文章中写过很多次，我自己也翻译过它，需要的同学后台回复“论文”即可得）

 

1970时，关系型数据计算已经非常火热了。但这种关系运算的查询，只掌握在少数天才人的手里。普通人只能看着眼馋。来，一起领略下当时的关系运算：

 

 

能看懂嘛？看懂举手，pingCAP，蚂蚁金服在召唤你！

 

事实证明，哪里有黑盒，那里就会产生魔法师。总有天才领袖为劳苦大众着想。Donald Chamberlin 和 Raymond Boyce 就是这样的天才！他们发明了 System R(关系型数据库原型），又在自然语言的研究方向上，发明了结构化英语查询语言（Structured English Query Lanuage, SEQUEL, 这也是为什么大家经常会把SQL读成 see-ku-er的原因）， 后因商标之争，SEQUEL更名为 SQL. 那么SQL 相比上面的数学表达式有啥好处呢，感受下：

 

 

前后两个运算都是在找出薪水比自己经理还高的那些员工。前者是关系数据表达式，只有数学大师才懂的符号；后者是 SQL 表达式，任何人在1星期绝对可以掌握的技术。

 

后来的事情，相信只要你不是00后，应该都有所耳闻了。IBM DB2, Oracle, SQL Server, MySQL 都如雨后春笋般的出来了，有了 System R 这般的磐石，有了 SQL 这代新型武器，各自造就了兵工厂，开疆扩土。战争一直打到现在。

 

如果不是因为 ARPANET 这位默默在墙角自习的好青年，恐怕拉里森这位Oracle家长还要嘚瑟个好多年。经过多年的沉寂修炼，ARPANET终于在我们这个时代成长成一个壮实的大小伙了。也就是今天的互联网！

 

来，见识下当年那一小撮默默地在加利福尼亚学习的小伙伴

 

 

革命不成功，壮士不歇息。尽管有这么多人在兢兢业业的付出，但撼动关系型数据库的江山还远不够实力，不也到时候。直到这位哥们的出现。你看，任何历史性的转折都要依靠一位伟人来带动，说不定下一位就是你，努力吧，少年！

 

 

这位 Tim 老兄在1989年，发明了万维网，一下子把数据的洪荒世界之门给打开了。数据以前所未有的体量和速度冲了进来。此时的关系型数据库也就慢慢有了吃力和老态的迹象。

 

历史再一次证明, 不被人胖揍，永远不知道自己几斤几两。

 

怪兽冲了进来，总要有奥特曼来对付吧。没错，这时候两位英雄人物出场了，一位是 Google, 一位是 Amazon. Google 的 MapReduce（2004）和 BigTable(2006)，打破了分布式计算和存储的瓶颈。这两篇论文可以在后台，回复“1024”得到。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 论文中怎么说的：

 

“While these systems provided some of the benefits of a database system, they lacked many traditional database features that application developers often rely on. A key example is a robust query language, meaning that developers had to write complex code to process and aggregate the data in their applications. As a result, we decided to turn Spanner into a full featured SQL system, with query execution tightly integrated with the other architectural features of Spanner (such as strong consistency and global replication).”

 

 

The original API of Spanner provided NoSQL methods for point lookups and range scans of individual and interleaved tables. While NoSQL methods provided a simple path to launching Spanner, and continue to be useful in simple retrieval scenarios, SQL has provided significant additional value in expressing more complex data access patterns and pushing computation to the data.

 

Spanner’s SQL engine shares a common SQL dialect, called “Standard SQL”, with several other systems at Google including internal systems such as F1 and Dremel (among others), and external systems such as BigQuery…

 

For users within Google, this lowers the barrier of working across the systems. A developer or data analyst who writes SQL against a Spanner database can transfer their understanding of the language to Dremel without concern over subtle differences in syntax, NULL handling, etc.

 

那我来精简一下，“我们 Google 要从 Nosql 转到 SQL 阵营来，SQL 即将成为一切数据访问的基础，就酱”

 

 

···End···