最佳实践—如何优化Batch Insert

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 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会改变,示意图如下图所示。

相关文章
|
SQL 弹性计算 分布式计算
TiDB计算层详解:分布式计算框架与查询优化机制
【2月更文挑战第26天】本文将深入剖析TiDB的计算层,详细解析其分布式计算框架和查询优化机制。通过了解计算层的核心组件和工作原理,我们可以更好地理解TiDB如何高效处理SQL查询和计算任务。本文将从计算层的架构、任务分发、查询优化等方面展开介绍,帮助读者全面掌握TiDB计算层的关键技术和优势。
|
SQL Prometheus 监控
TiDB集群监控与性能分析
【2月更文挑战第28天】本章将深入探讨TiDB集群的监控与性能分析技术。我们将介绍TiDB集群监控的关键指标、监控工具的使用,以及如何进行性能分析和调优。通过本章节的学习,读者将能够掌握TiDB集群的监控与性能分析方法,提高数据库的运行效率和稳定性。
|
消息中间件 存储 负载均衡
Kafka【付诸实践 01】生产者发送消息的过程描述及设计+创建生产者并发送消息(同步、异步)+自定义分区器+自定义序列化器+生产者其他属性说明(实例源码粘贴可用)【一篇学会使用Kafka生产者】
【2月更文挑战第21天】Kafka【付诸实践 01】生产者发送消息的过程描述及设计+创建生产者并发送消息(同步、异步)+自定义分区器+自定义序列化器+生产者其他属性说明(实例源码粘贴可用)【一篇学会使用Kafka生产者】
753 4
|
2月前
|
Ubuntu Linux 网络安全
Linux装软件神器:yum 超详细入门指南
在Linux中安装软件有三种常用方法:源码安装、rpm包安装和yum包管理器安装。其中,**yum**(或Ubuntu的apt)最为便捷,类似于手机应用商店,能自动解决依赖问题,适合新手使用。本文详细介绍了yum的工作原理、软件源配置、常用命令及生态系统的意义,帮助用户快速上手Linux软件安装与管理。
 Linux装软件神器:yum 超详细入门指南
|
8月前
|
存储 缓存 NoSQL
Redis缓存设计与性能优化
Redis缓存设计与性能优化涵盖缓存穿透、击穿、雪崩及热点key重建等问题。针对缓存穿透,可采用缓存空对象或布隆过滤器;缓存击穿通过随机设置过期时间避免集中失效;缓存雪崩需确保高可用性并使用限流熔断组件;热点key重建利用互斥锁防止大量线程同时操作。此外,开发规范强调键值设计、命令使用和客户端配置优化,如避免bigkey、合理使用批量操作和连接池管理。系统内核参数如vm.swappiness、vm.overcommit_memory及文件句柄数的优化也至关重要。慢查询日志帮助监控性能瓶颈。
310 9
|
存储 缓存 NoSQL
【redis】数据量庞大时的应对策略
【redis】数据量庞大时的应对策略
191 2
|
SQL 存储 分布式计算
HDFS数据(跨集群)迁移
HDFS数据(跨集群)迁移
|
消息中间件 缓存 Kafka
原理剖析| 一文搞懂 Kafka Producer(上)
本文介绍了Apache Kafka 3.7的Producer使用及原理,讲解了如何创建和使用Producer,展示了一个发送消息的示例代码,并介绍了ProducerRecord和Callback接口。ProducerRecord包含topic、partition等属性,Callback用于发送消息后的回调处理。接着阐述了send、flush和close方法的功能。文章还探讨了核心组件,包括ProducerMetadata、RecordAccumulator、Sender和TransactionManager,以及消息发送流程。最后,讨论了元数据刷新、分区选择、消息攒批和超时处理等实现细节。
737 0
原理剖析| 一文搞懂 Kafka Producer(上)