PG 15傳聞中的超級令人激動的功能大多數(shù)跳票了，年初我也寫過一個關(guān)于PG15新功能跳票的文章。PG 15 BETA已經(jīng)發(fā)出幾個月了，似乎PG 15里令人激動人心的功能不多，不過從長長的新功能列表里，我還是能夠從中學(xué)到不少東西。數(shù)據(jù)庫的發(fā)展是和現(xiàn)代硬件技術(shù)的發(fā)展密切相關(guān)的，而數(shù)據(jù)庫在某一個方面的突破，可以為應(yīng)用提供更大的舞臺，讓應(yīng)用能夠更加適應(yīng)某些特定場景。

實際上經(jīng)過幾個重要特性的跳票之后，我對PG 15的期待最主要集中在FULL PAGE WRITE的優(yōu)化上了。以前我也多次寫文章研究過PG的WAL產(chǎn)生以及CHECKPOINT對高負載應(yīng)用寫入性能的影響。其實這些性能影響大部分來自于FULL PAGE WRITE。因為當(dāng)某個臟塊在CHECKPOINT完成后的第一次被寫入的時候，都需要做一次FULL PAGE WRITE，以避免數(shù)據(jù)庫需要恢復(fù)時出現(xiàn)塊斷裂的情況。而FULL PAGE WRITE大規(guī)模產(chǎn)生的時候，因為WAL的寫入量大大增加，就會導(dǎo)致高并發(fā)寫應(yīng)用的性能問題。實際上，當(dāng)我們在做pg_basebackup等在線備份操作時，也是會引發(fā)大量的FULL PAGE WRITE的。緩解這個問題的方法是加大CHECKPOINT的延時，讓兩次CHECPOINT的間隔更長一些，這樣就會大量減少FULL PAGE WRITE。

加大CHEKPOINT的延時也是一個雙刃劍，因為這會讓數(shù)據(jù)庫在恢復(fù)時需要RECOVER更多的頁，同時也會在一個CHECKPOINT時集中寫入大量的數(shù)據(jù)塊。在瞬時對IO產(chǎn)生更大的影響。

在PG中關(guān)閉FULL PAGE WRITE也是一個選項，只不過需要找到支持PG關(guān)閉FULL PAGE WRITE的文件系統(tǒng)或者存儲系統(tǒng)。我們以前曾經(jīng)在ZFS上嘗試過關(guān)閉FULL PAGE WRITE，效果是相當(dāng)不錯的。只不過在我們的大多數(shù)PG運行環(huán)境中并沒有使用ZFS，因此對于PG 15在FULL PAGE WRITE上的優(yōu)化，我們還是很期待的。

我曾經(jīng)也考慮過通過WAL壓縮來緩解FULL PAGE WRITE的問題，在PG 12上我們做過一個測試，打開WAL壓縮。只不過打開WAL壓縮后，PG數(shù)據(jù)塊的高并發(fā)寫入性能并未提升，反而略有下降。能夠從以前的PG 12的WAL壓縮中獲得性能提升的場景十分有限。

PG 15的WAL壓縮有了一個十分令人興奮的改進，除了支持PGLZ外，WAL壓縮還支持LZ4和ZSTANDARD兩種壓縮算法。

從官方的對比來看，ZSTD是一種平衡了壓縮解壓吞吐量與壓縮比的十分優(yōu)秀的壓縮算法，而LZ在壓縮比上雖然不如ZSTD，但是在壓縮吞吐量上有著特別優(yōu)秀的表現(xiàn)。這兩種壓縮算法的引入，必定會大大改善WAL壓縮的性能。

因為時間關(guān)系，我們目前還沒有全面開展PG 15的測試，我想還是等正式版出來后再做完整的測試。不過從目前國外一些朋友對PG 15的測試來看，還是十分令人期待的。我們根據(jù)Mark Callaghan的測試用例來看一看效果吧。

和我們的預(yù)期相同，使用以前的pglz，對于僅有PK的場景影響并不大，對于PG來說，第一次數(shù)據(jù)寫入，都是創(chuàng)建的新塊，不同的算法之間的影響還不算太大。但是對于其他場景影響較大。而使用LZ4的效果極佳，裝載性能有了明顯的提升。zstd在有多個索引時的數(shù)據(jù)裝載表現(xiàn)出了較好的性能。

不過從上面的測試來看，還是比較簡單的，因此這個測試結(jié)果頁并不說明太多的問題。不過有一點是可以確定的，那就是LZ4和ZSTD的引入，會大大優(yōu)化WAL 壓縮的性能，從而緩解FULL PAGE WRITE的問題，也可以大大減輕DBA優(yōu)化CHECKPOINT的工作。CHECKPOINT的優(yōu)化可能會在大多數(shù)場景下變得更簡單了，我們只要根據(jù)自己的場景需求，選擇設(shè)置WAL壓縮參數(shù)就可以了。

挺巧的是，在PG 15里，增加了一個新的權(quán)限:pg_checkpointer。以往checkpint命令只能由超級用戶來執(zhí)行。而PG 15里，只要是授予這個權(quán)限的用戶，都可以在自己的應(yīng)用里執(zhí)行checkpoint命令了。將checkpoint命令的權(quán)限下放，是PG 15細粒度權(quán)限控制優(yōu)化的一部分。不過既然敢下放權(quán)限，那就說明checkpoint帶來的副作用已經(jīng)可控了。隨著現(xiàn)代硬件的發(fā)展，IO問題已經(jīng)得到了大大地緩解，同時因為WAL壓縮的優(yōu)化，也為checkpoint權(quán)限下放提供了有力的支撐。

不過業(yè)務(wù)場景十分復(fù)雜，這個權(quán)限還是不要隨便授予，因為目前來看，我還沒有想清楚，這個權(quán)限下放的真實好處在什么地方，什么場景下，應(yīng)用需要自己去控制checkpoint。如果有一天，DBA發(fā)現(xiàn)一個撓頭的IO性能問題，是因為某個應(yīng)用系統(tǒng)頻繁執(zhí)行checkpoint引發(fā)的，那就麻煩大了。對于開發(fā)人員來說，讓每條記錄盡快寫盤肯定是件喜聞樂見的事情，而對于DBA來說，那可能是個災(zāi)難。