作者
digoal
日期
2020-09-02
标签
PostgreSQL , paas , oom , 分区 , schema , 多租户
背景
传统软件通常是以卖软件正版License的方式牟利, 随着市场的饱和, 以及可持续发展的诉求, 软件厂商可以通过发布新的版本, 让用户继续购买新版本来维持持续发展. 但是这种软件安装在客户端的形态, 客户很容易迁移到其他的产品, 同时随着市场的充分竞争, 传统软件企业也在思考转型. 例如提供paas, saas类服务, 用户通过软件订阅的形式购买服务, 数据在云端, 客户迁移不是那么容易, 并且每年需要支付订阅费用. 还有一个好处是软件订阅容易对客户进行分级，针对用户定制功能， 拓展更大的用户市场， 免费版用来拉升客户数量，培养用户习惯。 企业版用来拉升营收. 更容易形成护城河。
从客户端安装的一锤子买卖, 到paas, saas类的长期订阅, 除了买卖形态上的差别, 另一个重要的差别是原来客户自己提供硬件, 现在云端提供硬件.
硬件成本就需要软件厂商扛, 特别是数据库, 数据库可以多个客户共享, 也可以按客户每个客户一个. 显然多个客户共享(数据隔离)的性价比可以更高, 从而降低软件企业的成本.
那么一个数据库需要提供给多家企业使用, 通过schema或者database来隔离客户数据, 一个database里面有多个schema或者多个database, 会给数据库带来什么挑战呢?
假设一个数据库里面存放1万个schema, 每个schema 2000张表, 5000个索引, 那么至少有7000万个对象.
挑战
1、连接数可能会很多, 特别是高峰期, 使用的企业多.
如果使用database模式(每个企业一个database), 连接不能跨database复用, 连接数的需求会更多.
使用schema模式(每个企业一个schema), 并且使用同一个user连接数据库的话, 连接可以跨企业复用, 需要的连接比database模式会少很多.
建议: schema模式, 同一个用户. 不同业务可以使用不同用户. 同一业务建议同一用户.
2、OOM问题, 因为连接多, 每个连接访问的对象多(例如同一个用户访问了很多企业的表, 每个表的结构、索引等都要存储在这个连接的本地内存中), 会导致连接的本地内存特别大.
当用户使用了长连接时, 内存就会越来越大.
建议: 降低总连接数(特别是微服务化场景, 每个服务都配置了很大的max connections, 雪崩时可能打爆数据库连接, 导致oom和连接爆满的问题).
建议: 配置连接池的连接生命周期, 一个连接可以存活的最大时长, 超过就自动释放(从而降低每个连接不断暴涨内存的情况).
建议: 配置连接池的连接idle超时, idle超过一定时间后, 自动释放, 好处同上.
建议: 使用huge page, 减少page table的使用量.
建议: 内核层面支持元数据(表结构、索引结构等)的global cache功能, 避免每个连接都需要缓存一份访问过的元数据的情况.
3、雪崩, 当有业务bug, 导致了一些慢查询, 高峰期会导致连锁反映, 越慢, 越开更多连接, 最后导致雪崩.
建议: 前端交互避免重复点击, 重复请求.
建议: 配置sql超时, 防止雪崩.
建议: 请求排队, 业务降级, 丢弃请求, 确保部分客户请求正常.
4、大小复杂请求混合干扰 ,
建议: 增加只读实例, 分担压力, 复杂请求(rt要求不高的)可以使用专门的只读实例.
5、数据膨胀, 在数据库存在超长事务, 同时有大量更新、删除操作时, 可能导致事务过程中产生的垃圾无法及时回收, 最后可能引起膨胀
建议: 避免长事务, 注意检查膨胀情况, 使用pg_repack缩小膨胀.
6、不同的客户相互干扰
建议: 内核层面支持多租户的功能, 包括: 隔离、流量控制、资源控制
PostgreSQL 许愿链接
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
9.9元购买3个月阿里云RDS PostgreSQL实例
PostgreSQL 解决方案集合
德哥 / digoal's github - 公益是一辈子的事.
