数据库内核月报 - 2016 / 02

PgSQL · 答疑解惑 · PostgreSQL 9.6 并行查询实现分析

背景

随着PG9.5 项目的release,属于PG9.6的代码也陆续进入代码主干,其中最让人激动的特性并行查询终于进入了核心代码。pger们对这个新特性期待了太久的时间,代码刚提交我们就迫不及待的拿到,从设计到性能进行一番探究,并通过本文介绍给大家。

并行技术的过去和未来

这是个很困难的工作,要说清楚它需要讲清楚并行技术相关的一些背景。

PG 目前的架构是基于多进程的,必要的信息通过共享内存这样的机制来传递。
该架构的好处是:

  1. 代码相对简单;
  2. 在多CPU环境下多会话任务可以由操作系统来调度;
  3. 多进程程序相对稳定。

不幸的是,虽然多会话任务可以利用操作系统并行调度满足需求,但是单个任务却只能最多使用一个CPU和一个IO通道。最近的计算机架构发展呈现出这样的发展趋势

  1. 单个CPU的运算能力没有大增长;
  2. 越来越多的CPU核心;
  3. SSD 存储的崛起 I/O 延迟急剧降低(尤其随机读写)。

但是数据库要处理的单个会话任务的复杂程度却急剧增加(想想复杂的多表JOIN任务、大表扫描任务、聚合操作和大量数据排序任务,再想想OLAP报表SQL)。单个任务的处理能力越来越成为了数据库任务处理的瓶颈.

PG发展路线是相对保守的,即使在这样的趋势下,已经在多个方面使用了并行技术。

  1. 利用部分OS系统调度的并行IO调度(effective_io_concurrency,已完成);
  2. 并行逻辑备份和恢复技术(已完成);
  3. 并行执行器(in pg96)。

对于并行执行器,也就是本文讨论的内容,相对于其他的技术点难度显然大得多。
对于目前的架构,单个SQL任务的执行被明显的分为:

  1. 语法分析语义识别;
  2. 查询重写;
  3. 产生查询计划;
  4. 执行查询计划。

一共4个大的阶段。并行技术很难把这几个明显的阶段并行起来执行,也不可能把某一阶段的工作提前。但是把执行查询计划这个阶段并行起来是可能的,也就是并行执行器。

设计思路

整个设计可以分为下面几个大的部分

  1. 一套用于并行执行框架的基础设施
    包括容错机制,这部分工作涉及到的点很杂也很多,按照计划在PG9.5之前就已经实现了其中的大部分。其中很重要的是容错机制,主进程需要了解属于自己工作进程的执行状态,处理工作进程执行过程中发生的任何错误,还有动态工作进程,动态共享内存API等等工作进程消息处理。

  2. 修改优化器,在传统的代价模型基础上增加计算并行执行路径的的代价数据,优化器能够输出并行执行计划。增加并行执行节点相关的path、plan,用于存放并行相关的代价信息。

  3. 开发一套用于多进程间同步数据的机制,目前的实现是开辟共享内存。当然也有其他选择,发送和接受数据的格式和形式也需要设计。

  4. 动态启动多个工作进程,把查询计划中部分任务下发给它们执行
    需要重组目前传统的执行器流程,也就是在目前执行器上面添加用户并行处理的执行节点:1)并行扫描节点,2)数据发送接收节点。

结合代码进行说明

还是从设计思路的4个方面讲。

基础设施
如上面的描述,这部分相当的杂,这些都是实现并行执行的技术设施。下面列举主要的部分:

  1. 动态共享内存,9.4完成,并提供了几种底层的实现选择(不同的OS选择不同),参考参数 dynamic_shared_memory_type
  2. 共享内存消息队列shm_mq,用于通过共享内存传递数据和状态。通过核心函数 shm_mq_receive ,可以看到无论是数据还是错误消息都通过该机制来同步;
  3. 主进程同步给工作进程相关的各种会话信息
    • 动态库 RestoreLibraryState()
    • 用户信息,用户登录的DB BackgroundWorkerInitializeConnectionByOid()
    • 当前会话中的GUC参数,并行SQL所在的事务信合和状态 RestoreGUCState()
    • 快照信息 RestoreSnapshot()
    • ComboCID信息 RestoreComboCIDState()

