TiAdvisorの概要：自動化されたTiDBインデックスアドバイザー

※このブログは2023年12月19日に公開された英語ブログ「Introducing TiAdvisor: An Automated TiDB Index Advisor」の拙訳です。

このブログでは、TiDB Index Advisor (TiAdvisor) を紹介します。TiAdvisorは、インデックス検出を自動化し、ユーザーのワークロード性能を向上させる新しいツールです。また、このツールを構築する際に採用したテクニックを概説し、その結果を検証するユースケースをご紹介します。

なぜTiDB Index Advisorが必要なのか？

データベースのインデックスはデータへのアクセスを高速化します。また、データベースのパフォーマンスにとても重要です。しかし、適切なインデックスを選択することは、数日から数週間を費やすこともあり、データベース開発者にとって困難な作業です。

TiDBは多様なワークロードを効率的に処理する機能を備えており、オンライントランザクション処理 (OLTP) とオンライン分析処理 (OLAP) の両方のタスクをシームレスに処理します。TiDBのTiKVによる行ベースのストレージは、OLTPワークロードを効率的に管理します。このようなワークロードでは、通常テーブルから少数の行を取得します。これらのワークロードのパフォーマンスは、TiKVテーブルのインデックスに大きく依存します。

手動によるインデックスの選定は複雑な作業です：

1. インデックスの余分なメンテナンスコストと、それがもたらすパフォーマンス上の利点は、トレードオフがあります。
2. クエリ最適化に関する専門的な知識が必要です。
3. ワークロードを考慮して適用するのは難しく、通常は一度に1つのクエリに対して行われます。
4. 全体として最良の解決策を得るには、何日も何週間も試行錯誤を繰り返すのが通常です。

TiDBでは、TiAdvisorによってこれらの課題を解決しました。このツールはワークロード全体を考慮し、全体のパフォーマンスを数分で向上させるインデックスを推奨します。

TiDB Index Advisorのアーキテクチャ内部

与えられたワークロードに対して、可能なインデックスの数は指数関数的に増える可能性があります。例えば、異なる順序とインデックスを持つ5つの列からなるテーブルを考えてみましょう。つまり、5つの単一列インデックス、20の2列インデックス、60の3列インデックス、そして120の4列および5列インデックス作成が可能です。つまり、このテーブルのためだけに325種類のインデックスを作成できることになります！ワークロードに含まれる複数のテーブルを考慮すれば、さらに膨大な数になります。

TiAdvisorはどのように機能するのか？

TiAdvisor は、まずワークロード内のSQLクエリをスキャンし、条件 (predicates)、グループ化 (group-by)、並べ替え (order-by) の句で使用されるカラムを収集します。それ以外のカラムは、SQLクエリのパフォーマンス向上に寄与しないため除外されます。これにより、TiAdvisorは検索空間を無駄に探索することを避けます。次に、TiAdvisorはシンプルな遺伝的アルゴリズムを適用し、まず単一カラムのインデックスを見つけ、それが全体的なワークロードに貢献するかを確認します。その後、2つのカラムを組み合わせたインデックスを探し、さらに必要に応じて複数カラムのインデックスを探索します。このプロセスは、インデックスの数や各インデックスの最大サイズのしきい値に達するまで繰り返されます。

TiAdvisorは、インデックスの候補が有用かどうかを確認するために、「もしこのインデックスがあったらどうなるか」というシナリオを実行します。このプロセスでは、仮想的なインデックス (実際に作成せず、メタデータのみ) を作成します。そして、インデックスがある場合とない場合のワークロード全体のコストを計算します。インデックスがある方がコストが低い場合、そのインデックスを推奨に加え、そうでない場合は無視します。このコスト計算はTiDBのオプティマイザーを活用するAPIによって行われます。

以下の図は、TiAdvisorのアーキテクチャを示し、ツールの入力と出力を詳しく説明しています。また、TiDBを使って仮想インデックスを作成し、クエリのコストを取得する仕組みも明らかにしています。

図1. TiAdvisorのアーキテクチャ図

調整対象のワークロードは、データベースのメタデータ (テーブルスキーマとテーブル統計情報) と一緒にTiAdvisorの入力となります。TiAdvisorの出力は、推奨されるインデックスを作成するためのDDLステートメントのリストです。

TiDB Index Advisorの使い方

TiAdvisorのベータ版が公開されました。以下のlinux shellコマンドでインストールできます：

curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/index_advisor/main/install.sh | sh 

ユーザーは「index-advisor -help」でツールの使い方を確認できます。さらに、GitHubのソースコードが利用可能ですが、ツールの実行には必要ありません。 

TiAdvisorは2つのモードで動作します：オンライン (推奨) とオフラインです。オンラインモードは、TiAdvisorが関連するワークロードデータを持つクラスタにアクセスできる場合に使用されます。このモードは、クラスタ上でTiAdvisorを実行してインデックス推奨を取得したいユーザーに便利です。

