GaussDB关键技术原理:高性能(三)

GaussDB关键技术原理:高性能(二)从查询处理综述对GaussDB的高性能技术进行了解读,本篇将从查询重写RBO、物理优化CBO、分布式优化器、布式执行框架、轻量全局事务管理GTM-lite等五方面对高性能关键技术进行分享。

目录

3 高性能关键技术

3.1 查询重写RBO

3.2 物理优化CBO

3.3 分布式优化器

3.4 分布式执行框架

3.5 轻量全局事务管理GTM-lite


3 高性能关键技术

内容概要:本章节介绍GaussDB中实现的高性能关键技术,内容涉及优化器、执行器、分布式数据库、存储引擎等多个方面。

目的:通过对GaussDB数据库关键高性能技术的学习,能够让读者更加清晰的理解数据库内核哪些优化是性能关键点同时也为类似的应用系统实现提供方法论和最佳实践。

3.1 查询重写RBO

在数据库里RBO基于规则的优化一般指查询重写技术,按照一系列关系代数表达式的等价规则,对查询的关系代数表达式进行等价转换,从逻辑上减少执行的总量从而提高查询执行效率,例如,通过条件的推导得出非必要的表扫描、避免非必要的计算表示等。

查询重写RBO优化是非常重要的一种逻辑优化手段,通常应用和实施在查询优化过程的前端,将一些肯定能够优化的场景进行优化,RBO优化结束后进行物理优化,以下以常用的几种重写优化进行介绍:

Example 1:谓词化简优化Predicate Simplification

使用谓词查询条件的可满足性Satisfiability (SAT)&可传递性Transitive Closure(TC)对查询进行化简,a.w.k SAT-TC,假设有t1,t2表,他们的定义分别为:T1(c1 int, c2 int);,T2(c1 int, c2 int check (c2 < 30));,则原查询:

SELECT t1.c1,t1.c2, t2.c1, t2.c2
FROM t1 JOIN t2 ON t1.c2 = t2.c2
WHERE t1.c2 > 20

可优化为:

SELECT dt1.c1,dt1.c2, dt2.c1, dt2.c2
FROM (select c1,c2 from t1 where t1.c2 between 20 and 30) as dt1,
(select c1,c2 from t2 where t2.c2 between 20 and 30) as dt2
WHERE dt1.c2 = dt2.c2;

说明:通过谓词逻辑可以发现当前查询中可以一次实施TC->SAT->TC优化策略。

step1: TC优化:内连接关联条件t1.c2 = t2.c2 && t1.c2 > 20可以得出t2.c2 > 20

step2: SAT优化:t2.c2列上创建有check-constraint可以得出t2.c2 BETWEEN 20 AND 30

step3: TC优化:同理得出t1.c2 BETWEEN 20 AND 30

到此t1,t2在关联之前就可以最大限度减小处理的元组数,达到提升性能的目的,以下是其他SATTC例子:

A=B AND A=C --> B=C
A=5 AND A=B --> B=5
A=5 AND A IS NULL --> FALSE
A=5 AND A IS NOT NULL --> A=5
X > 1 AND Y > X --> Y >= 3
X IN (1,2,3) AND Y=X --> Y IN (1,2,3)

Example 2:谓词下推优化Predicate Push Down

将谓词查询条件下沉到中间结果集的最底层提前过滤,可以有效减少读入到内存中数据的数量,减少计算层的代价

优化前:

SELECT MAX(total)
FROM (
SELECT product_key, product_name,
SUM(quantity*amount) AS total
FROM Sales, Product
WHERE sales_product_key=product_key
GROUP BY product_key, product_name
) AS v
WHERE product_key IN (10, 20, 30);

优化后:

SELECT MAX(total)
FROM (
SELECT product_key, product_name,
SUM(quantity*amount) AS total
FROM Sales, Product
WHERE sales_product_key=product_key AND product_key IN (10, 20, 30)
GROUP BY product_key, product_name
) AS v
WHERE product_key IN (10, 20, 30);

