如果 NoSQL 代表“Not only SQL”，那麼 SQL 是 NoSQL 的子集嗎？
這個定義有點令人困惑——基本上我是在問 SQL 是否是 NoSQl 系列的一個子集：
我問這個是因為“不僅”意味著 NoSQL 更大，但仍將 SQL 作為其中的一部分。
另一方面，由於我們不能在 NoSQL 數據庫中執行典型的 sql 操作，例如連接，所以 SQL 不是 nosql 的一部分！
我想知道哪個是真的？
TL; 博士
數據庫系統之間的主要區別不是用於查詢數據庫的語言，而是系統的一致性模型。維恩圖應該是兩個相交的集合——SQL 不是 NoSQL 的正確子集，而是它自己的數據訪問語言，可能會或可能不會被其他技術補充。SQL 將是數據庫查詢語言的適當子集。
有 NoSQL、OldSQL 和 NewSQL。
NoSQL曾經意味著“不是 SQL”，但現在（更多）可能意味著“不僅僅是 SQL”——因為許多 NoSQL 系統的提供者正在（試圖）在其鍵值（KV）上附加/移植 SQL 介面)、文件或圖形儲存。
OldSQL 系統本質上是主要的 RDBMS 供應商的產品（Oracle、SQL Server、Sybase、PostgreSQL、MySQL…）。在本展示文稿(.pdf) 的第 13 頁上，Michael Stonebraker聲稱表明 OldSQL 僅花費 4% 的時間做“有用”的工作 - 也可在此處找到：
他的論點是應該在不同系統之間拆分 OLTP 工作和 OLAP 工作 - OLTP 應該通過不共享的分片架構來完成，例如他自己的系統VoltDB，而 OLAP 應該由列式儲存完成（另見這裡) 類型架構（例如Vertica，他也曾在其中扮演過角色）。值得注意的是，Stonebraker 不僅在商業領域非常成功，而且在學術界也非常成功，並且獲得了圖靈獎——電腦科學的“諾貝爾獎”！
NewSQL是（恕我直言）最有趣的系統，可以像從 OldSQL 的灰燼中重生的鳳凰一樣（形像地說）。他們的USP是他們是HTAP系統（混合交易和分析處理）。
這些分佈式系統可以同時支持 OLAP 和 OLTP 查詢，因為數據分佈在多個節點上——這些節點可以在同一個機架、數據中心或大陸上或在同一個機架、數據中心或大陸上和/或在雲提供商之間和之間全球分佈以增加彈性和冗餘 - 預計您在正常執行時間供應中添加的每個小數“9”的成本都會增加一個“0” 。
他們使用共識算法（通常是Raft或Paxos）來協調節點的數據，並且分片是透明的——即使對系統的 DBA 也是如此。此類系統的三個範例是CockroachDB、TiDB和YugaByte。
有趣的是，這些系統雖然取得了一定程度的成功，但還不是（還？）家喻戶曉的名字。“大男孩”正在反擊，將柱狀儲存和 KV 產品用螺栓/嫁接到他們自己的系統上。在這場辯論中特別感興趣的是，這些系統本身位於 KV 儲存的“頂部”（通常是 RocksDB - 儘管 CockroachDB 正在開發自己的 Go語言 Pebble）。PostgreSQL 還有文件 (JSONB) 和KV 儲存。
為了回答這個問題，系統之間真正的區別特徵不是用於查詢數據的介面（它可以而且確實範圍從直接 C 語言程式（命令式）到 SQL（聲明式）——及其風格/改編），而是事務一致性模型。
這些模型要麼是ACID（一致）vs. BASE（可用），關鍵是這些系統在 CAP 定理方面的適合位置。此外，KV 儲存可以支持部分或全部ACID 事務特性。
OldSQL 和 NewSQL 重視一致性高於一切（CAP 系統下的“CP”）——他們的論點是，例如，結果不一致的銀行系統是災難的根源（真的！）。
然而，NoSQL 愛好者會建議，並非所有系統都需要鑄鐵一致性。例如，使用 BASE 數據庫（CAP 術語中的“AP”）從亞馬遜訂購一本書 -可能（顯示的庫存水平不正確）會延遲幾天，甚至取消 - 但好處是查詢速度更快，操作更容易（沒有共識要維持）。
這就是區分數據庫系統的癥結所在——“CP”或“AP”！CP 將始終為您提供正確答案（大多數節點仍然可用）或不提供答案，而 AP 系統通常會響應（即使只有一個節點啟動）但您的答案可能沒有考慮其他節點的數據更新響應（即它們之間的網路連結斷開……）。
我希望這是一個令人滿意的“第一次通過”答案——這是一個很大的話題，對於 db 書呆子來說，絕對令人著迷。我會敦促您閱讀它（Wiki 是一個好的開始，但不能替代主要來源）。特別是，我建議您詳細了解 CockroachDB 和 TiDB 的底層架構，看看它們如何在保持一致性的同時從一個節點分片和移動數據。
這里和這裡有各種 NoSQL 系統的綜合列表（最好的恕我直言）。這裡還有一個人氣評級網站（但要避免比較——他們只是重複系統網站上的宣傳——通常已經過時了）。
最後一句話，有“混合模型”（或多模型）數據庫（ArangoDB和OrientDB - 都有 F/LOSS 和 Enterprise 版本 - OrientDB 現在是 SAP 的一部分），但它們不是家喻戶曉的名字是有原因的。ArangoDB 不支持 ANSI SQL，而是支持它自己的風格 - AQL ， OrientDB也不支持ISO SQL。
我使用過的最好的多模型數據庫是 PostgreSQL，它具有如上所述的 KV 和文件儲存。您可以使用 SQL 來查詢這些並與“普通”表連接。正在向其中添加OpenCypher（一種開放的圖形查詢語言標準）的工作正在進行中（請參見此處和此處）。
最後，最後一句話：PostgreSQL 也有一個列儲存擴展和一個時間序列擴展——這兩者都是數據庫系統的非常重要的（子）類。兩個擴展都只是擴展而不是分叉——你可以使用帶有這些擴展的“普通”SQL（即所有 PostgreSQL 標準兼容的 SQL）。
因此，我們可以看到，雖然 NoSQL 在某些情況下，但不是全部（例如，許多系統設計人員樂於保持簡單的 KV 儲存）添加 SQL 功能，但 SQL 正在反擊，採用和適應新的和/或更複雜的數據儲存和檢索要求——其中一些我什至沒有涉及（GIS 系統……）。所以說 NoSQL 完全包含 SQL 將是一幅不完整的圖景……
正如對問題本身的評論所指出的那樣，SQL 標準現在處理非關係範式，這只會在未來增加！其他答案也解決了 - 值得一讀（1和2）！
