PostgreSQL 和 MySQL 的可擴展性限制
我聽說 MySQL 或 PostgreSQL 等非分片關係數據庫的性能“突破”超過 10 TB。
我懷疑確實存在這樣的限制，因為人們不會想出 Netezza、Greenplum 或 Vertica 等，但是我想問一下這裡是否有人參考了任何研究論文或正式案例研究，這些限制被量化了。
您的問題沒有簡單的答案，但這裡有一些事情需要考慮。
首先，規模並不是唯一需要擔心的事情。你用你的數據做什麼。如果您有 500 個表 30 TB 的數據，並且您正在執行簡單的 OLTP，並且報告很少，我認為您不會遇到太多問題。PostgreSQL 上有 32TB 的數據庫。但是，與此同時，性能會有所下降，因為它必須在所有內容上命中磁碟。同樣，如果您有 50TB 的數據，但通常有大約 100GB 的命中集，那麼您可以建構一個具有足夠 RAM 的伺服器，以將數據庫的那一部分保留在記憶體中，這樣您就很成功了。
另一方面，如果您嘗試從 1TB 數據中獲取模式（最常見的值），那麼無論您使用什麼系統，無論有沒有分片，這都會很痛苦。（編輯：事實上，分片可能會使這個問題變得更糟。）
在 MySQL 和 PostgreSQL 上使用巨大的數據庫時會遇到的主要問題是它們都不支持查詢內並行性。換句話說，查詢是由單個執行緒作為單個塊執行的，它不能被分解成小塊並單獨執行。在對大量數據執行大型分析查詢時，這通常是一個問題。這就是 Postgres-XC 和 Green Plum 的用武之地，因為它們將儲存與執行分開，並且可以在協調器級別執行此操作。請注意，Postgres-XC 和 Green Plum 本質上在內部使用分片，但協調器在全域範圍內強制執行所有一致性。
使用查詢內並行性，您可以分解查詢，讓不同的處理器/磁碟 I/O 通道執行其中的一部分，並報告要組裝的結果集片段並傳遞回應用程序。同樣，這通常對分析而不是事務處理負載最有幫助。
第二件事是某些系統，如 Vertica 或 Greenplum 將資訊列儲存在一起。從 OLTP 的角度來看，這使得系統更難使用並降低了性能，但它極大地提高了大型分析工作負載的性能。所以這是一個特定於工作負載的權衡。
所以答案是，一旦您的大小超過 1-2 TB，您可能會發現自己面臨著系統和工作負載之間的許多權衡。同樣，這特定於數據庫、工作集的大小等。但是此時您確實必須使用雪花系統，即那些獨特且適合您的工作負載的系統。
這當然意味著這些限制通常是不可量化的。
編輯：我現在使用了一個 9TB 的數據庫，它在 PostgreSQL 中處理決策支持和事務處理工作負載的混合。最大的挑戰是，如果您的問題涉及大部分數據集，您將不得不等待一段時間才能得到答案。
但是，如果仔細注意基本原理（包括索引、autovacuum、它們如何在低級別上工作等）和足夠的計算資源，這些都是完全可以管理的（我估計在 Pg 的 30TB 範圍內可以很好地管理）。
編輯 2：一旦你達到100TB，雖然有效的方法取決於你的數據集。我現在正在研究一個不會擴展到這個範圍的產品，因為它首先會達到 PostgreSQL 中每表 32TB 的限制。