【DB吐槽大會】第68期 - PG server less場景下的quota控制靈活性較弱

背景

1、産品的問題點

• PG server less場景下的quota控制靈活性較弱

2、問題點背後涉及的技術原理

• PG 本身沒有quota控制能力, 例如要控制一個使用者、一個資料庫、一個執行個體的存儲空間使用上限, 隻能建立邏輯對象、表空間、目錄的關系, 在目錄層面進行控制, 而且這種控制不友好, 到達上限寫入失敗會導緻資料庫崩潰.

• • 限制一個租戶在一個執行個體中空間的使用.
  • 限制一個執行個體的空間使用.

3、這個問題将影響哪些行業以及業務場景

• SaaS, 一個執行個體可能建立很多個database被不同租戶使用
• 微服務場景, 一個執行個體可能通過建立很多個database服務于多個微服務
• DBaaS場景

4、會導緻什麼問題?

• 使用過程中可能打滿存儲, 進而導緻資料庫崩潰, 影響業務.
• 不能對使用者、schema、database或表空間控制其存儲空間使用率, 無法滿足saas,微服務的業務需求, 例如: 租戶a就想多花點錢, 保留它的存儲配額.

• • 資源都應該可量化其價值, 如果無法量化, 那麼會導緻租戶争搶資源, 造成不公平.

5、業務上應該如何避免這個坑

• 基本無解, 隻能在OS層或者FS層進行控制, 例如zfs, btrfs都支援檔案系統級别的quota配置, 通過目錄、表空間來和使用者、資料庫挂鈎.

6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題

• 管理非常複雜, 而且無法滿足精細化管理需求(隻能到表空間級别)

7、資料庫未來産品疊代如何修複這個坑

• 希望核心支援table、使用者、schema、database或tablespace的存儲空間quota配置.
• 希望核心層面支援隻讀保護功能, 當觸發quota門檻值時, 轉換為隻讀模式, 而不是直接資料庫崩潰.

• • 《DB吐槽大會,第54期 - PG 資源隔離、管理手段較少》
  • 除了quota資源, 還有cpu\iops\帶寬\網絡等資源都可以量化管理.