PostgreSQL 並行vacuum patch - 暨為什麼需要並行vacuum或分割槽表

weixin_33763244發表於2018-04-18

背景

我們之前做過一個這樣的測試，單表資料從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

參考