一、需要

一个敌人接到一个需要，从大数据平台收到一个数据写入在20亿+，须要疾速地加载到MySQL中，供第二天业务展现应用。

二、实现再剖析

对于单表20亿， 在MySQL运维，说真的这块目前波及得比拟少，也根本没什么教训，但对于InnoDB单表Insert 如果内存大于数据状况下，能够维持在10万-15万行写入。 但很多工夫咱们承受的我的项目还是数据超过内存的。 这里应用XeLabs TokuDB做一个测试。

三、XeLabs TokuDB介绍

我的项目地址： https://github.com/XeLabs/tokudb

绝对官网TokuDB的优化：

  • 内置了jemalloc 内存调配；
  • 引入更多的内置的TokuDB性能指标；
  • 反对Xtrabackup备份；
  • 引入ZSTD压缩算法；
  • 反对TokuDB的binlog_group_commit个性；

四、测试表

TokuDB外围配置：

表构造：

利用load data写入数据：

计算一下每秒写入速度：

文件大小：

理论文件8.5G，写入TokuDB大小3.5G，只是靠近于一半多点的压缩量。 对于20亿数据写入，理论测试在58分钟多点就能够实现。能够满足理论需要，另外对于磁盘IO比拟好的机器（SSD类盘，云上的云盘），如果内存和数据差不多状况，这量级数据量测试在Innodb里须要增加自增列，能够在3个小多一点实现。 从最佳实战上来看，Innodb和TokuDB都写入同样的数据，InnoDB须要花大略是TokuDB3-4倍工夫。文件大小区别，同样20亿数据：

文件大小在5倍大小的区别。

测试论断：

利用TokuDB在某云环境中8核8G内存，500G高速云盘环境，屡次测试能够轻松实现57万每秒的写入量。

另外测试几种场景也供大家参考： 如果在TokuDB中应用带自增的主键，主键无值让MySQL外部产生写入速度，降落比拟显著，同样写入2亿数据，带有自建主键：

同样的数据写入在主键自增无值产生时，不能应用TokuDB的 Bulk loader data个性，相当于转换为了单条的Insert实现，所以成果上慢太多。

对于TokuDB Bulk Loader前提要求，这个表是空表，对于自增列，如自增列有值的状况下，也能够应用。 倡议理论应用中，如果自增列有值的状况下，能够思考去除自增属性，改成惟一索引，这样缩小自增的一些解决逻辑，让TokuDB能跑地更快一点。 另外在Bulk Loader解决中为了谋求更疾速的写入，压缩方面并不是很好。

对于TokuDB Bulk Loader :

https://github.com/percona/Pe...

五、测试环境阐明

测试应用CentOS7环境

本文作者：吴炳锡
起源：https://yq.aliyun.com/article...