乐趣区

关于mysql:技术译文-How-Can-ScaleFlux-Handle-MySQL-Workload

jiezi

本文是一篇译文，介绍 Percona 的工程师对 ScaleFlux 的性能压测报告
翻译：杨奇龙
原文地址：https://www.percona.com/blog/…

最近作者有一个针对 ScaleFlux 的产品也叫做 CSD 2000 进行压测的机会. 本文中作者将介绍应用 Intel SSD 和 ScaleFlux 存储设备进行压测的比照后果。

一 咱们为什么须要不一样的 ScaleFlux？

答案很简略 它为咱们提供了内置的压缩性能和反对原子写个性。对于很多工作场景尤其是数据库类型的业务而言，这些性能和个性十分重要。

因为内置的磁盘压缩性能 雷同的磁盘容量，咱们能够存储更多的数据在 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 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

做了哪些测试

首先作者做了规范的 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，咱们来看看后果比照图吧

Default Sysbench – Read/Write – 220G Datasize

在默认配置下，应用 100 张表，每个表 100w 条记录，数据集大小为 220G。从后果图中咱们能够看到 Intel SSD 稍微当先。ScaleFlux 存储设备在并发度为 96 之后有当先的劣势。

须要阐明都是 ScaleFlux 反对原子写，所以作者敞开了 InnoDB Double Write Buffer。而针对 Intel SSD 不反对原子写，InnoDB Double Write Buffer 是开启的。

Modified Sysbench – Read/Write – 440G Datasize

该场景下，作者应用了增加 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

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

因为 InnoDB 敞开了 double write，应用 ScaleFlux 存储设备的 MySQL 写性能 是 Intel 的靠近两倍。

论断

依据作者的测试，ScaleFlux 存储没有半点水分，言行不一。如果数据量越大而且数据的可压缩性越好，性能成果则越好。须要特地阐明的是 从第一次测试的后果来看，数据集比拟小而且数据不可压缩的状况下 Intel SSD 存储的劣势还是比拟显著的（其实价格，也比拟低）。

想要获取更具体的压测报告 能够点击原文：https://learn.percona.com/hub…

退出移动版