【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的請求進入隊列, 隊列超過一定長度後報錯丢棄.

https://github.com/digoal/blog/blob/master/202110/20211009_01.md#%E6%9C%9F%E6%9C%9B-postgresql-%E5%A2%9E%E5%8A%A0%E4%BB%80%E4%B9%88%E5%8A%9F%E8%83%BD https://github.com/digoal/blog/issues/76