PolarDB-X是阿里巴巴自研的云原生分布式数据库,采用了计算-存储分离的架构,其中计算节点承担着大量的表达式计算任务。这些表达式计算涉及到SQL执行的各个环节,对性能有着重要的影响。为此PolarDB-X引入向量化执行引擎,为表达式计算带来了几十倍的性能提升。
传统数据库执行器的缺陷
现代数据库系统的执行引擎,大多采用一次计算一行数据(Tuple-at-a-time)的处理方式,并且需要在运行时对数据类型进行解析和判断,来适应复杂的表达式结构。我们称之为“标量(scalar)表达式”。这种方式虽然易于实现、结构清晰,但是当需要处理的数据量增大时,它具有显著的缺陷:
为了适应复杂的表达式结构,计算一条表达式往往需要引入大量的指令;对于行式执行来说,处理单条数据需要算子树重新进行指令解释(instruction interpretation),从而带来了大量的指令解释开销。据论文 MonetDB/X100: Hyper-Pipelining Query Execution 统计,在MySQL执行TPC-H测试集的 Query1 时,指令解释就耗费了90%的执行时间。 此外,在最初的Volcano结构设计中,算子内部逻辑并没有避免分支预测(branch prediction)。错误的分支预测需要CPU终止当前的流水线,将ELSE语句中的指令重新载入,我们将这一过程称为pipeline flush或pipeline break。频繁的分支预测错误会严重影响数据库的执行性能。
向量化执行系统
数据库向量化执行系统最早由论文 MonetDB/X100: Hyper-Pipelining Query Execution 提出,它有以下几个要点:
- 采用vector-at-a-time的执行模式,即以向量(vector)为数据组织单位。
- 使用向量化原语(vectorization primitives)来作为向量化算子的基本单位,从而构建整个向量化执行系统。原语中避免产生分支预测。
- 使用code generation(代码生成)技术来解决静态类型带来的code explosion(代码爆炸)问题。
向量化引擎为PolarDB-X的表达式计算带来了显著的性能提升。在下图中,横轴为向量大小,纵轴为吞吐量,不同标量表达式和向量化表达式的性能测试对比结果如下:
![f58dacde7b7dd566f456bc9bc02d58d3.png](https://i-blog.csdnimg.cn/blog_migrate/99506ca18af523e36343a8f30fed67c6.jpeg)
CASE 表达式性能测试对比结果如下:
![d952290f8c5e526bd8a051a7f4b8a4e1.png](https://i-blog.csdnimg.cn/blog_migrate/7bfe4ec9348ac6bf7f02e67af0134a5e.jpeg)
整体流程
PolarDB-X中,向量化表达式的执行分为以下几个阶段:
- 用户SQL经解析后,在validator中进行校验,推导和修正表达式的类型信息;这一阶段为向量化运算提供正确的、静态的类型信息;
- 在优化器形成执行计划之后,需要对表达式树进行表达式绑定,实例化对应的向量化原语,同时分配好向量下标,供运行时内存分配;
- 执行阶段,依据Volcano式的结构,自顶向下的触发执行向量化原语,并将向量作为运行时数据结构。
![4181a278af8ce9c22780141aa86e8863.png](https://i-blog.csdnimg.cn/blog_migrate/122bd049300e7e8cb5279ef8ea7e144b.jpeg)
运行时数据结构
在PolarDB-X向量化执行系统中,采用以下的数据结构来存放数据:
![733d548ddf7f9fafd7c7828b7437c0a1.png](https://i-blog.csdnimg.cn/blog_migrate/f45a51fb9cdf8b2ff3ed6354f10e45c9.jpeg)
向量化表达式执行时,所有的数据都会存放在batch这一数据结构中。batch由许多向量(vector)和一个selection数组而组成。其中,向量vector包括一个存储特定类型的数值列表(values)和一个标识null值位置的null数组组成,它们在内存中都是连续存储的。null数组中的bit位以0和1来区分数值列表中的某个位置是否为空值。 我们可以用vector(type, index)来标识batch中一个向量。每个向量有其特定的下标位置(index),来表示向量在batch中的顺序;类型信息(type)来指定向量的类型。在进行向量化表达式求值之前,我们需要遍历整个表达式树,根据每个表达式的操作数和返回值来分配好下标位置,最后根据下标位置统一为向量分配内存。我们将在表达式绑定这一章节中详细介绍向量下标。
延迟物化
selection数组的设计体现了延迟物化的思想,参考论文《Materialization Strategies in a Column-Oriented DBMS》。所谓延迟物化,就是尽可能地将物化(matrialization)这一过程后推,减少内存访问带来的开销。在执行表达式计算时,往往会先经过Filter表达式过滤一部分数据,再对过滤后的数据执行求值处理;每次过滤都会影响到batch中所有的向量。以上图中的batch为例,如果我们针对第0个向量设置 vector(int, 0) != 1这一过滤条件,假设vector(int, 0)中有90%的数据满足该过滤条件(选择率selectivity = 0.9),那么我们需要将batch中所有向量90%的数据重新物化到另一块内存中。而如果我们只记录满足该过滤条件的位置,存入selection数组,我们就可以避免这一物化过程。相应的,以后每次向量化求值过程中,都需要参考此selection数组。
向量化原语
向量化原语是向量化执行系统中的执行单位,它最大程度限制了执行期间的自由度。原语不用关注上下文信息,也不用在运行时进行类型解析和函数调用,只需要关注传入的向量即可。它是类型特定(Type-Specific)的,即一类原语只能处理特定类型。 向量化原语的主体是Tight-Loop的代码结构。在一个循环体内部,只需要进行取值和运算即可,没有任何的分支运算和函数调用。一个简单的向量化原语结构如下所示:
map_plus_double_col_double_col(int n,
double*__restrict__ res,
double*__restrict__ vector1, double*__restrict__ vector2,
int*__restrict__ selection)
{
if (selection) {
for(int j=0;j<n; j++) {
int i = selection[j];
res[i] = vector1[i] + vector2[i];
}
} else {
for(int i=0;i<n; i++)
res[i] = vector1[i] + vector2[i];
}
}
其运算过程利用了selection数组,逐步对向量进行取值、运算和存值,如下图所示:
![88a6fab3443ae1eb085756fbd90e9fff.png](https://i-blog.csdnimg.cn/blog_migrate/86f1bc481a86f56beb733af1bc70e3ff.jpeg)
向量化原语带来了以下优点:
- Type-Specific以及Tight-Loop的结构,大大减少了指令解释的开销;
- 避免分支预测失败和虚函数调用对CPU流水线的干扰,同时也能有利于 loop pipeline 优化
- 从向量中存取数据,有利于触发cache prefetch,减少cache miss带来的开销。
我们为各种标量化表达式提供相应的原语实现,从而完成从标量到向量化的转变。例如将加法运算 plus(Object, Object) 针对不同操作数类型生成原语,包括plus(double,double),plus(long, long)等。
短路求值
在向量化原语的基础上,我们可以进一步对分支运算(也称为控制流运算 Control-Flow)进行短路求值(short-circuit calculation)优化,提升表达式计算的性能。 例如,case 表达式由n个when表达式、n-1个then表达式、1个else表达式构成。对于表达式
select case when a > 1 then a * 2
when b > 1 then b * 2
else a * b
其逻辑语义是:
- 对于满足 a > 1 的向量位置,计算 a * 2;
- 对于满足 a <= 1 and b > 1 的向量位置,计算 b * 2;
- 对于满足 a <= 1 and b <= 1 的向量位置,计算 a * b;
- 把所有位置的数值组合在一起形成新的向量,输出。
具有以下树形结构:
![19198a357068f11435b0c435dc368266.png](https://i-blog.csdnimg.cn/blog_migrate/d622abe3bf5a084517c5e8b05fc12086.jpeg)
由于标量化表达式按照volcano结构编排,并提供了统一的next()的接口,case表达式必须执行完所有的子表达式a>1,a2,b>1,b2和a*b之后,将全部结果汇总到一起,最后做case语义处理。这种执行方式不能根据when表达式的处理结果及时终止计算过程,而是对全部子表达式无差别执行。
引入向量化执行器以后,我们可以设计短路求值来优化此问题,每一个子表达式需要被提供合适的selection数组,从而正确选择列中合适的位置来进行向量运算。设第i个when条件表达式接受的selection元素集合为
![83c9c944afd5fd892ec181a88862ed9c.png](https://i-blog.csdnimg.cn/blog_migrate/04cf6dddbab628851590d4dd9015c377.jpeg)
总结
PolarDB-X向量化引擎利用原语(primitive)来构建表达式,以向量作为运行时数据结构。每种原语仅为特定类型进行服务,从而减少了指令总数;原语中的tight-loop结构不仅对CPU流水线十分友好,也允许CPU进行数据预取,并且避免分支预测。此外,一些优化如延迟物化、短路求值,进一步提升了表达式求值性能。 然而,从用户SQL到向量化执行之间,存在着一道巨大的鸿沟。我们需要解决以下几个重要问题:
- 如何确定表达式的输入输出类型,并为SQL中的表达式分配合适的原语?
- 每个原语需要使用不同的向量来进行输入和输出,如何为正确地为原语分配向量?
- 每种原语仅为特定类型进行服务,那么我们必然需要为一个表达式配备大量不同的原语,来适应不同的数据类型。如何应对原语数量爆炸这一问题?
在下一篇文章—— PolarDB-X 向量化引擎(2) 中,我们将为上述问题的解决方案进行详细介绍,敬请期待!