スマートスタイル TECH BLOG

Percona Server で MyRocks エンジン(RocksDB)を使う

MyRocks エンジンとは?

Facebook社が開発したMySQLのストレージエンジンです。RocksDBをバックグラウンドのストレージに使用しており、テーブル圧縮をしたInnoDBと比較して、高い圧縮性能をもち、高速な書き込み処理が可能という特徴があります。
Facebookでは独自に改良されたMySQL(5.6ベース)にMyRocksが組み込まれ、一部本番環境でも動いているようです。

MyRocksはオープンソースとして公開されており、Percona Server や MariaDB ではこれをマージする取り組みが進んでいます。
Percona Server 5.7.18 から実験的ながら このMyRocks エンジンが使えるようになりました。

この記事では、Percona Server でMyRocksのインストール方法、同じデータをインポートして InnoDBとMyRocksでどの程度ディスクスペースに差が出るかを調べたいと思います。

参考

RocksDBとは?

Google社が開発した LevelDB を元に、Facebook社のデータベースエンジニアリングチームが開発を進めているKey/Value型の組み込みデータベースです。
Cassandra や MongoDB の WiredTiger ストレージエンジンでも使われている Log-Structured Merge Tree 構造を採用することでSSDなどの高速ストレージを効率的に使えるように最適化されています。

参考

Log-Structured Merge Tree (LSM Tree)

LSM Tree は挿入処理において高い性能を持つデータ構造です。
複数からなるツリー上のデータ構造を持ち、マージソートを繰り返しながらツリーを大きくします。

参考 : Log-structured merge-tree – Wikipedia

InnoDBのテーブル圧縮処理

InnoDBではデフォルトで16KBのページと呼ばれるスペースで管理されており、1つのページで複数のレコードを保持しています。圧縮はこのページ単位で行われ、ディスクのブロック単位で格納されます。
仮に、16KBのページが圧縮されて5KBになったとしても、ディスクのブロックサイズが4KBの場合、2ブロック消費されるため(8KB)、3KB分無駄なスペースが生まれてしまうことになります。

参考 : MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.7 InnoDB 圧縮テーブル

MySQL5.7からは透過的ページ圧縮の機能が追加され、ページ圧縮を有効にすると、OSとファイルシステムがホールパンチに対応していれば、空のブロックがページの最後から解放されるようになり、テーブル圧縮よりも効率よくスペースが使われるようになりました。

RocksDBの実装と圧縮処理

RcoksDBではソート済みテーブルデータを複数のSST(Sorted Static Table)ファイルに書き出され管理されます。
圧縮処理はこのSSTファイル単位で行われるため、高い圧縮率とディスクスペースに対する効率がInnoDBと比較すると優れています。

MyRocksのデータ削減処理

それ以外にも、MyRocksでは以下の機能によってさらにデータサイズを小さくしています。

Prefix Key Encoding

列単位で同じ値が続く場合は省略することでデータサイズを減らしています。

Zero-filling row metadata

MyRocksでは7byteのシーケンスIDと1バイトのオペレーションタイプを各行ごとに保持しています。ただし、プライマリキーがある場合は二重管理となるため、このシーケンスIDを0にすることでサイズを減らしています。

参考 : MyRocks advantages over InnoDB · facebook/mysql-5.6 Wiki · GitHub

MyRocksのインストール(Percona Server)

MyRocksのコードがマージされていますが、まだテストレポジトリからしか使えないようです。
検証では CentOS 7 で試しました。

1.レポジトリを追加します

2.テストレポジトリを有効化します

[percona-testing-$basearch] と [percona-testing-noarch] セクションを enabled = 1 に変更する。

3.Percona Server をインストールします

4.Percona Server を起動します

5.rootの 一時パスワードを取得します
MySQL 5.7 (Percona Server) から yum によるインストールの場合、rootの一時パスワードはmysqlのエラーログに出力されれます。

