在過去的幾年中，軟件開發社區對流行的開源關系數據庫的熱愛已經達到了一個高潮。 這個Hacker News主題涵蓋了一個標題為" PostgreSQL是世界上最好的數據庫"的文章，它的縫隙處充斥著討人喜歡的可愛的無情的sy夫，這是這種現象的一個很好的例子。

雖然這些贊美肯定是當之無愧的，但缺乏有意義的異議使我有些煩惱。 沒有軟件是完美的，那么PostgreSQL的缺陷到底是什么?

自2003年以來，我一直在生產中使用PostgreSQL，其部署范圍從小型(千兆字節)到中等(到PB級)不等。 我的觀點主要來自構建和運行至少要持續可用的系統。 不用說，多年來，由于一些痛苦的生產問題，我已經獲得了PostgreSQL特殊特質的第一手經驗。

#1：災難性的XID解決方案

在這里閱讀更多。 可以說，這可以咬人。 有很多關于此問題導致多天停機的故事。 繼續進行下去，用Google搜索，您會發現許多可憐的人寫著他們踏上這枚地雷的時間。 幾乎所有沒有高級專家配備的簡單PostgreSQL安裝都將最終被使用。

在將來的某個時候，XID可能會過渡為使用64位整數，但是直到那時，我們仍然堅持使用它。 我想至少我們可以慶幸的是，與某些飛機軟件不同，有一個過程可以阻止它順理成章地發生。

#2：故障轉移可能會丟失數據

如果活動主服務器突然出現故障，那么運行中的流復制設置幾乎肯定會丟失已提交的數據。 有人可能會說："異步復制的代價就是這樣。"但不一定非要這樣。 PostgreSQL支持具有法定提交的同步復制，以實現容錯的持久性，但是它具有更嚴格的性能范圍，使應用程序復雜化。

等待不會占用系統資源，但交易鎖將繼續保留，直到確認轉移為止。 結果，由于響應時間增加和爭用增加，謹慎使用同步復制將降低數據庫應用程序的性能。

這種固定的仲裁復制在某些情況下很有用，但我不建議在通用用例中推薦它。 它類似于Kafka的ISR復制，具有acks = all和一個法定的min_isr，但是具有運行任意查詢的事務性關系數據庫的所有細微差別。 我目前尚不了解成功應用仲裁提交以非平凡的規模進行高可用性，高耐久性的復制。 如果有，請聯系!

就關系數據庫而言，Galera Cluster的組復制也不完美，但更接近理想狀態。 他們甚至鼓勵按地理分布的復制，這對于使用仲裁提交的PostgreSQL復制設置很可能是災難性的。

#3：低效率的復制會傳播腐敗

到目前為止，流復制是生產部署中最常用的復制機制。 它是物理復制的一種形式，這意味著它可以復制磁盤二進制數據本身中的更改。

每次需要通過寫操作修改磁盤上的數據庫頁面(8KB)時，即使只是一個字節，也將通過請求的更改進行編輯的整個頁面的副本寫入預寫日志(WAL) 。 物理流復制利用現有的WAL基礎結構作為流到副本的更改日志。

更新：有些人指出PostgreSQL僅需要在每個WAL檢查點執行一次全頁寫操作。 的確如此，但是在大多數實際系統中，大多數寫入將遵循冪律分布，最終出現在檢查點之間的唯一頁面上。 但是，更重要的是：在預測系統行為時，正確的方法是假設情況更為昂貴，尤其是如果它取決于應用程序的難以預測和高度動態的行為時。

例如，使用物理復制，大型索引構建會創建大量WAL條目，從而很容易成為復制流的瓶頸。 頁面粒度的讀取-修改-復制過程會導致主機上由硬件引起的數據損壞，更容易傳播到副本，這是我個人在生產中親眼目睹的。

這與邏輯復制相反，后者僅復制邏輯數據更改。 至少從理論上講，大型索引構建只會導致在網絡上復制單個命令。 盡管PostgreSQL在很長一段時間內就一直支持邏輯復制，但是大多數部署都使用物理流復制，因為它更健壯，受更廣泛的支持并且更易于使用。

#4：MVCC垃圾頻發

