最佳实践—如何优化Batch Insert

简介: Batch Insert语句是常见的数据库写入数据的方式,PolarDB-X兼容MySQL协议和语法,Batch Insert语法为:
INSERT [IGNORE] [INTO] table_name(column_name, ...) VALUES (value1, ...), (value2, ...), ...;

影响Batch Insert性能的主要因素包括:

  1. batch size
  2. 并行度
  3. 分片数目
  4. 列数目
  5. GSI的数目
  6. sequence数目

对于分片数目、列数目、GSI数目、sequence数目等内需因素,根据实际需求进行设置,并且常常会和读性能相互影响,例如GSI数目较多情况下,写入性能肯定会下降,但是对读性能有提升。本文不详细讨论这些因素的影响,主要聚焦于batch size和并行度的合理设置。

测试环境

本文档的测试环境见下表:

环境 参数
PolarDB-X版本 polarx-kernel_5.4.11-16279028_xcluster-20210802
节点规格 16核64GB
节点个数 4

测试的表用例:


CREATE TABLE `sbtest1` (

`id` int(11) NOT NULL,
`k` int(11) NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4;

Batch特性:BATCH_INSERT_POLICY=SPLIT

PolarDB-X针对数据批量写入,为保障更好的并发性,对Batch Insert进行了优化,当单个Batch Insert语句大小超过256K时,PolarDB-X会将Batch Insert语句动态拆分成多个小Batch,多个小Batch之间串行执行,这个特性称为SPLIT。

通过BATCH_INSERT_POLICY=SPLIT的机制,在保障最佳性能的同时,减少PolarDB-X并行执行Batch Insert的代价,尽可能规避分布式下多节点的负载不均衡。

相关参数:

  1. BATCH_INSERT_POLICY,可选SPLIT/NONE,默认值为SPLIT,代表默认启用动态拆分Batch。
  2. MAX_BATCH_INSERT_SQL_LENGTH,默认值256,单位KB。代表触发动态拆分Batch的SQL长度阈值为256K。
  3. BATCH_INSERT_CHUNK_SIZE_DEFAULT,默认值200。代表触发动态拆分Batch时,每个拆分之后的小Batch的批次大小。

关闭BATCH_INSERT_POLICY=SPLIT机制,可通过如下hint语句/+TDDL:CMD_EXTRA(BATCH_INSERT_POLICY=NONE)/ 。 此参数的目标是关闭BATCH_INSERT_POLICY策略,这样才可以保证batch size在PolarDB-X执行时不做自动拆分,可用于验证batch size为2000、5000、10000下的性能,从测试的结果来看batch size超过1000以后提升并不明显。

单表的性能基准

在分布式场景下单表只会在一个主机上,其性能可以作为一个基础的性能基线,用于评测分区表的水平扩展的能力,分区表会将数据均匀分布到多台主机上。

测试方法为对PolarDB-X中的单表进行Batch Insert操作,单表的数据只会存在一个数据存储节点中,PolarDB-X会根据表定义将数据写入到对应的数据存储节点上。

场景一:batch size

参数配置:

  • 并行度:16
  • 列:4
  • gsi:无
  • sequence:无
测试项 batch size 1 10 100 500 1000 2000 5000 10000
PolarDB-X【单表】 性能(行每秒) 5397 45653 153216 211976 210644 215103 221919 220529

场景二:并行度

参数配置:

  • batch size:1000
  • 列:4
  • gsi:无
  • sequence:无
测试项 thread 1 2 4 8 16 32 64 128
PolarDB-X【单表】 性能(行每秒) 22625 41326 76052 127646 210644 223431 190138 160858

测试总结

对于单表的测试,推荐batch size为1000,并行度为16~32时整体性能比较好。在测试batch size为2000、5000、10000时,需要添加hint参数来关闭SPLIT特性,从测试的结果来看batch size超过1000以后提升并不明显。示例:


/+TDDL:CMD_EXTRA(BATCH_INSERT_POLICY=NONE)/

分区表的性能基准

Batch size和并行度都会影响Batch Insert的性能,下面对这两个因素分开进行测试分析。

场景一:batch Size

在数据分片的情况下,由于包含拆分函数,Batch Insert语句会经过拆分函数分离values,下推到物理存储上的batch size会改变,示意图如下图所示。113.png

INSERT [IGNORE] [INTO] table_name(column_name, ...) VALUES (value1, ...), (value2, ...), ...;

影响Batch Insert性能的主要因素包括:

  1. batch size
  2. 并行度
  3. 分片数目
  4. 列数目
  5. GSI的数目
  6. sequence数目

对于分片数目、列数目、GSI数目、sequence数目等内需因素,根据实际需求进行设置,并且常常会和读性能相互影响,例如GSI数目较多情况下,写入性能肯定会下降,但是对读性能有提升。本文不详细讨论这些因素的影响,主要聚焦于batch size和并行度的合理设置。

测试环境

本文档的测试环境见下表:

环境 参数
PolarDB-X版本 polarx-kernel_5.4.11-16279028_xcluster-20210802
节点规格 16核64GB
节点个数 4

测试的表用例:


CREATE TABLE `sbtest1` (
`id` int(11) NOT NULL,
`k` int(11) NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4;

Batch特性:BATCH_INSERT_POLICY=SPLIT

PolarDB-X针对数据批量写入,为保障更好的并发性,对Batch Insert进行了优化,当单个Batch Insert语句大小超过256K时,PolarDB-X会将Batch Insert语句动态拆分成多个小Batch,多个小Batch之间串行执行,这个特性称为SPLIT。

通过BATCH_INSERT_POLICY=SPLIT的机制,在保障最佳性能的同时,减少PolarDB-X并行执行Batch Insert的代价,尽可能规避分布式下多节点的负载不均衡。

相关参数:

  1. BATCH_INSERT_POLICY,可选SPLIT/NONE,默认值为SPLIT,代表默认启用动态拆分Batch。
  2. MAX_BATCH_INSERT_SQL_LENGTH,默认值256,单位KB。代表触发动态拆分Batch的SQL长度阈值为256K。
  3. BATCH_INSERT_CHUNK_SIZE_DEFAULT,默认值200。代表触发动态拆分Batch时,每个拆分之后的小Batch的批次大小。

关闭BATCH_INSERT_POLICY=SPLIT机制,可通过如下hint语句/+TDDL:CMD_EXTRA(BATCH_INSERT_POLICY=NONE)/ 。 此参数的目标是关闭BATCH_INSERT_POLICY策略,这样才可以保证batch size在PolarDB-X执行时不做自动拆分,可用于验证batch size为2000、5000、10000下的性能,从测试的结果来看batch size超过1000以后提升并不明显。

单表的性能基准

在分布式场景下单表只会在一个主机上,其性能可以作为一个基础的性能基线,用于评测分区表的水平扩展的能力,分区表会将数据均匀分布到多台主机上。

测试方法为对PolarDB-X中的单表进行Batch Insert操作,单表的数据只会存在一个数据存储节点中,PolarDB-X会根据表定义将数据写入到对应的数据存储节点上。

场景一:batch size

参数配置:

  • 并行度:16
  • 列:4
  • gsi:无
  • sequence:无
测试项 batch size 1 10 100 500 1000 2000 5000 10000
PolarDB-X【单表】 性能(行每秒) 5397 45653 153216 211976 210644 215103 221919 220529

场景二:并行度

参数配置:

  • batch size:1000
  • 列:4
  • gsi:无
  • sequence:无
测试项 thread 1 2 4 8 16 32 64 128
PolarDB-X【单表】 性能(行每秒) 22625 41326 76052 127646 210644 223431 190138 160858

测试总结

对于单表的测试,推荐batch size为1000,并行度为16~32时整体性能比较好。在测试batch size为2000、5000、10000时,需要添加hint参数来关闭SPLIT特性,从测试的结果来看batch size超过1000以后提升并不明显。示例:


/+TDDL:CMD_EXTRA(BATCH_INSERT_POLICY=NONE)/

分区表的性能基准

Batch size和并行度都会影响Batch Insert的性能,下面对这两个因素分开进行测试分析。

场景一:batch Size

在数据分片的情况下,由于包含拆分函数,Batch Insert语句会经过拆分函数分离values,下推到物理存储上的batch size会改变,示意图如下图所示。

相关文章
|
存储 Java
【JVM】 程序计数器(Program Counter Register)
【JVM】 程序计数器(Program Counter Register)
504 1
|
缓存 安全 网络协议
socket是并发安全的吗 2
socket是并发安全的吗
813 0
|
SQL 关系型数据库 MySQL
Mysql连接池详解——原理部分
Mysql连接池详解——原理部分
|
数据格式 Python
【Python】已解决:Excel无法打开文件test.xIsx“,因为文件格式或文件扩展名无效。请确定文件未损坏,并且文件扩展名与文件的格式匹配。
【Python】已解决:Excel无法打开文件test.xIsx“,因为文件格式或文件扩展名无效。请确定文件未损坏,并且文件扩展名与文件的格式匹配。
1362 0
|
消息中间件 存储 负载均衡
两个实验让我彻底弄懂了「订阅关系一致」
这篇文章,笔者想聊聊 RocketMQ 最佳实践之一:**保证订阅关系一致**。 订阅关系一致指的是同一个消费者 Group ID 下所有 Consumer 实例所订阅的 Topic 、Tag 必须完全一致。 如果订阅关系不一致,消息消费的逻辑就会混乱,甚至导致消息丢失。
两个实验让我彻底弄懂了「订阅关系一致」
|
canal 缓存 NoSQL
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-03 Refresh Ahead + SingleFlight + 删除缓存 + 延迟双删
【5月更文挑战第11天】Refresh Ahead模式通过CDC异步刷新缓存,但面临缓存一致性问题,可借鉴Write Back策略解决。SingleFlight限制并发加载,减少数据库压力,适合热点数据。删除缓存模式在更新数据库后删除缓存,一致性问题源于读写线程冲突。延迟双删模式两次删除,理论上减少不一致,但可能降低缓存命中率。选用模式需权衡优劣,延迟双删在低并发下较优。装饰器模式可用于实现多种缓存模式,无侵入地增强现有缓存系统。
365 2
|
Java 调度
ScheduledExecutorService使用介绍
JUC包(java.util.concurrent)中提供了对定时任务的支持,即ScheduledExecutorService接口。 本文对ScheduledExecutorService的介绍,将基于Timer类使用介绍进行,因此请先阅读Timer类使用介绍文章。
1733 1
|
缓存 fastjson Java
FastJson - JSONPath 使用
FastJson - JSONPath 使用
1960 0
|
存储 移动开发 缓存
单线程 Redis 如此快的 4 个原因
为什么 Redis 单线程设计会带来如此高的性能?如果利用多个线程并发处理请求不是更好吗? 在本文中,我们将探讨使 Redis 成为快速高效的数据存储的设计选择。
641 2
|
SQL 存储 数据库
Sql查询原理与Select执行顺序(详细)
原文地址:点击打开链接 一切都是为了性能,一切都是为了业务 一、查询的逻辑执行顺序 (1) FROM left_table (3) join_type JOIN right_table (2) ON join_condition (4) WHERE where_condition (5) GROUP BY group_by_list (6) WITH {cube | rollup} (7
9033 0