技術譯文 | How Can ScaleFlux Handle MySQL Workload?

本文是一篇譯文，介紹 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...