《Parallel SQL Execution in Oracle 10g》 论文解读

简介: 《Parallel SQL Execution in Oracle 10g》 论文解读

Oracle Parallel Execution解决的问题是:在shared-disk架构下,如何进行大查询。

整体思路是:存储上是共享的,内存中是MPP share-nothing的计算模型。

Oracle PX基于shared-disk做了2大优化:

  1. 动态扫描数据,解决数据倾斜问题;
  2. full partition-wise join,加速分区表join;

此外,Oracle是OLTP型数据库,没有按照AP性能最大化来设计PX,在优化器和执行器上和MPP系统都有比较大的不同:

  1. 优化器:Oracle PX的优化器是基于TP优化器的改进,优化器先按照非PX模式执行计划的探索,然后在此基础上插入DFO,数据分布等逻辑,而不是像GPORCA等为AP重新设计的cascade优化器;
  2. 执行器:2-DFO调度,非全流水线调度,节省PES进程资源,防止对TP造成太高的资源竞争;

下面是正文:

ABSTRACT

Oracle7基于shared-disk架构初步实现了并行执行,Oracle 10g重构了并行执行架构实现了全局并行计划树,更易于维护和对SQL特性的扩展,加速了Oracle的并行执行的演进。

1. Introduction and Overview

并行执行是处理大规模数据的关键技术。一个先进的执行引擎能够支持节点的弹性扩展,动态的申请和释放。

Oracle 10g是基于shared-disk,每个节点可以访问所有的数据,数据无需事先分区。

通过优化器产生高性能的并行计划树以及Parallel Execution执行期优化(简称PX)能够把负载打散在几个节点上,同时降低节点间网络开销。对关键资源比如内存以及锁等通过execution-constructs做约束。

Oracle 10g的PX引入了PSC机制(Parallel Single Cursor),各个执行节点共享同一份计划树。解决了之前使用Oracle PX时的手工运维管理,手工监控,手工性能诊断等问题。

2. Concepts and key abstractions

Oracle PX支持两种并行机制:intra和inter。

1. intra:同一个节点,通过共享内存通信;

2. inter:跨节点,通过网络通信;

由PEC(Parallel Execution Coordinator)和PES(Parallel Execution Server)组成。

Oracle PX支持所有SQL功能:

1. relation操作符;

2. DML,DDL,分区表;

3. bulk load(外表);

4. AP类SQL;

5. data mining;

PEP(parallel execution plan)由4部分组成:

1. Dataflow operators(DFOs),由多个row source组成,类似slice,fragment的概念;

2. Table Queues(TQs),类似motion,shuffle,Exchange的概念;

3. GRA(granule interators控制水平动态切分表),shared-disk架构特有的功能,一个woker可以从其他worker上steal任务;

4. Parallelizer row source(控制并行度);

3. Parallel Single Cursor Model

在PSC(Parallel Single Cursor)模型中,使用单个全局的plan树表达并行执行所需的所有信息。计划树由PEC生成,PEC和PES同时调度执行该计划树。

3.1 Generation of a Single PEP

先生成逻辑计划树,然后再生成物理计划树

3.1.1 逻辑优化

  1. first pass
    考虑join顺序;
    考虑access nethod;
    考虑开启并行的代价:节点数,每个对象的分区数,分布方式;
  2. second pass:
    计算最优的distribution算法,使得plan被parallel化;

3.1.2 物理优化:

把1中的逻辑计划中,相关的算子(row source)组织成DFO,考虑clustering,排序属性,data-frag特性;

这个阶段不会考虑DOP(应该启动多少个并行度),优化器对并行的感知和share-nothing的引擎如:DB2-PE,Teradata类似。

image.png

和MPP的火山全流水模型不同的是,Oracle的并行的进程数目是固定的:2倍的DOP。

所有PES进程分成2个集合,每个集合下面有DOP个PES进程。执行时一个集合做为生产者,一个集合做为消费者;

生产者执行完当前DFO算子之后,切换成消费者;

原来的消费者,变成了生产者;

3.2 Implication of a Single Global PEP

由于并行需要在多个PES进程之间共享DFO计划,在经过物理优化之后得到一个可执行的计划树后,大多数DB的并行执行引擎,会使用中间语言或者更高级别的SQL结构来表达DFO树(序列化和反序列化),Oracle在实践中发现随着执行引擎不断的迭代和增大,中间语言和SQL表达DFO的逻辑维护异常复杂,需要时刻维护SQL和plan的序列化和反序列化相关逻辑和组件的一致性:

1. 中间语言:每个DFO用中间语言表达和执行过程极易出错(一旦出错,整个大查询终止);

2. 使用SQL描述DFO:先生成计划树,再把一个个DFO翻译成SQL,DFO是物理执行层面的树,SQL是声明式语言,无法建立一一对应的关系;

