详解GaussDB(DWS)中的行执行引擎
本文分享自华为云社区《GaussDB(DWS)行执行引擎详解》,作者:yd_227398895。
1.前言
GaussDB(DWS)包含三大引擎,一是SQL执行引擎,用来解析用户输入的SQL语句,生成执行计划,供执行引擎来执行;二是执行引擎,其中包含了行执行引擎和列执行引擎,执行引擎即查询的执行者,位于优化器和存储引擎之间,负责将数据从存储引擎中读取出来,并根据计划将数据处理加工后返回给客户端,执行引擎的目标是为了更好地利用计算资源,更快地完成计算。三是存储引擎,决定了数据库数据的存取方式,直接影响了数据库的读写性能。
其中行执行引擎应用于行存表中,传统的OLTP(OnLine Transaction Processsing 联机事务处理)场景与功能、业务强相关,数据需要进行频繁的增删改查,这时比较适合使用行存储式。行存储的优势主要有两个方面:首先是点查性能好,在点查场景下可以直接索引到某行数据的元组位置;其次就是更新效率高,行存储在实时并发入库,并发更新方面依然有着比较大的优势。行执行引擎的关键就是:一次处理一行数据,即一tuple,适合数据频繁更新,增删改操作多,且查询结果涉及表的多列的场景。
2.行执行引擎组成
2.1 行执行框架
行执行引擎的执行基本单位是算子,查询计划是以树的形式存在的,算子是执行树上的每个节点。每个算子需要经历初始化,执行,清理的生命周期,执行时包括递归遍历计划树的各个节点,从计划树根节点开始,递归到叶节点来获取一个tuple,经过逐层节点算子的处理,返回一个结果tuple,直到再无tuple。整体算子的执行采用Piepline模式,一次一tuple,控制流从上到下,数据流由下到上,图示实线为控制流,虚线为数据流,使用上层来驱动下层。
2.2 行执行引擎算子
算子总共分为四类,扫描算子,控制算子,物化算子,连接算子等。对于分布式系统而言,还包括着stream算子等。
2.2.1 扫描算子
扫描算子用来扫描表中的数据,每次获取一条元组作为上层节点的输入, 存在于查询计划树的叶子节点,它不仅可以扫描表,还可以扫描函数的结果集、链表结构、子查询结果集。一些比较常见的扫描算子如表所示。
2.2.2 连接算子
连接算子对应了关系代数中的连接操作,以表 t1 join t2 为例,主要的集中连接类型如下:inner join、left join、right join、full join、semi join、 anti join,其实现方式包括Nestloop、HashJoin、MergeJoin;
三类连接算子的实现方式特点:
2.2.3 物化算子
物化算子是一类可缓存元组的节点。在执行过程中,很多扩展的物理操作符需要首先获取所有的元组才能进行操作(例如聚集函数操作、没有索引辅助的排序等),这是要用物化算子将元组缓存起来;
2.2.4 控制算子
控制算子是一类用于处理特殊情况的节点,用于实现特殊的执行流程。
2.2.5 其他算子
其他算子包括Stream算子,以及RemoteQuery等算子
Stream算子主要有三种类型:Gather stream、Broadcast stream、Redistribute stream
Gather算子: 每个源结点都将其数据发送给目标结点进行汇聚
Broadcast stream: 由一个源节点将其数据发给N个目标节点进行运算
Redistrubute stream: 每个源节点将其数据根据连接条件计算Hash值,根据重新计算的Hash值进行分布,发给对应的目标节点
3. 执行框架总结
本文主要讲解了如下几个方面:
- 大致介绍了GaussDB(DWS)行执行引擎在整个数据库系统中的位置;
- 介绍了行执行引擎的框架;
- 最后介绍了一些常见和常用的行执行引擎相关的算子。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
克服 Prometheus 单值数据模型的局限性:GreptimeDB 的新路径
引言 Prometheus 已经成为监控和报警生态系统的基石,在高效、直接地处理实时指标(Metric)方面有着强大的表现。Prometheus 的核心是一个包含单个值和一系列标签的数据模型。这种设计在提升简单性和适应性的同时,也带来了一些挑战,包括影响数据收集效率、分析深度和查询能力。 本文探讨了 Prometheus 单值数据模型的固有限制,GreptimeDB 如何成为一个解决这些问题的创新方案,并结合若干实例说明其中的差别。 单值数据模型的挑战 1. 数据收集中的冗余标签传输 Prometheus 的数据模型要求测度(Measurement)上报时总要携带同一来源的所有标签,当测量需求涉及多个值时,意味着重复传输这些标签,从而导致数据收集和存储效率低下。虽然 Prometheus 的存储引擎优化了数据存储,但标签信息冗余问题仍是一个重大的开销。 示例:在从服务器集群收集 CPU 使用率、内存使用量和磁盘 I/O 等多个指标的场景下,每个指标都携带相同的标签,如 cluster_name、region、instance 和 server_type,这就导致了不必要的重复。 示例图...
- 下一篇
带你熟悉CCE集群增强型CPU管理策略enhanced-static
本文分享自华为云社区《华为云CCE集群增强型CPU管理策略enhanced-static》,作者: 可以交个朋友。 背景 开源Kubernetes默认提供的CPU管理策略有none和static两种: none: 不开启CPU管理策略,默认值。 static:开启静态绑核的CPU管理策略,允许为节点上具有某些资源特征的 Pod(Guaranteed pod)赋予CPU亲和性和独占性。 华为云cce集群提供增强型CPU管理策略(enhanced-static),兼容静态绑核CPU管理策略的基础上,新增一种符合某些资源特征的Burstable Pod(要求CPU的requests和limits参数值都是正整数)优先使用某些CPU的能力,以减少应用在多个CPU间频繁切换带来的影响。该特性是基于Huawei Cloud EulerOS 2.0内核中优化了CPU调度能力实现的。在Pod容器优先使用的CPU利用率超过85%时,会自动分配到其他利用率较低的CPU上,进而保障了应用的响应能力。 约束与限制 使用该特性,需同时满足以下条件: 集群版本为v1.23及以上。 节点操作系统为Huawei Cl...
相关文章
文章评论
共有0条评论来说两句吧...