【DB吐槽大會】第27期 - PG 單一 block size

背景

1、産品的問題點

• PG 僅支援單一 block size, 編譯叢集時指定, 後期無法改變, 而且軟體和資料庫資料檔案的block size不同時, 無法啟動.

2、問題點背後涉及的技術原理

• 資料庫的資料存儲在以block為機關組織的資料檔案中, 每個block記憶體儲tuple的内容, tuple通過itemid (line point)在block内進行内部尋址. 而外部尋址則通過block id進行.
• 當我們要尋找99号資料塊第3條記錄時, 即ctid=(99,3), 這條記錄如果被索引引用, 假設block size=8KB, 那麼在資料檔案中即偏移對應的size即可定位到第99号資料塊.
• 尋址相關代碼都是寫死的, 僅支援一個block size定義.

3、這個問題将影響哪些行業以及業務場景

• TP 和 AP混合型業務.
• 企業内既有偏TP的業務也有偏AP的獨立業務, 還有 append only 高速寫入的場景, 例如時序, IOT

4、會導緻什麼問題?

• 使用同一執行個體管理ap+tp業務時, 無法達到最好的效率.

• • TP業務的小事務, 通路資料塊内的少量事務, 使用小的block size可以提高通路效率, 節省shared buffer記憶體.
  • AP業務屬于低并發的大事務, 需要通路更多片的資料, 通常大的block size可以提高壓縮比, 提高大片資料的讀寫吞吐.

• 不同業務采用不同block size的執行個體管理, 會導緻管理更加複雜, 每個執行個體需要搞清楚資料塊大小, 并且使用對應的PG二進制來管理這個執行個體.

5、業務上應該如何避免這個坑

• 多套編譯好的PG軟體, 根據業務模型的需求, 選擇不同的PG軟體去初始化叢集.

6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題

• 在企業中使用不同資料塊大小的PG軟體, 會導緻管理成本增加.
• 在進行大版本更新時都要注意大小版本的二進制相容性, 否則會導緻更新不成功.

7、資料庫未來産品疊代如何修複這個坑

• 核心層支援多種BLOCK SIZE, 可以表級别進行設定, 滿足混合業務需求. 一套二進制軟體可以管理多種block size的資料庫, 降低企業管理負擔.

https://github.com/digoal/blog/blob/master/202109/20210903_02.md#postgresql-%E8%AE%B8%E6%84%BF%E9%93%BE%E6%8E%A5 https://github.com/digoal/blog/issues/76