為什麼橫向擴展關係數據庫比像 MongoDB 這樣的 NoSQL 數據庫更難？
由於遵守 ACID 事務，導致難以水平擴展/分發 RDBMS 的主要原因是什麼？是多個表如此互連還是其他原因？
我的印像是它主要是 ACID 要求，因為集群中的不同節點在任何給定時間可能具有不同的值。但是，哎呀，我對 ACID 的工作原理很模糊。
相反，為什麼有些 NoSQL 數據庫更容易分發？我對分佈式數據庫知之甚少，無法理解為什麼一個數據庫可以輕鬆分發而另一個數據庫不能。
任何人都可以解釋一下嗎？
為什麼水平擴展關係數據庫比 NoSQL 數據庫更難
恐怕你的假設有點缺陷。
水平（或沿任何其他軸）縮放關係（或任何其他）DBMS 並不難。困難的是在這樣做的同時保持 DBMS 提供的所有承諾。
關係 DBMS 主要承諾一致性，當它分佈在多個實例中時，它會讓您等到所有（或至少大多數）實例就事務的最終狀態達成一致。因此，在所有實例就事務狀態達成一致所需的時間內，您購買了數據庫的一致狀態。
所謂的1 “NoSQL”DBMS 通常承諾非常短的本地響應時間，其代價是在任何時間點（包括從不，在某些情況下）在其他實例中不保證相同的事務狀態。
一些應用程序（想到航空公司座位預訂）更重視一致性，而其他應用程序可能更喜歡更快的響應時間，即使結果不一定正確（就像一些社交網路那樣）。
從根本上說，您的問題簡化為“為什麼
$$ … $$很難$$ … $$比例尺$$ … $$數據庫”，答案是“因為”。任何事情都很難擴展，包括撫養孩子、送披薩、送人上太空、在後院養雞……
1 - 無論如何，沒有什麼可以阻止它使用 SQL 語法。
不，我不認為橫向擴展傳統 RDBMS 問題是由於 ACID。
問題是歷史。在建構傳統的 RDBMS 系統時，它們是小型電腦系統，具有有限容量的磁碟 - 因此它們可以有效地使用磁碟。他們還將所有數據放在一台機器上的一個地方，以進行高效查詢。那個時候網際網路規模還不存在。Michael Stonebaker 試圖解決的問題似乎是有效地查詢、檢索和連接數十億行的問題。數據庫技術。這就是我們獲得如此高效的 btree、索引和高效查詢技術的方式。
我從頭開始開發了一個玩具 SQL 數據庫（它非常小並且是用 Python 編寫的），並且我實現了分佈式 SQL 連接。數據可以大於任何副本的儲存空間，並且查詢每個節點以檢索其連接數據的子集。這以延遲為代價提供了一定程度的可擴展性，因為必須查詢每個分片以檢索數據的完整子集。理論上，一個連接的數據子集應該小於所有伺服器上的總數據量，因此不存在流量超過網路的問題。
CockroachDB、Tidb、RethinkDB 都證明您可以創建跨多個節點的可擴展數據庫。問題在於這樣做的工程努力。
PolarDB 並證明您可以使用分佈式 RDBMS 數據庫進行交易。我還實現了多版本並發控制。
現在我們有 Citusdata，它表明 postgres 可以橫向擴展。