最佳实践—如何优化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 数据库连接
Spring Boot 3 整合 Mybatis-Plus 动态数据源实现多数据源切换
Spring Boot 3 整合 Mybatis-Plus 动态数据源实现多数据源切换
|
SQL 弹性计算 分布式计算
TiDB计算层详解:分布式计算框架与查询优化机制
【2月更文挑战第26天】本文将深入剖析TiDB的计算层,详细解析其分布式计算框架和查询优化机制。通过了解计算层的核心组件和工作原理,我们可以更好地理解TiDB如何高效处理SQL查询和计算任务。本文将从计算层的架构、任务分发、查询优化等方面展开介绍,帮助读者全面掌握TiDB计算层的关键技术和优势。
|
SQL Prometheus 监控
TiDB集群监控与性能分析
【2月更文挑战第28天】本章将深入探讨TiDB集群的监控与性能分析技术。我们将介绍TiDB集群监控的关键指标、监控工具的使用,以及如何进行性能分析和调优。通过本章节的学习,读者将能够掌握TiDB集群的监控与性能分析方法,提高数据库的运行效率和稳定性。
|
Apache 流计算 OceanBase
手把手教你实现 OceanBase 数据到阿里云数据库 SelectDB 内核版 Apache Doris 的便捷迁移|实用指南
本文介绍了如何将数据从 OceanBase 迁移到阿里云数据库 SelectDB 内核版 Apache Doris。提供 3 种数据同步方法 1. 使用 DataX,下载 DataX 并编写配置文件,通过 OceanBaseReader 和 DorisWriter 进行数据迁移。 2. 利用 Apache Doris 的 Catalog功 能,将 OceanBase 表映射到 Doris 并插入数据。 3. 通过Flink CDC,设置 OceanBase 环境,配置 Flink 连接器,实现实时数据同步。
2171 0
手把手教你实现 OceanBase 数据到阿里云数据库 SelectDB 内核版 Apache Doris 的便捷迁移|实用指南
|
消息中间件 存储 负载均衡
Kafka【付诸实践 01】生产者发送消息的过程描述及设计+创建生产者并发送消息(同步、异步)+自定义分区器+自定义序列化器+生产者其他属性说明(实例源码粘贴可用)【一篇学会使用Kafka生产者】
【2月更文挑战第21天】Kafka【付诸实践 01】生产者发送消息的过程描述及设计+创建生产者并发送消息(同步、异步)+自定义分区器+自定义序列化器+生产者其他属性说明(实例源码粘贴可用)【一篇学会使用Kafka生产者】
803 4
|
9月前
|
存储 缓存 NoSQL
Redis缓存设计与性能优化
Redis缓存设计与性能优化涵盖缓存穿透、击穿、雪崩及热点key重建等问题。针对缓存穿透,可采用缓存空对象或布隆过滤器;缓存击穿通过随机设置过期时间避免集中失效;缓存雪崩需确保高可用性并使用限流熔断组件;热点key重建利用互斥锁防止大量线程同时操作。此外,开发规范强调键值设计、命令使用和客户端配置优化,如避免bigkey、合理使用批量操作和连接池管理。系统内核参数如vm.swappiness、vm.overcommit_memory及文件句柄数的优化也至关重要。慢查询日志帮助监控性能瓶颈。
378 9
|
存储 缓存 NoSQL
【redis】数据量庞大时的应对策略
【redis】数据量庞大时的应对策略
232 2
|
SQL 关系型数据库 MySQL
如何确认SQL用了索引:详细技巧与方法
在数据库管理中,索引是提高SQL查询性能的重要手段
2388 5