Zenn
😆

噂のTiDBをハンズオン - TiDB benchmark with sysbench -

2025/02/16に公開
MySQL
dba
NewSQL
TiDB
tech

はじめに

今回はTiDBにsysbenchで負荷をかけてmetricsを確認してみようの回です。そもそもTiDBはMySQL互換ですが内部的には分散アーキテクチャーなのでそもそも今までのテーブル設計やIndex設計と異なってくると思います。
また、分散アーキテクチャーなので実際のクラウド環境においては zone 間通信による Latency が確実に発生するため、従来のManaged Serviceを含むSingle ZoneのMySQLよりはlatencyは若干劣化するものと予想されます。但し、TiDBとTiKVが水平スケールするためThroughputはかなり伸びると思います。

とはいえいきなりクラウドでの検証はお金もかかるのでローカルで検証してみようと思います。

sysbench準備と負荷がけ

sysbenchのinstall

今回はMACなのでHomebrewでsysbenchをinstallします

brew install sysbench

tiproxy側の準備(auto-certs = true の設定)

実際に試した際にはTiProxy経由の場合、TiProxy側に証明書がなくエラーになるためauto-certs=trueにします。

  • 現在の tiproxy の設定を取得
/Users/${USER}/.tiup/components/tiproxy/v1.3.0/tiproxyctl --host 127.0.0.1 --port 3080 config get > test.toml
  • security.server-tls に auto-certs = true を追加
[security]
[security.server-tls]
min-tls-version = '1.2'
auto-certs = true
  • 変更後の toml ファイルの反映
cat test.toml | /Users/${USER}/.tiup/components/tiproxy/v1.3.0/tiproxyctl config set

sysbench側の準備

sysbench用のdatabaseを事前に作成し、sysbenchで準備用のデータを投入していきます。

mysql --host 127.0.0.1 --port 6000 -u root -e "create database tidb_test;"

sysbench  \
    --mysql-host=127.0.0.1 \
    --mysql-port=6000 \
    --mysql-db=tidb_test \
    --mysql-user=root \
    --tables=1 \
    --table_size=1000 \
    --mysql-ssl=off \
    oltp_common prepare

sysbench実行

いざ実行です！今回はローカルで非力ということもあり4threadで1分間程度負荷掛けしてみます。

sysbench  \
    --mysql-host=127.0.0.1 \
    --mysql-port=6000 \
    --mysql-db=tidb_test \
    --mysql-user=root \
    --mysql-password= \
    --tables=1 \
    --table_size=1000 \
    --threads=4 \
    --time=600 \
    oltp_read_write run

下記のような結果が得られました！

SQL statistics:
    transactions:                        12573  (209.49 per sec.)
    queries:                             252950 (4214.56 per sec.)
    ignored errors:                      89     (1.48 per sec.)
    reconnects:                          0      (0.00 per sec.)

Latency (ms):
         min:                                   10.51
         avg:                                   19.09
         max:                                  152.97
         95th percentile:                        0.00
         sum:                               240028.63

MySQL 8.4 と比較してみよう

MySQL 8.4 を docker で起動し同条件で sysbench の結果を取ってみました。
下記が結果です、MySQLの方が若干スループットと latency が劣っているように見えます。

SQL statistics:
    transactions:                        6642   (110.64 per sec.)
    queries:                             133142 (2217.87 per sec.)
    ignored errors:                      18     (0.30 per sec.)
    reconnects:                          0      (0.00 per sec.)

Latency (ms):
         min:                                   23.65
         avg:                                   36.15
         max:                                  264.94
         95th percentile:                        0.00
         sum:                               240081.17

結果

TiDB と MySQL の比較を下記の表にまとめます。
ThroughputとLatencyを見るとTiDBの方が結果はよいです。但し、あくまで今回はLocal環境であり、実際に商用環境で想定されるTiDB↔TiKVのzone間のNW Latencyが存在しないなので、TiDBが有利な条件にはなっています。逆にNW Latencyが存在しない状況であればTiDBの方が早い、とも解釈はできます。

database Throughput(queries/sec) Latency(avg)
TiDB 4214.56 19.09
MySQL 2217.87 36.15

TiDB Dashboard からの確認

TiDB Dashboard からも一連のクエリの確認が可能です。

SQL をクリックするとDashboard上から実行計画の確認も可能です。MySQLと同様にコストベースで実行計画が決まっていそうですね。

SQL実行のみではなく前段の実行計画のパース時間等も確認可能です。

Key Visualizerを見るとrow_504〜row_517が若干のHot Spotになっているようです。今回の sysbenchはAUTO_INCREMENTでidを生成しているので、そこが影響しているのかもしれません。

まとめ

今回TiDBに対してsysbenchで簡易的に負荷をかけてみました。ローカル環境ということもありましたが、TiDBの性能は期待できそうだと感じました。

  • 負荷掛けの過程もMySQLと同様で互換性の高さが伺える
  • 結果はThroughput,LatencyともにTiDBの方が優秀

実際の商用環境はTiDB,TiKV共にMulti Zoneが一般的であるため、物理的なNW Latencyが大きく関わってくるのですが、そこが実機で計測してどうかはポイントになると思います。ただ、上述のような NW Latencyが問題になる場合でもfollower readといった同じzone間で完結するような設定もあるためパラメータチューニングは必要になると思います。

最後に今回負荷掛けをして気になったのがTiDBベストプラクティスであるAUTO_RANDOMが、AUTO_INCREMENTと比較してどの程度の性能差になるのかは今後一度確認をしてみたいと思いました。

Discussion