说明:

  • 查询在优化前需要事先将中间结果集v计算出。

  • 在计算的过程中需要对sales、product两张表的全量数据进行读取进行,然后对结果集进行Group分组、Aggregation聚合操作,但是最终的结果集只要求输出product_key的值为10,20,30的结果集。

  • 利用谓词下推规则可以让product_key in(10,20,30)过滤操作在Join之前完成,如果查询条件product_key in(10,20,30)的选择率较低则可以减少Join、Aggregation、Group三个操作处理的数据量,从而提升性能。

Example 3:谓词上移优化Predicate Pullup

将谓词查询条件中比较繁重的函数计算放到最后,期望减小繁重计算的次数达到提升性能的目的。

优化前:

SELECT *
FROM t1,
(SELECT * FROM t2
WHERE complex_func(t2.c2) = 3) AS dt(c1,c2,c3)
WHERE t1.c1 = t2.c1 AND t1.c2 > 30

优化后:

SELECT *
FROM t1,
(SELECT * FROM t2) AS dt(c1,c2,c3)
WHERE t1.c1 = t2.c1 AND t1.c2 > 30 AND complex_func(t2.c2) = 3

说明:

  • 原查询“complex_func(t2.c2) = 3”查询条件在子查询中,如果该条件在子查询DT中被计算则会导致t2表中的全量数据被计算开销较大。

  • 通过谓词pullup上移到最外层让t2先和t1做关联和过滤,则能够有效减少complex_func被调用的次数,从而达到性能提升的目的。

查询重写是查询优化器阶主要分类之一,通常可以快速将处理的数据进行成倍数缩减,下图是常见的查询重写分类

3.2 物理优化CBO

在优化器处理完RBO的优化以后,路径的选择往往不能通过实现制定好的规则进行变换,而是需要根据数据的分布(统计信息)情况来对查询执行路径进行评估,从可选的路径中选择一个执行代价最小的路劲进行执行,例如是否选择索引SeqScan vs. IndexScan、选择哪个索引,两表关联选择什么样的连接顺序,选择怎样的具体算法等,因此,可以将物理优化总结为对多个可行的物理执行代价进行评估,选择最优的计划输出到执行器进行执行,例如有以下查询:

select * from t1 join t2 on t1.a=t2.b;

可选择的计划有:

如上图所示,根据T1、T2可访问的执行路径:IndexScan vs. SeqScan,关联算法:HashJoin、MergeJoin、NestLoop;关联内表外表等多个维度的选择,就会生成多达数十种不同的执行计划,由于考虑到T1、T2的表大小,谓词的选择率、是否有索引等因素很难从一个固定的规则里选出一个合理的执行计划,此时需要对T1、T2表的数据特征进行建模,构建代价模型从而选出最优的计划,这个过程按照处理的顺序大体上可以分为:统计信息、行数估算、代价估算、路径搜索、计划生成五个处理步骤:

(1)统计信息,物理优化的依据来源于表信息的统计, 描述基表数据的特征包括唯一值、MCV值等,用于行数估算。

(2)行数估算,代价估算的基础,来源于基表统计信息的推算,估算基表baserel、Join中间结果集joinrel、Aggregation中结果集大小,为代价估算做准备。

(3)代价估算,根据关系的行数,推算出当前算子的执行代价,根据数据量估算不同算子执行代价,各算子代价之和即为计划总代价。

(4)路径搜索,依据若干算子的执行代价对最优路径进行路径搜索,通过求解路径最优算法(e.g. 动态规划、遗传算法)处理连接路径搜索过程,以最小搜索空间找到最优连接路径。

(5)计划生成,将查询的执行路径转换成PlanTree能够输出给执行器做查询执行,在分布式场景下根据数据分布的属性决定Data-Shuffling数据迁移总体方案。

3.3 分布式优化器

分布式数据库场景下表分布在各个节点上,数据的本地性Data Locality是分布式优化器中生成执行计划时重点考虑的因素,基于Share Nothing的分布式数据库中有一个很关键概念就是“移动数据不如移动计算”,之所以有数据本地性就是因为数据在网络中传输会有不小的I/O消耗,网络的overhead通常情况下会大于本地的计算,因此分布式数据库优化的一个重要的原则就是尽量减少这个网络I/O消耗就能够提升效率。例如有以下例子一个聚集查询的例子:

