溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶(hù)服務(wù)條款》

PostgreSQL實(shí)際場(chǎng)景的缺陷有哪些

發(fā)布時(shí)間：2021-11-04 17:13:59 來(lái)源：億速云 閱讀：133 作者：iii 欄目：關(guān)系型數(shù)據(jù)庫(kù)

本篇內(nèi)容介紹了“PostgreSQL實(shí)際場(chǎng)景的缺陷有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

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

關(guān)于這一點(diǎn)建議你查看更多資料，毫不避諱地說(shuō)，這個(gè)缺點(diǎn)真的很讓人頭疼。該問(wèn)題導(dǎo)致過(guò)很多長(zhǎng)時(shí)間停機(jī)的故障，長(zhǎng)達(dá)數(shù)天。如果你查看足夠的材料，比如用Google搜索，就會(huì)發(fā)現(xiàn)許多人都在這個(gè)功能上踩雷。幾乎所有不具備高級(jí)專(zhuān)家經(jīng)驗(yàn)的PostgreSQL技術(shù)人員，都會(huì)遇到這個(gè)問(wèn)題。
 
或許將來(lái)某個(gè)時(shí)候，XID可能會(huì)過(guò)渡為使用64位整數(shù)，但是在那之前，我們?nèi)匀灰^續(xù)應(yīng)對(duì)這個(gè)挑戰(zhàn)。不過(guò)好一點(diǎn)的是，與飛機(jī)上的應(yīng)用軟件不同，這個(gè)故障我們是可以盡量去避免的，只要不使用這個(gè)功能的話(huà)。
 
缺陷2：failover故障可能會(huì)丟失數(shù)據(jù)
 
如果運(yùn)行中的主服務(wù)器突然出現(xiàn)故障，那么運(yùn)行中的流復(fù)制設(shè)置幾乎肯定會(huì)丟失已提交的數(shù)據(jù)。有人可能會(huì)說(shuō)：“異步復(fù)制的代價(jià)就是這樣?！?但并不是所有的異步復(fù)制都會(huì)丟失數(shù)據(jù)。PostgreSQL雖然支持同步復(fù)制優(yōu)選提交的機(jī)制，以實(shí)現(xiàn)容錯(cuò)的持久性，但是如果要保證較小的性能影響范圍，就會(huì)對(duì)應(yīng)用程序提出更復(fù)雜的設(shè)計(jì)要求。
 
這種情況下，雖然等待不會(huì)占用系統(tǒng)資源，但是事務(wù)鎖會(huì)繼續(xù)保留，直到確認(rèn)轉(zhuǎn)移為止。導(dǎo)致的結(jié)果是，為了避免響應(yīng)時(shí)間增加和資源爭(zhēng)用增加，需要謹(jǐn)慎使用同步復(fù)制，因?yàn)榭赡軙?huì)將降低數(shù)據(jù)庫(kù)應(yīng)用程序的性能。
 
同步復(fù)制優(yōu)選提交在某些情況下很有用，但我不推薦在通用用例中使用。這個(gè)機(jī)制有點(diǎn)類(lèi)似于Kafka的ISR復(fù)制，具有acks = all和一個(gè)已定義的min_isr，但是在運(yùn)行任意查詢(xún)的時(shí)候，根據(jù)目標(biāo)端數(shù)據(jù)庫(kù)類(lèi)型及事務(wù)處理原理不同，會(huì)表現(xiàn)出細(xì)微的差別。我還沒(méi)有了解到過(guò)，通過(guò)failover故障轉(zhuǎn)移，有過(guò)成功應(yīng)用仲裁提交，在數(shù)據(jù)規(guī)模較大的環(huán)境中實(shí)現(xiàn)高可用性，高耐久性的復(fù)制案例。如果各位讀者有這樣的案例，我愿意一聽(tīng)！
 
就關(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ù)制磁盤(pán)二進(jìn)制數(shù)據(jù)本身中的更改。
 
每次需要通過(guò)寫(xiě)操作修改磁盤(pán)上的數(shù)據(jù)庫(kù)頁(yè)面（4KB）時(shí)，即使只是一個(gè)字節(jié)，也將使用請(qǐng)求的更改進(jìn)行編輯的整個(gè)頁(yè)面的副本寫(xiě)入預(yù)寫(xiě)日志（WAL） 。物理流復(fù)制利用此現(xiàn)有的WAL基礎(chǔ)結(jié)構(gòu)作為流到副本的更改日志。
 
例如，使用物理復(fù)制，大型索引構(gòu)建會(huì)創(chuàng)建大量WAL條目，從而很容易成為流復(fù)制的瓶頸。頁(yè)面粒度的讀取-修改-復(fù)制過(guò)程會(huì)導(dǎo)致主機(jī)上由硬件引起的數(shù)據(jù)損壞，更容易將損壞傳播到副本，這種故障我個(gè)人在生產(chǎn)中親眼目睹過(guò)。
 
這與邏輯復(fù)制相反，后者僅復(fù)制邏輯數(shù)據(jù)更改。至少?gòu)睦碚撋现v，大型索引構(gòu)建只會(huì)導(dǎo)致在網(wǎng)絡(luò)上復(fù)制單個(gè)命令。盡管PostgreSQL已經(jīng)支持邏輯復(fù)制已有相當(dāng)長(zhǎng)的一段時(shí)間了，但是大多數(shù)部署都使用物理流復(fù)制，因?yàn)樗?，支持范圍更廣并且更易于使用。
 
缺陷4：MVCC垃圾回收頻發(fā)
 
與大多數(shù)主流數(shù)據(jù)庫(kù)一樣，PostgreSQL使用多版本并發(fā)控制（MVCC）來(lái)實(shí)現(xiàn)并發(fā)事務(wù)。但是，其特定的實(shí)現(xiàn)通常會(huì)給垃圾行的數(shù)據(jù)版本及其清理（VACUUM）帶來(lái)操作上的麻煩。一般來(lái)說(shuō)，UPDATE操作會(huì)為任何已修改的行創(chuàng)建新副本（或“行版本”），將舊版本保留在磁盤(pán)上，直到可以清除它們?yōu)橹埂?br/> 
多年來(lái)，這種情況一直在穩(wěn)步改善，但它是一個(gè)復(fù)雜的系統(tǒng)，對(duì)于任何初次接觸該問(wèn)題的人來(lái)說(shuō)都是一個(gè)黑匣子。比如說(shuō)，你是否了解堆內(nèi)元組（HOT）及其何時(shí)啟動(dòng)對(duì)于繁重的就地更新工作負(fù)載（如連續(xù)保持一致的計(jì)數(shù)器列），這種操作很可能會(huì)失敗。默認(rèn)的自動(dòng)真空設(shè)置在大多數(shù)情況下都有效，但是，如果真的失效了，那后果就不堪設(shè)想。
 
相較而言，MySQL和Oracle使用Redo和undo日志。他們不需要類(lèi)似的后臺(tái)垃圾收集過(guò)程。為了實(shí)現(xiàn)整個(gè)功能所作出的權(quán)衡犧牲主要是事務(wù)提交和回滾操作的額外延遲。
 
雖然這樣會(huì)有延遲產(chǎn)生，但是也許是在遙遠(yuǎn)的將來(lái)的某個(gè)時(shí)候，這個(gè)功能就會(huì)變得很有價(jià)值了。
 
缺陷5：每次連接處理=規(guī)?；纯?/strong>
 
PostgreSQL為每個(gè)連接生成一個(gè)進(jìn)程，而其他大多數(shù)數(shù)據(jù)庫(kù)都使用更有效的連接并發(fā)模型。由于存在一個(gè)相對(duì)較低的閾值，在該閾值上添加更多的連接會(huì)降低性能（約2個(gè)內(nèi)核），最終會(huì)導(dǎo)致性能下降，而性能下降的比例可能會(huì)很高（難以估計(jì)，高度依賴(lài)于工作負(fù)載），就會(huì)使得性能調(diào)優(yōu)的難度增加。
 
