关于数据库:详解SQL优化必备并行执行框架和执行计划

摘要：在关系型数据库中，优化器是数据库的外围组件之一，因为一些列因素都会影响语句的执行，优化器综合衡量各个因素，在泛滥的执行打算中抉择认为是最佳的执行打算。

本文分享自华为云社区《华为云GaussDB(for openGauss)专场直播第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语句，点查场景）。
原理：CN间接下发语句QPBE报文到对应DN，这样的做的益处是，执行效率高，线性扩大比好。

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节点间的流动；执行引擎是一个分布式并行执行框架，反对节点间并行和节点内并行能力，充分利用以后多核特点，通过并发执行，进步零碎吞吐量，具备大数据下高性能查问能力。

Ps：更多精彩内容，请点击回播链接进行观看：https://bbs.huaweicloud.com/l...

点击关注，第一工夫理解华为云陈腐技术~