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