啃论文俱乐部——分布式查询优化的历史与现状

系统 OpenHarmony
分布式的性能查询处理算法的性能在很大程度上取决于某些中间关系的大小。因此,选择合理的估计算法是极其重要的。

​想了解更多关于开源的内容,请访问:​

​51CTO 开源基础软件社区​

​https://ost.51cto.com​

1984—关于分布式查询优化

该部分为1984的分布式查询优化综述概括,介绍了分布式数据库中优化查询的各种技术。虽然没有涵盖这个主题上所有提出的算法,但概述了从现有算法中提取的相当多的想法。

运营和成本措施

假设关系数据库中的关系分布在不同的站点。本文中使用的关系数据操作包括投影、选择、连接和半连接。

  • 投影:选择符合关系的列。
  • 选择:选择符合关系的元组(行)。
  • 连接:就是将两个表合并,然后选择出满足关系的元组。

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

半连接:属性A上从关系R2到关系R1的半连接用【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区表示。其中R2是发送关系,R1是简化关系,A是连接属性。有时使用【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区来表示【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区它可以通过将属性A上的R2和R1连接起来,然后将得到的关系投影到R1的模式上而得到,半连接在数据库机器中很有用。如果关系不被分割,那么在投影和选择中,只涉及本地处理成本。但是,执行连接和半连接时,除了本地处理成本之外,还会产生不同站点之间的通信成本。例如,如果R1和R2在不同的站点,R1必须发送到包含R2的站点。或者R2必须被发送到R1的站点才能进行操作。本地处理成本通常根据磁盘访问次数和cpu的处理时间来评估,而通信成本是以传输的数据总量来表示的。但本地处理成本对本地网络更为重要。在此主要认为网络是地理上分散的计算机网络。

我们假设从一个站点向另一个站点传输一定数量的数据(比如X)的成本是c0 + c1* X,其中c0是启动传输的启动成本,c1是比例常数。回答一个查询的成本可以用总成本或响应时间来表示。

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

在上图图(a)中,回答查询所需的X个数据单元从站点1传输到站点2,Y个数据单元从站点2传输到站点3,总成本为(c0+c1* X)+(c0+c1* Y)= 2c0 + c1*(X + Y)。响应时间是从开始查询到产生答案的时间。在上图图(b)中,来自站点1的X个数据单元和来自站点2的Z个数据单元被并行传输到站点3以应答查询,响应时间成本是c0+c1* X和c0 + c1*Z的最大值,在本文中,我们主要关注总成本测量。由于传输的数据量会影响策略的成本,因此有人尝试降低成本。一个可能的方法是利用半连接。

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

比如在上图图(a)中从属性B上的关系R2到关系R1的半连接可以将R2投影到属性B上,然后将投影的结果与R1 连接得到,可以看出得到的结果比原来的R1小得多。

在c0比较小的情况下,这种半连接是合理的。但在另一方面,在上图图(b)中,如果R1,R2之间的共同值很多,使用半连接可能不划算,所以在执行半连接之前,最好能估计两个关系之间共同值的数量。

估计

从上文可以看出,分布式的性能查询处理算法的性能在很大程度上取决于某些中间关系的大小。因此,选择合理的估计算法是极其重要的。

半连接后,R1投影在b属性上的问题可以用下面的球颜色问题来证明:“有n个球,有m种不同颜色。如果从n个球中随机选择t个球,求出颜色的期望值。”可以得到下列公式:

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

如果该公式以现在的形式计算,它的计算成本将会变得很大,并且t值较大时可能导致溢出。

一个半连接策略也可以看作有向图,通过有向图也可以估算出预期数量。

将半连接策略看作一个有向图,其中顶点是Ri到Rj之间的关系。有向边表示从Ri到Rj的半连接,即Ri->Rj。首先执行的半连接是那些入度为0的节点的半连接。然后,产生简化Rj,用表示。然后就是-> ,入度变为零,那么将会被执行。显然,半连接策略中不会出现有向环。

假设有三个关系R1、R2和R3,每个都有属性值A和B。在以上策略中,R1-B->R2-A->R3和R2-B->R1-A->R3在执行半连接后得到的关系是不相等的,因此,在一个半连接策略中计算关系的大小,必须要了解操作的过程。

三个阶段

分布式查询的处理可以分为三个阶段:副本识别阶段、简化阶段和组装阶段。

在副本识别阶段,出现在查询限定中的每个关系的一个或多个副本被识别,并将用于处理查询。由于分布式数据库系统可能包含一些关系的复制副本,所以为了最小化传输成本而识别关系的适当副本可能不是一个容易的过程。

