在過去的幾年中，軟件開發(fā)社區(qū)對(duì)流行的開源關(guān)系數(shù)據(jù)庫(kù)的熱愛已經(jīng)達(dá)到了一個(gè)高潮。 這個(gè)Hacker News主題涵蓋了一個(gè)標(biāo)題為" PostgreSQL是世界上最好的數(shù)據(jù)庫(kù)"的文章，它的縫隙處充斥著討人喜歡的可愛的無情的sy夫，這是這種現(xiàn)象的一個(gè)很好的例子。

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

自2003年以來，我一直在生產(chǎn)中使用PostgreSQL，其部署范圍從小型(千兆字節(jié))到中等(到PB級(jí))不等。 我的觀點(diǎn)主要來自構(gòu)建和運(yùn)行至少要持續(xù)可用的系統(tǒng)。 不用說，多年來，由于一些痛苦的生產(chǎn)問題，我已經(jīng)獲得了PostgreSQL特殊特質(zhì)的第一手經(jīng)驗(yàn)。

#1：災(zāi)難性的XID解決方案

在這里閱讀更多。 可以說，這可以咬人。 有很多關(guān)于此問題導(dǎo)致多天停機(jī)的故事。 繼續(xù)進(jìn)行下去，用Google搜索，您會(huì)發(fā)現(xiàn)許多可憐的人寫著他們踏上這枚地雷的時(shí)間。 幾乎所有沒有高級(jí)專家配備的簡(jiǎn)單PostgreSQL安裝都將最終被使用。

在將來的某個(gè)時(shí)候，XID可能會(huì)過渡為使用64位整數(shù)，但是直到那時(shí)，我們?nèi)匀粓?jiān)持使用它。 我想至少我們可以慶幸的是，與某些飛機(jī)軟件不同，有一個(gè)過程可以阻止它順理成章地發(fā)生。

#2：故障轉(zhuǎn)移可能會(huì)丟失數(shù)據(jù)

如果活動(dòng)主服務(wù)器突然出現(xiàn)故障，那么運(yùn)行中的流復(fù)制設(shè)置幾乎肯定會(huì)丟失已提交的數(shù)據(jù)。 有人可能會(huì)說："異步復(fù)制的代價(jià)就是這樣。"但不一定非要這樣。 PostgreSQL支持具有法定提交的同步復(fù)制，以實(shí)現(xiàn)容錯(cuò)的持久性，但是它具有更嚴(yán)格的性能范圍，使應(yīng)用程序復(fù)雜化。

等待不會(huì)占用系統(tǒng)資源，但交易鎖將繼續(xù)保留，直到確認(rèn)轉(zhuǎn)移為止。 結(jié)果，由于響應(yīng)時(shí)間增加和爭(zhēng)用增加，謹(jǐn)慎使用同步復(fù)制將降低數(shù)據(jù)庫(kù)應(yīng)用程序的性能。

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

就關(guān)系數(shù)據(jù)庫(kù)而言，Galera Cluster的組復(fù)制也不完美，但更接近理想狀態(tài)。 他們甚至鼓勵(lì)按地理分布的復(fù)制，這對(duì)于使用仲裁提交的PostgreSQL復(fù)制設(shè)置很可能是災(zāi)難性的。

#3：低效率的復(fù)制會(huì)傳播腐敗

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

每次需要通過寫操作修改磁盤上的數(shù)據(jù)庫(kù)頁面(8KB)時(shí)，即使只是一個(gè)字節(jié)，也將通過請(qǐng)求的更改進(jìn)行編輯的整個(gè)頁面的副本寫入預(yù)寫日志(WAL) 。 物理流復(fù)制利用現(xiàn)有的WAL基礎(chǔ)結(jié)構(gòu)作為流到副本的更改日志。

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

例如，使用物理復(fù)制，大型索引構(gòu)建會(huì)創(chuàng)建大量WAL條目，從而很容易成為復(fù)制流的瓶頸。 頁面粒度的讀取-修改-復(fù)制過程會(huì)導(dǎo)致主機(jī)上由硬件引起的數(shù)據(jù)損壞，更容易傳播到副本，這是我個(gè)人在生產(chǎn)中親眼目睹的。

