写点什么

数据库物理计划执行指南

作者:KaiwuDB
  • 2024-06-18
    上海
  • 本文字数:3573 字

    阅读完需:约 12 分钟

一、背景介绍


伴随信息技术地迅猛发展和应用范围地逐步扩大,数据库已成为企业存储与管理数据的重要工具。但数据量激增以及用户访问需求的与日剧增,数据库性能也将面临巨大挑战。


好在数据库物理计划执行是解决数据库性能问题的重要手段之一,我们可以通过对数据库物理结构进行合理规划和优化,提高数据库的查询速度、降低存储空间的占用率,从而提高数据库整体性能。


二、物理计划基础概念


2.1 算子执行


在数据库系统中,算子执行是指查询语句中的各种操作符(算子)实际执行的过程。数据库查询通常由一个或多个操作符组成,这些操作符包括选择、投影、连接、排序等,它们按照特定的顺序和方式执行来完成查询任务。以下是算子执行的常规过程:


  • 解析查询语句

数据库系统首先会解析查询语句,识别其中的各种操作符和操作数,并构建查询执行计划(Query Execution Plan)。


  • 查询优化

在执行计划构建过程中,数据库系统会进行查询优化,尝试找到最有效的执行计划以提高查询性能。其中会涉及到选择合适的索引、调整连接顺序、重新排列操作等优化策略。


  • 执行计划生成

一旦查询优化完成,数据库系统会生成最终的执行计划,该计划描述了执行查询所需的具体步骤和顺序,以及每个步骤所需的算子。


  • 算子执行

数据库系统按照执行计划中描述的顺序逐步执行各个算子。每个算子通常都会对输入的数据进行一些处理,并生成输出,供下一个算子使用。


  • 结果返回

最后,当所有算子执行完成后,数据库系统将返回执行结果给用户或者应用程序。


整个执行过程如图所示,通过下述步骤,数据库系统能够高效地执行各种复杂的查询,并返回用户所需的结果,优化算子执行过程是提高数据库性能的关键之一。



2.2 物理计划


在数据库管理系统中,物理计划是指将逻辑查询转换为一系列物理操作的执行计划。物理计划是针对数据库物理结构而言的,它决定了数据库访问方式、数据存储方式、数据传输方式等,这些因素都将对数据库性能产生非常大的影响。


物理计划是将逻辑查询转化为物理操作的执行计划。数据库中的各种组件,如执行器、扫描器、排序器、连接器、聚合器、索引、缓存和分区等,都是物理计划执行的基础概念。


三、KaiwuDB 物理计划

3.1 物理计划组成


KaiwuDB 是一个分布式数据库系统,其物理计划与传统的关系型数据库系统有所不同,因为它需要考虑分布式数据存储和处理的特点。KaiwuDB 的物理计划通常会涉及到以下几个方面:


  • 数据分布和复制

KaiwuDB 将数据分布到不同的节点上,并通过数据复制确保数据的高可用性和容错性。因此在执行查询时,物理计划需要考虑到数据的分布情况,以及在哪些节点上复制了查询所需的数据。


  • 分布式查询处理

KaiwuDB 支持将查询分布到不同的节点上并行执行,以提高查询的性能。物理计划会涉及到如何将查询分解为多个子查询,并将这些子查询发送到不同的节点上执行,然后将结果合并。


  • 数据传输和网络通信

由于数据存储在不同的节点上,KaiwuDB 的物理计划需要考虑如何在节点之间传输数据,并且需要最小化网络通信的开销。


  • 分布式索引和统计信息

KaiwuDB 支持分布式索引和统计信息,物理计划会根据索引和统计信息来选择最优的查询执行路径,以提高查询的性能。


  • 节点资源管理

在执行查询时,KaiwuDB 的物理计划需要考虑每个节点的资源利用情况,以避免节点过载或资源不均衡导致的性能问题。


总体来说,KaiwuDB 的物理计划与传统的关系型数据库系统类似,但在处理分布式数据存储和查询处理时有所不同。优化 KaiwuDB 的物理计划通常需要考虑到分布式环境下的特殊情况,以确保查询在整个集群中的高效执行。


3.2 KaiwuDB 物理计划构造类图



3.3 KaiwuDB 物理计划生成时序图



四、KaiwuDB 物理计划样例


样例 1

以一个简单的物理计划为例,该计划表示为两个表 T1 和 T2 的 Join,Join 的等值关系为 T1.k=T2.k,T1 和 T2 的数据都分布在 3 个节点,表示为如下图:



物理计划会确认数据的分布信息,设置每一个 Tablereader 算子的 Filter、Projection 等操作,最终将生成的几个 Tablereader 加入到物理计划当中。



将左右计划进行合并:



findJoinProcessorNodes 函数决定在几个节点做 Join 操作,这里的 Tablereader 算子是 3 节点,所以 Join 算子也会对应构建 3 个节点,因此这里会调用 AddJoinStage 生成 3 个 HashJoiner(不考虑其他 Join 算法的情况下),并且将其左右算子(这里指代图中的 6 个 Tablereader)的 Output 类型改为 OutputRouterSpec_BY_HASH(意味着执行时需要跨节点 Hash 重分布),物理计划视图变为如下图所示:



然后调用 MergeResultStreams 按照节点数量将 T1 和 T2 的各 3 个 Tablereader 连接到各个 HashJoiner 的左右两端,有向箭头表示 Stream,起于一个算子的 Output,终于另一个算子的 Input,物理计划视图如下,图中的 Output 类型均为 OutputRouterSpec_BY_HASH:



createPhysPlan 函数生成了物理计划的整体拓扑,FinalizePlan 函数还会在已有的物理计划基础上增加一个 Noop 算子,用于汇总最终的执行结果,然后设置每个算子的 Input 和 Output 所关联的 StreamID,以及 Stream 的类型(StreamEndpointSpec_LOCAL 或者 StreamEndpointSpec_REMOTE,Stream 如果连接相同节点的算子为 StreamEndpointSpec_LOCAL,否则为 StreamEndpointSpec_REMOTE)。在执行完 createPhysPlan-->FinalizePlan 后,整体的物理计划便构建完成,如下图所示:



样例 2

我们将通过以下 SQL 语句来介绍物理计划的生成:


select max(height),class from heights join students on heights.id=students.id group by class having class in(1,2) order by max(height) desc limit 2;
复制代码


(左右滑动查看完整语句)


该查询语句的 PlanNode 如下图所示:



以上述 PlanNode 为例,其最下层为两个 ScanNode,分别是对 heights 和 students 的一个全表扫描,其结果会返回给上层的 JoinNode,JoinNode 会将两张表做 Join 生成一张虚拟表,里面有两张表中的所有列。


其上层的 RenderNode 会对这张虚拟表进行查询,筛选出 height 列和 class 列,GroupNode 会对 class 列进行 group 处理,并对 class 作 max 聚合。然后, SortNode 对 GroupNode 处理过的 max 聚合结果进行排序,LimitNode 对结果作相应的操作。最后,最上层的 RenderNode 对结果进行查询,筛选出 max(height) 列和 class 列。以上即为该 PlanNode 的详细信息。


接着会通过 createPlanForNode 函数对 PlanNode 进行解析生成物理计划。该函数是一个递归函数,会通过 PlanNode 的类型来构建相应的物理计划。


以上述查询语句为例,该 PlanNode 会层层递归先执行 ScanNode 的构建函数 createTableReaders;接着,通过 initTableReaderSpec 新建 Tablereader 的 Spec;随后,通过逻辑计划传下来的 PlanNode 得到算子的 Filter 和 Limit;然后,通过 MakeExpression() 构造物理计划的 Filter 并将 Filter 和 Limit 传入 Post 中。


最后,通过 planCtx 的 isLocal 判断是否是分布式读取计划。

  • 若是,则构建 SpanPartition 数组,在各个节点读取 Table 的值;

  • 若否,则单读取本地数据即可。


具体流程如下图所示:



在构建完 left ScanNode 和 right ScanNode 的计划后得到 rightPlan 和 leftPlan, leftPlan 和 rightPlan 执行 MergePlans() 合并左右计划,将左右计划的 Processor 和 Stream 等信息合并。


之后判断是否为分布式执行的步骤与上面的判断方法类似。最后再判断 leftMergeOrd.Columns 是否等于 nil。


  • 若是,则构建 hashjoinspec;

  • 若否,则构建 mergejoinspec。


执行 AddjoinStage() 将 joinProcessor 添加到指定的节点上去并将左右 Output 连接到这些 Processor 中,JoinNode 也就处理完毕了,基本流程如下图。依次处理 RenderNode , GroupNode , SortNode 等,将相应算子信息添加到物理计划中。



五、总结


执行器在执行之前需要充分的计划做支撑,查询计划分为 LogicPlan 逻辑计划和 PhysicalPlan 物理计划(分布式计划)。


逻辑计划的数据结构为二叉树,由 AST 经过语义解析、 RBO 和 CBO 后生成,每个节点表示一个对应的关系操作(如关系运算连接,在逻辑计划中会转换为实际的 Join 算法,比如 HashJoin、MergeJoin、LookuopJoin)。


逻辑计划构建完成后,开始物理计划的构建,根据数据分布情况将逻辑计划进行垂直方向拆分,对应的逻辑计划节点转换为特定算子(Processor),算子之间通过 Stream 进行连接,整个物理计划的拓扑结构为一个有向无环图,之后便开始计划的执行。


在整个执行总体架构中, 物理计划在逻辑计划之后。物理计划需要得到逻辑计划经过执行后给到的 PlanNode 信息,该 PlanNode 中存放了执行一句 SQL 语句需要执行的操作,涉及的表信息,列信息等。


之后通过物理计划构建 Processor (用以说明需要用到哪些算子、执行顺序、以及算子在什么节点上执行信息;最后通过 Router 将 Processor 发送到各节点进行执行操作,即物理计划在总体架构中的位置处于逻辑计划之后,执行之前。

用户头像

KaiwuDB

关注

还未添加个人签名 2021-04-29 加入

KaiwuDB 是浪潮集团控股的数据库企业,公司汇聚了全球顶尖的数据库人才,以多模数据库为核心产品,面向工业物联网、数字能源、交通车联网、智慧产业等各大行业领域,提供领先创新的数据服务软件。

评论

发布
暂无评论
数据库物理计划执行指南_数据库_KaiwuDB_InfoQ写作社区