背景
1、产品的问题点
- PG 没有内置进程池
2、问题点背后涉及的技术原理
- PG 是进程模型, 每个新建的连接在PG数据库端都会fork一个新的进程来进行对接.
- Oracle也是进程模型的数据库, 这种模式较dedicate server模式.
3、这个问题将影响哪些行业以及业务场景
- 互联网类的高并发业务
- 大量连接, 小事务, 写操作
- 高并发短连接
4、会导致什么问题?
- 性能急剧下降
5、业务上应该如何避免这个坑
- 可以在业务和数据库中间增加1个连接池, 例如pgbouncer. 使用事务级别的连接池复用模式.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 使用连接池时, 业务与数据库的连接会多1跳, 使得SQL的RT可能增加
- 由于使用事务级别的连接池复用模式, 每个事务结束后, 后端数据库连接可能切换给其他会话使用, 下次发起请求时, 用到的也可能是不一样的后端数据库连接. 因此在业务层无法使用绑定变量等含会话层属性的特性, 无法使用绑定变量可能导致高并发性能下降, CPU使用率上升.
7、数据库未来产品迭代如何修复这个坑
- 希望支持内核层面的连接池。 类似oracle的shared server模式. 并且要支持会话变量多进程共享的能力, 避免出现无法支持会话变量或属性(例如绑定变量)的功能.
- 连接池考虑支持多个分组，用户可以自定义使用哪个分组，或者默认根据QUERY的读写特性区分分组，或者根据QUERY的时长区分分组。
- 例如olap业务可以使用ap分组(这样的话资源之间可以做到很好的隔离) , TP业务使用TP分组. 分组之间的后端连接区分开来, 相互不干扰.
