背景

1、产品的问题点

• PG 里面的某些单核瓶颈

2、问题点背后涉及的技术原理

• 虽然PG已经支持并行计算, 大多数的SQL支持通过并行计算加速, 使得PG可以支撑OLAP类业务. 但是还存在一些单核场景.

• • WAL writer
  • vacuum 单表/单分区时
  • checkpointer
  • 崩溃recovery时

3、这个问题将影响哪些行业以及业务场景

• 写压力较大的场景
• 表比较大而且这个表的更新并发较高的场景, 例如互联网业务
• ssd云盘使用网络通信, 相比本地盘存在先天缺陷, 虽然带宽大, 但是每次IO的延迟较高. 所以小IO或离散IO的场景(特别是数据库): 单线程打不满IO.

4、会导致什么问题?

• 写压力特别大的场景, 可能有两个性能瓶颈, datalbock extend exclusive lock, 或者 wal insert exclusive lock.
• 表比较大, 而且更新并发高时, 可能导致vacuum赶不上产生垃圾的速度, 产生恶性表膨胀.
• shared buffer配置较大而且脏页较多时, checkpoint 周期可能会很长.
• 如果检查点周期很长, 崩溃恢复过程中需要恢复的WAL文件数可能较多, 从而导致恢复时间漫长.

5、业务上应该如何避免这个坑

• 拆库
• 拆表或使用分区表, 解决vacuum 单表/单分区串行问题.
• 配置更豪华的SSD存储, 一定程度缓解检查点慢或者恢复慢点问题

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 需要调整业务, 可能涉及业务代码的修改.
• 分区表会引入一定的性能问题. (PG大版本有改观, 性能影响几乎可以忽略不计, 一定要用大版本).

7、数据库未来产品迭代如何修复这个坑

• 希望内核层面可以支持更多并行化的后台进程任务

• • 采用 wal 分区设计、减少锁冲突、同时支持更多的并行insert
  • 支持vacuum 单表/单分区/单索引内的并行(目前支持单表的多个索引的并行)
  • 支持并行的checkpoint, 支持并行的recovery