表信息:
- T1: distribute By HASH(c1)
执行查询:
- select sum(c1), c2 from t1 group by c2

由于表T1的分布列为c1但实际上要按照c2为键值进行聚集,对聚集列进行重分布是不可避免的一步操作,因此先做聚集还是先做数据迁移重分布就成为分布式优化器的一个选项,针对这一情况可以有以下两种分布式执行计划选择:

说明:

(1)执行计划A未考虑Data Locality的优化按照聚集的逻辑直接从扫描输出的100m元组进行重分布操作,造成大量的数据传输和网络资源消耗。

(2)执行计划B考虑Data Locality的优化,把AGG算子分解成2次AGG,其中第一次AGG在本地执行对原始数据进行缩减然后再通过网络重分布进入第二次AGG,虽说执行计划B相比A多了1个AGG算子,尽管计算的总量未发生变化但是节省了大量的网络IO操作,端到端提升了查询性能。

表关联也是类似的原理,如果当join列与分布列不一致时,需要网络stream节点算子对数据进行重分布或者复制确保查询执行的语义正确。

3.4 分布式执行框架

由于GaussDB采用的是无共享Shared-nothing的架构,由众多独立且互不共享CPU、内存、存储等系统资源的逻辑节点组成。在这样的系统架构中,业务数据被分散存储在多个物理节点上,数据分析任务会被推送到数据所在位置就近执行,通过控制模块的协调,并行地完成大规模的数据处理工作,实现对数据处理的快速响应。DN是基于本节点存储的数据执行具体的执行计划;DN之间可能会有数据交互,这个数据交互就通过分布式执行框架来完成。分布式框架主要靠网络通信算子Steram完成,Stream算子是分布式执行框架的核心元素,Stream算子主要有2个职责:(1)数据重分布(Data Shuffling):负责将单节点DataNode进程串联成为分布式集群的能力也就是通常理解的数据重分布,其他友商如GreemPlum的Motion节点,VectorWise的DXchg节点也具备类似的功能;(2)分布式流水线(Distribute Pipeline):将原有的分布式执行计划进行并行切分,即以Stream节点作为处理流水线分界由不同的工作线程完成,线程间以PV生产者消费者模式工作,

数据重分布(Data Shuffling)

针对当前GaussDB所支持的数据重分布机制上有3种工作模式:

(1)Gather Stream(N:1)每个源节点都将其数据发送给目标节点,一般用于汇总DN节点到CN节点的过程。

(2)Redistribute Stream(M:N):M个DN节点将其数据根据关联条件、聚集分组表达式算出Hash值,根据重新计算的Hash值进行分布,发送数据到对应的目标节点。一般用于Join、Agg、NodeGroup中的重分布场景。

(3)Broadcast Stream(1:N):有一个源节点将其数据发给N个目标节点。

例如下图的分布式执行计划,由于不同的表分布属性不同,因此通过分布式执行框架Stream节点进行数据串联并执行,最后在CN节点进行结果集汇总。

说明:

(1)执行的过程中对T1、T2的扫描都在DN节点上并行完成。

(2)优化器生成的执行计划选择了前一节中描述的方案3,即T1保持不动复制T2到所有节点,并完成分布式HASHJOIN。

(3)HashJoin节点在所有节点上执行完成以后通过Gather节点在CN上进行结果集汇总。

分布式执行流水线(Distribution Pipeline)

在分布式执行过程中如果存在数据搬移,Stream算子的数据发送端、数据接收端有不同的线程完成,他们在时间分片上重叠以并行的方式执行,因此全局执行计划被网络通信算子Stream切分成多个计划片段,分别有不同的线程来完成执行,不同的线程之间采用PC生产者消费者进行交互通信,全局上达到并行执行的效果。如下图,实际的计划执行在DN这一层以Stream算子为界,被切分成多个线程并行处理。

3.5 轻量全局事务管理GTM-lite