這與邏輯復(fù)制相反，后者僅復(fù)制邏輯數(shù)據(jù)更改。 至少?gòu)睦碚撋现v，大型索引構(gòu)建只會(huì)導(dǎo)致在網(wǎng)絡(luò)上復(fù)制單個(gè)命令。 盡管PostgreSQL在很長(zhǎng)一段時(shí)間內(nèi)就一直支持邏輯復(fù)制，但是大多數(shù)部署都使用物理流復(fù)制，因?yàn)樗眩芨鼜V泛的支持并且更易于使用。

#4：MVCC垃圾頻發(fā)

與大多數(shù)主流數(shù)據(jù)庫(kù)一樣，PostgreSQL使用多版本并發(fā)控制(MVCC)來實(shí)現(xiàn)并發(fā)事務(wù)。 但是，其特定的實(shí)現(xiàn)通常會(huì)給垃圾行版本及其清理(VACUUM)帶來操作上的麻煩。 一般來說，UPDATE操作會(huì)為任何已修改的行創(chuàng)建新副本(或"行版本")，并將舊版本保留在磁盤上，直到可以清除它們?yōu)橹埂?/p>

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

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

也許是在遙遠(yuǎn)的將來的某個(gè)時(shí)候，哲普拯救了我們所有人。

#5：每次連接處理=規(guī)模痛苦

PostgreSQL為每個(gè)連接派生一個(gè)進(jìn)程，因?yàn)槠渌蠖鄶?shù)數(shù)據(jù)庫(kù)都使用更有效的連接并發(fā)模型。 由于存在一個(gè)相對(duì)較低的閾值，在該閾值上添加更多的連接會(huì)降低性能(大約2個(gè)內(nèi)核)，最終會(huì)導(dǎo)致性能下降，而這又是一個(gè)較高的閾值(難以估計(jì)，高度依賴于工作負(fù)載)，這將導(dǎo)致難以調(diào)整的問題。

使用連接池的標(biāo)準(zhǔn)方法當(dāng)然可以解決問題，但是會(huì)帶來額外的架構(gòu)復(fù)雜性。 在一個(gè)特別大的部署中，我最終不得不在第二個(gè)pgbouncer層中分層。 一層在應(yīng)用程序服務(wù)器上運(yùn)行，另一層在數(shù)據(jù)庫(kù)服務(wù)器上運(yùn)行。 它總共聚合了大約一百萬個(gè)客戶端進(jìn)程的連接。 調(diào)整時(shí)需要40%的深色藝術(shù)品，40%的蠻力和10%的純正運(yùn)氣。

進(jìn)程可伸縮性在每個(gè)主要版本中都在逐步提高，但與MySQL中使用的"每連接線程數(shù)"相比，最終該體系結(jié)構(gòu)的性能受到了一定的限制。

有關(guān)更多技術(shù)深度，請(qǐng)參見https://brandur.org/postgres-connections。

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

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

PostgreSQL中的CLUSTER命令會(huì)根據(jù)索引重新組織表以提高性能，但實(shí)際上不適用于大多數(shù)實(shí)際的OLTP情況。 它以互斥鎖重寫整個(gè)表，從而阻止任何讀取或?qū)懭搿?PostgreSQL不維護(hù)新數(shù)據(jù)的群集布局，因此該操作必須定期運(yùn)行。 因此，僅當(dāng)您可以使數(shù)據(jù)庫(kù)長(zhǎng)時(shí)間長(zhǎng)時(shí)間脫機(jī)時(shí)，它才真正有用。

但更關(guān)鍵的是，索引組織的表可以節(jié)省空間，因?yàn)樗饕恍枰獑为?dú)的行數(shù)據(jù)副本。 對(duì)于具有主要由主鍵覆蓋的小行的表(例如聯(lián)接表)，這可以輕松地將表的存儲(chǔ)空間減少一半。

考慮下表，該表存儲(chǔ)任意對(duì)象的社交"贊"：

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

#7：主要版本升級(jí)可能需要停機(jī)

