digoal
2021-09-02
PostgreSQL , 只读实例 , 孤岛
1、产品的问题点
- 只读实例是独立的孤岛实例, 不能联合起来完成同一个任务(例如一个大的SQL请求, 创建索引, JOIN等)
2、问题点背后涉及的技术原理
- 业界有两种使用只读实例的方法
- 每个只读实例有独立的URL, 应用程序创建多个数据源(每个数据源对应1个只读实例), 应用程序自己控制将SQL请求发给哪个数据源.
- 使用读写分离的中间件, 应用只需要连接1个地址(中间件地址), 中间件解析SQL, 将SQL路由到RW或RO实例.
3、这个问题将影响哪些行业以及业务场景
- 人类的祖先智人为什么能干掉脑容量更大的尼安德特人? 社交能力. 即大群体能力对抗小群体(150人)的能力.
- 既有TP(单机为主, 灵活, 低延迟高并发小事务, 全局一致性等需求), 又有复杂分析的业务(OLAP, 多机并行计算为主).
- 很多企业会在业务库上跑日报、周报、月报的需求, 通常是半夜业务低峰跑报表, 白天跑高并发业务的场景.
4、会导致什么问题?
- 一般来说读写分离可以解决读请求能力扩展的问题, 但是对于复杂的分析, 不行.
- 单一实例的CPU核数有限, 实例内并行计算的话很容易达到单机天花板.
5、业务上应该如何避免这个坑
- 复杂SQL使用其他产品, 将数据同步到专门的OLAP数据库进行处理.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 额外的OLAP数据库, 增加了成本.
- 同步有延迟问题, 导致报表数据不及时.
- 跨产品同步还可能引入类型不兼容、编码不兼容、丢数据等难缠的问题, 导致报表数据不准确.
- 增加了同步带来的研发、软件、维护开销.
- 增加了管理复杂度.
7、数据库未来产品迭代如何修复这个坑
- 内核改进: 将多个RO节点联合起来执行同一个任务, 例如一个非常复杂的SQL, JOIN, 创建索引等. 类似于Greenplum的MPP处理能力. 可以线性提升性能.
- 或者可以通过PolarDB for PG的开源版本体验一下跨节点并行的功能(ePQ) 参考文章: 《开源PolarDB|PostgreSQL 应用开发者&DBA 公开课 - 5.5 PolarDB开源版本必学特性 - PolarDB 特性解读与体验》
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
