摘要: 在关系型数据库中,优化器是数据库的外围组件之一,因为一些列因素都会影响语句的执行,优化器综合衡量各个因素,在泛滥的执行打算中抉择认为是最佳的执行打算。
本文分享自华为云社区《华为云 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…
点击关注,第一工夫理解华为云陈腐技术~