一些主要版本升級(jí)需要數(shù)小時(shí)的停機(jī)時(shí)間才能轉(zhuǎn)換大型數(shù)據(jù)庫(kù)的數(shù)據(jù)。 使用典型的流復(fù)制機(jī)制，不可能通過升級(jí)副本并進(jìn)行故障轉(zhuǎn)移來優(yōu)雅地做到這一點(diǎn)。 磁盤二進(jìn)制格式在主要版本之間不兼容，因此，主副本之間的有線協(xié)議實(shí)際上也是不兼容的。

希望邏輯復(fù)制最終將完全取代流復(fù)制，這將啟用在線滾動(dòng)升級(jí)策略。 當(dāng)我進(jìn)行大規(guī)模的水平擴(kuò)展部署時(shí)，我們?cè)谧远x基礎(chǔ)架構(gòu)上進(jìn)行了重大的工程投資，以使用額外的基于觸發(fā)器的復(fù)制系統(tǒng)(也用于分片遷移)在不停機(jī)的情況下進(jìn)行這些升級(jí)。

#8：有點(diǎn)繁瑣的復(fù)制設(shè)置

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

#9：荒謬的無計(jì)劃提示教條

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

我確實(shí)了解他們的理由，主要是為了防止用戶使用查詢提示來攻擊問題，而應(yīng)該通過編寫適當(dāng)?shù)牟樵儊斫鉀Q這些提示。 但是，當(dāng)您發(fā)現(xiàn)生產(chǎn)數(shù)據(jù)庫(kù)在突然而意外的查詢計(jì)劃變更下突然陷入全面崩潰時(shí)，這種哲學(xué)似乎是殘酷的家長(zhǎng)式作風(fēng)。

在許多情況下，給計(jì)劃者的提示可以在幾分鐘內(nèi)減輕問題，使工程團(tuán)隊(duì)可以花數(shù)小時(shí)或數(shù)天的時(shí)間對(duì)查詢進(jìn)行適當(dāng)?shù)男迯?fù)。 盡管有一些間接的解決方法涉及禁用某些查詢計(jì)劃器策略，但它們存在風(fēng)險(xiǎn)，因此絕對(duì)不應(yīng)在任何時(shí)間壓力下使用。

那個(gè)象牙塔肯定一定不錯(cuò)。

#10：無塊壓縮

InnoDB在MySQL中的頁面壓縮通?？梢詫⒋鎯?chǔ)空間減少一半，并且從性能的角度來看幾乎是"免費(fèi)的"。 PostgreSQL將自動(dòng)壓縮較大的值，但這對(duì)于將數(shù)據(jù)存儲(chǔ)在關(guān)系數(shù)據(jù)庫(kù)中的最常用的方式?jīng)]有用。 對(duì)于大多數(shù)RDBMS用例，一行通常為幾百個(gè)字節(jié)或更少，這意味著壓縮僅在跨多行或成塊應(yīng)用時(shí)才真正有效。

對(duì)于PostgreSQL核心的數(shù)據(jù)結(jié)構(gòu)來說，塊壓縮確實(shí)很難實(shí)現(xiàn)，但是盡管有一些缺點(diǎn)，但MySQL InnoDB存儲(chǔ)引擎采用的"打孔"策略在實(shí)踐中似乎效果很好。

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

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

在PostgreSQL世界中唯一被廣泛使用的通用塊壓縮設(shè)置利用了ZFS，它似乎對(duì)人們來說非常有效。 ZFS如今已成為L(zhǎng)inux上的生產(chǎn)級(jí)現(xiàn)實(shí)，但無疑帶來了一些管理開銷，而對(duì)于XFS或ext4等更"現(xiàn)成的"文件系統(tǒng)而言，ZFS卻不存在。

說了所有…

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

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

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

我很自豪地說，我已經(jīng)在PostgreSQL的基礎(chǔ)上構(gòu)建了將近20年的軟件，盡管存在缺陷，但我仍然是堅(jiān)定的擁護(hù)者。 鑒于我多年來令人難以置信的開發(fā)團(tuán)隊(duì)所見證的進(jìn)步，我可以說，大多數(shù)(如果不是全部)這些問題將在適當(dāng)?shù)臅r(shí)候得到解決。