始め方の例

オンラインモードでTiAdvisorを実行する例です：

index-advisor advise-online --query-schemas='tuner_db'

--query-path=examples/tpch_example1/queries

--dsn='root:@tcp(127.0.0.1:4000)/tuner_db'

--output=examples/tpch_example1/output

この例では、TPC-H標準ベンチマークの推奨インデックスを探索します。このコードも GitHubにあります。この例では、tuner_dbの下にTPC-Hのサンプルデータをロードする必要があります。また、22個のTPC-Hワークロード・クエリをすべてこのディレクトリに書き込む必要があります。examples/tpch_example1/queries/. 

この例で使用されているオプションについての詳細：

• advise-online はオンラインオプションを表します。
• --query-schemas は、ワークロードのクエリのスキーマを持つデータベースを指定します。
• --query-path 、すべてのワークロードクエリのディレクトリを指定します。
• --dsn はクラスタ情報を指定します。
• --outputは、ツールの出力先をリストアップします。

この例のDDL出力は、下図に示すように、5つのインデックスのDDLになります。

図2. TPC-Hワークロードに対するインデックス推奨。

本番クラスタ外でツールを実行したい場合、ユーザーはオフラインモードを実装できます。ただし、最初にワークロードのメタデータをエクスポートおよびインポートする準備が必要です。このメタデータには、データベーススキーマ、テーブル統計、および別のテストクラスタへの同じ情報のインポートが含まれます。このモードの例を以下に示します。

始めにワークロードのメタデータをエクスポートします： 

index-advisor workload-export--dsn='root:@tcp(127.0.0.1:4000)/test'

--status_address='http://127.0.0.1:10080' --output=examples/offline/export 

• --dsn はクラスタ情報 root:@tcp(127.0.0.1:4000)/test をデフォルトで指定します。
• --status_address はクラスタのステータスアドレスで、統計情報のダンプに使われます。
• --output は、ワークロードのメタデータを保存するディレクトリを指定します。

最後に、エクスポートされたメタデータを使用して、オフラインモードでTiAdvisorを実行します：

index-advisor advise-offline --dir-path=examples/offline/export

--max-num-indexes=3 --output=examples/offline/output 

--dsn='root:@tcp(127.0.0.1:4000)/tuner_db 

• --dir-path は、ワークロードのメタデータのパスを指定します。
• --max-num-indexes はTiAdvisorが推奨するインデックスの最大数を指定します。
• --output は、ツールの出力先をリストアップします。

TiDB Index Advisorの成功事例

TiAdvisorはベータ版をリリースする前に徹底的なテストを行いました。TPC-HでTiAdvisorを実行しました。このベンチマークはよりOLAP中心であり、インデックスはそのような環境では重要ではないにもかかわらず、ワークロードを16％改善しました。 

また、TiAdvisorをjoin-order-benchmark (JOB) にかけました。これにより、5つの推奨インデックスで46%の性能向上が得られました。JOBベンチマークはクエリワークロードがより複雑なため、この改善はTPC-Hよりも顕著です。以下のスクリーンショットは、TiAdvisorへの影響の例として、JOBクエリ6aのインデックス有無を示しています。

図3. JOBクエリの例

オリジナルのクエリプランでは、大規模なテーブル「mk」と「ci」に対してフルテーブルスキャンが実行されていました。一方、最適化されたクエリではインデックスアクセスが利用され、クエリの待ち時間が99%以上短縮されました。

さらに、インデックスの効率的な利用が求められる TiDB Web3の顧客環境でTiAdvisorを実行しました。このツールはわずか数分で処理を完了し、手作業では数週間かかるプロセスと同等の成果を達成しました！

以下の図は、インデックスなし、ユーザーが定義したインデックスあり、そして TiAdvisor によるインデックスありのそれぞれの顧客ワークロードにおけるパフォーマンスを比較しています。TiAdvisor の結果は、手動で作成されたものよりも簡潔で、冗長なインデックスを含まない可能性が高いです。

図4. 秒単位で見積もった総作業負荷コスト

まとめ

TiAdvisorは、アプリケーションの可能性を引き出し、システムパフォーマンスを向上させる最適なインデックスを見つける際に、ユーザーが直面する複雑な課題を解決する能力を実証しています。このツールは現在ベータ版として公開されており、標準的なベンチマークや顧客の本番システムで徹底的にテストされています。

今後、TiAdvisorをさらに改善し充実させるため、コミュニティからのフィードバックを歓迎しています。ロードマップには、検索範囲の拡大やコストモデルの改良といった強化ポイントが含まれています。加えて、TiAdvisorをTiUPパッケージマネージャやTiDBのDBaaSであるTiDB Cloudへ統合する計画も進めています。

TiAdvisorのソースコードはGitHubでチェックできます。ご質問やフィードバックがありましたら、Twitter、LinkedIn、Slack Channelからお気軽にご連絡ください。