與大多數主流數據庫一樣，PostgreSQL使用多版本并發控制(MVCC)來實現并發事務。 但是，其特定的實現通常會給垃圾行版本及其清理(VACUUM)帶來操作上的麻煩。 一般來說，UPDATE操作會為任何已修改的行創建新副本(或"行版本")，并將舊版本保留在磁盤上，直到可以清除它們為止。

多年來，這種情況一直在穩步改善，但它是一個復雜的系統，對于任何初次接觸該問題的人來說都是一個黑匣子。 例如，了解純堆元組(HOT)及其何時啟動對于繁重的就地更新工作負載(如連續保持一致的計數器列)來說可能是成敗的。 默認的自動真空設置在大多數情況下都有效，但是，當無效時，天哪。

相反，MySQL和Oracle使用重做和撤消日志。 他們不需要類似的后臺垃圾收集過程。 他們做出的權衡主要是事務提交和回滾操作的額外延遲。

也許是在遙遠的將來的某個時候，哲普拯救了我們所有人。

#5：每次連接處理=規模痛苦

PostgreSQL為每個連接派生一個進程，因為其他大多數數據庫都使用更有效的連接并發模型。 由于存在一個相對較低的閾值，在該閾值上添加更多的連接會降低性能(大約2個內核)，最終會導致性能下降，而這又是一個較高的閾值(難以估計，高度依賴于工作負載)，這將導致難以調整的問題。

使用連接池的標準方法當然可以解決問題，但是會帶來額外的架構復雜性。 在一個特別大的部署中，我最終不得不在第二個pgbouncer層中分層。 一層在應用程序服務器上運行，另一層在數據庫服務器上運行。 它總共聚合了大約一百萬個客戶端進程的連接。 調整時需要40%的深色藝術品，40%的蠻力和10%的純正運氣。

進程可伸縮性在每個主要版本中都在逐步提高，但與MySQL中使用的"每連接線程數"相比，最終該體系結構的性能受到了一定的限制。

有關更多技術深度，請參見https://brandur.org/postgres-connections。

#6：主鍵索引是"太空豬"

PostgreSQL中的表有一個主鍵索引和稱為堆的單獨行存儲。 其他數據庫將它們集成在一起或支持"索引組織表"。 在這種安排下，主鍵查找過程直接導致行數據，而無需輔助獲取完整行以及必要的額外CPU和I / O利用率。

PostgreSQL中的CLUSTER命令會根據索引重新組織表以提高性能，但實際上不適用于大多數實際的OLTP情況。 它以互斥鎖重寫整個表，從而阻止任何讀取或寫入。 PostgreSQL不維護新數據的群集布局，因此該操作必須定期運行。 因此，僅當您可以使數據庫長時間長時間脫機時，它才真正有用。

但更關鍵的是，索引組織的表可以節省空間，因為索引不需要單獨的行數據副本。 對于具有主要由主鍵覆蓋的小行的表(例如聯接表)，這可以輕松地將表的存儲空間減少一半。

考慮下表，該表存儲任意對象的社交"贊"：

PostgreSQL將維護與基表存儲區分開的主鍵索引。 該索引將為每行包含object_type，object_id和user_id列的完整副本。 每行28個字節中的20個(〜70%)將被復制。 如果PostgreSQL支持索引組織的表，則不會消耗所有這些額外的空間。

#7：主要版本升級可能需要停機

一些主要版本升級需要數小時的停機時間才能轉換大型數據庫的數據。 使用典型的流復制機制，不可能通過升級副本并進行故障轉移來優雅地做到這一點。 磁盤二進制格式在主要版本之間不兼容，因此，主副本之間的有線協議實際上也是不兼容的。

希望邏輯復制最終將完全取代流復制，這將啟用在線滾動升級策略。 當我進行大規模的水平擴展部署時，我們在自定義基礎架構上進行了重大的工程投資，以使用額外的基于觸發器的復制系統(也用于分片遷移)在不停機的情況下進行這些升級。

#8：有點繁瑣的復制設置

公平地說，MySQL的即用型復制要麻煩得多，但是與MonNoDB和Redis等某些NoSQL存儲或MySQL Group Replication和Galera Cluster等面向集群的復制系統相比，其易用性 和避免邊緣現象的角度來看，在PostgreSQL中設置復制仍有很多不足之處。 從理論上講，邏輯復制為第三方解決方案提供了更大的靈活性，以彌補這些空白，但到目前為止，使用流復制來替代它存在一些很大的警告。