在简化阶段,半连接通常用于消除不满足查询条件的关系元组并且要求最大化地减少成本。例如,对于前面引用的具有关系副本的最佳选择的查询,可以执行半连接来消除一些元组,而不会产生通信成本。如果半连接的结果不是最优结果,则可以执行其他半连接以减少成本。

在组装阶段,查询得到的结果关系被发送到一个站点,以产生用户所要求的输出。

我们要指出的是﹐将查询处理策略分离成三个阶段只是倾向于简化所涉及的概念。一个合理的选择关系副本的策略是找到包含所选关系副本的最小平均数的站点。不幸的是,这也是一个NP-complete问题,即最难的决定性问题。然而,由于查询引用的关系数量和包含这些关系的站点数量通常较少﹐通过列举找到站点的数量不需要很多时间。减少阶段和组合阶段将在后文中详细描述。

树查询与循环查询

特征:只有某些类型的查询可以使用半连接解决。更准确地说,如果不满足查询限定条件的所有元组都被消除,那么投影的关系将被完全减少。如果使用半连接来减少关系,可能会产生较少的通信成本。但是查询中出现的关系可能没有完全减少。因此,组装关系的沟通成本仍然很高。因此,需要对可以通过半连接完全减少的查询类型进行精确的描述。

树状查询图:关系的查询图可以转换成树状的。如果查询图不是树形的﹐那么这就是一个循环查询。如前所述,如果查询是树状查询﹐树状查询的关系可以通过半连接完全减少﹐但循环查询无法通过半连接完全减少。这说明了识别出该查询是否树状查询的重要性。

有一种简单的算法可以识别,如下所示。该算法将一个查询作为输入,他有两个关键步骤,最初,对于每个关系Rt,构造条件中出现的关系的属性集J(Rt)。如前所述,假设存在三种关系R1 R2 R3.

第一步,假设存在某种关系,这个关系保证了可以通过替换表格中的每个子元组来构造等价替换。替换后Ri只出现在关系Ri.X=Rj.X中。很明显,在查询图中,Ri与Rj变成了相邻,而不属于任何循环。因此,消除R不会改变查询图的类型。在图7中,R3的A2属于R1,将R3到R4的边替换为R1到R4的边(以及R1到R3的边)。因此,R3不属于任何周期,可以在不影响查询类型的情况下消除它。

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

第二步,如果在第1步中消除了任何关系,则检查它是否导致了某个属性的消除。如果一个属性只剩下一个包含该属性的关系,则该属性将被删除。(如果一组关系包含相同的属性,它们之间的关系是由该属性的相等性决定的;因此,如果没有一个以上的关系具有该属性,那么这种关系就不存在。) 很明显,删除一个属性会导致关系R的更新。如果在算法结束时消除了所有关系,那么原始查询就是树查询,因为算法不影响查询的类型(树查询或循环查询),而null查询显然是树查询。如果在算法的最后确实存在一些关系,那么可以表明原始查询是一个循环查询。

将循环查询转换为树查询

因为树查询是完全可约的,所以能够将循环查询转换成树查询的算法是合乎需要的. 基本上,有三种不同的变换算法:

(1)关系合并算法。

(2)tuplewise分解算法。

(3)属性添加算法。

关系合并算法简单地连接存在于循环中的某些关系以消除循环。例如,给定下图图(a)所示的循环查询,该算法可以连接循环中的任意两个关系。这导致循环消失。下图图(b)显示了将R1和R2连接在一起的查询图。

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

元组式分解算法:

R1thm算法基于Wong和Youssefi的元组替换思想。该算法通过将一个循环查询分解成多个树子查询来消除循环。

(3)属性添加算法:

循环中涉及的一些关系的某些属性被添加到其他关系中,从而产生树查询。然后通过半连接来完全简化任何给定的关系。

简单查询的最佳策略

在还原阶段描述的查询处理算法都是启发式的﹐不一定能产生最优策略。在这一节中﹐提出了一个简单查询的最优算法(在这种查询的限定中出现的所有关系都有相同的属性﹐并且每个关系都有一个属性)。

一个策略的成本是执行边所代表的半连接的数据传输成本之和。由于在策略执行前不可能找到策略的精确成本,通常的程序是使预期成本最小化。

对于简单查询,优化策略可以满足某些属性。它们的列表如下:所有关系都应该出现在一个方向上。有两种情况。在第一种情况下,结果站点是包含R1、R2 . . . . . Rn。在另一种情况下,站点不包含这n种关系中的任何一种。

