為什么說SQL正在擊敗NoSQL，這對數據的未來意味著什么？

隨著計算機的日益普及，各種應用每天產生的數據量呈指數級增長。如何存儲這些數據，有效處理分析這些數據,并從中提取有價值的信息,是當下迫切需要解決的問題。在過去的十年里，NoSQL在軟件工程師陣營里越來越受歡迎，其中最重要的實現是MapReduce ，Bigtable,Cassandra，MongoDB,等產品。 它主要用于解決SQL的可擴展性問題。

然而今天SQL開始回歸。幾乎所有的云計算服務提供商都在提供備受青睞的關系型數據庫管理服務：例如Amazon RDS，Google Cloud SQL，Azure 的PostgreSQL數據庫（Azure今年推出）。在亞馬遜看來，其PostgreSQL和MySQL兼容的數據庫產品Aurora一直是AWS歷史上增長最快的服務。Hadoop和Spark之上的SQL接口繼續迅猛發展。就在上個月，Kafka推出了SQL支持。

在這篇文章中，我們將研究SQL備受青睞的原因以及這對未來的數據社區工程和分析意味著什么。

第1部分：新希望的崛起

想要了解SQL為什么回歸，讓我們先了解他最初的設計初衷。

故事始于20世紀70年代初的IBM研究院，其中關系型數據庫誕生了。那時候，查詢語言依賴于復雜的數學邏輯和符號。Donald Chamberlin和Raymond Boyce兩位博士對關系型數據模型造詣頗深，看到查詢語言將成為其主要瓶頸。他們開始設計一種新的查詢語言（以他們自己的話來說）：“ 用戶使用更容易，不需要再參加數學或計算機程序設計方面的正規培訓 ”。

回想在互聯網之前，在PC出現以前，當程序設計語言C首次被引入世界時，兩名年輕的計算機科學家意識到，“計算機行業的成功很大程度上依賴于培養一種除了訓練有素的計算機專家以外的用戶。“他們渴望一種與英文一樣容易閱讀的查詢語言，包括數據庫管理和操作。

結果是SQL在1974年首次被引入世界，成了關系型數據庫的最主要語言。在接下來的幾十年里，SQL被證明也是很受歡迎的。作為關系型數據庫，如System R，Ingres，DB2，Oracle，SQL Server，PostgreSQL，MySQL（等等）在軟件行業里的發展壯大，SQL也成為了與數據庫進行交互的首選語言，成為了一個日益擁擠、競爭激烈的生態系統的通用語言。。

（不幸的是，Raymond Boyce從來沒有機會見證SQL的成功，他只做了一個早期的SQL演講，1個月后他便死于腦動脈瘤，當時他只有26歲，留下了一個妻子和一個年輕的女兒。）

有一段時間，似乎SQL已經成功地履行了它的使命。接著互聯網出現了。

第2部分：NoSQL反擊

雖然Chamberlin和Boyce正在開發SQL，但他們沒有意識到的是，加利福尼亞州的 另一批工程師正在開展另一個新興項目，該項目逐漸成熟后，明顯威脅到SQL的存在。該項目就是 ARPANET，誕生于1969年10月29日。

但是此前SQL發展一直很好，直到1989年，另一位工程師的出現并發明了萬維網。

互聯網和Web的蓬勃發展正在改變著我們的世界，但是對于數據社區來說，也是很讓人頭痛的：數據以大的量級和更快的速度爆炸式增長。

隨著互聯網的不斷發展和壯大，軟件社區發現當時的關系數據庫無法應對新的負載壓力，就好像一百萬個數據庫突然過載讓人抓狂一般。

然后兩家新的互聯網巨頭取得突破，并開發了自己的非關系型分布式系統來應對這種新的數據沖擊：Google的MapReduce（2004年發布）和Bigtable（2006年發布）以及亞馬遜的Dynamo（2007年發布）。這些開創性論文導致出現了更多的非關系型數據庫，包括Hadoop（基于MapReduce論文，2006），Cassandra（Bigtable和Dynamo的深度解析，2008 ）和MongoDB（2009））。因為這些都是從零開始大量編寫的新系統，避開了SQL，導致了NoSQL運動的興起。

開發者社區的軟件工程師們逐漸地也接受了NoSQL，相較于SQL當時的出現，被越來越多的工程師所接受。這個原因非常容易理解：NoSQL是現在流行的；它承諾了規模和權力；這似乎是項目通往成功的捷徑。但后來問題出現了。

開發人員很快發現，不用SQL的局限性。每個NoSQL數據庫都提供了自己獨特的查詢語言，這意味著：要學習更多的語言（并向同事教授）; 將這些數據庫連接到應用程序的難度增加，導致大量膠水代碼的出現（代碼之間有很強的耦合性）;缺乏第三方生態系統，要求企業必須開發自己的操作和可視化工具。

這些NoSQL語言是新的，也沒有完全開發。例如，關系型數據庫已經運行很多年了，為SQL添加必要的功能（例如JOIN）也早都已經完成了，NoSQL語言的不成熟意味著在應用程序級別就會有更多的復雜性。缺乏JOIN也導致了非規范化，導致數據膨脹和僵化。

一些NoSQL數據庫添加了自己的“類SQL”的查詢語言，如Cassandra的CQL。但這往往使問題更糟。使用幾乎相同的界面，卻讓內心更糾結：工程師不知道什么是支持的，什么不是。

社區中的一些人在早期就看到了NoSQL的問題（例如，DeWitt和Stonebraker在2008年就看到了）。經過時間的實戰檢驗，以及使用過程中的經驗積累，越來越多的軟件開發人員也看到了這一點。

第3部分：回歸SQL