6.Percona Server にログインしてパスワードを変更します

7.RocksDB パッケージをインストールします
MyRocksエンジンを使うには別途パッケージをインストールする必要があります。

インストール時に以下のメッセージが出るのでスクリプトを動かします。

8.MyRocksエンジンを有効にします

9.RocksDB が有効になっていることを確認します

これで ENGINE= RocksDB を指定すれば使えます。

MyRocksのデータ構造

デフォルトでは /var/lib/mysql/.rocksdb 以下にデータが格納されます。

データが投入された ./rocksdb の中はこんな感じです。

[シーケンス番号].sst

ソート済みデータが格納されています。SSTファイルと呼ばれます。InnoDBの場合の .ibd と役割はおおよそ同じです。

[シーケンス番号].log

書き込みリクエストが MemTable と同時にファイルも書き出されます。WALファイルと呼ばれます。ib_logfile と役割はおおよそ同じです。

LOG

MyRocksのログです。現状ではビルド時のファイルパスが出力されていたりと、デバッグログに近い内容だと思われます。

データ圧縮性能比較

今回のデータ圧縮性能比較では英語版Wikipediaのpageテーブルをインポートした後のディスクサイズを比較したいと思います。

使用したデータは以下です。
https://dumps.wikimedia.org/enwiki/20170801/enwiki-20170801-page.sql.gz (1.5GBほどあるので注意)

ダンプファイルではエンジンが InnoDB になっているので RocksDB に変更してデータをインポートします。

my.cnf などの設定値は myrocks を含め全てデフォルトです。

InnoDB(圧縮無し) MyRocks
11.0GB 9.1GB (-18%)

Facebookのベンチマークでは、LinkBenchのデータでInnoDBの圧縮無しの場合とMyRocksのデータベースサイズを比較すると3.5倍ほど小さくなる結果でしたが、今回の検証ではデータサイズが小さいことやパラメーターがデフォルトであることが影響してか想定ほどデータサイズに差が出ませんでした。
(FacebookのベンチマークではInnoDBの圧縮無しで250GB〜330GB程度のデータを使用)

参考 : MyRocks: A space- and write-optimized MySQL database

まとめ

  • Percona Server を使えばソースコードからビルドしなくてもパッケージインストールでMyRocksが使えます。
  • 今回の検証では残念ながらFacebookのベンチマークほどデータ圧縮効果は見られませんでした。

(追記:9月8日)InnoDBのページ圧縮も含めて追加検証

追加検証では、RocksDBエンジンとInnoDBの圧縮無しだけでなく、InnoDBのページ圧縮も含め、データ投入量を増やしてデータ圧縮性能を比較してみました。
Percona Server のバージョンは前回と同様です。

データ

ベンチマークツールのsysbenchで使われるテーブル構成と同じにしました。また投入するデータについても極力sysbenchと同様にしました。

テーブル構成

投入データ例

測定方法

1回のイテレーションで1テーブル作成し、10,000,000レコードを挿入します。
1イテレーションごとにMySQLのデータディレクトリのサイズを計測しました。
今回はそれを100イテレーション行いました。

測定結果

100イテレーション終了時

エンジン データサイズ 圧縮率
InnoDB(圧縮無し) 214GB
InnoDB(圧縮) 117GB -46%
RocksDB 187GB -13%

InnoDBのページ圧縮がもっとも圧縮性能が良いという結果が出ました。

追加検証のまとめ

データサイズを増やしてみましたが、残念ながら思ったほど圧縮性能が出ない結果となりました。

今の段階で性能が出ない原因として考えられるのは

- RocksDBのオプション設定をデフォルトにしているため、圧縮性能がフルに使えていない可能性があります
- Percona ServerへRocksDBのコードがマージされたが最適化が不十分だった可能性があります
- LinkBenchとsysbenchではデータの構成、傾向が異なるため、圧縮に不利だった可能性があります


Percona

 

Return Top