背景

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分组. 分组之间的后端连接区分开来, 相互不干扰.