この記事は、TiDB Advent Calendar 2023 4日目の記事です。

前回の記事ではtiupの基本的な使い方をご紹介しました。この記事でtiupを使って何かしらTiDBで遊ぶことができるようになったかと思います。では次の段階へ進みましょう！

この記事ではTiDBでベンチマークを実行する方法をご紹介します。TiDBに限らず、製品を評価するにあたってベンチマークで性能を確かめることは製品の特性を知る上でとても重要です。一方で、性能評価は簡単ではありません。どのベンチマークを使うのか、どの程度のデータ量で実施すれば良いか、ハードウェアの構成やスペックをどうすれば良いか…。こういったトピックを語るだけでもかなりの文量が必要になりますが、この記事では、tiupでベンチマークを簡単に実行できるということをご紹介します。

tiupでベンチマークを実行する

出オチ感がありますが、実は公式ドキュメントで紹介されています。

https://docs.pingcap.com/tidb/stable/tiup-bench#stress-test-tidb-using-tiup-bench-component

これを読んでしまえば、この記事はもうおしまいなのですが、せっかくなので各ベンチマークについて少しだけ深掘りしながら紹介します。

tiup bench

改めてtiupについて説明すると、tiupはTiDBエコシステムのパッケージを一元的に管理するパッケージマネージャーという側面と、各種ツールをサブコマンドとして利用してTiDBを操作および管理するコマンドランナーという側面があります。

コマンドランナーという側面でみると、大まかな説明ですが、tiupがやっているのは基本的に指定されたコマンドのバイナリファイルを実行しているだけです（ビルトインされているコマンドもあります）。tiup benchというコマンドでベンチマークを実行しますが、これも同様にtiup benchで指定されたベンチマークツールのバイナリを実行しているだけです。tiup benchが執筆時点でサポートしているベンチマークは以下のとおりです。

$ tiup bench
tiup is checking updates for component bench ...
Starting component `bench`: /Users/shige/.tiup/components/bench/v1.12.0/tiup-bench
Usage: tiup bench {ch/rawsql/tpcc/tpch/ycsb} [flags]
...

上記の出力からtiup benchは５つのベンチマークをサポートしていることがわかります。それぞれについて簡単に説明します。

この記事ではtpccとrawsqlについて見ていきます。なお、特に断りが無い限り、ターゲットとなるDBはローカルにあるPlaygroundクラスタ（tiup playgroundで起動したクラスタ）とします^[1]。

TPC-C

TPC-CはOLTPを想定したトランザクションでベンチマークを測定します。詳細は以下のURLでご確認ください。

https://www.tpc.org/tpcc/

さっそく使い方を見てみましょう。

$ tiup bench tpcc
tiup is checking updates for component bench ...
Starting component `bench`: /Users/shige/.tiup/components/bench/v1.12.0/tiup-bench tpcc
Usage:
  go-tpc tpcc [command]

Available Commands:
  check       Check data consistency for the workload
  cleanup     Cleanup data for the workload
  prepare     Prepare data for TPCC
  run         Run workload
...

おや？と思いましたか？Usageのところにgo-tpc tpcc [command]とありますね。先ほど申し上げたように、tiup自体は指定されたコマンドのバイナリを実行しているだけです。tpcc、 tpch、ch、そしてrawsqlの場合はgo-tpcというコマンドを実行しています。

使い方の話に戻りましょう。tiup bench tpccでできることは以下の4つです。

check: ワークロード実行後にデータの整合性を確認する
cleanup: ワークロード実行後に使用したDBなどのデータを削除する
prepare: TPC-Cワークロードに応じたデータをDBにロードする
run: ワークロードを実行する。

これを見るとわかるように、TPC-Cでのベンチマークは prepare -> run -> check -> cleaup という順で実行することになります。

細かい手順は公式ドキュメントを見ていただくとして、この記事ではtiup bench tpccを実行すると、どのような結果が得られるのかを見ていきます。

まずはPlaugroundクラスタを起動します。ここでは最小構成で起動しています。ベンチマークの結果をちゃんと見るのであれば、--without-monitorは外したほうが良いでしょう。

$ tiup playground --db 1 --tiflash 0 --without-monitor

tiup bench tpccを実行します。

# データの準備
$ tiup bench tpcc --warehouses 2 --parts 2 prepare
# workloadの実行
$ tiup bench tpcc --warehouses 2 --time 1m run
...

runが完了すると、以下のような結果が出ます。

