作者 | Tina、核子可樂

哪怕大牛也得承認，有時候單憑自己的成果不足以解決問題。如今，SQL 之父認爲 NoSQL 才是出路。

1974 年 5 月，Donald Chamberlin 與 IBM 同事 Raymond Boyce 發表了一篇關于 SEQUEL 的論文，這是一種用于管理和排序數據的結構化查詢語言。由于另一家公司擁有“SEQUEL”一詞的版權，該語言更名爲“結構化查詢語言”（SQL）。隨後在 70 年代後期，隨著像 Oracle 這樣的數據庫公司推出新式關系型數據庫産品，SQL 也被這些公司所采用。正如人們常說的那樣，剩下的就是曆史了。

SQL 現已有 50 歲了。2000 年左右入行的人，可能知道它的高光時刻，那時三層後端應用架構正盛行。當時的技術架構主要包括網絡服務器（通常是 Apache）、應用服務器和數據庫。由于掌握這些知識和經驗的人較少，因此開發人員需要具備多方面的技能，包括 HTML、JavaScript（主要用于處理表單提交）、一種應用服務器層業務邏輯處理語言（當時通常是 Java），以及數據庫操作語言 SQL。不同的人有不同的偏好和專長，但要成爲一名高效的開發人員，就必須具備所有這些技術的的基本知識。

當時，整個開發工程師行業只關注“開發”（dev），“運維”（ops）則被忽視。 運維工作要麽由開發人員兼顧（在小型組織中），要麽由系統管理員負責（在大型組織中）。後來，小型組織逐漸發展出 DevOps 思維方式，而大型組織則開始采用 SRE 模式。當時的數據科學領域也尚未興起。

數據庫管理員（DBA）的主要職責是確保數據備份和維護數據庫性能。他們會“懲罰”那些用寫得糟糕的查詢或定義錯誤的索引汙染數據庫的人。因此，他們有時也會兼任開發人員的 SQL 導師。

由于幾乎每個人都是開發人員，並且開發人員需要具備多方面的技能，因此在面試中，工程師經常會被問到 SQL 問題。 面試通常會從簡單的 join 開始，然後對于更高級的求職者會考察他們在索引和性能方面的知識。

但如今，你會發現一些非常聰明、知識淵博的年輕同事可能從未學習過 SQL。他們可能會通過將這些查詢與他之前遇到過的其他基于 JSON 的 *QL（例如 PromQL、GraphQL 等）進行比較來理解它們。

Martin Fowler 指出，“NoSQL”實際上是“No DBA”。

因爲隨著運維 (ops) 的興起，IT 行業的專業化分工也日益細化。雖然 DBA 已經存在了很長時間，但隨著前端工程師、測試人員、數據科學家、DevOps 工程師、站點可靠性工程師 (SRE)、安全工程師等越來越多專精崗位的出現，“開發人員” (dev) 的角色逐漸被細分。因此，SQL 是否是一種偏“小衆”的技能，逐漸成爲了一個爭議點。

Don Chamberlin 認爲，SQL 早前能夠興起，有幾個主要原因。首先關系模型既簡單又強大、靈活而不失優雅，也因此讓種種功能成爲可能。其次，Ingress 項目等早期研究的公開發表也有很大幫助。第三，ANSI 標准在提供定義良好的語言規範的同時，也設定了正確的語言發展方式，能夠切實滿足新的需求。這使得 SQL 在數十年間始終跟得上新興需求，從而保持住了良好活力。第四點是有大量高質量的開源 SQL 一直在免費供應。這幾條，足夠維持 SQL 的活力。

SQL 發展得比想象中更成功，但 Don Chamberlin 也表示他們必須得承認，SQL 語言只在一定程度上實現了他們當初定下的目標。

“畢竟 Ray 和我當初都把 SQL 看作一種低門檻的技術方案，應該面向那些非程序員的‘臨時用戶’群體。”

現在，“我們預想中的臨時用戶仍然存在，而他們卻並不使用 SQL。他們更傾向于使用 Google 搜索，而且最近一段時間越來越多地使用像 ChatGPT 這樣的 AI 系統。”

Chamberlin 認爲半個世紀的數據庫革命，其深層驅力源自經濟。同時硬件正以指數速度變得更強大、更便宜。硬件層面的進步讓三件事成爲了可能。首先就是幹淨、優雅的數據模型，比如說 Codd 提出的關系模型。第二就是出現了高級的非過程化語言，也就是 SQL。第三就是經過優化的編譯器能夠將這一切整合起來，最終實現商業意義上的可行性。數據模型、查詢語言和優化編譯器這三者的相互協同，構成了鼎立般的穩固效應。

但如今，SQL 之父現已明確表示支持 NoSQL 數據庫運動，爲這場強調擺脫 RDBMS 表限制的技術趨勢增添了新的光彩。

Chamberlin 在接受采訪時解釋稱，NoSQL 數據庫及其查詢語言有助于執行關系系統在設計之初從未考慮過的各種任務。

