ReaderMX.
PostgreSQL码农集散地

猪队友居然是领导，请问怎么办？

Pdigoal约 4 分钟

文章开始前推荐2个学习环境:

1、欢迎使用镜像快速体验PostgreSQL/DuckDB强大功能: 《最好的PostgreSQL学习镜像 》

2、欢迎使用云起实验室: 《免费体验PolarDB开源数据库 》 3、PolarDB开源数据库内核、应用等学习图谱:  https://www.aliyun.com/database/openpolardb/activity

欢迎关注：

昨天刚得知“ 团队来了猪队友，请问怎么办？ ”

今天发现猪队友居然是领导，请问怎么？

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节点（master是那个猪队友吗？）

  • 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

解释:

  • 参考本文内容 


欢迎关注我的github (https://github.com/digoal/blog) , 学习数据库不迷路.  近期正在写公开课材料, 未来将通过视频号推出, 欢迎关注视频号:
文章中的参考文档请点击阅读原文获得. 

KEEP THE THREAD GOING

更多来源文章