使用連接池的標(biāo)準(zhǔn)方法當(dāng)然可以解決問(wèn)題，但是會(huì)帶來(lái)額外的架構(gòu)復(fù)雜性。在一次特別大規(guī)模的部署中，我最終不得不在第二個(gè)pgbouncer層中分層。一層在應(yīng)用程序服務(wù)器上運(yùn)行，另一層在數(shù)據(jù)庫(kù)服務(wù)器上運(yùn)行。它總共聚合了大約一百萬(wàn)個(gè)客戶(hù)端進(jìn)程的連接。這時(shí)候?qū)τ谡{(diào)優(yōu)工作來(lái)說(shuō)，大概只有40%的技術(shù)含量，剩下大概要花40%的蠻力，還需要10%的碰運(yùn)氣了。
 
進(jìn)程可擴(kuò)展性在每個(gè)主要版本中都在逐步提高，但與MySQL中使用的“每連接線(xiàn)程數(shù)”相比，最終該體系結(jié)構(gòu)的性能還是受到了一定的限制。
 
有關(guān)更多技術(shù)詳情，請(qǐng)參見(jiàn)https://brandur.org/postgres-connections。
 
缺陷6：主鍵索引簡(jiǎn)直是浪費(fèi)空間
 
PostgreSQL中的表有一個(gè)主鍵索引和稱(chēng)為堆的獨(dú)立行存儲(chǔ)。其他數(shù)據(jù)庫(kù)將它們集成在一起或支持“索引組織表”。在PostgreSQL的這種機(jī)制下，主鍵查找過(guò)程直接指向具體的行數(shù)據(jù)，而不需要輔助獲取完整行以及必需的額外CPU和I / O利用率。
 
PostgreSQL中的CLUSTER命令會(huì)根據(jù)索引重新組織表以提高性能，但實(shí)際上不適用于大多數(shù)OLTP的情況。它是以互斥鎖重寫(xiě)整個(gè)表，從而阻止任何讀取或?qū)懭?。PostgreSQL不維護(hù)新數(shù)據(jù)的群集布局，因此該操作必須定期運(yùn)行。因此，如果你不能接受數(shù)據(jù)庫(kù)長(zhǎng)時(shí)間脫機(jī)，這種機(jī)制就無(wú)法使用。
 
但更關(guān)鍵的是，索引組織的表可以節(jié)省空間，因?yàn)樗饕恍枰獑为?dú)的行數(shù)據(jù)副本。對(duì)于對(duì)于主要由主鍵覆蓋的小行的表（例如聯(lián)接表），這可以輕松地將表的存儲(chǔ)空間減少一半。
 
比如針對(duì)下表，該表存儲(chǔ)任意對(duì)象的社交獲得的“贊”：
 
CREATE TABLE likes (
object_type INTEGER NOT NULL,
object_id BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY,
user_id BIGINT NOT NULL,
created_at TIMESTAMP WITH TIME ZONE NOT NULL,
PRIMARY KEY(object_type, object_id, user_id)
);
 

PostgreSQL將維護(hù)與基表存儲(chǔ)區(qū)分開(kāi)的主鍵索引。 該索引將為每行包含object_type，object_id和user_id列的完整副本。 每行28個(gè)字節(jié)中的20個(gè)（大約70％）將被復(fù)制。 我們想一下，如果PostgreSQL支持按索引組織的表，則不需要消耗所有這些額外的空間。

缺陷7：大版本升級(jí)可能需要停機(jī)
 
針對(duì)大型的數(shù)據(jù)庫(kù)， 一些主要版本升級(jí)需要數(shù)小時(shí)的停機(jī)時(shí)間，才能實(shí)現(xiàn)數(shù)據(jù)的完全轉(zhuǎn)移。如果使用典型的流復(fù)制機(jī)制，無(wú)法通過(guò)升級(jí)副本并執(zhí)行故障轉(zhuǎn)移來(lái)優(yōu)雅地做到這一點(diǎn)。而磁盤(pán)二進(jìn)制格式在大版本之間不兼容，因此，主副本之間的有線(xiàn)協(xié)議實(shí)際上也是不兼容的。
 
