最近作者有一個針對 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 的優勢之處，他們聲稱如果數據可以被壓縮，那么 ScaleFluxIntel 的性能要好很多。
作者還修改了 OLTP lua 腳本來適配新的表結構，
index_updates = { "UPDATE %s%u SET k=?,data1=? WHERE id=?", t.INT,,t.INT}, non_index_updates = { "UPDATE %s%u SET c=?,data2=? WHERE id=?", ,,t.INT}, inserts = { "INSERT INTO %s%u (id, k, c, pad, data1, data2) VALUES (?, ?, ?, ?, ?, ?)", t.INT, t.INT, , , , }, index_selects = { "SELECT id,data2 FROM %s%u WHERE data1=?", }, update_based_on_data1 = { "UPDATE %s%u SET data2=? WHERE data1=?", ,},
壓測的配置如下：
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 的接近兩倍。