他指出，“世界絕不會一成不變，特別是在計算機科學領域。這是一個快速叠代、不斷發展的行業。新的需求不斷出現，技術當然也需要相應改變方可滿足這些需求。我認爲現狀也的確如此。NoSQL 運動是由新型應用程序（特別是 Web 應用程序）所推動的，它們需要強大的可擴展性。與之對應，關系數據庫的誕生時期較早，當時可擴展性與性能相對不那麽重要。因此爲了實現現代應用程序所需要的可擴展性和性能，諸多系統正在放寬對關系數據模型的種種限制。”

NoSQL 具有多種形式，每種形式旨在解決不同的挑戰。目前流行的文檔數據庫基于開放 JSON 標准，主要嘗試繞過 RDBMS 的架構約束。這類方案包括 MongoDB、Couchbase 以及亞馬遜的 DynamoDB。而鍵值存儲方案可以提供更好的靈活性和速度表現，具體包括 Aerospike、Memcached 和 Redis，它們常被作爲互聯網應用緩存，也是目前亞馬遜雲科技上最流行的數據庫。圖數據庫強調將關系網絡表示爲邊和節點，主要方案包括 Neo4j 和 TigerGraph 等系統。

數據庫專家之間一直存在著激烈的爭論，有些人認爲 NoSQL 方法確有必要，但也有一些人認爲可以把 NoSQL 系統的屬性轉化爲關系系統中的功能。例如，大多數流行的關系系統現在都支持 JSON 文檔，而 Oracle 和 PostgreSQL 則提供圖式查詢。

但在 Chamberlin 看來，NoSQL 的存在對于支持現代應用程序來說確有必要。

我都已經退休了，但還是會經常聽到 NoSQL 這個詞。我認爲 NoSQL 運動的靈感，來自那些需要大規模可擴展數據庫的 Web 應用程序。這類用例最需要的就是強大的可擴展性，同時願意放松某些在傳統關系數據庫上比較嚴格的限制。

咱們舉例說話。第一，關系數據庫往往有著嚴格的模式，要求准確描述表的樣式和所處系統。NoSQL 系統有時候會放寬這方面要求，比如可能提供壓力模式，但也可能根本沒有模式，所以會更加靈活。

第二，關系數據庫只適用于關系數據模型，也就是由大量同質化表建立的數據結構。在每個表中，所有行看起來都大差不差。但 NoSQL 系統有時會放松這方面要求，允許使用不同的數據模型。其中有些會非常簡單，比如鍵-值存儲。NoSQL 可能還支持嵌套表，或者基于 XML 和 JSON 之類的特定文檔格式。

至于第三點區別，就是關系數據庫系統往往包含一些保證機制，比如通過 ACID 屬性保持數據的一致狀態。而 NoSQL 系統有時候會稍微放寬這種限制。

它們往往會跨多個節點複制數據，而且可能接受所謂“最終一致性”，也就是各節點間的數據要過一段時間才能實現同步。所以說 NoSQL 確實是個令人興奮的新方向，我認爲也可以用它來概括數據庫研究領域最具前途的整體思路。

傳統的關系系統需要爲事務保留資産記錄，從而提供即時一致性。對于一致性問題，他在采訪中表示，“爲了實現更高的性能，現在我們經常會把數據分布在機器集群上。也就是說能實現最終一致性就可以了，因此我們可以耐心等待，讓所有機器在一段時間之後再達到一致。對于高度擴展的環境，這種用時間換性能的作法很有必要。”

Chamberlin 是一位長期效力于 IBM 的員工，目前已經處于半退休狀態，但他仍抽出時間擔任 NoSQL 廠商 Couchbase 的技術顧問。

在這個職位上，他成爲一種新型查詢語言的倡導者，這就是 SQL++。該語言旨在克服應用程序語言及數據庫內數據結構之間的“摩擦阻力”。

SQL++是加州大學聖叠戈分校教授 Yannis Papakonstantinou 提出的解決方案，旨在消除基于對象的 JavaScript（Web 開發領域的核心語言）與 SQL 中嵌入的預設關系方法間的“摩擦阻力”。

與 C++一樣，SQL++在設計上屬于早期 SQL 語言的兼容擴展，但號稱能夠更好地處理 JavaScript 所固有的 JSON 文件格式。

Couchabse 與亞馬遜雲科技均已采用這種語言，只是雲巨頭將其稱爲 PartiQL。

Chamberlin 于 2019 年針對 Couchbase 發表的論文介紹了 SQL++與 SQL:2016，關注了這兩種語言編寫的部分示例查詢並做出比較。

但他同時強調，SQL++只是 SQL 的有益補充、而非替代品。

“我認爲 SQL 並不會消失。世界上很大一部分業務數據都是用 SQL 編碼的，而且數據具有很強的粘性。只要掌握了數據庫，就可以把數據駐留在其中。此外，關系系統在其自身功能定位之內表現極佳，MySQL、PostgreSQL 和 SQLite 中都是質量極高的開源關系數據庫實現。”

“這些 SQL 實現非常強大、功能完備且可靠性出色，也都有著龐大的用戶社區。如果您是一家想在網絡上銷售鞋子或者其他商品的初創公司，又需要一套數據庫，那麽這些 SQL 實現將幫您免費滿足這些需求。我認爲關系數據庫和 SQL 語言仍將在久遠的未來繼續陪伴在大家身邊。”

原文鏈接：