吐槽(鞭策)PG以来我掉了“一半流量”!老外听不得忠言逆耳吗? (本期抽奖-掌上游戏机)
文中参考文档点击阅读原文打开, 同时推荐2个学习环境:
1、懒人Docker镜像, 已打包200+插件:《最好的PostgreSQL学习镜像》
2、有web浏览器就能用的云起实验室: 《免费体验PolarDB开源数据库》
3、PolarDB开源数据库内核、最佳实践等学习图谱: https://www.aliyun.com/database/openpolardb/activity
自从开始吐槽(鞭策)PG, Github掉了一半的流量啊, 老外听不进去忠言逆耳吗?我这完全是为用户们着想, 想让PG变得更好才吐槽(鞭策)瑟, 我这真爱!
难道只能说: PG好PG妙PG呱呱叫? Tom lane棒棒哒?
国内公众号的粉丝们请在公众号留言评评理吧. 除了持续写各种干货内容, 继续给粉丝们薅各种小奖品, 么么哒.
掉粉也要继续吐槽(鞭策)!
第14期吐槽:只读实例是孤岛
1、产品的问题点
只读实例是独立的孤岛实例, 不能联合起来完成同一个任务(例如一个大的SQL请求, 创建索引, JOIN等)
2、问题点背后涉及的技术原理
业界有两种使用只读实例的方法
每个只读实例有独立的URL, 应用程序创建多个数据源(每个数据源对应1个只读实例), 应用程序自己控制将SQL请求发给哪个数据源.
使用读写分离的中间件, 应用只需要连接1个地址(中间件地址), 中间件解析SQL, 将SQL路由到RW或RO实例.
3、这个问题将影响哪些行业以及业务场景
想想人类的祖先智人为什么能干掉脑容量更大的尼安德特人? 社交能力. 即大群体能力对抗小群体(邓巴给出的150人强社交上限)的能力. 孤立的只读实例 vs MPP 哪个强?
既有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 特性解读与体验》在github阅读原文
本期彩蛋-KubeBlocks定制掌上游戏机
感谢 KubeBlocks 社区赞助本期周边礼品。KubeBlocks 是开源数据库管理控制面，支持在 K8s 上运行和管理数据库、消息队列以及其他类型的数据基础设施。KubeBlocks 本身也是个非常优秀的基于 K8s 的 PostgreSQL operator，欢迎大家试用产品。以下是他们家的公众号。
抽奖方法: 转发本文(), 同时关注以上KubeBlocks公众号(云猿生聊技术)回复抽奖，近几天公布获奖名单.
持续招商为《PostgreSQL码农集散地》粉丝们谋福利。“阿里云开源PolarDB”您要不赞助点啥，很多老铁看上了PolarDB文化衫和双肩包。第1次Q, Q到赞助为止! 老铁们留言区回复顶上去, 看看飞刀的开源团队啥时候能赞助!
文章中的参考文档请点击阅读原文获得.
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号: