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 之间进行数据交互。

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 节点间的流动；执行引擎是一个分布式并行执行框架，支持节点间并行和节点内并行能力，充分利用当前多核特点，通过并发执行，提高系统吞吐量，具备大数据下高性能查询能力。

内容出处：，

声明：本网站所收集的部分公开资料来源于互联网，转载的目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。如果您发现网站上有侵犯您的知识产权的作品，请与我们取得联系，我们会及时修改或删除。文章链接：http://www.yixao.com/tech/25430.html