經歷了黎明前的黑暗，軟件社區看到了曙光，那就是回歸SQL。

首先是Hadoop（之后的Spark）之上的SQL接口，引導業界興起了NoSQL ,NoSQL“不僅僅是SQL”。

然后，NewSQL的興起：新的可擴展性數據庫，完全支持SQL。來自于麻省理工學院(MIT)和布朗大學(Brown)研究人員的H-Store （2008年發布）是第一個可擴展OLTP數據庫之一。Google在發布的第一份Spanner論文（2012年發布）（其作者包括最初的MapReduce作者）中揭示這是基于 SQL 的查詢語言，可以將一份數據復制到全球范圍的多個數據中心，并保證數據的一致性，從而開創了可地理復制的SQL界面的數據庫，接著是CockroachDB（2014）這樣的先驅者。

與此同時，PostgreSQL社區開始復蘇，增加了JSON數據類型（2012），以及PostgreSQL 10 的新特性：對分區和復制更好的本地支持，JSON的全文搜索支持等（今年晚些時候發布）。其他像CitusDB（2016）和其他的公司(今年發布的TimescaleDB)發現了新的方法從而針對特定數據工作負載的擴展PostgreSQL。

事實上，我們開發TimescaleDB的過程與業界的發展軌跡密切相關。早期的TimescaleDB內部版本使用了我們自己的類sql查詢語言“ioQL”。是的，我們正是被困難驅動著：構建我們自己的查詢語言才能更強大。但是，雖然看似簡單，但我們很快意識到，我們必須做更多的工作：例如，決定語法，構建各種連接器，培訓用戶等。我們還發現自己需要不斷地去查找合適的語法，去查詢那些已經可以用SQL進行查詢的內容。

有一天，我們意識到建立自己的查詢語言是沒有意義的。關鍵還是要擁抱SQL。這是我們做出的最好的決策之一。同時也開啟了一個全新的世界。今天，即使我們的數據庫才問世5個月，但我們的用戶完全可以使用我們的產品，并獲得各種各樣支持：可視化工具（Tableau），通用ORM連接器，各種工具和備份選項，大量的在線教程和語法說明等。

－－－

但是不要把我們的話放在心上，看看谷歌

Google已經十多年來一直處于數據工程和基礎設施的領先地位。我們應該密切關注他們正在做什么。

看看谷歌的第二大Spanner論文，僅在四個月前發布（Spanner：成為一個SQL系統，2017年5月），你會發現它支持我們的發現成果。

例如，Google開始在Bigtable之上開發，但是后來發現缺少SQL產生了一系列問題（在下面的所有引號中有強調）：

“雖然這些系統提供了數據庫系統的一些優勢，但它們缺乏應用程序開發人員常常依賴的許多傳統數據庫功能。一個關鍵的例子是強大的查詢語言，這意味著開發人員必須編寫復雜的代碼來處理和聚合應用程序中的數據。因此，我們決定將Spanner變成一個功能齊全的SQL系統，其查詢執行與Spanner的其他架構功能（如強一致性和全局復制）緊密集成。

在本文的后面，他們進一步了解從NoSQL轉換到SQL的理由：Spanner的原始API提供了為單個和交叉表的點查找和范圍掃描的NoSQL方法。雖然NoSQL方法提供了啟動Spanner的簡單路徑，并且在簡單的檢索方案中繼續有用， 但SQL在表達更復雜的數據訪問模式并將計算推送到數據方面提供了重要的附加價值。

本文還介紹了如何在Spanner上使用SQL并不會停止，哪怕某一個數據中心停止運轉,仍然可用。但實際上擴展到Google的其余部分，其中多個系統共享一個通用的SQL語言：

Spanner的SQL引擎與Google的其他幾個系統共享一個稱為“標準SQL”的常見SQL語言，包括內部系統，如F1和Dremel（以及其他）以及外部系統，如BigQuery 。

對于Google用戶，這會降低跨系統的工作障礙。對Spanner數據庫編寫SQL的開發人員或數據分析師可以將他們對語言的理解轉移到Dremel，而不用擔心語法，NULL處理等方面的微妙差異。

這就是這種方法的成功奧秘。當“潛在云客戶對SQL有濃厚興趣”時，Spanner已經成為Google主要系統的根基（包括AdWords和Google Play） 。

考慮到Google最先啟動了NoSQL的運動，這是非常顯著的，它今天正在回歸SQL。（引起一些人反思：“ Google 10年前挺進大數據市場就是個大忽悠嗎”？）

這對數據的未來意味著什么：SQL將變成窄腰

在計算機網絡中，有一個叫做“窄腰”的概念。

這個概念的出現解決了一個關鍵問題：在任何給定的網絡設備上，想象一個堆棧，底層硬件層和頂層軟件層。中間可能會存在各種網絡硬件;類似地，也存在各種軟件和應用程序。需要一種方法來確保無論硬件如何，軟件仍然可以連接到網絡; 無論軟件如何，網絡硬件都知道如何處理網絡請求。

在網絡中，窄腰的角色由互聯網協議(IP)扮演，它是???局域網設計的底層聯網協議和更高級別的應用程序和傳輸協議的公共接口。(這是一個很好的解釋。)而且（在一個廣泛的過度簡化）中，這個公共接口成為了計算機的通用語言，使網絡互連，設備進行通信，而這個“網絡網絡”可以發展成為今天豐富多樣的互聯網。

我們認為，這等同于SQL已成為數據分析的“窄腰。

我們生活在一個數據正在成為“世界上最寶貴資源”的時代（”

“經濟學人”，2017年5月）。我們看到了Cambrian 的專業數據庫（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。一切都遵循能量守恒定律。

 

來自：http://www.linuxidc.com/Linux/2017-10/147749.htm