如果结果位点不包含这n种关系中的任何一种,那么最优策略中的所有关系都是不同的;也就是说,关系不会出现超过一次。这个结论是相当明显的,因为如果一个关系出现两次或两次以上,那么该关系的第二次和后续的出现就可以从该策略中移除,产生一个等价但成本更低的策略。因此,最优策略实际上是R1、R2 . . . . . Rn。对于简单的查询,可以容易地获得最佳策略。

TREG查询的最优策略

在此只说明一种情况,以获得最佳策略来完全减少树状查询的尖系。其限制条件是任何两个关系最多只有一个共同的连接属性。

基于半连接的启发式算法

讨论两种使用半连接的查询处理算法。它们假设查询引用的每个关系的一个副本已经被选择,然后执行简化和组装阶段。

第一种半连接X-A-Y的成本定义为将X.A从包含A的站点转移到包含Y的站点的成本(如果两个站点相同,成本为零)。半连接的好处是操作前Y的大小减去操作后Y的大小。如果成本小于收益,那么这个半连接是有利可图的。

减少阶段是非常简单的﹔它确定了任何两个关系之间所有可能的半连接。每个半连接的成本和收益都被估算出来。然后选择一个具有最小成本的有利的半连接。

那些可能被半连接策略影响的成本和收益不断更新,并涉及了接下来的半连接。这个过程重复进行,直到找不到有利的半连接为止。

基于连接的算法

虽然半连接的使用减少了数据传输的数量,但它并不总是最优解。一个原因是,对于某些网络,交换的消息数量可能更重要,而不是传输的数据量。

毕竟当使用半连接时,可能会生成额外的消息。另一个原因是,本地处理成本可能会非常高。最后,尽管半连接可以并行执行,但使用半连接的效应时间最小化是很复杂的。

第二种:有教授提出了一种算法,它是上文中给出的处理简单查询的最佳算法的推广。该算法构造的策略是n个子策略的并集,每个子策略对应一个关系,其中n是查询引用的关系数。考虑查询的关系R。设A是R的一个连接属性,寻找一个最佳的方法来简化R,并只在属性A上使用半连接将R发送到结果站点产生答案。

枚举算法

该算法首先将查询中的关系集划分成两个互补的组G1和G2,其中G1具有至少两个关系,而G2具有零个或多个关系。接下来,通过将包含最大关系的站点指定为结果站点,并将G1中的所有其他关系发送给它,来获得G1中的关系的子策略。它通过递归调用G2中的关系来寻找最小代价子策略。

假设关系R1、R2和R3位于不同的位置,并且查询请求这三个关系的连接,算法会首先将R1、R2和R3划分为{{R1, R2}, {R3}}。然后构造{R1, R2}的最小代价子策略,将两个关系R1和R2中的较小的一个发送给另一个。将R1与R2的关系(例如T1)加入到第二组中,寻找{T1, R3}的最小代价子策略。然后得到R1、R2和R3的连接策略。重复相同的过程为{{R1, R3},{R2}},{{R2,R3}, {R1}},和 {{R1,R2,R3},{ }}。最后,得到查询的最优策略。

非数值算法

它将一个查询分解为链式查询﹐并解决它们以获得答案。

链式查询指的是其查询图是一条链的查询。

一个给定的链式查询被分解成多个子查询,在两个连续的子查询之间最多只有一个共同变量。每个子查询都是不可化简的。我们假设关系不被分割﹐只考虑数据通信成本。如果一个子查询是一个有两个节点的链﹐比如Rx和Ry,那么要么Rx被发送到包含Ry的站点,要么Ry被发送到包含Rx的站点,这取决于哪个策略产生的成本更低。如果子查询是一个循环查询﹐那么就必须决定是一次性处理整个子查询还是将其细分为若干部分。如果子查询有以下情况﹐则对其进行细分来降低成本。

假设给定一个指定为根节点的链式查询。该算法找到集合点﹐也就是查询所引用的数据数量最多的站点。然后,该算法重复以下过程﹐直到得到链式查询的答察。从一个叶子开始﹐算法先把叶子和它的父本连接起来,然后把结果发送到集合点﹐检查是否比直接把两个关系发送到集合点并在那里进行连接的成本要低。如果前一种策略的成本较低﹐那么叶子节点和它的父节点就会被合并﹐形成一个临时关系﹐并且查询图被修改﹐用新创建的关系替换连接两个关系的图的部分。否则﹐叶子节点就会被送到装配点,并从查询图中删除。这个过程在修改后的查询图上重复进行。当两个关系被连接时﹐算法将较小的关系发送到包含较大关系的站点并合并它们。

片段处理

