本文中，我們將通過基準測試來給大家展示MyRocks引擎的性能。

Percona Server MySQL 5.7新引入的一個數據庫引擎。關於他性能可能還是還待探索，所以今天我們就一起來看看它在相對高端的服務器和SSD存儲下的性能表現。

我們想要檢查它對於給定的數據庫不同大小的可用內存情況表現。它與之前Percona官方發佈的InnoDB基準測試相同的條件下，我們使用sysbench-tpcc基準測試，用InnoDB作為基準，然後用其對MyRocks和InnoDB兩種引擎進行對比測試。

作為基準測試，我將使用100個TPC-C倉庫，以及一組10個表格（從行遞增調整瓶頸）。這應該提供大約90GB的數據大小（加載到InnoDB時），大致相當於1000個數據倉庫的數據量。

為了改變內存大小，我們將InnoDB的innodb_buffer_pool_size從5GB更改為100GB，MyRocks的 rocksdb_block_cache_size也做同樣修改。

對於MyRocks，我們將使用LZ4作為存盤的默認壓縮。 MyRocks存儲引擎中的數據大小為21GB。需要注意的是是，在MyRocks中未壓縮的數據存儲上限70GB。

這兩種引擎，均未使用FOREIGN KEYS，因為MyRocks目前還不支持。

MyRocks不支持Percona Server中實現的REPEATABLE-READ模式中的"SELECT .. FOR UPDATE"語句。但是，在此基準測試中使用了"SELECT .. FOR UPDATE"。必須使用READ-COMMITTED模式。

還要提及的最重要的設置是啟用二進制日誌，原因如下：

1、任何重要的生產系統都都會啟用二進制日誌

2、如果禁用的二進制日誌，MyRocks會受到的非最優事務協調器的影響

我們對二進制日誌使用了以下設置：

binlog_format ='ROW'

binlog_row_image = minimal

sync_binlog = 10000（我沒有使用0，因為這會在二進制日誌轉存到硬盤時候時候導致嚴重的卡頓）

雖然我並不是MyRocks調優的完整專家，但我使用了此頁面的調優建議：github上 /facebook/mysql-5.6/wiki/my.cnf-tuning。同時Facebook-MyRocks工程團隊還為我們提供了關於MyRocks最佳設置配置。

結果展示

內存性能

讓我們回顧一下不同內存大小的結果。

這第一張圖顯示吞吐量抖動。這有助於瞭解吞吐量結果的分佈情況。吞吐量每1秒測量一次，圖表上顯示運行2000秒後的所有測量結果（每次運行的總長度為3600秒）。所以我們展示了每次運行的最後1600秒（去除準備熱身階段）：

為了更好地量化結果，讓我們對比看boxplot圖。理解箱型圖的最快方法是看中間線。它代表測量的中位數。

內存吞吐變化

在我們給出結果總結之前，讓我們來看看InnoDB和MyRocks的吞吐量變化。我們100GB內存分配的結果將放大到的1秒分辨率圖表：

我們可以看到，MyRocks在定期1秒性能下降中變化很大。目前，我們還不知道導致吞吐量變化的原因。

因此，讓我們來看看不同內存設置下每個引擎的平均吞吐量（結果以tps為單位，而且越多越好）：

這是MyRocks與InnoDB行為不同的地方。 InnoDB從額外的內存中受益良多，直到增加到工作數據集的大小。之後，內存增加被限制。

於此對比，有趣的是MyRocks並沒有從額外的內存中獲益。

基本上，MyRocks按預期執行寫優化引擎。有關更多詳細信息，請參閱我的文章"三種基本數據結構如何影響存儲和檢索"。

總之，當工作數據集適合（或幾乎適合）可用內存時，InnoDB的性能會更好（與其本身相比），而MyRocks可以在小內存上運行（並且勝過InnoDB）。

IO和CPU使用率

值得關注的是每個引擎的資源利用率。我們對每次運行都進行了vmstat測量，以便分析IO和CPU使用情況。

寫性能

首先，讓我們回顧一下每秒寫入的數量（以KB/秒為單位）。注意，這些寫操作也包括二進制日誌寫入，而不僅僅是存儲引擎寫入。

我們還計算了各存儲引擎每次執行的寫入次數：

上面的圖顯示了InnoDB和MyRocks之間的本質區別。 MyRocks是一個寫優化的引擎，每個事務使用的寫入量不變。

相比較InnoDB，寫入的數量很大程度上取決於內存大小。我們擁有的內存越少，它需要執行的寫入就越多。

讀性能

下表顯示了以每秒KB為單位的讀取。

我們可以將其轉換為每個事務的讀取次數：

這張圖顯示了MyRocks的讀取放大。分配更多內存有助於減少IO讀取，但不如InnoDB那麼明顯。

CPU使用率

讓我們在看看兩個存儲引擎的CPU使用情況。先是InnoDB：

