亂象​

當今數據庫供應商風頭正茂的，要數這三家公司，Amazon, Google, Microsoft. 沒錯，他們都是云計算提供者?；馃岬娜羁醇耶a品分別是：

• Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL.

A廠CTO說，AWS最火的產品是什么呢?是 Aurora 數據庫，它同時兼容 PostgreSQL 與 MySQL. 他還指出，Hadoop 也好，Spark, Kafka 也罷，都在極力推動 SQL 接口來讓更多的服務 API 暴露給程序員。

[[281642]]

從 A 廠產品的銷量來說，企業(yè)比較青睞于這些有標準 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"} 
 } 
 } 
 } 
 } 
} 

當中一個括號少了，查詢就運行不下去。一個 SQL, WHERE, GROUP BY 就能解決的問題，整出一堆 Json 表達式。你能看得下去?

再比如，我們存日志的 MongoDB, 它的官方語言是 javascript: 

看上去，這比 ElasticSearch 好看一些，每個字段都加了一個 $ 符號，請問為什么 total 就不用加呢?

原本這些數據(搜索用的 ElasticSearch, 日志用的 MongoDB)都存在 SQL 數據庫中，使用 SQL 一勞永逸的搞定所有查詢。但現在呢, 要花點時間熟悉 ES 和 MongoDB 的古怪語法了，還要搞清楚，數據在流轉過程中，是否有丟失。帶來的復雜度不僅僅是一點點。

什么，你說程序員不就是應該 996，拼命學的嘛?這是福報。嗯，這樣的福報誰愛要，誰拿去，反正我不!

歷史

讓我們一起回憶下SQL關系型數據庫的起源。這要追溯到IBM發(fā)表關系型數據庫論文的那個年代，1970年。

1970時，關系型數據計算已經非?；馃崃恕５@種關系運算的查詢，只掌握在少數天才人的手里。普通人只能看著眼饞。來，一起領略下當時的關系運算： 

能看懂嘛?看懂舉手，pingCAP，螞蟻金服在召喚你!

事實證明，哪里有黑盒，那里就會產生魔法師?？傆刑觳蓬I袖為勞苦大眾著想。Donald Chamberlin 和 Raymond Boyce 就是這樣的天才!他們發(fā)明了 System R(關系型數據庫原型)，又在自然語言的研究方向上，發(fā)明了結構化英語查詢語言(Structured English Query Lanuage, SEQUEL, 這也是為什么大家經常會把SQL讀成 see-ku-er的原因)， 后因商標之爭，SEQUEL更名為 SQL. 那么SQL 相比上面的數學表達式有啥好處呢，感受下： 

前后兩個運算都是在找出薪水比自己經理還高的那些員工。前者是關系數據表達式，只有數學大師才懂的符號;后者是 SQL 表達式，任何人在1星期絕對可以掌握的技術。

后來的事情，相信只要你不是00后，應該都有所耳聞了。IBM DB2, Oracle, SQL Server, MySQL 都如雨后春筍般的出來了，有了 System R 這般的磐石，有了 SQL 這代新型武器，各自造就了兵工廠，開疆擴土。戰(zhàn)爭一直打到現在。

如果不是因為 ARPANET 這位默默在墻角自習的好青年，恐怕拉里森這位Oracle家長還要嘚瑟個好多年。經過多年的沉寂修煉，ARPANET終于在我們這個時代成長成一個壯實的大小伙了。也就是今天的互聯(lián)網!

來，見識下當年那一小撮默默地在加利福尼亞學習的小伙伴。

革命不成功，壯士不歇息。盡管有這么多人在兢兢業(yè)業(yè)的付出，但撼動關系型數據庫的江山還遠不夠實力，不也到時候。直到這位哥們的出現。你看，任何歷史性的轉折都要依靠一位偉人來帶動，說不定下一位就是你，努力吧，少年! 

這位 Tim 老兄在1989年，發(fā)明了萬維網，一下子把數據的洪荒世界之門給打開了。數據以前所未有的體量和速度沖了進來。此時的關系型數據庫也就慢慢有了吃力和老態(tài)的跡象。

歷史再一次證明, 不被人胖揍，永遠不知道自己幾斤幾兩。

怪獸沖了進來，總要有奧特曼來對付吧。沒錯，這時候兩位英雄人物出場了，一位是 Google, 一位是 Amazon. Google 的 MapReduce(2004)和 BigTable(2006)，打破了分布式計算和存儲的瓶頸。這兩篇論文可以在后臺，回復“1024”得到。A廠在整個云計算時代都有它的份兒，閃亮的光芒甚是耀眼。它的 Dynamo 數據庫，采用了鍵值對存儲，集合了各種眼花繚亂的云計算技術，號稱能保障高可用服務。

磐石有了，兵工廠就不會遠了。跟 SQL 的發(fā)展很像，之后很快各個公司就有了 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 就是典型代表，他倆選擇聯(lián)起手來一塊干點事兒。推出了 SQL 級的方言，用來封裝自己復雜的外表，原理就是 SQL ON Hadoop.

Hadoop 負責存儲，而 SQL 負責計算，存儲引擎與計算引擎分離開來，拉攏了不少 SQL 群眾，開始鋪設廣泛的群眾基礎。

王者歸來

第一次小弟們像大佬妥協(xié)，就是推出自己的 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 即將成為一切數據訪問的基礎，就醬”。