Percona Xtrabackup の ZSTD圧縮モードについて

この記事は最終更新から1年以上経過しています。内容が古くなっている可能性があります。

Percona Xtrabackupでは、以前から以下の2つの圧縮方式が選択できました。

  • quicklz
  • lz4

まだtech preview ではありますが、v8.0.30では第三の圧縮方式としてZSTDを選択できるようになりました。

今回は、以下の観点で今までの圧縮方式とZSTDを比較してみようと思います。

  • 圧縮効率
  • バックアップ速度
  • 解凍速度
目次

テストデータについて

今回テストデータについては、TPC-Hのデータを利用しました。

TPC-H

また、テーブル定義の作成については、MySQL HeatWave 用の公開ベンチマークのDDLスクリプトを利用させて頂きました。

./dbgen -s 100 として 約100GB のデータセットを作成し、TPC-Hで使用するテーブルセットのそれぞれのテーブルを5つずつ作成しました(LINEITEM_1, LINEITEM_2…のように)
そして、100GBのデータセットをそれぞれのテーブルセットにインポートしましたので、最終的には 672 GB となりました。

前述のDDLスクリプトでは、 LINEITEMテーブルがKEYパーティションとなっているため、複数のテーブルスペースファイルに分割されており、テーブルスペースファイル数としては tpch データベースに 675ファイル 存在するという結果になりました。

検証環境について

今回は、Oracle Cloud上に構築したインスタンスを利用しました。
スペックは以下のようにしました。

リソース
Shape VM.Standard.E4.Flex
OCPU 8(=16core)
ネットワーク帯域幅(Gbps) 8
MEMORY 32GB
OSイメージ Oracle-Linux-8.6-2022.12.15-0
Boot Volume Size: 1TB/VCPU: 20(50,000 IOPS, Throughput 614.4MB/s)
Block Volume Size: 1TB/VCPU: 40(75,000 IOPS, Throughput 860.16MB/s)

MySQLのdatadirはBoot Volumeに、バックアップはBlock Volumeにあるという構成です。

実行前準備について

圧縮・解凍を行うために各圧縮ソフトをインストールしておく必要があります。

Percona Xtrabackupは以下のようにインストールを行うことができます。

実行コマンドについて

以下のコマンドを実行し、それぞれの結果を比較しました。

--parallel(ファイルコピー時の並列スレッド数)、 --compress-threads(圧縮時の並列スレッド数)、--decompress-threads(解凍時の並列スレッド数) はCPUコア数と同数にしています。
補足として、解凍(--decompress)の際は、Percona Xtrabackupは拡張子から適切なメソッドを判断するロジックとなっているため、解凍コマンドはすべてケースで同一です。
ディスクスペースの都合上、解凍の際には--remove-originalオプションを付与して解凍後に圧縮ファイルを削除しています。

実行結果

バックアップサイズ

圧縮率

バックアップ実行時間

バックアップ解凍時間

これまでのquicklz/lz4でもバックアップのサイズをかなり減らす事ができますが、zstdのlevel 1でもquicklz/lz4と比較して約20%のサイズダウンを実現できることがわかりました。

バックアップの実行時間としても、それなりにCPUを使用できる環境であれば、非圧縮の実行時間と遜色ない速度が実現できることも確認できました。

一方で以下は、 mpstat -P ALL を zstd level 19の実行中に確認したものです。
すべてのコアでCPUビジーになっており、%iowaitはそれほど無い様子が確認できます。

以下は、 mpstat -P ALL を zstd level 5の実行中に確認したものです。
CPUの仕事量がlevel 19に比較して少ないため、ディスク性能がボトルネックになっている様子が確認できます。

これらの事から、I/Oが非常に高速でCPUビジーになる状況では、もっと顕著に非圧縮の実行時間よりもzstdの実行時間が増加することになるでしょう。

zstdの最大レベルの圧縮では、もとのバックアップサイズの1/5という素晴らしい結果になりましたが、「実行速度を犠牲にしてもバックアップのサイズを減らしたい」というようなケース以外では、levelを上げることについては慎重になったほうが実用性が高そうです。

バックアップの実行時間(圧縮時の実行時間)と比較して、解凍時の実行時間は zstdのlevelを増やしたとしても顕著な増加は無いというのは実用上嬉しいポイントです。

まとめ

バックアップのサイズが大きすぎて問題となっている運用者様は多いのでは無いでしょうか。

zstdを活用して、バックアップディスクの空きを増やす、これまでは保持できなくて諦めていた複数世代のバックアップを持つなど、ご検討頂けると幸いです。

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃MySQLのサポート業務に従事している有資格者で構成された技術サポートチームがMySQLに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがPerconaに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次