一个关系可以被视为一个矩阵,其中行代表元组,列代表属性。关系的水平片段是矩阵行的子集。它是通过对关系应用选择操作获得的。有时一个水平片段在一个站点被频繁访问,而另一个水平片段在另一个站点被频繁引用。因此,根据它们的参考位置将片段分配给站点可能是有益的。

关系的垂直片段是关系的列的子集,并且通过使用关系上的投影运算来构造。这一节只讨论水平碎片。这个方法中,引用分段关系的查询首先被分解成子查询。然后,使用第7节中描述的算法来获得每个子查询的答案。所有子查询答案的并集就是该查询的答案。

转换方法

也许处理查询的更系统的方法是转换方法。在这种方法中,存在一组规则,其中每个规则将查询表达式转换成等价的表达式。这个想法是重复应用这些规则来获得一个可以用很小的代价评估的表达式。通常,应用一元操作符(如project或select)后的结果关系往往比原始关系小,而应用二元操作符(如join或union)后的结果关系可能比原始操作数大得多。如果操作数在不同的位置,则可以通过应用一元操作符来减小它们的大小,同时保持表达式的等价性。

例如,在属性B上加入RI(A, B, C)和R2(B, E, F)关系,然后将结果投影到属性(A, B, E)上,相当于在属性A和B上投影R1来消去C,在属性B和E上投影R2来消去F,然后再将两者的简化关系进行连接。如果R1和R2在不同的位置,则后一种表达式可以用较少的数据传输来计算,因此更可取。

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

2021—:地理分布查询处理方法

今天的全球化世界拓宽了数据分析应用的前景。大型组织在不同的站点上容纳多个数据库和IT基础设施组织需要在不同的地点进行数据分析。以统一的方式支持地理分布式数据分析对组织的日常运营至关重要。本部分介绍了一个基于遵从性的查询优化器,该优化器考虑了数据流策略,这些策略使用我们的策略表达式声明性地指定,以生成遵从性的地理分布式执行计划。

前提例子

有一个公司名叫CarCO,它在三个地区拥有分公司。

它的总部在欧洲,同时在欧洲拥有多个办事处。数据库记为DN。

它有子公司在北美。数据库记为DE。

供应商制造部门在亚洲。数据库记为DA。

数据表为:

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

因为在实际的地理情况当中,数据的运输被规则所约束,称之为数据流约束。

假设CarCo公司不同地理位置的数据流为:

1.北美的客户只有在压制账户余额信息后才能发往国外。

2.只有聚合的订单数据才能从欧洲发送到亚洲,订单价格不能发送到北美。

3.只有从亚洲汇总的订单数量和延伸价格才能发往欧洲。

这里的工作目标有两个:

1.确定简单有效的数据流策略。

2.设置优化器。

关于数据流策略

定义

数据流策略指定了哪些信息以及这些信息可以合法传输的方式和位置。

我们把数据流策略用【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区来表示【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区表示在D位置上的信息可以运输到位置LD上。

政策规范

一种简单而直接的指定方式——策略表达式。

两个规定:

1.用屏蔽函数转换数据(简单表达式和聚合表达式)。

2.信息披露模式(指明什么数据不允许被发送)。

举例一个查询如下:

select C.name,sum(O.totprice),sum(S.quantity)
from Custom AS C,Orders AS O,Supply AS S
where C.custkey=O.custkey and O.ordkey=S.ordkey
group by C.name

该查询表示查询Custom表中的name属性,Orders表中totprice的总和当C.custkey=O.custkey时以及Supply表中的quantity的总和当O.ordkey=S.ordkey时,并且以name属性。

简单表达式

假设该策略还允许将客户的mktsegment和区域信息发送到CarCo的商业客户的欧洲。我们可以使用以下策略表达式:

ship custkey,name from Customer C to Asia, Europe
ship mktseg, region from Customer C to Europe
where mktseg=‘commercial’

聚合表达式

虽然简单的表达式足以表示各种各样的数据流策略,但有些策略只允许传递聚合信息。

ship acctbal as aggregates sum, avg from Customer C
to * group by mktseg, region

兼容的优化查询处理

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

系统将策略存储在策略目录中,以进行查询优化。在查询时,基于遵从性的查询优化器在枚举计划时使用这个策略编目(通过策略评估器)来验证它们是否符合输入数据流策略。优化器使用这种验证机制来知道最终查询执行计划(QEP)何时违反了现有的数据流策略。如果是,则拒绝执行查询。只有当生成的QEP符合要求时,它才会继续执行查询。

兼容的查询处理框架依赖于两个核心部分:(i)指定与每个数据位置相关的数据流策略,以及(ii)在这些策略下的查询优化过程。在下文中,我们将首先形式化数据流策略和遵从查询计划的概念,然后定义遵从查询处理问题。

