哪个网站做视频收益高,软件界面设计欣赏,网站建设实训报告册,wordpress建商城平台简介#xff1a; 随着数据规模的不断扩大#xff0c;用户SQL的执行时间越来越长#xff0c;这不仅对数据库的优化能力提出更高的要求#xff0c;并且对数据库的执行模式也提出了新的挑战。本文将介绍基于代价进行并行优化、并行执行的云数据库的并行查询引擎的关键问题和核…简介 随着数据规模的不断扩大用户SQL的执行时间越来越长这不仅对数据库的优化能力提出更高的要求并且对数据库的执行模式也提出了新的挑战。本文将介绍基于代价进行并行优化、并行执行的云数据库的并行查询引擎的关键问题和核心技术。 作者 | 智邻 来源 | 阿里技术公众号
一 背景
随着数据规模的不断扩大用户SQL的执行时间越来越长这不仅对数据库的优化能力提出更高的要求并且对数据库的执行模式也提出了新的挑战。随着数据库在云上的蓬勃发展越来越多的传统用户迁移到云上享受云上弹性扩展的红利但是随着业务的快速扩张却发现即使动态增加了很多资源但SQL的执行时间还是越来越慢并没有随着资源的投入达到预期的效果。显而易见虽然新增了很多资源但这些资源并没用被充分利用很多传统的商业数据库如Oracle、SQL Server等都提供对并行查询引擎的支持以充分利用系统资源达到加速SQL执行的效果。
本文主要介绍基于代价进行并行优化、并行执行的云数据库的并行查询引擎的关键问题和核心技术。
二 如何将查询并行起来
对于一个类OLAP的查询显而易见的是它通常是对大批量数据的查询数据量大意味着数据远大于数据库的内存容量大部分数据可能无法缓存到数据库的缓冲区中而必须在查询执行时才动态加载到缓冲区中这样就会造成大量IO操作而IO操作又是最耗时的因此首先要考虑的就是如何能加速IO操作。
由于硬件的限制每次IO的耗时基本是固定的虽然还有顺序IO和随机IO的区别但在SSD已经盛行的今天两者的差异也在逐渐接近。那么还有没有其它方式可以加速IO呢? 显然并行IO是一个简单易行的方法如果多个线程可以同时发起IO每个线程只读取部分数据这样就可以快速的将数据读到数据库的缓冲区中。 并行读取数据的示意如上图所示每个worker代表一个线程如果数据已经有partition分区可以每个线程读取一个partition也可以将全部数据按固定大小进行分片比如按一个数据页面大小然后每个线程以Round-robin模式轮询读取一个分片。
这里需要注意的是按已有partition分配给不同worker可能会导致每个worker处理的数据不均匀而按Round-robin模式进行轮询如果分片设置的比较小相对来说就比较容易做到每个worker处理的数据比较均匀。
如果只是将数据读取到缓冲区中而不是立即进行后续处理那么这些数据就会因缓冲区爆满导致数据被换出从而失去加速IO的意义。因此在并行读取数据的同时必须同时并行的处理这些数据这是并行查询加速的基础。
传统的优化器只能生成串行的执行计划为了实现并行读取数据同时并行处理数据首先必须对现有的优化器进行改造让优化器可以生成我们需要的并行计划。比如选择哪个表或哪些表可以并行读取并且通过并行读取会带来足够的收益或者哪些操作可以并行执行并且可以带来足够的收益。
并不是说并行化改造一定会有收益比如对一个数据量很小的表可能只是几行如果也对它进行并行读取的话并行执行所需要的多线程构建再加上线程间的数据同步等所需要的代价可能远大于所得到的收益总体来说并行执行会需要更多的资源和时间这就得不偿失了。因此查询计划的并行化必须是基于代价的否则可能会导致更严重的性能退化问题。
三 如何选择并行扫描的表
选择并行扫描的表是生成并行计划的重要基础通过基于并行扫描代价的计算和比较选择可以并行扫描的表作为候选是并行执行计划迭代的第一步。基于新的并行代价也许会有更优的JOIN顺序选择尤其是当参与JOIN的表的数量比较多时这需要更多额外的迭代空间为防止优化过程消耗太多的时间保持原有计划的JOIN顺序是一个不错的选择。另外对于参与JOIN的每张表因为表的访问方法不同比如全表扫描、Ref索引扫描Range索引扫描等这些都会影响到最终并行扫描的代价。
通常我们选择最大的那张表作为并行表这样并行扫描的收益最大当然也可以选择多个表同时做并行扫描后面会继续讨论更复杂的情况。
下面以查询年度消费TOP 10的用户为例
SELECT c.c_name, sum(o.o_totalprice) as s
FROM customer c, orders o
WHERE c.c_custkey o.o_custkey AND o_orderdate 1996-01-01 AND o_orderdate 1996-12-31
GROUP BY c.c_name
ORDER BY s DESC
LIMIT 10;
其中orders表为订单表数据很多这类表也被称之为事实表customer表为客户表数据相对较少这类表也被称之为维度表。那么此SQL的并行执行计划如下图所示 从计划中可以看出orders表会做并行扫描由32个workers线程来执行每个worker只扫描orders表的一部分数据分片然后与customer表按o_custkey做index lookup进行JOINJOIN的结果发送到一个collector组件然后由collector组件继续做后续的GROUP BY、ORDER BY及LIMIT操作。
四 选择多表并行的JOIN
将一张表做并行扫描之后就会想为什么只能选择一张表如果SQL中有2张或更多的FACT表能不能可以将FACT表都做并行扫描呢答案是当然可以。以下面SQL为例
SELECT o.o_custkey, sum(l.l_extendedprice) as s
FROM orders o, lineitem l
WHERE o.o_custkey l.l_orderkey
GROUP BY o.o_custkey
ORDER BY s
LIMIT 10;
其中orders表和lineitem表都是数据量很大的事实表此SQL的并行执行计划如下图所示 从计划中可以看到orders表和lineitem表都会做并行扫描都由32个workers线程来执行。那么多个表的并行是如何实现的呢我们以2个表为例当2个表执行JOIN时通常的JOIN方式有Nested Loop JOIN、HASH JOIN等对于不同的JOIN方式为保证结果的正确性必须选择合理的表扫描方式。
以HASH JOIN为例对于串行执行的HASH JOIN来说首先选择一个表创建HASH表称之为Build表然后读取另一个Probe表计算HASH并在Build表中进行HASH匹配若匹配成功输出结果否则继续读取。如果改为并行HASH JOIN并行优化器会对串行执行的HASH JOIN进行并行化改造使之成为并行HASH JOIN并行化改造的方案可以有以下两种解决方案。
方案一是将2个表都按HASH key进行分区相同HASH值的数据处于同一个分区内由同一个线程执行HASH JOIN。方案二是创建一个共享的Build表由所有执行HASH JOIN的线程共享然后每个线程并行读取属于自己线程的另外一个表的分片再执行HASH JOIN。最终选择哪种方案通过代价估算来决定。 图2 并行HASH JOIN示意图 对于方案一需要读取表中的所有数据根据选中的HASH key对数据进行分区并将数据发送到不同的处理线程中这需要额外增加一个Repartition算子负责根据分区规则将数据发送到不同的处理线程。对于方案二需要并行创建共享的HASH build表当build表创建成功后每个线程读取Probe表的一个分片分别执行HASH JOIN这里的分片并不需要按照HASH key进行分片每个线程分别读取互不相交的分片即可。
五 分析统计的复杂算子的并行
对于一个分析统计的需求GROUP BY操作是绕不开的操作尤其对大量的JOIN结果再做GROUP BY操作是整个SQL中最费时的一个过程因此GROUP BY的并行也是并行查询引擎必须优先解决的问题。
以年度消费TOP10客户的SQL为例对GROUP BY并行化后的并行执行计划如下图所示 与之前的执行计划相比新的执行计划中多了一个collector组件总共有2个collector组件。首先我们看第二行的collector组件它的extra信息中有2条Using temporary; Using filesort这表示它是对从workers接收到的数据执行GROUP BY然后再按ORDER排序因为只有第一个collector组件在用户的session中所以这个collector也是在worker中并行执行也就是说并行的做Group by和Order by以及Limit然后看第一行的collector组件它的extra信息中只有一条Merge sort表示session线程对从workers接收到的数据执行一次merge sort然后将结果返回给用户。这里可能就有人会提出疑问为什么session线程只做merge sort就可以完成GROUP BY操作呢另外LIMIT在哪里呢
首先回答第2个问题因为explain计划显示的问题在常规模式下不显示LIMIT操作但在Tree模式下会显示LIMIT操作。如下所示 从Tree型计划树上可以清楚的看到LIMIT操作有2处一处在计划的顶端也就是在session上做完limit后将数据返回给用户另外一处在计划树的中间位置它其实是在worker线程的执行计划上在每个worker线程中在排序完成后也会做一次limit这样就可以极大减少worker返回给session线程的数据量从而提升整体性能。
下面来回答第一个问题为什么GROUP BY只需要在worker线程上执行一次就可以保证结果的正确性。通常来说每个worker只有所有数据的一个分片只在一个数据分片上做GROUP BY是有极大的风险得到错误的GROUP BY结果的因为同一GROUP分组的数据可能不只是在本WORKER的数据分片上也可能在其它WORKER的数据分片中被其它WORKER所持有。但是如果我们可以保证同一GROUP分组的数据一定位于同一个数据分片并且这个数据分片只被一个WORKER线程所持有那么就可以保证GROUP BY结果的正确性。通过Tree型执行计划可以看到在并行JOIN之后将JOIN的结果按GROUP分组的KEY值: c.c_name进行Repartition操作将相同分组的数据分发到相同的WORKER从而保证每个WORKER拥有的数据分片互不交叉保证GROUP BY结果的正确性。
因为每个WORKER的GROUP BY操作已经是最终结果所以还可以将ORDER BY和LIMIT也下推到WORKER来执行进一步提升了并行执行的效率。
六 并行查询引擎对TPCH的线性加速
附图是一个并行查询引擎对TPCH的加速效果TPC-H中100%的SQL可以被加速70%的SQL加速比超过8倍总和加速近13倍Q6和Q12加速甚至超过32倍。 七 总结
数据库是应用系统的核心而优化器是数据库的核心优化器的好坏几乎可以决定一个数据库产品的成败。开发一个全新的优化器对任何团队都是一个巨大的挑战技术的复杂度暂且不提就是想做到产品的足够稳定就是一个非常难以克服的困难。因此即使传统商业数据库也是在现有优化器的基础上不断改进逐渐增加对并行的支持最终成为一个成熟的并行优化器。对PolarDB也是如此在设计和开发并行查询引擎时我们充分利用现有优化器的技术积累和实现基础不断改进不断打磨最终形成了一个持续迭代的技术方案以保证新的优化器的稳定运行和技术革新。
原文链接
本文为阿里云原创内容未经允许不得转载。
