【DB吐槽大會】第65期 - PG 沒有内置程序池

背景

1、産品的問題點

• PG 沒有内置程序池

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

• PG 是程序模型, 每個建立的連接配接在PG資料庫端都會fork一個新的程序來進行對接.

• • Oracle也是程序模型的資料庫, 這種模式較dedicate server模式.

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

• 網際網路類的高并發業務

• • 大量連接配接, 小事務, 寫操作
  • 高并發短連接配接

4、會導緻什麼問題?

• 性能急劇下降

• • 《DB吐槽大會,第9期 - PG 大量連接配接寫小事務性能差》
  • 《DB吐槽大會,第8期 - PG 高并發短連接配接性能差》

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

• 可以在業務和資料庫中間增加1個連接配接池, 例如pgbouncer. 使用事務級别的連接配接池複用模式.

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

• 使用連接配接池時, 業務與資料庫的連接配接會多1跳, 使得SQL的RT可能增加
• 由于使用事務級别的連接配接池複用模式, 每個事務結束後, 後端資料庫連接配接可能切換給其他會話使用, 下次發起請求時, 用到的也可能是不一樣的後端資料庫連接配接. 是以在業務層無法使用綁定變量等含會話層屬性的特性, 無法使用綁定變量可能導緻高并發性能下降, CPU使用率上升.

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

• 希望支援核心層面的連接配接池。 類似oracle的shared server模式. 并且要支援會話變量多程序共享的能力, 避免出現無法支援會話變量或屬性(例如綁定變量)的功能.
• 連接配接池考慮支援多個分組，使用者可以自定義使用哪個分組，或者預設根據QUERY的讀寫特性區分分組，或者根據QUERY的時長區分分組。

• • 例如olap業務可以使用ap分組(這樣的話資源之間可以做到很好的隔離) , TP業務使用TP分組. 分組之間的後端連接配接區分開來, 互相不幹擾.