該圖表顯示，對於5GB內存大小，InnoDB大部分時間用於IO等待（綠色區域），並且CPU使用率（藍色區域）隨著更多內存的增加而增加。

做為對比MyRocks的情況：

其詳細表格數據如下：

我們可以看到無論分配了多少內存，MyRocks都使用了很多CPU（用戶+系統態）。這導致MyRocks性能受限於CPU性能而非可用內存的限制。

MyRocks目錄大小

隨著MyRocks寫入所有更改並壓縮成SST文件，可以看到基準測試期間數據目錄大小如何變化，以便我們估算存儲需求。下面是數據目錄大小的圖表：

我們可以看到，數據目錄從開始時的20GB變為基準期間的31GB。觀察數據增長直到壓縮，然後縮小呈現週期性的規律變化。

結論

總之，我可以說MyRocks性能隨著數據集大小與內存的比例增加而增加，在5GB內存分配的情況下，性能比InnoDB高出近5倍。吞吐量變化是值得關注的問題，但我們希望這一點在未來得到改善。

MyRocks不需要大量內存，並且在使用大部分CPU資源時顯示穩定地寫入IO。

我們認為這特性可能會使MyRocks成為雲數據庫實例的絕佳選擇，而內存和IO都消費都會比較合算。 MyRocks部署可以讓雲部署更便宜。

我們將跟進更多基於雲計算的基準測試。

附件

原始結果，腳本和測試配置

我的目標是提供完全可重複的基準測試。為此，我們在GitHub分享相關信息包括我們使用的所有腳本和設置：

Github鏈接：Percona-Lab-results/201803-sysbench-tpcc-myrocks

MyRocks設置

rocksdb_max_open_files=-1

rocksdb_max_background_jobs=8

rocksdb_max_total_wal_size=4G

rocksdb_block_size=16384

rocksdb_table_cache_numshardbits=6

# rate limiter

rocksdb_bytes_per_sync=16777216

rocksdb_wal_bytes_per_sync=4194304

rocksdb_compaction_sequential_deletes_count_sd=1

rocksdb_compaction_sequential_deletes=199999

rocksdb_compaction_sequential_deletes_window=200000

rocksdb_default_cf_options="write_buffer_size=256m;target_file_size_base=32m;max_bytes_for_level_base=512m;max_write_buffer_number=4;level0_file_num_compaction_trigger=4;level0_slowdown_writes_trigger=20;level0_stop_writes_trigger=30;max_write_buffer_number=4;block_based_table_factory={cache_index_and_filter_blocks=1;filter_policy=bloomfilter:10:false;whole_key_filtering=0};level_compaction_dynamic_level_bytes=true;optimize_filters_for_hits=true;memtable_prefix_bloom_size_ratio=0.05;prefix_extractor=capped:12;compaction_pri=kMinOverlappingRatio;compression=kLZ4Compression;bottommost_compression=kLZ4Compression;compression_opts=-14:4:0"

rocksdb_max_subcompactions=4

rocksdb_compaction_readahead_size=16m

rocksdb_use_direct_reads=ON

rocksdb_use_direct_io_for_flush_and_compaction=ON

InnoDB設置

# files

innodb_file_per_table

innodb_log_file_size=15G

innodb_log_files_in_group=2

innodb_open_files=4000

# buffers

innodb_buffer_pool_size= 200G

innodb_buffer_pool_instances=8

innodb_log_buffer_size=64M

# tune

innodb_doublewrite= 1

innodb_support_xa=0

innodb_thread_concurrency=0

innodb_flush_log_at_trx_commit= 1

innodb_flush_method=O_DIRECT_NO_FSYNC

innodb_max_dirty_pages_pct=90

innodb_max_dirty_pages_pct_lwm=10

innodb_lru_scan_depth=1024

innodb_page_cleaners=4

join_buffer_size=256K

sort_buffer_size=256K

innodb_use_native_aio=1

innodb_stats_persistent = 1

#innodb_spin_wait_delay=96

# perf special

innodb_adaptive_flushing = 1

innodb_flush_neighbors = 0

innodb_read_io_threads = 4

innodb_write_io_threads = 2

innodb_io_capacity=2000

innodb_io_capacity_max=4000

innodb_purge_threads=4

硬件和系統配置列表

超微服務器:

CPU:

Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz

2 sockets / 28 cores / 56 threads

內存: 256GB of RAM

硬盤: 三星 SM863 1.9TB Enterprise SSD

文件系統: ext4

數據庫：Percona-Server-5.7.21-20

操作系統: Ubuntu 16.04.4, linux內核 4.13.0-36-generic

本文蟲蟲譯自percona官方博客，作者是percona聯合創始人Vadim Tkachenko和CTO。（原文鏈接見percona最新blog，此處略）。

閱讀更多 蟲蟲安全 的文章

關鍵字: 基準 引擎 腳本語言