GTM,全称Global Transaction Manager,即全局事务管理器,负责全局事务号的分发,事务提交时间戳的分发以及全局事务运行状态的登记,作为事务管理中的重要模块,为支持事务一致性提供必要的保证。事务开始和提交时与GTM进行交互获取必要的全局事务信息,包括事务ID,全局时间戳,全局快照等等。与其他模块一个很重要的不同点就是,为了保证一致性和事务标识全局唯一,集群中只要一个主GTM,即只有一个GTM真正参与事务(不过GTM和DN一样是高可用的,支持一主多备或主备从)。使用GTM来进行事务管理,一个很重要的问题就是会出现单点瓶颈,因为所有需要获取事务唯一标识的事务都需要连接GTM,获取全局快照的时候也都需要连接GTM,在大并发的情况下频繁的交互导致大量的网络通信和锁等待,从而限制了集群性能。

在老的GTM模式下,虽然通过将活跃事务链表替换为CSN来减少了通信量,但是由于仍采用全局事务id的策略,所以每个活跃事务仍要在GTM注册槽位,GTM负责管理和分发全局事务id,这导致当并发量大的时候,GTM容易成为单点瓶颈,主要体现在以下两个方面:

(1)在一个事务的执行流程中,CN会与GTM进行多次交互,如事务开始时在GTM注册槽位、获取快照时从GTM获取全局事务id、事务结束时向GTM提交并移除槽位等,这些频繁的交互会带来大量的网络通信和等待;

(2)当并发量超过槽位数限制时,会由于槽位不够影响业务正常进行。

由此可见,其影响性能的主要原因在于GTM的协调太强,通过对全局事务id的管控,虽然保证了事务的一致性,但是也限制了事务处理的效率。与GTM模式相反,GTM-FREE模式下CN/DN不与GTM交互,通过CN/DN分别维护本地事务id来保证事务系统的正常运行。这种模式下由于缺少全局事务id以及GTM的其他协调(CSN),事务的一致性会受到影响,从而限制了这种模式的适用范围。综上,现有的两种模式在效率和一致性要求上并没有达到一个很好的平衡,而影响这种平衡的主要因素在与“协调”,协调带来更多一致性的保障,但是却降低了性能。由此,一个好的模式应该是在尽可能少的协调的情况下,达到尽可能高的性能,这也是本章介绍的GTM-LITE模式

GTM-LITE的主要目标就是在消除GTM瓶颈影响的同时,尽可能通过更少的信息交互,利用它来协调好事务的并发,从而保证事务一致性的同时提升性能。为此,GTM-LITE的主要设计思路包含以下4点:

(1)本地事务id取代全局事务id。GTM不再分配全局唯一的事务id,每个CN/DN节点用本地产生的事务id,保证节点内事务id不会重复;对于跨节点的事务,由全局唯一的gid标识符前缀来保证写一致性,由全局唯一的csn号来保证事务读的一致性。

(2)GTM不再维护槽位信息,仅在事务提交时下发全局唯一的csn序列号。GTM下发的全局csn是一个递增的uint64值。这一设计消除了BEGIN, GetNewTransactionId同GTM的交互。进一步,如果事务在GTM提交时失败,可以retry重新获取最新的csn,减少网络故障对系统造成的影响。

(3)本地维护多版本过期脏元组的回收,并引入Snapshot Invalid机制,保证全局事务的一致性。由于舍弃全局事务id,无法直接根据RecentGlobalXmin确定需要清理的脏元组,所以需要利用全局csn来计算RecentGlobalXmin,从而实现GTM架构代码的有效复用。

(4)引入prepared array链表对单节点事务可见性判断进行优化。对于单节点的读事务,不再向GTM申请快照,而是使用本地的快照+prepared array链表来进行可见性判断,这种方式在保证读外部一致性的前提下,尽可能的减少同GTM的交互。基本判断方法为:对于csn<本地快照csn的事务以及本地prepared(在prepared array中)且最终提交的事务,均可见。

以上内容从查询重写RBO、物理优化CBO、分布式优化器、布式执行框架、轻量全局事务管理GTM-lite等五方面对高性能关键技术的进行了分享,下篇将从USTORE存储引擎、计划缓存计划技术、数据分区与分区剪枝、列式存储和向量化引擎、SMP并行执行等方面继续解读高性能关键技术,敬请期待!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/864037.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

