作者
digoal
日期
2022-01-10
标签
PostgreSQL , PolarDB
懂PostgreSQL, 学PolarDB不难, 就好像有九阳神功护体, 可以快速融会贯通.
对于DBA只要学会PolarDB精髓即可.
对于开发者来说不需要学习, 使用PolarDB和PostgreSQL一样.
为什么增加只读实例不能提高单条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
解释:
- 参考本文内容