【DB吐槽大会】第74期 - PG 不支持SQL维度资源限流

背景

1、产品的问题点

• PG 不支持SQL维度按资源限流的功能

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

• 用户发起SQL, SQL按执行计划execute过程中消耗CPU、IOPS、存储带宽、网络带宽等.

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

• 通用

4、会导致什么问题?

• SQL执行计划异常(使得SQL更加耗费资源)、请求数暴增等发生时:

• 当资源够用时, 不会对业务有什么影响.
• 当资源不够用时, 将影响业务, 严重时雪崩.

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

• 可以设置用户、db、全局的 statement timeout.

• 不友好, 因为不能针对sql设置, 而不同的sql有的本身执行就很快(例如KV类查询), 有的本身就慢(例如复杂JOIN), 如果设置统一的语句超时值, 不能适应所有的sql.
• 效果较差, 甚至不可行. 除非在事务中针对每条SQL执行前设置statement timeout, 这样可以控制每条SQL的超时.

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

• 在事务中针对每条SQL执行前设置statement timeout, 控制每条SQL的超时.

• 使得开发复杂度增加, 同时需要预估SQL的执行耗时,
• 一旦系统或业务变更导致SQL无法按原有预期执行完就会导致超时报错, 带入了人为故障的大概率.

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

• 目的: 防止雪崩、防止某些业务或个人提交某些sql把资源耗尽.
• 期望: 内核支持:

• 比较理想的状态是和SQL执行计划评估出的代价挂钩, 可以用系数来进行设置, 如增加statement_timeout_cost参数, 例如代价和耗时为1000:1ms的关系, 那么代价是2500的SQL, 超时设置为2.5毫秒.
• 还有一种设置方法是白名单、黑名单方式: 在白名单中的SQL, 一对一的设置SQL的超时时间. 不在白名单中的SQL设置统一的超时、或者使用以上系数法.
• 除了超时, 实际上还可以通过资源消耗阈值来进行控制, 对于同样的query id的SQL, 在一个周期内, 限定其CPU timing 、IOPS 、存储带宽、网络, 这种方法与cgroup挂钩或者内部有rsq的功能来进行支持.
• 最后, 还可以按query id来限定QPS(例如sql1: qps上限10000, sql2: qps上线1000). 超出qps的请求进入队列, 队列超过一定长度后报错丢弃.