阅读 538

详解 SQL 优化必备:并行执行框架和执行计划

摘要:在关系型数据库中,优化器是数据库的核心组件之一,由于一系列因素都会影响语句的执行,优化器综合权衡各个因素,在众多的执行计划中选择认为是最佳的执行计划。

本文分享自华为云社区《华为云GaussDB(foropenGauss)专场直播第5期:SQL优化解读》,原文作者:心机胖。

1、前言

在关系型数据库中,优化器是数据库的核心组件之一,由于一系列因素都会影响语句的执行,优化器综合权衡各个因素,在众多的执行计划中选择认为是最佳的执行计划。随着大数据时代的到来,像电商、游戏、电信等行业都大规模的应用,单一数据库节点是难以应对数据规模的不断增长并确保性能的需要,业务面临“存不下、算得慢、算不准”的问题。而 GaussDB(for openGauss)采用了可横向扩展的分布式架构,可以很好满足大规模海量数据的存储和计算的需求,其通过目标 SQL 执行计划的 CBO 成本,从目标 SQL 的诸多执行计划中选取成本值最小的执行路径为其执行计划,各执行路径的成本值是根据目标 SQL 中涉及到的表、索引、列等相关对象的统计信息计算出来的,实际反应执行目标 SQL 所要消耗的 I/O、CPU 和网络资源的一个估计值。

  • I/O 资源:把表的数据从磁盘读入内存时所需代价
  • CPU 资源:处理内存中表的数据所需的代价
  • 网络资源:需要 DN 间数据交互的分布式 SQL,在实际执行时所需要的数据并不在本地 DN 中(需要从其他 DN 中取数据),便会将网络资源消耗折算成对等的 I/O 资源消耗再进行估算。

本文结合第 5 场直播内容从分布式并行执行框架、分布式执行计划等方面进行介绍。

2、分布式并行执行框架

2.1 执行器:PIPELINE 模型

GaussDB(for openGauss)的执行器特点是:按照查询计划树从底往上执行,基于火山模型执行,即每个节点执行返回一行记录给父节点。

火山模型的最大优点就是可以按需请求,每次只取出一条元组,在处理本条元组后,系统将会取出下一条满足条件的元组,直到取出所有满足条件的元组为止。从这种方式的运行机制可以看出,其每次执行时对于系统资源的需求都非常小。

2.2 高性能分布式查询引擎

GaussDB(for openGauss)充分利用当前多核特点,通过多线程并发执行,提高系统吞吐量。众所周知,在传统的分布式 MPP 数据库中,因数据的重分布,也就是数据 shuffle 的代价非常昂贵,从而限制了用户使用场景范围。

GaussDB(for openGauss)能充分利用当前多核特点,采用并行执行机制,在 SQL 执行优化方面有多年的沉淀,并提供了三种 stream 流(广播流、聚合流和重分布流)来降低数据在 DN 节点间的流动,突破了传统分布式 MPP 数据库因为数据 shuffle 代价高昂带来的用户使用场景限制,即使是复杂的 SQL、事务分析混合(HTAP)场景也能得到最佳执行。

GaussDB(for openGauss)的大致执行过程:

  • 业务应用下发 SQL 给 Coordinator ,SQL 可以包含对数据的 CRUD 操作;
  • Coordinator 利用数据库的优化器生成执行计划,每个 DN 会按照执行计划的要求去处理数据;
  • 数据基于一致性 Hash 算法分布在每个 DN,因此 DN 在处理数据的过程中,可能需要从其他 DN 获取数据,GaussDB 提供三种 stream 流(广播流、聚合流和重分布流)实现数据在 DN 间的流动,使得 join 无需抽取到 CN 执行;
  • DN 将结果集返回给 Coordinate 进行汇总;
  • Coordinator 将汇总后的结果返回给业务应用。

3、分布式执行计划

CN 根据表的分布列信息和关联列信息进行判定,SQL 语句是否可以直接在各个 DN 上执行而且不需要数据交流,如果是,CN 采用 LIGHT_QUERY 或 FQS_QUERY 流程,保持了事不关己的态度,你发给我什么我就下发什么,直接将整个 query 命令下发给 DN 执行,执行完成后直接输出;如果需要在各个 DN 之间进行数据交互,则会选择使用 stream 算子;如果发现无法使用 stream 算子时,就回到了原始的 PGXC 流程。

