关于mysql:MySQL每秒57万的写入带你飞

36次阅读

共计 1125 个字符,预计需要花费 3 分钟才能阅读完成。

一、需要

一个敌人接到一个需要,从大数据平台收到一个数据写入在 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…

正文完
 0