作者
digoal
日期
2022-01-11
标签
PostgreSQL , PolarDB
懂PostgreSQL, 学PolarDB不难, 就好像有九阳神功护体, 可以快速融会贯通.
对于DBA只要学会PolarDB精髓即可.
对于开发者来说不需要学习, 使用PolarDB和PostgreSQL一样.
Coordinator也会有瓶颈?
https://www.bilibili.com/video/BV1pR4y1j7uG/
在shared nothing架构的产品(例如greenplum, pg-xc, citus)中, 需要协调节点(CN、coordinator node)来对接客户端的请求(客户端并不直接与DN节点对接), 并生成分布式执行计划, 下发给DN, 再汇总结果, 有些时候可能还需要做汇总结果排序再返回.
看起来coordinator比较轻松, 为什么会给整个系统带来瓶颈呢?
- 注意: 瓶颈也许可能不是Coordinator本身, 而是因为引入Coordinator的架构带来了整个系统的瓶颈.
社区版本:
Greenplum:
- master(类似coordinator的角色) 单点瓶颈, 只有1个Coordinator节点
- SQL 优化器瓶颈: 复杂SQL, 并发较高时会把master cpu打爆
- 接收从所有segment节点过来的数据, 吞吐瓶颈
- 数据入库的吞吐瓶颈, (通过gpfdist服务解决, 绕过master)
- SQL 排序, 需要在master节点merge sort, 增加master的负担
- 最后阶段的聚合, 可能要在master完成, 增加master负担
- 有了master增加了一跳, 任何查询都要经过master到达segment, 增加了一定的SQL RT.
PS: 不知道greenplum哪个版本会增加多master的功能.
PG-XC, Citus:
- 支持多个Coordinator节点, 但是多个Coordinator的元数据需要同步, 内部将DDL发到主coordinator执行, 然后采用2PC同步DDL到各个Coordinator节点.
- 多个coordinator节点要获取global sequence协调起来也比较复杂. 使用GTM则会成为生成瓶颈.
- https://www.postgres-xl.org/documentation/pg-xc-specifics.html
- sequence_range (integer)
- This parameter is used to get several sequence values at once from GTM. This greatly speeds up COPY and INSERT SELECT operations where the target table uses sequences. Postgres-XL will not use this entire amount at once, but will increase the request size over time if many requests are done in a short time frame in the same session. After a short time without any sequence requests, decreases back down to 1. Note that any settings here are overriden if the CACHE clause was used in CREATE SEQUENCE or ALTER SEQUENCE.
- 分布式SQL, 下发给DN的是SQL而非plan tree级别(greenplum下发的是plan tree), 增加了一次SQL解析的消耗.
- https://docs.citusdata.com/en/v6.2/performance/query_processing.html#distributed-query-executor
- 任务模型适合复杂select SQL(涉及节点或shards多的请求), 实时模型适合dml (涉及节点或shards不多的请求).
- 其他瓶颈与gpdb类似
- SQL 排序, 需要在Coordinator节点merge sort, 增加master的负担
- 最后阶段的聚合, 可能要在Coordinator完成, 增加Coordinator负担
- 有了Coordinator增加了一跳, 任何查询都要经过Coordinator到达segment, 增加了一定的SQL RT.
PolarDB:
POLARDB 共享存储, 任何节点都可以读取catalog, 任何节点(包含所有的RW和RO节点)都可以是Coordinator角色.
- 不增加跳数, 没有增加SQL RT
- 不存在Coordinator单点瓶颈
- 不需要同步catalog
- 与greenplum类似, 对于分布式执行计划改造自gpdb的orca优化器, 下发plan tree, 而不是sql, 没有二次SQL解析的开销.
本期问题1:
coordinator 可能会引入哪些瓶颈?
- a. greenplum master(类似coordinator的角色) 单点瓶颈
- b. SQL 优化器瓶颈: 复杂SQL, 并发较高时会把master cpu打爆
- c. 接收从所有segment节点过来的数据, 可能遇到吞吐瓶颈
- d. SQL 排序, 需要在master节点merge sort, 增加master的负担
- e. 最后阶段的聚合, 可能要在master完成, 增加master负担
- f. 有了master增加了一跳, 任何查询都要经过master到达segment, 增加了一定的SQL RT.
- g. 需要从DN(segment) 节点获取catalog, 增加了SQL RT
答案:
- abcdef
解释:
- 参考本文内容
本期问题2:
关于 POLARDB 的coordinator功能描述正确的是?
- a. polardb coordinator节点存在单点瓶颈
- b. polardb coordinator节点需要解析SQL请求
- c. polardb 需要单独建立coordinator节点
- d. polardb 的RW和RO实例都可以承担coordinator节点的功能
- e. polardb 的coordinator节点需要独立存储和维护catalog元数据
答案:
- bd
解释:
- 参考本文内容
期望 PostgreSQL 增加什么功能?
PolarDB for PostgreSQL云原生分布式开源数据库
PostgreSQL 解决方案集合
德哥 / digoal's github - 公益是一辈子的事.
