为什么增加只读实例不能提高单条SQL的执行速度?
文章开始前推荐2个学习环境:
1、欢迎使用镜像快速体验PostgreSQL/DuckDB强大功能:《最好的PostgreSQL学习镜像》
2、欢迎使用云起实验室: 《免费体验PolarDB开源数据库》
3、PolarDB开源数据库内核、应用等学习图谱: https://www.aliyun.com/database/openpolardb/activity
为什么增加只读实例不能提高单条SQL的执行速度?
https://www.bilibili.com/video/BV17b4y1n7Yd/
社区版本:
社区版本的主实例、只读实例的每个实例是独立的个体, 有自己的计算和独立的存储, 无法合作完成同一个任务, 包括执行同一条SQL, 因此也无法加速一条SQL的执行.
PG社区版本通过内在的并行计算(单个实例内并行)来加速一条SQL的执行.
PG的衍生版本Greenplum通过sharding+MPP的方式, 将数据打散到多个计算节点, 使用多个计算节点并行加速一条SQL的执行.
缺点: 引入了分布式事务管理、全局序列、跨节点数据重分布等额外的开销, 同时导致触发器、存储过程或函数也必须是兼容分布式架构的, 或者无法支持某些单节点已有的功能. 对OLTP业务场景(高并发小事务)不友好.
PolarDB:
采用计算存储分离架构, 所有的计算节点(包括只读实例与主实例)共享同一份存储, 有了共享存储所以打破了只读实例与主实例的二元对立, 形成一个统一体(通常称之为cluster).
PolarDB通过改进SQL优化器, 实现跨节点的同一条SQL(数据扫描、运算符计算)的任务分配(实际上是改进并优化了Greenplum的MPP SQL优化器, 适配共享存储架构), 每个节点只需要扫描并计算一部分数据, 所以PolarDB可以通过增加只读实例提高单条SQL执行速度.
后面专门讲一期PolarDB的动态并行优化: 使得PolarDB的计算节点可以在负载不均匀、计算能力不均匀的情况下实现“增加计算节点并行度”带来“线性的性能提升”.
本期问题1:
为什么PostgreSQL社区版本不能增加只读实例来提升一条SQL的执行速度?
a. PG社区版本增加只读实例, 通过PG-pool中间件读写分离功能可以提高SQL吞吐量
b. PG社区版本的只读实例是孤立的个体, 无法协调并行执行同一条SQL
c. PG社区版本的只读实例接收WAL有延迟
d. PG社区版本的只读实例回放WAL有延迟
答案:
b
解释:
参考本文内容
本期问题2:
为什么PolarDB可以通过增加只读实例来提升一条SQL的执行速度?
a. PolarDB 将一条SQL切分为不同的部分, 通过外部表和分区接口在多个节点之中实现并行计算
b. PolarDB 会将SQL分发到多个节点执行, 每个节点执行同样的SQL, 扫描全部的数据, 最快执行完成的节点结果返回给客户
c. PolarDB 采用计算存储分离架构, 通过改进SQL优化器, 实现跨节点的同一条SQL(数据扫描、运算符计算)的任务分配, 加速单条SQL的执行.
d. PolarDB 将SQL拆分成几段, 每一段交给一个节点执行, 例如有的节点执行数据扫描, 有的执行条件过滤, 有的执行JOIN, 有的执行聚合, 有的执行排序.
答案:
c
解释:
参考本文内容
本期问题3:
PolarDB 拥有跨节点并行计算功能后, 适合哪些业务场景?
a. 类似redis的缓存场景
b. 类似sqlite的嵌入式数据库场景
c. 存粹的分析业务场景.
d. HTAP场景, 既有高并发小事务又有大量计算的业务场景, 例如业务库的异步准实时报表计算、准实时的流计算等.
答案:
cd
解释:
参考本文内容
欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.
近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号:
文章中的参考文档请点击阅读原文获得.