【DB吐槽大会】第54期 - PG 资源隔离、管理手段较少

背景

1、产品的问题点

• PG 资源隔离、管理手段较少

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

• PG 是一个支持OLTP OLAP混合负载的数据库系统, 类似于Oracle. PG 从9.6开始支持并行计算, 一条复杂SQL在使用并行计算时可能耗费较多资源.
• PG 支持单实例多database的模式, 很多(租户)用户可能在同一个instance中创建多个database分配给不同的业务使用. 特别是saas软件行业, DBaaS服务等.

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

• 有混合负载的业务场景、SaaS业务、serverless dbaas服务.

4、会导致什么问题?

• 复杂SQL可能消耗掉所有的资源, 影响对RT很敏感的高并发OLTP类业务.
• 在同一个instance中创建多个database时, 某个database对应的业务如果使用的 cpu|io|网络 资源较多, 可能影响其他database对应的业务.

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

• 将TP和AP类业务使用不同的数据库用户
• 给SaaS, DBaaS的不同业务分配使用不同的数据库用户
• 使用cgroup限制不同用户的backend process资源(cpu,io,网络等资源)

• 《重新发现PostgreSQL之美 - 12 serverless & SaaS行业 & 多租户 & 资源隔离 & 捣蛋鬼,你揍开》

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

• 资源调度要求较高, 依赖cgroup, 及时的PID和cgroup设置.
• 必须按要求设计schema, 否则无法区分什么SQL应该放入什么Resource Queue.

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

• 希望内核能支持resource queue管理功能.

• 限制user, database的cpu|io|网络等使用.
• 支持分时间配置: 例如每分钟的粒度, 某个用户可以分配的资源百分比或绝对值.
• 支持分段配置: 例如半夜AP用户给更多资源, 白天TP用户给更多资源.
• 支持资源隔离 : 表级、会话级、用户级、语句级、schema级、库级 . 支持粒度 : 内存、CPU单位时间、IOPS 限制