一些NoSQL數(shù)據(jù)庫添加了自己的“類SQL”的查詢語言，如Cassandra的CQL。但這往往使問題更糟。使用幾乎相同的界面，卻讓內(nèi)心更糾結(jié)：工程師不知道什么是支持的，什么不是。
社區(qū)中的一些人在早期就看到了NoSQL的問題(例如，DeWitt和Stonebraker在2008年就看到了)。經(jīng)過時(shí)間的實(shí)戰(zhàn)檢驗(yàn)，以及使用過程中的經(jīng)驗(yàn)積累，越來越多的軟件開發(fā)人員也看到了這一點(diǎn)。
第3部分：回歸SQL
經(jīng)歷了黎明前的黑暗，軟件社區(qū)看到了曙光，那就是回歸SQL。
首先是Hadoop(之后的Spark)之上的SQL接口，引導(dǎo)業(yè)界興起了NoSQL ,NoSQL“不僅僅是SQL”。
然后，NewSQL的興起：新的可擴(kuò)展性數(shù)據(jù)庫，完全支持SQL。來自于麻省理工學(xué)院(MIT)和布朗大學(xué)(Brown)研究人員的H-Store (2008年發(fā)布)是第一個(gè)可擴(kuò)展OLTP數(shù)據(jù)庫之一。Google在發(fā)布的第一份Spanner論文(2012年發(fā)布)(其作者包括最初的MapReduce作者)中揭示這是基于 SQL 的查詢語言，可以將一份數(shù)據(jù)復(fù)制到全球范圍的多個(gè)數(shù)據(jù)中心，并保證數(shù)據(jù)的一致性，從而開創(chuàng)了可地理復(fù)制的SQL界面的數(shù)據(jù)庫，接著是CockroachDB(2014)這樣的先驅(qū)者。
與此同時(shí)，PostgreSQL社區(qū)開始復(fù)蘇，增加了JSON數(shù)據(jù)類型(2012)，以及PostgreSQL 10 的新特性：對(duì)分區(qū)和復(fù)制更好的本地支持，JSON的全文搜索支持等(今年晚些時(shí)候發(fā)布)。其他像CitusDB(2016)和其他的公司(今年發(fā)布的TimescaleDB)發(fā)現(xiàn)了新的方法從而針對(duì)特定數(shù)據(jù)工作負(fù)載的擴(kuò)展PostgreSQL。
事實(shí)上，我們開發(fā)TimescaleDB的過程與業(yè)界的發(fā)展軌跡密切相關(guān)。早期的TimescaleDB內(nèi)部版本使用了我們自己的類sql查詢語言“ioQL”。是的，我們正是被困難驅(qū)動(dòng)著：構(gòu)建我們自己的查詢語言才能更強(qiáng)大。但是，雖然看似簡單，但我們很快意識(shí)到，我們必須做更多的工作：例如，決定語法，構(gòu)建各種連接器，培訓(xùn)用戶等。我們還發(fā)現(xiàn)自己需要不斷地去查找合適的語法，去查詢那些已經(jīng)可以用SQL進(jìn)行查詢的內(nèi)容。
有一天，我們意識(shí)到建立自己的查詢語言是沒有意義的。關(guān)鍵還是要擁抱SQL。這是我們做出的最好的決策之一。同時(shí)也開啟了一個(gè)全新的世界。今天，即使我們的數(shù)據(jù)庫才問世5個(gè)月，但我們的用戶完全可以使用我們的產(chǎn)品，并獲得各種各樣支持：可視化工具(Tableau)，通用ORM連接器，各種工具和備份選項(xiàng)，大量的在線教程和語法說明等。
但是不要把我們的話放在心上，看看谷歌
Google已經(jīng)十多年來一直處于數(shù)據(jù)工程和基礎(chǔ)設(shè)施的領(lǐng)先地位。我們應(yīng)該密切關(guān)注他們正在做什么。
看看谷歌的第二大Spanner論文，僅在四個(gè)月前發(fā)布(Spanner：成為一個(gè)SQL系統(tǒng)，2017年5月)，你會(huì)發(fā)現(xiàn)它支持我們的發(fā)現(xiàn)成果。
例如，Google開始在Bigtable之上開發(fā)，但是后來發(fā)現(xiàn)缺少SQL產(chǎn)生了一系列問題(在下面的所有引號(hào)中有強(qiáng)調(diào))：
“雖然這些系統(tǒng)提供了數(shù)據(jù)庫系統(tǒng)的一些優(yōu)勢(shì)，但它們?nèi)狈?yīng)用程序開發(fā)人員常常依賴的許多傳統(tǒng)數(shù)據(jù)庫功能。一個(gè)關(guān)鍵的例子是強(qiáng)大的查詢語言，這意味著開發(fā)人員必須編寫復(fù)雜的代碼來處理和聚合應(yīng)用程序中的數(shù)據(jù)。因此，我們決定將Spanner變成一個(gè)功能齊全的SQL系統(tǒng)，其查詢執(zhí)行與Spanner的其他架構(gòu)功能(如強(qiáng)一致性和全局復(fù)制)緊密集成。
在本文的后面，他們進(jìn)一步了解從NoSQL轉(zhuǎn)換到SQL的理由：Spanner的原始API提供了為單個(gè)和交叉表的點(diǎn)查找和范圍掃描的NoSQL方法。雖然NoSQL方法提供了啟動(dòng)Spanner的簡單路徑，并且在簡單的檢索方案中繼續(xù)有用， 但SQL在表達(dá)更復(fù)雜的數(shù)據(jù)訪問模式并將計(jì)算推送到數(shù)據(jù)方面提供了重要的附加價(jià)值。
本文還介紹了如何在Spanner上使用SQL并不會(huì)停止，哪怕某一個(gè)數(shù)據(jù)中心停止運(yùn)轉(zhuǎn),仍然可用。但實(shí)際上擴(kuò)展到Google的其余部分，其中多個(gè)系統(tǒng)共享一個(gè)通用的SQL語言：
Spanner的SQL引擎與Google的其他幾個(gè)系統(tǒng)共享一個(gè)稱為“標(biāo)準(zhǔn)SQL”的常見SQL語言，包括內(nèi)部系統(tǒng)，如F1和Dremel(以及其他)以及外部系統(tǒng)，如BigQuery 。
對(duì)于Google用戶，這會(huì)降低跨系統(tǒng)的工作障礙。對(duì)Spanner數(shù)據(jù)庫編寫SQL的開發(fā)人員或數(shù)據(jù)分析師可以將他們對(duì)語言的理解轉(zhuǎn)移到Dremel，而不用擔(dān)心語法，NULL處理等方面的微妙差異。
這就是這種方法的成功奧秘。當(dāng)“潛在云客戶對(duì)SQL有濃厚興趣”時(shí)，Spanner已經(jīng)成為Google主要系統(tǒng)的根基(包括AdWords和Google Play) 。
考慮到Google最先啟動(dòng)了NoSQL的運(yùn)動(dòng)，這是非常顯著的，它今天正在回歸SQL。(引起一些人反思：“ Google 10年前挺進(jìn)大數(shù)據(jù)市場就是個(gè)大忽悠嗎” )