深度解析PolarDB数据库并行查询技术

简介： 随着数据规模的不断扩大，用户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