本文是一篇译文，介绍 Percona 的工程师对 ScaleFlux 的性能压测报告。
翻译：杨奇龙
最近作者有一个针对 ScaleFlux 的产品也叫做 CSD 2000 进行压测的机会。本文中作者将介绍使用 Intel SSD 和 ScaleFlux 存储设备进行压测的对比结果。
一、我们为什么需要不一样的 ScaleFlux？
答案很简单，它为我们提供了内置的压缩功能和支持原子写特性。对于很多工作场景尤其是数据库类型的业务而言，这些功能和特性非常重要。
因为内置的磁盘压缩功能相同的磁盘容量，我们可以存储更多的数据在 ScaleFlux 存储设备上。（引申：大规模数据存储的情况下，耗费的机器数量更少，机架位也更少。）
存储设备配置:
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 for MySQL 8.0.19 。
作者禁用了 binary, slow query logging 和 adaptive hash，使用比较小的 BPS 配置，为了减少数据缓存，尽量让 sql 请求访问磁盘。另外就是测试了关闭和开启 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做了哪些测试
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 的性能要好很多。
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，我们来看看结果对比图吧。
Default Sysbench – Read/Write – 220G Datasize
需要说明都是 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。
Modified Sysbench – Read/Write – 2.5T Datasize
两个设备都有 3.2T 的存储容量，作者压测的数据使用了 2.5T。作者使用修改的表结构重建了 sysbench 的表。从结果上来看 ScaleFlux 存储设备上的 MySQL 性能优势比较明显。一个影响性能的因素是 SSD 存在写放大。当数据量达到一定容量比例，SSD 会进行类似垃圾回收的任务，耗费资源，影响 SSD 的写能力。
Disk Latency
从图中可以查看到 ScaleFlux 存储设备的响应时间非常稳定而 Intel 设备的响应时间则波动比较大。
CPU Usage
ScaleFlux – Read/Write – Modified Sysbench – 540 tables – 2.5T
Intel – Read/Write – Modified Sysbench – 540 tables – 2.5T
我们可以看到 Intel 设备的 iowait 比较高 31.52%，而 ScaleFlux 设备的 iowait 则是 11.46%，明显低于 Intel 设备。
Disk Operations
从系统层的监控数据来看测试期间的 IOPS 表现。ScaleFlux 存储设备提供更高的 IOPS 大约是 Intel 的 2 倍。更高的 IOPS 意味着 MySQL 的 QPS/TPS 更高，性能更好。下面的图也说明了这一点。
InnoDB Row Operations
结论
根据作者的测试，ScaleFlux 存储没有半点水分，言行一致。如果数据量越大而且数据的可压缩性越好，性能效果则越好。需要特别说明的是，从第一次测试的结果来看，数据集比较小而且数据不可压缩的情况下 Intel SSD 存储的优势还是比较明显的（其实价格也比较低 ^_^）。
想要获取更详细的压测报告，可以点击原文：
https://learn.percona.com/hubfs/Collateral/Whitepapers/Testing-the-Value-of-ScaleFlux.pdf