.secret勒索病毒详解,如何防御网络隐秘威胁

引言&#xff1a; 在数字化日益普及的今天&#xff0c;网络安全问题愈发凸显&#xff0c;其中勒索病毒作为一种极具破坏性的恶意软件&#xff0c;给个人用户和企业带来了巨大的损失和心理压力。.secret勒索病毒&#xff0c;作为这一威胁中的佼佼者&#xff0c;以其高度的隐蔽性…

Android Graphics 显示系统 - BufferQueue的状态监测

“ BufferQueue作为连接生产者和消费者的桥梁&#xff0c;时刻掌握队列中每一块Buffer的状态&#xff0c;对于解决一些卡死卡顿问题很有帮助&#xff0c;辨别是否有生产者或消费者长期持有大量Buffer不放导致运行不畅的情况。” 01 — 前言 在Android系统中&#xff0c;应用U…

Redis基础教程(四):redis键(key)

&#x1f49d;&#x1f49d;&#x1f49d;首先&#xff0c;欢迎各位来到我的博客&#xff0c;很高兴能够在这里和您见面&#xff01;希望您在这里不仅可以有所收获&#xff0c;同时也能感受到一份轻松欢乐的氛围&#xff0c;祝你生活愉快&#xff01; &#x1f49d;&#x1f49…

MicroBin好用的粘贴板工具

有时候你可能想从一台电脑上粘贴文本到另一台电脑上&#xff0c;或者是你想要分享一张图片或者是一些文件&#xff0c;某些设备上登陆qq和微信有不太方便&#xff0c;那么就可以使用MicroBin&#xff0c;它不但可以实现跨设备复制粘贴的功能&#xff0c;还支持文件上传等功能 …

微信小程序的在线客服系统源码 附带完整的源代码包以及搭建部署教程

系统概述 微信小程序的在线客服系统源码是一套专门为微信小程序开发的客服解决方案。它通过与微信小程序的紧密集成&#xff0c;为用户提供了便捷、高效的客服沟通渠道。该系统源码采用先进的技术架构&#xff0c;具备良好的稳定性和扩展性&#xff0c;能够满足不同规模企业的…

韩顺平0基础学java——第34天

p675-689 UDP网络编程 1.类 DatagramSocket和 DatagramPacket[数据包/数据报]实现了基于UDP协议网络程序。 2.UDP数据报通过数据报套接字DatagramSocket发送和接收&#xff0c;系统不保证UDP数据报一定能够安全送到目的地,也不能确定什么时候可以抵达。 3.DatagramPacket对象…

【前端】从零开始学习编写HTML

目录 一、什么是前端 二、什么是HTML 三、HTML文件的基本结构 四、HTML常见标签 4.1 注释标签 4.2 标题标签 4.3 段落标签 4.4 换行标签 4.5 格式化标签 4.6 图片标签 4.7 超链接标签 4.8 表格标签 4.9 列表标签 4.10 表单标签 &#xff08;1&#xff09;form标…

MySQL高可用(MHA高可用)

什么是 MHA MHA&#xff08;MasterHigh Availability&#xff09;是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。 MHA 的出现就是解决MySQL 单点的问题。 MySQL故障切换过程中&#xff0c;MHA能做到0-30秒内自动完成故障切换操作。 MHA能在故障切换的过程中最大…

内容营销专家刘鑫炜:如何撰写一篇吸睛又能转化的医疗推广软文?

在我每天要处理的稿件中&#xff0c;有1/3以上是医疗软文&#xff0c;但稿件质量情况不容乐观&#xff0c;大部分医疗软文甚至用极其糟糕来形容都为过&#xff0c;互联网都到下半场了&#xff0c;很多医疗机构营销人员的营销思维还是停留在二十几年前&#xff0c;投放的软文还是…

SpringMVC系列八: 手动实现SpringMVC底层机制-第三阶段

手动实现SpringMVC底层机制 实现任务阶段六&#x1f34d;完成控制器方法获取参数-RequestParam1.&#x1f966;将 方法的 HttpServletRequest 和 HttpServletResponse 参数封装到数组, 进行反射调用2.&#x1f966;在方法形参处, 指定 RequestParam, 将对应的实参封装到参数数组…

