背景
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\带宽\网络等资源都可以量化管理.
