【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阈值时, 转换为只读模式, 而不是直接数据库崩溃.
上一篇:【重新发现PostgreSQL之美】- 9 面向多值列的倒排索引GIN|RUM


下一篇:【DB吐槽大会】第70期 - PG 不支持update | delete skip locked, nowait语法