Redis缓存问题二、缓存雪崩

缓存雪崩 缓存雪崩&#xff1a;是指在同一时段大量的缓存key同时失效或者Redis服务宕机&#xff0c;导致大量请求到达数据库&#xff0c;带来巨大压力。 缓存雪崩的解决方案&#xff1a; 给不同的Key的TTL添加随机值利用Redis集群提高服务的可用性给缓存业务添加降级限流策略…

sql-语句

文章目录 SQL语句的学习sql是什么sql的内置命令sql的种类sql mode库&#xff0c;表属性介绍&#xff1a;字符集&#xff0c;存储引擎列的数据类型&#xff1a;数字&#xff0c;字符串&#xff0c;时间列的约束DDL: 数据定义语言库表 Online DDL(ALGORITHM) *DML :数据操纵语言资…

SpringBoot实现文章点赞功能

提示&#xff1a;今日是2024年的6月30日&#xff0c;未来的你看到这篇文章&#xff0c;希望你依旧快乐 文章目录 前言 首先在这里前缀部分我就不做要求了,比如说登录信息什么的 数据库表格 这里实现点赞功能&#xff0c;主要是围绕论坛项目完成的 user_info代表用户信息表 for…

SprongBoot3整合Knife4j

大家好&#xff0c;我是晓凡。 写在前面 在上一篇文章&#xff0c;我们详细介绍了SpringBoot3 怎么整合SpringDoc实现在线接口文档。但是&#xff0c;有不少小伙伴 都觉得接口界面太丑了。有没有什么更美观一点的UI界面呢&#xff1f; 当然是有的了&#xff0c;毕竟这是一…

抖音直播自动点赞脚本:让点赞变得简单

抖音直播自动点赞脚本&#xff1a;让点赞变得简单 简介 点赞是社交媒体上表达喜爱的一种方式&#xff0c;尤其在抖音这样的平台上&#xff0c;点赞不仅能够增加主播的人气&#xff0c;还能鼓励他们创作更多优质内容。然而&#xff0c;手动点赞往往既耗时又费力。为了解决这个…

云服务出现故障这样处理

无法连接云服务器 服务器远程无法连接时&#xff0c;可通过7ECloud控制台进行连接。 常见故障现象 1、ping不通 2、ping丢包 3、部分端口telnet不通 4、全部端口telnet不通 5、广告、弹窗植入 6、域名无法访问IP访问正常 常见故障原因 1、云服务器过期、关机或者EIP被…

深度学习基准模型Transformer

深度学习基准模型Transformer 深度学习基准模型Transformer&#xff0c;最初由Vaswani等人在2017年的论文《Attention is All You Need》中提出&#xff0c;是自然语言处理&#xff08;NLP&#xff09;领域的一个里程碑式模型。它在许多序列到序列&#xff08;seq2seq&#xf…

恭喜了!全体前端彻底狂欢吧!这个好消息来得太及时!

在这个快速变化的科技时代&#xff0c;作为独立开发者&#xff0c;你是否常常被繁琐的开发任务压得喘不过气&#xff1f;前端开发要操心后端的各种服务搭建和接口开发&#xff0c;这些琐碎而耗时的工作常常让人头大。但现在&#xff0c;你可以松一口气了&#xff0c;因为MemFir…

【ARM-Linux篇】项目:智能家居

一、项目概述 •项目功能 通过语音控制客厅灯、卧室灯、风扇、人脸识别开门等,可以进行火灾险情监测,可以并且实现Sockect发送指令远程控制各类家电等 •项目描述 全志H616通过串口连接各模块硬件,检测语音的识别结果,分析语音识别的结果来对家电设备进行控制。摄像头拍…

视频上面怎样编辑文字?4种视频编辑文字方法分享

视频已成为我们日常生活中不可或缺的一部分。无论是社交分享、商业宣传还是个人记录&#xff0c;视频都以其直观、生动的特点吸引着观众的眼球。然而&#xff0c;一个优质的视频&#xff0c;除了画面和音效&#xff0c;文字编辑也是提升观看体验的关键。那么&#xff0c;如何在…