0. 结论先行
重要结论先说:导入大批量数据时,采用GreatSQL 8.0.32-24中新增并行load data特性是最快的,关于该特性的描述详见:Changes in GreatSQL 8.0.32-24。
1. 背景介绍
前几天我用MySQL官网提供的airportdb库中的weatherdata表做测试,结论是相比原生快了约5倍。
群里有小伙伴反驳说用myloader更香,于是就有了本次测试。
由于weatherdata表较小,表空间只有228MB,所以我改用sysbench表做测试,该表共600万行数据,表空间约1.5GB,其他信息如下:
2. 测试过程
本次测试基于GreatSQL 8.0.32-24版本,其他相关信息如下:
默认开启binlog + 双1 + redo log + doublewrite buffer:
3. 结果对比
下面是几个不同导入方式的对比测试结果,每种方式我都测试至少3次,去除噪点数据后取平均值:
工具 | 耗时(秒) | binlog大小(MB) | mysqld内存增长(MB) |
原生load data | 62.801741 | 1091 | 1536 |
并行load data(chunk=4MB,并发16线程) | 11.81 | 1091 | 1522 |
myloader(dump时chunk=64MB,load时并发16线程) | 29.358 | 2246 | 1868 |
myloader(dump时chunk=64MB,load时并发16线程)+ 关binlog | 21.426 | 无 | |
myloader(默认 + 开binlog) | 82.651 | 2246 | |
myloader(默认 + 关binlog) | 62.830 | 无 | |
util.importTable(默认,chunk=64MB,并发8线程) | 16.0034 | 1091 | 1662 |
从这个测试结果可以看到几个对比关系:
- 原生load data最慢,因为是单线程的,它的耗时是并行load data的5.32倍;
- 原生load data的耗时是多线程模式下myloader的2.14倍;
- 原生load data的耗时是多线程模式下util.importTable的3.92倍;
- 当myloader没有开启并行(mydumper备份时要先进行分配)的话,它的耗时是最久的,是并行load data的7倍,是多线程模式下util.importTable的5.16倍;
- 当myloader未开启binlog时(其默认行为,有"作弊"嫌疑),其耗时是并行load data的1.81倍,是多线程模式下util.importTable的1.34倍;
- 最后,myloader导入后造成的binlog文件最大,内存开销也最大。
图片
综上,在MySQL 8.0/GreatSQL 8.0.32中,采用myloader导入数据就不再是最优方案了,推荐采用GreatSQL的并行load data,或者MySQL Shell的util.loadDump/util.importTable导入,其本质也是采用并行的思路,导入效率更高,额外的binlog和内存开销也更小。
最后,补充说下,myloader导入时产生的binlog更多,是因为它的导入方式是反复执行INSERT SQL,在 binlog_rows_query_log_events = ON 时,相比load data方式会产生更多binlog。
附录
1. myloader多分片方式导出
设置导出时进行分片,每个分片(chunk)10MB
最后的(未压缩)文件总大小为1.2GB。
2. outfile导出
很简单,平平无奇,最后的(未压缩)文件总大小为1.1GB。
3. util.dumpTables多分片方式导出 设置导出时进行分片,每个分片(chunk)64MB(默认值)