MySQL 基于ScaleFlux SSD性能测试

答案很简单 它为我们提供了内置的压缩功能和支持原子写特性。对于很多工作场景尤其是数据库类型的业务而言，这些功能和特性非常重要。

因为内置的磁盘压缩功能 相同的磁盘容量，我们可以存储更多的数据在 ScaleFlux 存储设备上。(引申 大规模数据存储的情况下 耗费的机器数量更少，机架位也更少。)

作者基于不同的数据集大小，不同schema数据量进行多次测试。需要说明的是在这些测试场景中我并不打算压测这些卡的性能极限，而是对比相同容量下 ScaleFlux 存储设备 和Intel SSD的性能表现。

存储设备配置:
ScaleFlux – CSD 2000 4TB
Intel –  P4610 3.2TB

服务器配置:
Application server: Supermicro; SYS-6019U-TN4RT
48xIntel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz
190G RAM
Database Server: Inspur; SA5212M4
32xIntel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
64G RAM

在 Application server 运行sysbench 压测工具，在 Database Server 运行Percona Server 8.0.19 。

作者禁用了binary, slow query logging和 adaptive hash，为了减少数据缓存，尽量让 sql 请求访问磁盘，数据库使用比较小的BPS配置。另外就是测试了关闭和开启doublewrite的性能表现 。

数据库的配置如下：

innodb_buffer_pool_size=8G
innodb_log_file_size = 2G
max_connections=500
slow_query_log=off
disable_log_bin
innodb_doublewrite=ON/OFF
tmpdir = /var/lib/mysql/
innodb_adaptive_hash_index=off
innodb_flush_method=O_DIRECT
innodb_purge_threads=32
sync_binlog=0
max_prepared_stmt_count=4000000

首先作者做了标准的 OLTP read_only, write_only, 和 read-write 测试，然后作者修改了表结构：

CREATE TABLE `sbtest1` (
  `id` int NOT NULL AUTO_INCREMENT,
  `k` int NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  `data1` varchar(255) DEFAULT NULL,
  `data2` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `k_1` (`k`),
  KEY `idx_data1` (`data1`)
) ENGINE=InnoDB AUTO_INCREMENT=9999948 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

新增加了data1和data2 两个varchar字段，使用一本书( Gutenberg project)中的内容行记录进行填充。

为什么这样做？因为这也是 ScaleFlux 的优势之处，他们声称如果数据可以被压缩，那么 ScaleFlux 将比 Intel 的性能要好很多。

作者还修改了OLTP lua 脚本来适配新的表结构

index_updates = {
      "UPDATE %s%u SET k=?,data1=? WHERE id=?",
      t.INT,{t.CHAR,255},t.INT},

   non_index_updates = {
      "UPDATE %s%u SET c=?,data2=? WHERE id=?",
       {t.CHAR,120},{t.CHAR,255},t.INT},

   inserts = {
      "INSERT INTO %s%u (id, k, c, pad, data1, data2) VALUES (?, ?, ?, ?, ?, ?)",
      t.INT, t.INT, {t.CHAR, 120}, {t.CHAR, 60}, {t.CHAR,255}, {t.CHAR,255}},

   index_selects = {
      "SELECT id,data2 FROM %s%u WHERE data1=?",
      {t.CHAR,255}},

   update_based_on_data1 = {
      "UPDATE %s%u SET data2=? WHERE data1=?",
       {t.CHAR,255},{t.CHAR,255}},

压测的配置如下：

default lua scripts – 100 tables – 10ML rows each – 220G default lua scripts – 1000 tables – 10ML rows – 2.3T modified lua scripts – 100 tables – 10ML rows each – 440G modified lua scripts – 540 tables – 10ML rows each – 2.5T modified lua scripts – 540 tables – 20ML rows each – 4.7T

talk is cheap，我们来看看结果对比图吧

在默认配置下，使用100张表，每个表100w条记录，数据集大小为220G。从结果图中我们可以看到 Intel SSD略微领先。ScaleFlux 存储设备在并发度为96之后有领先的优势。

需要说明都是 ScaleFlux 支持原子写，所以作者关闭了InnoDB Double Write Buffer。而针对Intel SSD 不支持原子写，InnoDB Double Write Buffer是开启的。

该场景下，作者使用了添加2个字段的压测模型。数据量扩大到440G，而且使测试数据适合压缩。

从压测结果上看，和ScaleFlux 声明的一样，在数据可压测的情况下，MySQL 在 ScaleFlux设备上的性能明显优于 Intel SSD ,在高并发场景下，性能优势明显。 再次说明 Intel SSD上的MySQL 未关闭InnoDB Double Write Buffer，而是用ScaleFlux 设备的MySQL 是关闭了 InnoDB Double Write Buffer的。

我们来看一下 Intel SSD 的MySQL 也关闭 InnoDB Double Write Buffer的测试结果

在同时开启或者关闭 Double Write 特性的对比测试中，是用 ScaleFlux 存储设备的MySQL都表现比较明显。

需要注意的是，我们不推荐在任何不支持原子写的设备上关闭InnoDB Double Write 。

两个设备都有3.2T的存储容量，作者压测的数据使用了2.5T 。作者使用修改的表结构 重建了sysbench的表。从结果上来看 ScaleFlux 存储设备上的MySQL 性能优势比较明显。一个影响性能的因素是SSD存在写放大。当数据量达到一定容量比例，SSD会进行类似垃圾回收的任务，耗费资源，影SSD的写能力。

从图中可以查看到 ScaleFlux 存储设备 的响应时间非常稳定而Intel设备的 响应时间则波动比较大。

我们可以看到 Intel 设备的iowait比较高 31.52% ,而ScaleFlux 设备的iowait则是 11.46%，明显低于Intel设备。

从系统层的监控数据来看测试期间各个设备的IOPS的表现。ScaleFlux 存储设备提供更高的 IOPS 约Intel SSD 的2倍。更高的IOPS 意味着MySQL 的QPS/TPS 更高,性能更好。下面的图也说明了这一点。

从上面这张图中我们看到 Innodb层的统计数据，每分钟 inserted/updated/deleted 多少行记录。

因为InnoDB关闭了double write，使用 ScaleFlux 存储设备的MySQL 写性能是Intel的接近两倍。