Oracle的并行执行引擎的做法是:

1. QC分发原始的SQL给PES进程组;

2. 每个节点上的一个PES进程再执行一次优化器生成plan;

3. 该节点上其他PES进程直接使用生成的plan;

好处:

1. 提升并行查询期间的管理和监控:所有的并行相关结构在物理计划中也被抽象成了算子(row source);每个算子的统计(内存,消息数,负载倾斜)等可以记录在算子上,最后可以把所有PES进程上的所有算子做聚合,得到计划树在多个节点上的执行情况;

2. 支持新的px算子时,无需修改序列化和反序列化相关的兼容问题,只要定义新算子的相关属性即可(类似单机算子);

3. 代码可维护性,方便调试,同时减少中间plan树的内存;

4. Execution of a Parallel Single Cursor

  1. PEC和PES共享相同的plan;
  2. PEC先给PES发送调度DFO的控制信息(启动PES进程组);
  3. PES扫描一个fragment info,通过GRA算子实现,每次消耗完一个granule就向PEC请求下一个granule(比如:一个granule代表一批block),生产的数据往对端PES消费者进程组发送,只有消费进程组消费完了后,才请求后续的granule。通过这种方式实现了动态的负载均衡;

在shared-nothing的系统中,每个表都必须使用分区存储,因此每个节点只能访问一个分区的数据(Teradata和GP默认是Hash的方式)。

调度器必须感知数据分区和节点的静态的映射关系,一个分区上的数据不能被其他节点访问。

Oracle PX不要求数据一定是分区存储的,Oracle的分区表只是用来高可用和性能,Oracle的PX引擎不受用户如何分区的限制(实际上分区的使用应该仅仅考虑业务上的特性,而不需要和性能绑定)。

Oracle的PX同样会对分区做优化:Full Partition-wise join,每个PES进程只扫描2个表的特定的分区数据直接join,而不用和其他PES进程之间交互数据。而且任何一个PES都可进行partition-wise join,因此底层是共享存储。

4.1 Cluster-aware PX

4.1.1 partition-wise join

在优化器阶段,考虑能启动的PES数目,以及query中扫描到的分区数目,尽量的在数据的流动的垂直方向进行切分,以减少横向的数据流动。

image.png

2个表分别有4个分区表,为了减少数据的横向流动使用partition-wise join。每个节点处理2个成对的分区表。

partition-wise join时,一个PES进程只处理一个分区表,最大的并行度是有限制的,比如上图中,DOP不能超过4。

也许使用更多的DOP能提高整体性能,多个DOP同时扫描一个分区表,这样就需要横向的数据流动了,因此,最终应该通过优化器来决定DOP的数目。

和shared-nothing的系统又本质的区别,shared-nothing的并行度是固定的,一个进程只处理一个分区表。

4.1.2 px hash join

下图是DOP=8,一共16个PES进程的执行过程。8个生产者8个消费者,生产者在发送数据时需要根据join key进行hash(这个过程叫重分布),几个PES生产进程共同扫表一个分区表。

image.png

4.1.1 hybrid partition-wise join

在partition-wise中,如果分区数目比较少,那么就无法启动更多的DOP来计算。

hybrid的模式:把PES进程根据分区表的数目进行分组。多个PES进程处理partition-wise join中的一对分区表。1个分区表的多个PES进程之间需要shuffler(如果在一台机器上,无需网络及,直接sharememory),而分区表之间的PES进程组不需要;

好处是:无需all node data tansform,尤其是有大量的小节点;

hybrid模式:

1. 可以看做是, partition-wise join执行模式的扩展,partition-wise join中一个PES进程处理一个分区,现在是多个PES进程处理一个分区;

2. 也可以看做是,对普通PX执行的约束,PES之间增加一个映射关系,使得集合内部是普通的PX执行;

hybrid模式通过PES-mapper机制来实现:

1. 根据物理约束(分区表),把pes分成组,组之间无联系,组内在一台机器上,通过共享内存通信;

2. 优化器提供一个PES mapper函数,每行数据经过PES mapper之后找到相应的组内的消费者PES进程;

PES-mapper优化:表现如同share-nothing,同时可以利用shareddisk来负载均衡;

image.png

PES Mapper方式类似MPP中:一个分区启动多个worker。

4.2 PM Performace

PES mapper机制提升30%,pm机制保证节点间没有数据流动,可以方便的扩展节点数。

image.png

4.3 Resource-Aware PX

PX是资源消耗性查询,不能影响正常的TP查询,因此PX需要做严格的资源管理:

1. 内存:统计每个节点内存情况,动态分配DOP,比如:对分区表执行parallel INSERT,可以每个PES进程处理一个分区,但是如果分区特别多,PES就会很多,内存占用就会很大,PES mapper把一个PES处理多个独立的分区表;;

