KingbaseES PDML海量数据写入加速实战

原创于 2026-06-18 23:05:50 发布 · 3.4k 阅读

10 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#数据库 #云服务 #SQL #大数据

文章目录

让多核真正跑起来：KingbaseES PDML 海量数据写入加速实战

让多核真正跑起来：KingbaseES PDML 海量数据写入加速实战

在金融、政务等核心业务系统中，数据库不仅要保证稳定和可靠，还要应对越来越庞大的批量数据处理任务。无论是日终跑批、数据清洗，还是报表汇总，一旦数据规模达到数千万甚至数亿行，传统串行 DML 的执行效率就很容易成为系统瓶颈。

即使服务器拥有多核 CPU 和高速 SSD，如果数据库仍然采用单进程完成查询与写入，大量硬件资源也无法得到充分利用。针对这一问题，电科金仓 KingbaseES（KES）提供了并行 DML（PDML）能力，并通过 MGQ、GMQ 等执行计划，将查询、写入、索引维护和约束检查等任务分配给多个工作进程。

本文围绕一个典型的大规模数据插入场景，介绍 KES PDML 的工作原理、配置方法、SQL Hint 用法以及实际性能表现。

一、业务痛点：多核服务器为何仍被单核限制

在某大型银行的批处理业务中，DBA 需要执行一条复杂的 INSERT INTO ... SELECT ... 语句。该语句涉及多张基础表，数据总量达到 1.7 亿行。

服务器已经配置了 32 核高性能 CPU 和高速 SSD，但任务运行时却出现了明显的资源利用不均：

一个 CPU 核心长期处于高负载状态；
其他核心大部分时间处于空闲状态；
3000 万行单表插入在串行模式下约需 97 秒；
上亿行多表关联插入可能持续数小时。

这类现象的根本原因并不在于硬件性能不足，而是传统执行方式只能由单个进程完成主要工作。当单核计算能力达到上限后，继续增加 CPU 核数也无法直接缩短执行时间。

PDML 的价值就在于把原本集中在一个进程中的任务拆分给多个 Worker，使查询、计算和数据写入能够并行执行，从而真正发挥多核服务器的能力。

二、执行原理：MGQ 与 GMQ 有什么区别

KES 的并行 DML 采用“Leader 进程 + Worker 进程”的执行模型。Leader 负责协调任务，Worker 则按照执行计划处理各自的数据分片。

根据查询和修改阶段的并行范围不同，KES 主要提供 MGQ 和 GMQ 两类计划。

2.1 MGQ：查询阶段并行

MGQ 的全称为 Modify-Gather-Query。

在这种模式下，多个 Worker 可以并行完成数据扫描、过滤、关联和计算。查询结果汇总到 Leader 后，再由 Leader 统一执行数据修改操作。

其执行过程可以概括为：

Worker 并行执行查询；
查询结果汇总至 Leader；
Leader 单进程执行 Insert、Update 或 Delete。

MGQ 能够明显提升查询阶段的处理效率，更适合查询工作量较大、实际修改数据量相对较少的场景。

2.2 GMQ：查询与修改全流程并行

GMQ 的全称为 Gather-Modify-Query，也是 KES PDML 中更具代表性的执行方式。

与 MGQ 不同，GMQ 不仅并行处理查询，还会把数据修改任务一并分配给多个 Worker。每个 Worker 在完成自己负责的数据扫描和计算后，可以直接执行对应的数据写入。

其优势主要体现在以下几个方面：

查询和修改可以同时并行；
索引维护任务可以分散到多个进程；
约束检查不再完全由 Leader 承担；
CPU 密集型操作能够更均匀地分布到多个核心。

在适合并行执行的业务场景中，GMQ 的性能收益通常会随着并行度提升而增加。原测试数据显示，部分场景中的性能提升可达到 74%。

三、配置实操：开启 PDML 并行模式

3.1 开启 DML 并行功能

首先在当前会话中开启并行 DML：

SET enable_parallel_dml = on;

该参数用于允许优化器为 DML 语句生成并行执行计划。

3.2 设置并行 Worker 数量

接下来配置系统可使用的并行进程数量：

SET max_parallel_workers = 16;
SET max_parallel_workers_per_gather = 8;

其中：

max_parallel_workers 表示系统允许使用的并行 Worker 总数；
max_parallel_workers_per_gather 表示单个 Gather 节点最多能够调用的 Worker 数量。

并行度并不是越高越好。实际配置时，需要结合 CPU 核数、磁盘性能、并发任务数量以及数据库整体负载进行调整。

3.3 优化 WAL 和检查点配置

当多个 Worker 同时写入数据时，WAL 日志和检查点可能成为新的性能瓶颈。为了减少日志写入等待，可以根据测试环境进行以下调整：

SET wal_buffers = '512MB';
SET checkpoint_timeout = '1d';
SET synchronous_commit = off;

这些参数的作用分别是：

增大 WAL 缓冲区，减少前台进程因日志缓冲不足而等待；
延长检查点间隔，降低跑批过程中频繁刷盘造成的干扰；
关闭同步提交后，可以减少事务提交阶段的等待时间。

需要注意的是，synchronous_commit = off 更适合对性能要求较高、且能够接受一定提交确认延迟的场景。正式生产环境中应根据可靠性要求谨慎设置。

四、使用 Hint 引导并行执行计划

除了系统级和会话级参数，KES 还支持通过 SQL Hint 对单条语句进行更精细的控制。

下面以多表关联插入为例，同时为目标表和查询部分指定 8 个并行进程：

INSERT /*+ parallel(target_tab, 8) */ INTO target_tab
SELECT /*+ parallel(8) */
       t1.id,
       t2.info
FROM source_tab1 t1
INNER JOIN source_tab2 t2
        ON t1.id = t2.id
WHERE t1.batch_no = '20241027';