#9：荒謬的無計劃提示教條

使用計劃者提示，查詢可以指示查詢計劃者使用自己不會使用的策略。 PostgreSQL開發團隊多年來一直拒絕支持查詢計劃程序提示，這似乎是足夠聰明的編譯器參數的一種形式。

我確實了解他們的理由，主要是為了防止用戶使用查詢提示來攻擊問題，而應該通過編寫適當的查詢來解決這些提示。 但是，當您發現生產數據庫在突然而意外的查詢計劃變更下突然陷入全面崩潰時，這種哲學似乎是殘酷的家長式作風。

在許多情況下，給計劃者的提示可以在幾分鐘內減輕問題，使工程團隊可以花數小時或數天的時間對查詢進行適當的修復。 盡管有一些間接的解決方法涉及禁用某些查詢計劃器策略，但它們存在風險，因此絕對不應在任何時間壓力下使用。

那個象牙塔肯定一定不錯。

#10：無塊壓縮

InnoDB在MySQL中的頁面壓縮通常可以將存儲空間減少一半，并且從性能的角度來看幾乎是"免費的"。 PostgreSQL將自動壓縮較大的值，但這對于將數據存儲在關系數據庫中的最常用的方式沒有用。 對于大多數RDBMS用例，一行通常為幾百個字節或更少，這意味著壓縮僅在跨多行或成塊應用時才真正有效。

對于PostgreSQL核心的數據結構來說，塊壓縮確實很難實現，但是盡管有一些缺點，但MySQL InnoDB存儲引擎采用的"打孔"策略在實踐中似乎效果很好。

2020年4月7日更新：" MySQL在Facebook"一舉成名的Mark Callaghan在此質疑我的說法，即打孔壓縮"在實踐中效果很好"。 事實證明，正如我之前認為的那樣，世界上最大的MySQL安裝從未使用過打孔壓縮。 但是，他們確實成功地使用了較早版本的InnoDB壓縮的稍作修改，但是在幾年前遷移到MyRocks之前，它們取得了成功。

雖然打孔壓縮似乎確實對某些人有用，但是有些注意事項使打孔壓縮不像本壘打那樣。 如果您運行的是Percona的MySQL版本，那么MyRocks是更好的選擇。 如果不是這樣，那么對于閃存中的大量讀取工作負載而言，經典的InnoDB表壓縮似乎是一個更安全的選擇。 馬克沒有指出重大生產問題的任何具體實例，但指出他"懷疑文件系統是為每頁打孔而設計的，我會擔心隱晦的故障。"

在PostgreSQL世界中唯一被廣泛使用的通用塊壓縮設置利用了ZFS，它似乎對人們來說非常有效。 ZFS如今已成為Linux上的生產級現實，但無疑帶來了一些管理開銷，而對于XFS或ext4等更"現成的"文件系統而言，ZFS卻不存在。

說了所有…

您可能應該仍然使用PostgreSQL，而不是使用其他任何方式來存儲理想情況下要保存的數據。 通常，我建議從PostgreSQL開始，然后嘗試弄清楚為什么它不適用于您的用例。

PostgreSQL非常成熟，設計精良，功能豐富，通常沒有鋒利的邊緣，并且在絕大多數用例中都表現出色。 它也不受主要公司贊助商的限制，包括出色的文檔資料，并擁有一個專業的，包容的社區。

好消息是，可以通過使用托管數據庫服務(例如Heroku PostgreSQL，Compose PostgreSQL，用于PostgreSQL的Amazon RDS或用于PostgreSQL的Google Cloud SQL)來減輕或消除由本文中提到的許多問題引起的痛苦。 如果您可以使用其中一項服務，為了愛所有神圣的東西，請這樣做!

我很自豪地說，我已經在PostgreSQL的基礎上構建了將近20年的軟件，盡管存在缺陷，但我仍然是堅定的擁護者。 鑒于我多年來令人難以置信的開發團隊所見證的進步，我可以說，大多數(如果不是全部)這些問題將在適當的時候得到解決。