3.1 LIGHT_QUERY

- 场景:语句可以直接在一个 DN 执行(单 shard 语句,点查场景)。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1);
create table t2 ( col1 int, col2 varchar ) distribute by hash(col1);
复制代码

3.2 FQS_QUERY

- 场景:当语句可以完全下推到多个 DN 上执行,且 DN 之间不需要数据交互时。

- 原理:CN 不通过优化器,直接生成 RemoteQuery 计划,走执行器逻辑下发到 DN,各 DN 根据下推语句生成执行计划并进行执行,执行结果在 CN 上进行汇总。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1);
create table t2 ( col1 int, col2 varchar ) distribute by hash(col1);
复制代码

LIGHT_QUERY 和 FQS_QUERY 的最大异同点在于,虽然 CN 都是经过判定后直接把收到的 query 下发给 DN 进行处理,但是 LIGHT_QUERY 只涉及到单 DN 进行操作,而 FQS_QUERY 涉及到多个 DN 分别进行操作,它们都不会涉及到 DN 间的数据交互。

3.3 STREAM GATHER

- 场景:需要各 DN 之间进行数据交互。

- 原理:CN 根据原语句通过优化器生成带 stream 算子的执行计划,下发给 DN 进行执行,DN 执行过程中存在数据交互(stream 节点),stream 算子在 DN 之间建立连接进行数据交互,CN 汇总执行结果并承担大部分计算。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1);
create table t2 ( col1 int, col2 varchar ) distribute by hash(col2);
复制代码

3.4 STREAM REDISTRIBUTE

- 场景:需要各 DN 之间进行数据交互。

- 原理:CN 根据原语句通过优化器生成带 stream 算子的执行计划,下发给 DN 进行执行,各 DN 执行过程中存在数据交互(stream 节点),stream 算子在 DN 之间建立连接进行数据交互,CN 汇总执行结果并承担大部分计算。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1);
create table t2 ( col1 int, col2 varchar ) distribute by hash(col2);
复制代码

3.5 STREAM BROADCAST

- 场景:需要各 DN 之间进行数据交互。

- 原理:CN 根据原语句通过优化器生成带 stream 算子的执行计划,下发给 DN 进行执行,各 DN 执行过程中存在数据交互(stream 节点),stream 算子在 DN 之间建立连接进行数据交互,CN 汇总执行结果并承担大部分计算。

create table t1 ( col1 int, col2 varchar ) distribute by hash(col1);
create table t2 ( col1 int, col2 varchar ) distribute by hash(col2);
复制代码

使用 REDISTRIBUTE 算子时,数据进行重分布可以充分利用多个节点的算力,而 BROADCAST 算子主要用于 stream 的子计划产生的数据量较少的情况,此时 BROADCAST 的代价较少。

3.6 PGXC

- 场景:不能满足前面处理方式的极端场景,性能非常差。

- 原理:CN 通过优化器把原语句中的部分语句生成 RemoteQuery 计划,把每个 RemoteQuery 下发到 DN,DN 执行后把中间结果数据发送给 CN,CN 收集后进行剩余执行计划的执行计算,CN 承担了大部分计算。

总结

综上所述,GaussDB(for openGauss)作为自主研发的新一代金融级分布式关系型数据库,采用可横向扩展的分布式架构,通过 SQL 优化器生成分布式算子以及分布式执行计划,提供了三种 stream 流(广播流、聚合流和重分布流)来降低数据在 DN 节点间的流动;执行引擎是一个分布式并行执行框架,支持节点间并行和节点内并行能力,充分利用当前多核特点,通过并发执行,提高系统吞吐量,具备大数据下高性能查询能力。

更多精彩内容,请点击回播链接进行观看:

bbs.huaweicloud.com/live/cloud_…

点击关注,第一时间了解华为云新鲜技术~

文章分类
后端
文章标签