2. 锁:parallel DELETE/UPDATE在并行执行时会对同一个block上锁,PES mapper机制限制每个object被上锁的次数,控制PES数目;

3. 自适应DOP和PES分配:

1. 先确定参与px的节点:计算节点按照业务编号,支持只在固定node上服务固定业务的sql,

2. 确定inter和intra;

4. granule:分配unit时,考虑data locality和affinity;也可以根据SQL特点,分配unit;

5. A feature-rich Parallel Engine

5.1 Flexible data distribution and pipeline

如果多个表join后的结果集进行group-by和order-by,那么优化器会考虑把hash重分布替换成range分布模式(Oracle独有的技术),同时消除底层DFO的order-by;

ETL场景,对table function的输入使用px扫描:

1. 多PES进程扫描一个分区;

2. 扫描时外部数据进行granule切分(动态平衡);

3. 再按照partition by传给对应执行function的PES进程组;

4. 如果输入的hash和导入新表的partition by的hash是一致的,无需数据重分布;

5.2 Cost-based Parallelization of Subqueries

Oracle支持大部分子查询转join和agg的逻辑优化技术。

对于实在不能去关联化的子查询,可以对子查询部分独立的启动并行度PX或者串行执行,这取决于启动px的代价;

5.3 Recursive and Interative Computation

通过DFO之间传输中间结果集的temp table,以支持px+递归;

5.4 Load-Balanced Table Queues

对数据分布敏感的分布策略,进行动态的sampling,防止range倾斜;

6. Conclusions

本文讲解了Oracle10g的并行执行引擎技术:

1. Oracle10g对OPS进行了重构,替代了原来使用DSL对plan进行序列化和反序列化,PEC和PES节点之间传输SQL,每个节点独自执行优化得到single-plan,每个节点上不同PES共享一份single-plan;

2. 执行模型和数据分布解耦合。底层数据是shared-disk存储,而不是share-nothing系统中的分片存储。PX可以在任意节点扫描任意数据集合,因此PES-mapping机制可以更加灵活的在PES进程和节点上进行重新安排,充分的考虑集群内存,锁,网络等因素;

3. Oracle10g借助PX框架对大量的SQL场景进行了并行优化;

相关文章
|
1月前
|
SQL 自然语言处理 算法
NL2SQL进阶系列(5):论文解读业界前沿方案(DIN-SQL、C3-SQL、DAIL-SQL)、新一代数据集BIRD-SQL解读
NL2SQL进阶系列(5):论文解读业界前沿方案(DIN-SQL、C3-SQL、DAIL-SQL)、新一代数据集BIRD-SQL解读
NL2SQL进阶系列(5):论文解读业界前沿方案(DIN-SQL、C3-SQL、DAIL-SQL)、新一代数据集BIRD-SQL解读
sbs
|
SQL 存储 监控
One SQL to Rule Them All: An Efficient and Syntactically Idiomatic Approach to Management of Streams and Tables 论文翻译
One SQL to Rule Them All: An Efficient and Syntactically Idiomatic Approach to Management of Streams and Tables[文件: One SQL to Rule Them All- An Efficient and Syntactically Idiomatic Approach to Manag
sbs
169 0
One SQL to Rule Them All: An Efficient and Syntactically Idiomatic Approach to Management of Streams and Tables 论文翻译
|
SQL 移动开发 Oracle
|
SQL 负载均衡 并行计算
Parallel SQL Execution in Oracle 10g 论文解读
这篇简短的paper从非常high level的角度描述了下Oracle 10g对于parallel query所做的重新设计和其中的一些优化,由于Oracle RAC特殊的share-disk架构,使其在并行计算上与普通的MPP数据库有一些不同,例如对于worker的调度和分配方式以及对于资源/数据的动态调整。
234 0
Parallel SQL Execution in Oracle 10g 论文解读
|
9天前
|
SQL DataWorks NoSQL
DataWorks产品使用合集之如何将SQL Server中的数据转存到MongoDB
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
209 1
|
1月前
|
SQL API 流计算
实时计算 Flink版产品使用合集之在Mac M1下的Docker环境中开启SQL Server代理的操作步骤是什么
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
158 1
|
1天前
|
SQL IDE Java
Java连接SQL Server数据库的详细操作流程
Java连接SQL Server数据库的详细操作流程
|
2天前
|
SQL 弹性计算 API
云服务器 ECS产品使用问题之如何通过API调用阿里云服务器上SQL Server数据库中的数据
云服务器ECS(Elastic Compute Service)是各大云服务商阿里云提供的一种基础云计算服务,它允许用户租用云端计算资源来部署和运行各种应用程序。以下是一个关于如何使用ECS产品的综合指南。
|
2天前
|
SQL 存储 关系型数据库
关系型数据库中的SQL Server
【6月更文挑战第11天】
30 3