...
Finished
[Summary] DELIVERY - Takes(s): 59.9, Count: 596, TPM: 596.6, Sum(ms): 8687.6, Avg(ms): 14.6, 50th(ms): 13.6, 90th(ms): 17.8, 95th(ms): 19.9, 99th(ms): 25.2, 99.9th(ms): 50.3, Max(ms): 83.9
[Summary] NEW_ORDER - Takes(s): 60.0, Count: 6576, TPM: 6578.1, Sum(ms): 30926.3, Avg(ms): 4.7, 50th(ms): 4.7, 90th(ms): 6.3, 95th(ms): 7.3, 99th(ms): 11.5, 99.9th(ms): 21.0, Max(ms): 71.3
[Summary] ORDER_STATUS - Takes(s): 59.9, Count: 555, TPM: 555.9, Sum(ms): 1361.6, Avg(ms): 2.5, 50th(ms): 2.6, 90th(ms): 3.1, 95th(ms): 4.7, 99th(ms): 5.8, 99.9th(ms): 6.8, Max(ms): 14.7
[Summary] ORDER_STATUS_ERR - Takes(s): 59.9, Count: 1, TPM: 1.0, Sum(ms): 0.4, Avg(ms): 0.8, 50th(ms): 1.0, 90th(ms): 1.0, 95th(ms): 1.0, 99th(ms): 1.0, 99.9th(ms): 1.0, Max(ms): 1.0
[Summary] PAYMENT - Takes(s): 59.9, Count: 6452, TPM: 6459.4, Sum(ms): 16228.6, Avg(ms): 2.5, 50th(ms): 2.6, 90th(ms): 3.1, 95th(ms): 4.2, 99th(ms): 7.3, 99.9th(ms): 16.3, Max(ms): 52.4
[Summary] STOCK_LEVEL - Takes(s): 59.8, Count: 588, TPM: 589.7, Sum(ms): 1898.8, Avg(ms): 3.2, 50th(ms): 3.1, 90th(ms): 4.2, 95th(ms): 4.2, 99th(ms): 6.8, 99.9th(ms): 8.4, Max(ms): 11.0
tpmC: 6578.0, tpmTotal: 14779.6, efficiency: 25575.6%

[Summary]にあるDELIVERYやNEW_ORDERはトランザクションを指しています。ここではテストケースぐらいの理解で良いでしょう。このように各トランザクションでの結果を見ることができます。これらの数値が意味するところはTPC-Cのホームページを見てください。

このように、tiupを使うことで非常に簡単にTPC-Cを行うことができます。これだけ簡単に実行できるのであればいろんなケースをテストすることができますね！

Raw SQL

TPC-CやTPC-Hなどのベンチマークはすでにシナリオやテーブル構造などが決められたベンチマークです。となると、つぎは自分のもっているDBでベンチマークを走らせてみたいですね？

そういった場合に使えるのがtiup bench rawsqlです。rawsqlではユーザーが指定したSQLを実行させることができます。似たようなツールとしてはmysqlslapがあります。残念ながらmysqlslapの結果ほど詳細な出力を得ることはできませんが、簡易なベンチマークとして便利に使うことができます。

それでは使い方を見てみましょう。まずは適当にテーブルを作成します。

mysql > USE test;
mysql > CREATE TABLE t (a int);

もし、ベンチマークを取りたいトランザクションがSELECT文であるならば、ここで必要な量だけデータをINSERTしておいてください。

つぎにベンチマークを測定したいクエリをSQLファイルに書き出します。ここではdemo.sqlとします。

BEGIN;
INSERT INTO t VALUES (RAND()*100);
UPDATE t SET a = a * RAND(10) WHERE a < RAND()*3;
-- 時間のかかるクエリをエミュレートする
SELECT a, SLEEP(RAND()*3) FROM t WHERE a < RAND()*3;
COMMIT;

ランダムにデータを追加、更新、そして参照します。

1分間クエリを実行してみます。デフォルトでは10秒ごとに途中経過（[Current]の行）が出力されます。

$ tiup bench rawsql run --time 1m --query-files demo.sql
[Current] DEMO: 0.23s
[Current] DEMO: 0.87s
[Current] DEMO: 0.78s
[Current] DEMO: 1.02s
[Current] DEMO: 1.12s
[Current] DEMO: 0.98s
Finished
[Summary] DEMO: 0.64s
[Summary] DEMO_ERR: 0.07s

[Current]に出てくるのは10秒（--intervalオプションで指定した時間）ごとのクエリ実行時間の平均となっています。[Summary]は全実行時間の平均となっています。

ベンチマークを取りたいSQLファイルは複数指定することができます。例えば、もう１つsample.sqlというファイルも加えたい場合は--query-filesオプションにカンマ区切りで追加してください。

$ tiup bench rawsql run --time 1m --query-files demo.sql,sample.sql
tiup is checking updates for component bench ...
Starting component `bench`: /Users/shige/.tiup/components/bench/v1.12.0/tiup-bench rawsql run --time 1m --query-files demo.sql,sample.sql
[Current] DEMO: 0.23s
[Current] SAMPLE: 0.00s
[Current] DEMO: 2.08s
[Current] SAMPLE: 0.00s
...

このように、SQLファイル名に基づいてテストケースの名前が生成されていることがわかります。

SQLファイルを複数使う場合の注意点ですが、例えば今回のように--timeオプションを利用する場合、指定した時間だけ２つのSQLファイルを実行します。rawsql(というかgo-tpc)では実行時間だけでなく、--countで実行回数を指定することができます。このとき、実行対象のSQLファイルが複数あると、各ファイルの実行回数はファイル数に応じて除算されます。例えば、--count 10でSQLファイルが２つあると、1ファイルにつき5回となります。

まとめ

今回の記事ではtiupでTiDBをもっと遊ぶためにtiup benchをご紹介しました。ベンチマークの実施はそれなりに大変ではありますが、tiup benchを使うことで少しでも作業を楽にしていきたいですね！

脚注

tpcc、 tpch、ch、そしてrawsqlはMySQLドライバもしくはPostgreSQLドライバで接続可能なRDBMSであればターゲットDBとすることが可能です。ycsbの場合は　https://github.com/pingcap/go-ycsb/tree/master#supported-database　をご参照ください。 ↩︎

Discussion