'為什麼SQL正在擊敗NoSQL，這對未來的數據意味著什麼'
導讀：經過多年的沉寂之後，今天的SQL正在復出。緣由如何？這對數據社區有什麼影響？看看本文的分析。以下為譯文。
自從可以利用計算機做事以來，我們一直在收集的數據以指數級的速度在增長，因此對於數據存儲、處理和分析技術的要求也越來越高。在過去的十年裡，由於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為何捲土重來？
要理解SQL為何會捲土重來，先從為什麼設計SQL開始。
導讀：經過多年的沉寂之後，今天的SQL正在復出。緣由如何？這對數據社區有什麼影響？看看本文的分析。以下為譯文。
自從可以利用計算機做事以來，我們一直在收集的數據以指數級的速度在增長，因此對於數據存儲、處理和分析技術的要求也越來越高。在過去的十年裡，由於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為何捲土重來？
要理解SQL為何會捲土重來，先從為什麼設計SQL開始。
我們的故事始於20世紀70年代早期的IBM研究，那時關係型數據庫就誕生了。當時的查詢語言依賴於複雜的數學邏輯和符號。Donald Chamberlin和Raymond Boyce兩個人剛剛完成哲學博士學位，對關係型數據模型印象深刻，但是發現查詢語言將成為其發展的一個主要瓶頸。於是他們便開始設計一種新的查詢語言(用他們自己的話說)：“讓那些沒有接受過數學和計算機編程方面正規訓練的用戶更容易使用”。
導讀：經過多年的沉寂之後，今天的SQL正在復出。緣由如何？這對數據社區有什麼影響？看看本文的分析。以下為譯文。
自從可以利用計算機做事以來，我們一直在收集的數據以指數級的速度在增長，因此對於數據存儲、處理和分析技術的要求也越來越高。在過去的十年裡，由於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為何捲土重來？
要理解SQL為何會捲土重來，先從為什麼設計SQL開始。
我們的故事始於20世紀70年代早期的IBM研究，那時關係型數據庫就誕生了。當時的查詢語言依賴於複雜的數學邏輯和符號。Donald Chamberlin和Raymond Boyce兩個人剛剛完成哲學博士學位，對關係型數據模型印象深刻，但是發現查詢語言將成為其發展的一個主要瓶頸。於是他們便開始設計一種新的查詢語言(用他們自己的話說)：“讓那些沒有接受過數學和計算機編程方面正規訓練的用戶更容易使用”。
兩個查詢語言的比較
仔細想想這件事。在互聯網出現之前，在個人電腦出現之前，當編程語言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的存在。這個項目就是ARPANET，1969年10月29日，它誕生了。
ARPANET的一些創造者，最終演變成今天的互聯網
SQL一直髮展的都很好，但是直到1989年，另一個工程師出現併發明瞭萬維網。
像那些茂密的野草一樣，互聯網和網絡蓬勃發展，極大地擾亂了我們的世界，但對於數據社區來說，它還造成了一個特別的麻煩:跟以前相比，新的數據源以更高的數量和速度生成數據。
隨著互聯網的不斷髮展，軟件社區發現，當時的關係型數據庫無法處理這一新的負載。因此出現了一陣騷動的力量，就好像一百萬個數據庫突然過載了。
然後，兩個新的互聯網巨人取得了突破，並開發了他們自己的非關係型分佈式系統來幫助解決這一新的數據衝擊：由谷歌發佈的MapReduce和Bigtable，以及亞馬遜發佈的 Dynamo。這些開創性的論文導致出現了更多的非關係數據庫，包括Hadoop，Cassandra和MongoDB。因為這些新系統基本上都是從零開始編寫的，所以它們也沒有使用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將變成細腰
在計算機網絡中，有一個概念叫做“細腰結構”。
這個想法的出現解決了一個關鍵問題:在任何給定的網絡設備上，想象一個堆棧，底層的硬件層和頂部的軟件層。中間可能會存在各種網絡硬件;同樣，也存在存在各種各樣的軟件和應用程序。需要某種可以確保無論硬件發生了什麼情況，軟件仍然可以連接到網絡的方法;同樣的也能確保無論軟件發生什麼，網絡硬件都知道如何處理網絡請求。
導讀：經過多年的沉寂之後，今天的SQL正在復出。緣由如何？這對數據社區有什麼影響？看看本文的分析。以下為譯文。
自從可以利用計算機做事以來，我們一直在收集的數據以指數級的速度在增長，因此對於數據存儲、處理和分析技術的要求也越來越高。在過去的十年裡，由於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為何捲土重來？
要理解SQL為何會捲土重來，先從為什麼設計SQL開始。
我們的故事始於20世紀70年代早期的IBM研究，那時關係型數據庫就誕生了。當時的查詢語言依賴於複雜的數學邏輯和符號。Donald Chamberlin和Raymond Boyce兩個人剛剛完成哲學博士學位，對關係型數據模型印象深刻，但是發現查詢語言將成為其發展的一個主要瓶頸。於是他們便開始設計一種新的查詢語言(用他們自己的話說)：“讓那些沒有接受過數學和計算機編程方面正規訓練的用戶更容易使用”。
兩個查詢語言的比較
仔細想想這件事。在互聯網出現之前，在個人電腦出現之前，當編程語言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的存在。這個項目就是ARPANET，1969年10月29日，它誕生了。
ARPANET的一些創造者，最終演變成今天的互聯網
SQL一直髮展的都很好，但是直到1989年，另一個工程師出現併發明瞭萬維網。
像那些茂密的野草一樣，互聯網和網絡蓬勃發展，極大地擾亂了我們的世界，但對於數據社區來說，它還造成了一個特別的麻煩:跟以前相比，新的數據源以更高的數量和速度生成數據。
隨著互聯網的不斷髮展，軟件社區發現，當時的關係型數據庫無法處理這一新的負載。因此出現了一陣騷動的力量，就好像一百萬個數據庫突然過載了。
然後，兩個新的互聯網巨人取得了突破，並開發了他們自己的非關係型分佈式系統來幫助解決這一新的數據衝擊：由谷歌發佈的MapReduce和Bigtable，以及亞馬遜發佈的 Dynamo。這些開創性的論文導致出現了更多的非關係數據庫，包括Hadoop，Cassandra和MongoDB。因為這些新系統基本上都是從零開始編寫的，所以它們也沒有使用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正在復出。緣由如何？這對數據社區有什麼影響？看看本文的分析。以下為譯文。
自從可以利用計算機做事以來，我們一直在收集的數據以指數級的速度在增長，因此對於數據存儲、處理和分析技術的要求也越來越高。在過去的十年裡，由於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為何捲土重來？
要理解SQL為何會捲土重來，先從為什麼設計SQL開始。
我們的故事始於20世紀70年代早期的IBM研究，那時關係型數據庫就誕生了。當時的查詢語言依賴於複雜的數學邏輯和符號。Donald Chamberlin和Raymond Boyce兩個人剛剛完成哲學博士學位，對關係型數據模型印象深刻，但是發現查詢語言將成為其發展的一個主要瓶頸。於是他們便開始設計一種新的查詢語言(用他們自己的話說)：“讓那些沒有接受過數學和計算機編程方面正規訓練的用戶更容易使用”。
兩個查詢語言的比較
仔細想想這件事。在互聯網出現之前，在個人電腦出現之前，當編程語言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的存在。這個項目就是ARPANET，1969年10月29日，它誕生了。
ARPANET的一些創造者，最終演變成今天的互聯網
SQL一直髮展的都很好，但是直到1989年，另一個工程師出現併發明瞭萬維網。
像那些茂密的野草一樣，互聯網和網絡蓬勃發展，極大地擾亂了我們的世界，但對於數據社區來說，它還造成了一個特別的麻煩:跟以前相比，新的數據源以更高的數量和速度生成數據。
隨著互聯網的不斷髮展，軟件社區發現，當時的關係型數據庫無法處理這一新的負載。因此出現了一陣騷動的力量，就好像一百萬個數據庫突然過載了。
然後，兩個新的互聯網巨人取得了突破，並開發了他們自己的非關係型分佈式系統來幫助解決這一新的數據衝擊：由谷歌發佈的MapReduce和Bigtable，以及亞馬遜發佈的 Dynamo。這些開創性的論文導致出現了更多的非關係數據庫，包括Hadoop，Cassandra和MongoDB。因為這些新系統基本上都是從零開始編寫的，所以它們也沒有使用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。一切都將遵循能量守恆定律。
想了解更多關於數據庫、雲技術的內容嗎？
快來關注“數據和雲"、"雲和恩墨，"公眾號及"雲和恩墨"官方網站，我們期待大家一同學習與進步！
導讀：經過多年的沉寂之後，今天的SQL正在復出。緣由如何？這對數據社區有什麼影響？看看本文的分析。以下為譯文。
自從可以利用計算機做事以來，我們一直在收集的數據以指數級的速度在增長，因此對於數據存儲、處理和分析技術的要求也越來越高。在過去的十年裡，由於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為何捲土重來？
要理解SQL為何會捲土重來，先從為什麼設計SQL開始。
我們的故事始於20世紀70年代早期的IBM研究，那時關係型數據庫就誕生了。當時的查詢語言依賴於複雜的數學邏輯和符號。Donald Chamberlin和Raymond Boyce兩個人剛剛完成哲學博士學位，對關係型數據模型印象深刻，但是發現查詢語言將成為其發展的一個主要瓶頸。於是他們便開始設計一種新的查詢語言(用他們自己的話說)：“讓那些沒有接受過數學和計算機編程方面正規訓練的用戶更容易使用”。
兩個查詢語言的比較
仔細想想這件事。在互聯網出現之前，在個人電腦出現之前，當編程語言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的存在。這個項目就是ARPANET，1969年10月29日，它誕生了。
ARPANET的一些創造者，最終演變成今天的互聯網
SQL一直髮展的都很好，但是直到1989年，另一個工程師出現併發明瞭萬維網。
像那些茂密的野草一樣，互聯網和網絡蓬勃發展，極大地擾亂了我們的世界，但對於數據社區來說，它還造成了一個特別的麻煩:跟以前相比，新的數據源以更高的數量和速度生成數據。
隨著互聯網的不斷髮展，軟件社區發現，當時的關係型數據庫無法處理這一新的負載。因此出現了一陣騷動的力量，就好像一百萬個數據庫突然過載了。
然後，兩個新的互聯網巨人取得了突破，並開發了他們自己的非關係型分佈式系統來幫助解決這一新的數據衝擊：由谷歌發佈的MapReduce和Bigtable，以及亞馬遜發佈的 Dynamo。這些開創性的論文導致出現了更多的非關係數據庫，包括Hadoop，Cassandra和MongoDB。因為這些新系統基本上都是從零開始編寫的，所以它們也沒有使用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。一切都將遵循能量守恆定律。
想了解更多關於數據庫、雲技術的內容嗎？
快來關注“數據和雲"、"雲和恩墨，"公眾號及"雲和恩墨"官方網站，我們期待大家一同學習與進步！
數據和雲小程序”DBASK“在線問答，隨時解惑，歡迎瞭解和關注！
導讀：經過多年的沉寂之後，今天的SQL正在復出。緣由如何？這對數據社區有什麼影響？看看本文的分析。以下為譯文。
自從可以利用計算機做事以來，我們一直在收集的數據以指數級的速度在增長，因此對於數據存儲、處理和分析技術的要求也越來越高。在過去的十年裡，由於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為何捲土重來？
要理解SQL為何會捲土重來，先從為什麼設計SQL開始。
我們的故事始於20世紀70年代早期的IBM研究，那時關係型數據庫就誕生了。當時的查詢語言依賴於複雜的數學邏輯和符號。Donald Chamberlin和Raymond Boyce兩個人剛剛完成哲學博士學位，對關係型數據模型印象深刻，但是發現查詢語言將成為其發展的一個主要瓶頸。於是他們便開始設計一種新的查詢語言(用他們自己的話說)：“讓那些沒有接受過數學和計算機編程方面正規訓練的用戶更容易使用”。
兩個查詢語言的比較
仔細想想這件事。在互聯網出現之前，在個人電腦出現之前，當編程語言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的存在。這個項目就是ARPANET，1969年10月29日，它誕生了。
ARPANET的一些創造者，最終演變成今天的互聯網
SQL一直髮展的都很好，但是直到1989年，另一個工程師出現併發明瞭萬維網。
像那些茂密的野草一樣，互聯網和網絡蓬勃發展，極大地擾亂了我們的世界，但對於數據社區來說，它還造成了一個特別的麻煩:跟以前相比，新的數據源以更高的數量和速度生成數據。
隨著互聯網的不斷髮展，軟件社區發現，當時的關係型數據庫無法處理這一新的負載。因此出現了一陣騷動的力量，就好像一百萬個數據庫突然過載了。
然後，兩個新的互聯網巨人取得了突破，並開發了他們自己的非關係型分佈式系統來幫助解決這一新的數據衝擊：由谷歌發佈的MapReduce和Bigtable，以及亞馬遜發佈的 Dynamo。這些開創性的論文導致出現了更多的非關係數據庫，包括Hadoop，Cassandra和MongoDB。因為這些新系統基本上都是從零開始編寫的，所以它們也沒有使用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。一切都將遵循能量守恆定律。
想了解更多關於數據庫、雲技術的內容嗎？
快來關注“數據和雲"、"雲和恩墨，"公眾號及"雲和恩墨"官方網站，我們期待大家一同學習與進步！
數據和雲小程序”DBASK“在線問答，隨時解惑，歡迎瞭解和關注！