當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

PostgreSQL 并行vacuum patch - 暨为什么需要并行vacuum或分区表

發布時間：2025/5/22 数据库 14 豆豆

生活随笔收集整理的這篇文章主要介紹了 PostgreSQL 并行vacuum patch - 暨为什么需要并行vacuum或分区表小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

標簽

PostgreSQL , vacuum , freeze , 分區表 , 并行vacuum

背景

我們之前做過一個這樣的測試，單表數據從1000萬到10億，對其進行增刪改查的壓測，性能幾乎沒有衰減。

數據量寫入吞吐查詢tps更新tps

1000萬	58萬行/s	67萬	23.1萬
1億	53.2萬行/s	63.4萬	24.5萬
10億	162.6萬行/s	60.6萬	23.4萬

《HTAP數據庫 PostgreSQL 場景與性能測試之 45 - (OLTP) 數據量與性能的線性關系(10億+無衰減), 暨單表多大需要分區》

是不是就意味著我們不需要對數據庫進行分表了呢？

實際上單表太大，還可能引入其他問題，例如：

1、創建索引，大表創建索引時間會更久，當然PostgreSQL 11已經支持單表并行創建索引了，所以這個問題逐漸會不存在。

《PostgreSQL 11 preview - 并行排序、并行索引 (性能線性暴增) 單實例100億TOP-K僅40秒》

2、加字段并加默認值，或者不能online DDL的操作。單表越大，操作時間會越久。

這個問題的解法：1 支持更多的ONLINE DDL(類似?pg_repack?的原理)。2 支持DDL并行。

3、垃圾回收，因為單表的垃圾回收目前只支持串行，所以單表越大，垃圾回收的時間越長。

這個問題的解法：支持并行VACUUM。社區已經在做這個PATCH。

4、FREEZE表，與垃圾回收類似的問題，單表的垃圾回收，目前只能串行。而FREEZE如果很慢，并且慢過產生TXID的速度，可能導致數據庫因為XID耗盡，需要停止業務來進行凍結。

這個問題的解法：1 支持并行VACUUM。社區已經在做這個PATCH。 2 skip clean page(9.6開始已經支持)，使得freeze效率高了很多。3 支持64BIT txid，完全杜絕freeze操作。

5、單表可能打爆文件系統，因為單個表只能放在單個表空間中，表空間對應文件系統，所以單表的大小也受到文件系統大小的限制。

這個問題的解法：1 使用類似LVM，ZFS這樣的卷管理，使得單個文件系統很大很大。 2 使用分區表。

以上問題是單表很大時，可能出現的問題。

所以單表多大需要使用分區表呢？主要考慮幾個方面：

1、表上的DML頻率。

2、數據庫的硬件性能指標。

3、查詢方面的優化需求，例如是否可以通過分區來降維，優化SQL性能。

比較傻瓜式的建議（SSD，多核）：

不頻繁更新、刪除的表：記錄數20億，表占用空間200 GB。就可以考慮分表了。

平反更新、刪除、插入的表：記錄數2億，表占用空間20 GB。就可以考慮分表了。

如何平滑將單表切換為分區表？

1、pg_pathman提供了平滑切換到分區表的API。

https://github.com/postgrespro/pg_pathman

《PostgreSQL 9.5+ 高效分區表實現 - pg_pathman》

vacuum的內核改進

針對前面提到的垃圾回收，freeze操作，內核層面可以做出的改進。

1、并行vacuum

https://www.postgresql.org/message-id/flat/CAD21AoD1xAqp4zK-Vi1cuY3feq2oO8HcpJiz32UDUfe0BE31Xw@mail.gmail.com#CAD21AoD1xAqp4zK-Vi1cuY3feq2oO8HcpJiz32UDUfe0BE31Xw@mail.gmail.com

https://commitfest.postgresql.org/13/954/

目前這個PATCH還沒有提交到主干。

2、跳過clean page(根據vm文件標記位)，9.6開始，就支持了SKIP CLEANUP PAGE，freeze性能大幅提升。

《PostgreSQL 9.6 vacuum freeze大幅性能提升代碼淺析》

3、64bit xid，治本的方法。

https://commitfest.postgresql.org/17/1178/

PostgresPRO 版本引入了64BIT的txid，所以不再需要全局freeze操作。

https://postgrespro.com/docs/enterprise/10/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

將數據庫的PAGE轉換為兼容postgrespro的PAGE，可以使用如果工具。

對于FREEZE操作來說，方法1和2都是治標不治本的方法，3是社區正在改進的方向，可以看到社區的commitfest已經在加快做64bit txid 的 refact了。

https://github.com/postgrespro/pg_pageprep

參考