可以看到,为了让工作进程完成部分工作,需要装载主进程的很多上下文信息。这里有大量的工作,也意味着并行模式需要承担一定的代价。这一点PG的并行模型的代价模型实现中有清晰的考虑。

完成了这一步,才能重用目前执行器中的大量现有流程。

修改优化器
考虑优化器的相应修改,我们知道PG优化器生成执行计划是基于代价模型,并行执行在优化器的重点就是考虑如何准确估计并行执行的代价。

实现原理:新增并行相关的节点的执行path,并填充他们准确的 cost,让它们参与到动态规划或遗传算法的迭代计算中。最终如果并行相关path最优,则创建完整的执行计划交给执行器执行.

  1. 新增的cost类型
    • parallel_setup_cost 并行计划启动代价,对应工作进程的创建和上下文信息的传递所需要的代价。它也说明只有需要一定工作量的复杂SQL才有必要使用并行方式执行;
    • parallel_tuple_cost 主进程和工作进程间传递数据是需要消耗资源的,这取决于实现它的方式(目前消耗的资源多是内存拷贝和tuple的重组和解析);
      上述代价是并行执行模型需要考虑的,结合统计信息中表上的其他信息,能预估出对应表或JOIN使用并行模型执行时的代价。
  2. cost_seqscan 顺序扫描采取了并行的执行方式,需要计算并行模式的代价。
    顺序扫描的代价分为3个部分 startup_cost + cpu_run_cost + disk_run_cost 并行模式下CPU 和 DISK 被分担到了多个工作进程中,每个工作进程处理整个表中的一部分数据。相应的代价被重新评估.
    • create_parallel_paths 适合并行的表创建并行path并,并填充cost;
    • standard_planner 当然并行模式并不适合所有查询,做逻辑优化阶段需要关掉并行计划的计算;
    • 当然,随着工作进程能承担的工作越多,更多的执行节点可以让工作进程完成,在优化器中需要做适当的节点下推(push down)。

数据同步
这部分(shm_mq)底层使用共享内存在一个OS中,在多个独立进程间同步数据。在实现上又抽象成了消息队列的形式,用于工作进程和主进程间同步数据。

表上的数据(tuple)和错误消息被封装成”消息”的形式发送给主进程,核心函数shm_mq_sendvshm_mq_receive 可以看到,底层实现是通过在共享内存上用memcpy来做的。

执行流程重组
执行器的工作主要是改造传统的逐层迭代方式以支持并行执行方式,当然是在重用之前代码的基础上,几个关键的实现是:

  1. ExecGather 添加用于接受工作进程发送数据的节点,内部调用了底层shm_mq 模块中的API;
  2. 在工作进程空间中,添加流程 ParallelQueryMain 用于工作进程完成工作并把数据通过 shm_mq 发送给主进程;
  3. 改造顺序扫描执行节点和下层的存取节点,支持按照blocknum为单位并行扫描同一个表。核心函数 heap_parallelscan_nextpage,他决定当前工作进程扫描任务是如何分配的。

该部分的工作重用了大量的旧的流程,但这和之前的执行器的工作模式有本质的区别,大量任务在独立的进程空间中由OS 并行的调度执行,它们用 shm_mq 传递数据。

总结

从公布的测试数据上来,部分场景在并行模式下能显著提高性能。

由于并行模式有一定的开销(被抽象成了各种成本),它并不是万金油。当然,好的实现能让它适应更多更复杂的场景。数据量特别小的场景不适合使用并行,这一点优化器能很好的评估成本,选择正确的执行计划。

其次,并行工作进程并不是越多越好,多到一定程度后性能的提升就不明显了。

目前能放在工作进程中并行执行的任务还不多,只支持扫描类型的任务,但是整个并行框架是有了基本的雏形,相信几轮迭代之后整套执行框架会越来越高效和稳定。