第42期吐槽:PG 读写分离不友好
文中参考文档点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》
3、PolarDB开源数据库内核、最佳实践等学习图谱: https://www.aliyun.com/database/openpolardb/activity
第42期吐槽:PG 读写分离不友好
1、产品的问题点
PostgreSQL 读写分离非常不友好, 没有内置的对业务完全透明的读写分离功能.
2、问题点背后涉及的技术原理
为什么要读写分离?
读请求占比较高, 并且单个实例无法支撑业务的请求吞吐时, 通过增加只读实例, 将读请求分流到只读实例以满足业务需求.
什么是业务透明的读写分离?
应用发起SQL, 数据库根据SQL是否会对数据库产生写操作自动分发到主库或只读库.
3、这个问题将影响哪些行业以及业务场景
读占比和吞吐较大的业务
读请求相对来说比较复杂, 需要耗费较大IO和CPU计算, 怕影响主实例(RW实例)的业务
4、会导致什么问题?
没有读写分离功能, 业务必须连接多个数据源, 在代码中自己判断, 将读、写请求发送到不同的数据源. 增加了程序设计复杂度.
而且只读和读写节点可能发生角色切换, 代码里面不仅要判断SQL是否要路由到RO, 还要判断当前数据源到底是RO还是RW角色.
5、业务上应该如何避免这个坑
使用 pgpool-II 中间件
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
通过pgpool-II连接数据库, 性能存在巨大的损耗
多一跳延迟增加、
pgpool-II自身的损耗
高并发小事务损耗50%以上 (tpc-b测试样例)
功能不完备, 例如:
函数内的query不能再路由
自定义函数需要配置黑白名单, 否则统一路由到rw节点. (函数白名单、黑名单需要手工维护)
增加了1个组件增加了1份故障点
增加了配置复杂度, 例如
心跳检测配置
从库与主库延迟多少后自动踢出只读实例列表
恢复后是否自动加入只读实例列表
连接池个数, 空闲自动释放时间, 生命周期等
7、数据库未来产品迭代如何修复这个坑
希望内核层面支持对业务透明的自动读写分离
不管是rw还是ro节点, 平等对待所有连接. 应用可以使用驱动来load balance连接
从库与主库延迟自动踢出只读实例列表, 恢复后是否自动加入只读实例列表
解析SQL, 生成执行计划, 自动路由plan execute
根据SQL的代价来决定是否要将sql分发给只读实例. 用户可以设置代价阈值.
不依赖外部产品
本期彩蛋-招商中,有需要的小伙伴可联系嵌入...
文章中的参考文档请点击阅读原文获得.
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: