譯者|
自從可以利用計算機做事以來，我們一直在收集的數據以指數級的速度在增長，因此對于數據存儲、處理和分析技術的要求也越來越高。在過去的十年里，由于 SQL 無法滿足這些要求，軟件開發人員就拋棄了它，NoSQL 也就因此而漸漸發展起來：，，， 等等。
然而，如今 SQL 正在重新復出。云端的主要供應商們現在都提供了廣受大眾歡迎的關系型數據庫的托管服務：例如亞馬遜 RDS[1]，谷歌 Cloud SQL[2]，Azure 的 數據庫[3]（Azure 將于今年發布它）。用亞馬遜自己的話來說就是 數據庫結合了 和 MySQL 數據庫，因此該產品一直是“AWS 歷史上增長最快的服務[4]”。在 和 Spark 之上的 SQL 接口繼續蓬勃發展。就在上個月，Kafka 推出了 SQL 支持[5]。
在這篇文章中，我們將研究 SQL 現在為什么會復出的原因，以及這對未來的數據社區工程和分析意味著什么。
第一章：新希望
為了理解為什么 SQL 會卷土重來，讓我們先了解一下最初設計它的原因。
好的故事都是起源于 20 世紀 70 年代
我們的故事始于 20 世紀 70 年代早期的 IBM 研究，那時關系型數據庫就誕生了。當時的查詢語言依賴于復雜的數學邏輯和符號。 和 Boyce 兩個人剛剛完成哲學博士學位，對關系型數據模型印象深刻，但是發現查詢語言將成為其發展的一個主要瓶頸。于是他們便開始設計一種新的查詢語言（用他們自己的話說）：“讓那些沒有接受過數學和計算機編程方面正規訓練的用戶更容易使用[6]”。
兩個查詢語言的比較 ? (來源[6])
仔細想想這件事。在互聯網出現之前，在個人電腦出現之前，當編程語言 C 首次被引入世界時，兩位年輕的計算機科學家意識到，“計算機行業的成功很大程度上依賴于培養一種除了訓練有素的計算機專家以外的用戶[7]”。他們想要的是一種像英語一樣易于閱讀的查詢語言，這也將包括數據庫管理和操作。
其結果就是在 1974 年首次將 SQL 引入世界。在接下來的幾十年里，SQL 將被證明是非常受歡迎的。隨著諸如 R、、DB2、、SQL 、、MySQL 等等關系型數據庫接管了軟件行業，SQL 也成為了與數據庫交互的卓越語言，成為了一個日益擁擠、競爭激烈的生態系統的通用語言。
（遺憾的是， Boyce 從來沒有機會見證 SQL 的成功。1 個月后他便死于腦動脈瘤[8]，只做了一個最早的 SQL 演講，當時他只有 26 歲，留下了一個妻子和一個年輕的女兒。）
有一段時間，似乎 SQL 成功地完成了它的任務。但后來互聯網誕生了。
第二章：NoSQL 的反擊
在 和 Boyce 開發 SQL 的同時，令他們沒有想到的是在加州的第二組工程師正在研究另一個正在萌芽的項目，該項目后來會廣泛擴散并威脅到 SQL 的存在。這個項目就是阿帕網[9]，1969 年 10 月 29 日，它誕生了[10]。
阿帕網的一些創造者，最終演變成今天的互聯網（來源[10]）
SQL 一直發展的都很好，但是直到 1989 年，另一個工程師出現并發明了萬維網WWW[11]。
發明萬維網的物理學家（來源[12]）
像那些茂密的野草一樣，互聯網和網絡蓬勃發展，極大地擾亂了我們的世界，但對于數據社區來說，它還造成了一個特別的麻煩：跟以前相比，新的數據源以更高的數量和速度生成數據。
隨著互聯網的不斷發展，軟件社區發現sql中數據類型，當時的關系型數據庫無法處理這一新的負載。因此出現了一陣騷動的力量，就好像一百萬個數據庫突然過載了。
然后，兩個新的互聯網巨人取得了突破，并開發了他們自己的非關系型分布式系統來幫助解決這一新的數據沖擊：由谷歌發布的 （2004 年發表[13]）和 （2006 年發表[14]），以及亞馬遜的 （2007 年發表[15]）。這些開創性的論文導致出現了更多的非關系數據庫，包括 （基于 論文，2006[16]），（受 和 論文的啟發，2008[17]）和 （2009[18]）。因為這些新系統基本上都是從零開始編寫的，所以它們也沒有使用 SQL，從而導致了 NoSQL 運動的興起。
開發者社區的軟件工程師們也接受了 NoSQL，而且跟 SQL 當時的出現相比，接受的群眾范圍更廣了。這個原因很容易理解：NoSQL 是現在又新又炫；它為大規模數據提供了支持；這似乎是項目通往成功的捷徑。但后來出現了問題。
典型的被 NoSQL 誘惑的軟件開發人員。不要學這家伙
開發人員很快發現，沒有 SQL 實際上是非常受限的……每個 NoSQL 數據庫都提供了自己獨特的查詢語言，這意味著：學習更多的語言（并在同事之間傳播知識）；增加了將數據庫連接到應用程序的難度，導致代碼之間有很強的耦合性；缺乏第三方生態系統，需要公司開發自己的運維和可視化工具。
這些 NoSQL 語言是新的，而且也沒有完全開發完成。例如，關系型數據庫已經運行很多年了，像為 SQL 添加必要的特性（例如 JOIN）這些工作早都已經完成了；NoSQL 語言的不成熟意味著在應用程序級別就會有更多的復雜性。缺乏 JOIN 特性也導致了反范式化sql中數據類型，從而又導致數據膨脹和僵化。
一些 NoSQL 數據庫添加了自己的 “類 SQL” 查詢語言，比如 的 CQL。但這常常會使問題變得更糟。如果使用跟別的東西完全一樣的界面，如果越常見，實際上會導致心理產生更多的疑問：工程師壓根就不知道支持什么，不支持什么。
社區中的一些人在早期就看到了 NoSQL 的問題（例如德維特和斯通布雷克在 2008 年就發現了[21]）。隨著時間的推移，通過使用過程中個人經驗的辛苦積累，越來越多的軟件開發人員也同意了這一點。
第三章：SQL 的回歸
最初被黑暗勢力所誘惑的軟件社區開始看到了光明，SQL 也上演了英雄回歸的一幕。
首先是 上的 SQL 接口（Spark 之后也是），導致該行業重新闡述 NoSQL 為“不只是 SQL”Not Only SQL（耶，干的不錯！）。
緊接著 興起了：完全接納了 SQL 的新的可擴展數據庫。來自于麻省理工學院和布朗大學研究人員的 H-Store（2008年發表[22]）是最早的擴展 OLTP 數據庫之一。谷歌再次引領了風向標，根據他們的 論文（發布于 2012 年[23]）（其作者包括 原作者）開創了基于地理復制的 SQL 界面的數據庫，其次再是 （2014[24]）這樣的其它先驅者。
與此同時， 社區開始復蘇，添加了一些關鍵的改進，比如 JSON 數據類型（2012），以及 10[25]中的新特性的集錦：更好的原生支持分區和復制，支持對 JSON 的全文搜索，以及其它更多的特性（定于今年晚些時候發布的版本）。其他如 （2016[26]）以及鄙公司（今年發布[26]的[26]）找到了針對特定數據任務來擴展 的新方法。
事實上，我們開發[27]的過程與這個行業的發展軌跡是密切相關。早期的 內部版本使用了我們自己的類 SQL 查詢語言 “ioQL”。是的，我們也沒能抵擋住黑暗一面的誘惑：我們感覺能夠構建自己的查詢語言應該會非常強大。然而，盡管這似乎是一條簡單的道路，但我們很快意識到其實需要做更多的工作。我們還發現自己需要不斷地去查找合適的語法，去查詢那些已經可以用 SQL 進行查詢的內容。
有一天，我們意識到構建自己的查詢語言毫無意義。最關鍵還是要接受 SQL。這是我們做出的最好的設計決定之一。頓時，一個全新的世界出現了。現在盡管我們的數據庫才問世 5 個月，但是用戶卻可以在生產環境上使用我們的數據庫，還有很多其他的美好事物：可視化工具（），與常見的 ORM 的連接器，各種工具和備份選項，豐富的在線教程和語法解釋等等。
信谷歌，得永生
谷歌已經在數據工程和基礎架構領域領先了十多年了。我們應該密切關注他們正在做的事情。
看看谷歌的第二篇主要的 論文，就在四個月前發布的（：成為一個 SQL 系統[28]，2017 年 5 月)，你會發現它支持我們的發現成果。
例如，谷歌開始的時候是在 上面構建，但后來發現不用 SQL 會造成很多問題（在我們下面所有的引用內容中強調）：
雖然這些系統提供了數據庫系統的某些優點，但它們缺少許多應用程序開發人員經常依賴的傳統數據庫特性。舉一個關鍵的例子就是健壯的查詢語言，這意味著開發人員必須編寫復雜的代碼來處理和聚合應用程序中的數據。因此，我們決定將 變成一個完整的 SQL 系統，查詢的執行與 的其他架構特性緊密集成（例如強一致性和全局復制）。
在論文的后面，他們進一步抓住了從 NoSQL 過渡到 SQL 的基本原理：
的原始 API 提供了對單個表和交叉表的點查找和范圍掃描的 NoSQL 方法。雖然 NoSQL 方法提供了一個簡單的啟動 的方法，并且在簡單的檢索場景中繼續有用，但是 SQL 在表達更復雜的數據訪問模式和將計算推到數據上提供了重要的附加價值。
本文還描述了 SQL 的采用是如何沒有止步于 ，而是實際上擴展到了谷歌的其余部分，這里的多個系統現在共享一個通用的 SQL 方言:
的 SQL 引擎共享一個共同的 SQL 方言，稱為“標準 SQL”，包括幾個谷歌內部的系統如 F1 和 （其中之一），以及如 這樣的外部系統…
對于谷歌的用戶來說，這降低了跨系統工作的障礙。一個編寫了針對 數據庫的 SQL 的開發人員或數據分析人員，可以將他們對該語言的理解轉移到 ，而不必擔心語法、NULL 處理等細微的差異。
這種方法的成功不言自明。 已經成為主要的谷歌系統的“真相之源”，包括 和谷歌 Play，而“潛在的云客戶對使用 SQL 非常感興趣”。
考慮到谷歌首先幫助發起了 NoSQL 運動，很值得注意的是，它現在正在接受 SQL。（導致一些人最近想：“谷歌過去 10 年給大數據產業做的都是假象嗎？[29]”）
這對數據的未來意味著什么：SQL 將變成細腰
在計算機網絡中，有一個概念叫做“細腰結構 waist”。
這個想法的出現解決了一個關鍵問題：在任何給定的網絡設備上，把它想象成一個堆棧，底層是硬件層，頂部是軟件層。會存在各種網絡硬件；同樣，也有各種各樣的軟件和應用程序。需要某種可以確保無論硬件發生了什么情況，軟件仍然可以連接到網絡的方法；同樣的也能確保無論軟件發生什么，網絡硬件都知道如何處理網絡請求。
在網絡中，細腰的角色由互聯網協議（IP）[30]扮演的，它是為局域網設計的底層聯網協議和更高級別的應用程序和傳輸協議的公共接口（這有一個很好的解釋[31]）。而且（在一個廣泛的簡化中），這個公共接口成為了計算機的通用語言，使網絡能夠相互連接，設備可以通信，而這種“網絡的網絡”成長為今天豐富多樣的互聯網。
我們認為 SQL 已經成為數據分析的細腰。
我們生活的時代，數據正在成為“世界上最有價值的資源”(《經濟學人》，2017 年 5 月[32])。因此，我們看到了專業數據庫（OLAP、時間序列、文檔、圖表等），數據處理工具（、Spark、Flink），數據總線（Kafka、）等呈現出了寒武紀大爆發 式的情形。我們也有了更多需要依靠這些數據基礎設施的應用程序，無論是第三方數據可視化工具（、 、），web 框架（Rails、）或定制的數據驅動的應用程序。
像網絡一樣，我們也有一個復雜的堆棧，底層是基礎設施，頂部是應用程序。通常，我們最終會編寫大量的膠水代碼來使這個堆棧工作起來。但是膠水代碼可能很脆弱：需要精心的運維。
我們需要的是一個公共接口，允許堆棧的各個部分彼此通信。理想情況下，這個行業已經標準化了。它能讓不同層之間的通信阻礙能夠降到最小。
這就是 SQL 的力量。和 IP 一樣，SQL 也是一個公共接口。
但 SQL 實際上比 IP 復雜得多。因為數據還需要支持人類分析。而且，SQL 創建者最初給它設定的目標之一就是可讀性要高。
SQL 是完美的嗎？不，但社區中的大多數人都已經了解了這門語言。雖然已經有工程師在開發更自然的語言界面，但是這些系統最終會連接到哪里？還是 SQL。
所以在堆棧的頂部還有一層。那一層就是我們人類。
SQL 回歸
SQL 回來了。不只是因為在組裝 NoSQL 工具時編寫膠水代碼的做法十分令人反感，也不僅僅是因為學習各種各樣的新語言是困難的，也不只是因為標準會帶來各種優點。
也因為這個世界充滿了數據。它包圍著我們，束縛著我們。起初，我們依靠人類的感覺神經系統來處理它。現在，軟件和硬件系統也變得足夠智能，可以幫助我們。隨著收集的數據越來越多，我們也可以更好地認識這個世界，系統的復雜性、存儲、處理、分析以及對這些數據可視化的需求只會繼續增長。
數據科學家尤達大師
要么我們生活在滿大街的系統都是如紙一般脆弱，接口量達到數百萬個的世界里，要么我們可以再次選擇 SQL，這樣我們生活的世界也可能會變得越來越強大。