跨境数据流策略描述了跨组织和/或地理边界传输数据的限制。一般来说,数据流策略指定了哪些信息以及这些信息可以合法传输的方式和位置。

基于火山的优化器生成器

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

1.引入了新的抽象逻辑属性来注释操作符。

执行特征是一个逻辑属性,描述操作符在哪里可以合法执行,而运输特征描述操作符的输出在哪里可以合法运输。

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

如该图所示,节点3表示一个执行特征,表示该执行在北美被允许。

节点4表示运输特征,节点3的结果可以运输到欧洲和北美。

根据数据流策略,操作符节点可以有0个、1个或多个执行和传递特征。

2.调整每个物理操作符的成本函数。

扩展了代价函数来考虑操作符的执行特征,以防止优化器丢弃操作符尚未注释的计划/子计划。

3.引入了一组规则,允许我们以在计划枚举期间确定注释。

它们使优化器能够在优化过程中获得计划操作符的执行和交付特征。优化器通过其规则引擎将操作符节点与注释规则进行匹配,以获得其运输和执行特征。

四个注释规则:

(1)假设一个操作符节点n有一个执行特征【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区,那么l是合法操作执行的位置。

(2)假设一个操作符节点n有一个执行特征【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区,表示在操作的所有输入都可以运到l处时,操作可以在强制在l处进行。例如,在美国加入来自欧洲和亚洲的数据,只有当这两种数据都能合法运到美国时才执行合法操作。

(3)假设一个操作符节点n有一个运输特征【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区即运输特征为运输特征和执行特征的并集,那么操作员的输出总是可以合法地运送到合法执行它的地点。

(4)假设一个操作符节点n有一个运输特征【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区,该规则对属于单个数据源的查询子表达式调用策略评估。

计划注释器Plan Annotator——优化第一阶段

计划注释器的作用:接收逻辑计划和基于遵从性的优化目标作为输入,以输出带注释的QEP。

遵从以优化目标为基础:

将优化目标设置为计划向量,该向量指定非空运输特性的需求,以及所需的物理属性。

优化过程

假设给定一个逻辑表达式和基于遵从性的优化目标,计划注释器从初始表达式树开始。计划注释器从一个初始表达式树开始,通过Volcano的规则引擎反复应用规则来枚举qep的搜索空间。

规则有:

1.代数等价规则。

2.逻辑运算符节点转换为物理运算符节点的实现规则。

3.强制规则可以“强制”输入具有特定的物理属性。

该计划注释器依赖于Volcano的搜索引擎和基于成本的修剪,以确定成本最低的注释计划。

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

上图即为一个优化后的带有注释的QEP查询图

站点选择器Site Selector——优化第二阶段

此时已经拥有一个带注释的QEP图。

站点选择器的作用是继续放置操作符节点。

可能造成的后果:计划成指数级增长。

又上述可知站点选择器不宜使用贪婪方法和穷尽枚举,而是使用动态规划:一种记忆的递归自顶向下。

站点选择器算法:

【DQOS】啃论文俱乐部——分布式查询优化的历史与现状-开源基础软件社区

​想了解更多关于开源的内容,请访问:​

​51CTO 开源基础软件社区​

​https://ost.51cto.com​​。

责任编辑:jianghua 来源: 鸿蒙社区
相关推荐

2022-08-22 17:36:13

啃论文方法啃论文俱乐部

2022-05-13 23:03:25

大数据Big Data巨量资料

2022-09-19 14:25:35

JSON压缩算法

2010-07-06 09:39:20

SQL Server分

2022-04-07 15:03:07

Harmony计算机鸿蒙

2022-04-20 20:37:58

鸿蒙操作系统

2022-10-18 16:14:28

2022-03-28 15:09:17

无线传感器网络Harmony鸿蒙

2022-05-13 22:44:35

物联网算法鸿蒙

2022-06-27 14:01:31

LZ4 分析数据密集型压缩算法

2024-05-23 10:19:57

2022-06-15 16:06:29

LZ4 算法硬件加速

2022-09-07 15:08:58

操作系统鸿蒙

2022-05-12 15:05:32

云计算数据压缩

2022-09-06 15:46:52

speexdsp鸿蒙

2022-09-16 15:01:37

操作系统技术鸿蒙

2022-09-13 16:10:15

鸿蒙操作系统

2022-06-08 16:29:45

无损压缩方案分布式

2022-09-14 15:28:19

操作系统鸿蒙

2022-09-15 15:21:22

操作系统鸿蒙
点赞
收藏

51CTO技术栈公众号