希望邏輯復(fù)制最終將完全取代流復(fù)制，以便使得用戶(hù)能夠啟用在線(xiàn)滾動(dòng)升級(jí)策略。我之前進(jìn)行大規(guī)模水平部署時(shí)，我們?cè)谧远x基礎(chǔ)架構(gòu)上進(jìn)行了重大工程投入，并且使用額外的基于觸發(fā)器的復(fù)制系統(tǒng)（也用于分片遷移），最終才保證了在不停機(jī)的情況下進(jìn)行這些升級(jí)的。
 
缺陷8：有點(diǎn)繁瑣的復(fù)制設(shè)置
 
公平地說(shuō)，MySQL的即用型復(fù)制要麻煩得多，但是與某些NoSQL存儲(chǔ)（如MongoDB和Redis）或某些面向集群的復(fù)制系統(tǒng)（如MySQL Group Replication和Galera Cluster）相比，其易用性 以及避免邊緣化的觀點(diǎn)，在PostgreSQL中設(shè)置復(fù)制仍有很多不足之處。從理論上講，邏輯復(fù)制為第三方解決方案提供了更大的靈活性，以彌補(bǔ)這些空白，但到目前為止，使用它代替流復(fù)制存在很大的問(wèn)題。
 
缺陷9：缺乏Planner hints機(jī)制
 
一般數(shù)據(jù)庫(kù)中， 通過(guò)Planner hints提示，可以引導(dǎo)用戶(hù)使用自己不會(huì)使用的策略。但PostgreSQL開(kāi)發(fā)團(tuán)隊(duì)多年來(lái)一直拒絕支持Planner hints程序提示，認(rèn)為這好像是一種更聰明的編譯器參數(shù)的形式。
 
我確實(shí)理解他們的理由，這主要是為了防止不法用戶(hù)使用應(yīng)通過(guò)編寫(xiě)適當(dāng)查詢(xún)而解決的查詢(xún)提示來(lái)攻擊的問(wèn)題。但是，當(dāng)你看到生產(chǎn)數(shù)據(jù)庫(kù)在突然而意外的查詢(xún)計(jì)劃變動(dòng)下急劇陷入崩潰時(shí)，沒(méi)有任何提示也不知道怎么操作的時(shí)候就比較惱火了。
 
在許多情況下，給用戶(hù)的hint提示可以在幾分鐘內(nèi)緩解問(wèn)題，并為工程團(tuán)隊(duì)節(jié)省他們?yōu)椴樵?xún)進(jìn)行適當(dāng)修復(fù)所需的時(shí)間，比如幾小時(shí)甚至幾天。盡管有一些間接的解決方法涉及禁用某些查詢(xún)計(jì)劃器策略，但它們存在風(fēng)險(xiǎn)，因此絕對(duì)不應(yīng)無(wú)任何限制地使用。
 
當(dāng)然如果能同時(shí)滿(mǎn)足這兩種需求那就很完美了。
 
缺陷10：無(wú)塊壓縮
 
InnoDB在MySQL中的頁(yè)面壓縮通常可將存儲(chǔ)空間減少一半，并且從性能角度來(lái)看幾乎是“免費(fèi)的”（不受影響）。PostgreSQL只支持自動(dòng)壓縮較大的數(shù)值，但這對(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)來(lái)說(shuō)，塊壓縮確實(shí)很難實(shí)現(xiàn)，但是盡管有一些缺點(diǎn)， MySQL InnoDB存儲(chǔ)引擎采用的“打孔”策略在實(shí)踐中似乎效果還不錯(cuò)。
 
PostgreSQL世界中唯一被廣泛使用的通用塊壓縮設(shè)置利用了ZFS，很多人覺(jué)得比較好用。ZFS如今已成為L(zhǎng)inux上的生產(chǎn)級(jí)實(shí)現(xiàn)，但無(wú)疑也帶來(lái)了一些管理上的開(kāi)銷(xiāo)，而對(duì)于XFS或ext4等更“現(xiàn)成的”文件系統(tǒng)而言，ZFS卻不存在。

“PostgreSQL實(shí)際場(chǎng)景的缺陷有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

向AI問(wèn)一下細(xì)節(jié)

免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI
助
手