TiDB Xが業務への影響をほぼゼロに抑えて1秒あたり550万行ものインデックスを作成する方法

※このブログは2026年03月16日に公開された英語ブログ「How TiDB X Creates Indexes at 5.5M Rows/s with Near-Zero Business Impact」の拙訳です。

主なポイント

• TiDB Xは最大で1秒あたり550万行の速度でインデックスを作成でき、従来のオンラインDDLの72倍の高速化を実現します。
• DXFはインデックスの作成タスクを複数ノードに分散し、スループットをほぼ線形にスケーリングします。
• グローバルソートによりSSTファイルの重複を排除し、Raft Engine上でのコンパクションを削減し、TiKVのパフォーマンスを安定させます。
• エラスティックなワーカークラスタはインデックスの計算処理を本番環境からオフロードし、QPSとレイテンシーの安定性を維持します。

インデックスの追加は常に慎重を要する操作：

• 小規模なテーブルについては、v6.5.0以降、Fast DDLを備えたTiDBのオンラインDDLにより、従来のトランザクション型DDLと比較して最大10倍のパフォーマンス向上がすでに実現されています。これについては、TiDBはどのようにしてオンラインDDLのパフォーマンスを10倍向上させたのかで詳しく説明しています。
• しかしテーブルのサイズが数百TB規模に成長し、本番クラスタでより多くのワークロードが稼働するようになると、従来の方法には次のような限界が現れます：
  • 単一ノードのDDLオーナーがCPUやI/Oのボトルネックになる可能性があります。
  • 分散インデックス作成ではSSTの重複が発生し、TiKVにコンパクションと追加の負荷を引き起こします。
  • 最適化された取り込みであっても本番クラスタのリソースを消費するため、QPSやレイテンシーが変動するリスクがあります。

課題は明確です。大規模環境でも高速で安定、かつ業務への影響を最小限に抑えながらインデックスを構築するにはどうすればよいのでしょうか？

専用のオブジェクトストレージを導入したTiDBの最新バージョンであるTiDB Xは、3つの主要なイノベーションを組み合わせることでこの問題に対処しています：

1. TiDB分散実行フレームワーク(DXF)：インデックス作成タスクを複数のノードに分散させ、パフォーマンスを劇的に向上させます。
2. グローバルソート：取り込み前にインデックスSSTファイルをグローバルに順序付けし、RocksDBのコンパクションを削減してTiKVを安定させます。
3. サイドローディング機能を備えたエラスティックなワーカークラスタ：ほとんどのインデックスの構築処理を本番クラスタ外に移動させ、オンラインワークロードへの影響を最小化します。

本ブログでは、なぜそれぞれのイノベーションが必要だったのか、それらがどのように機能するのか、そしてこれらが組み合わせることでビジネスへの影響をほぼゼロに抑えながら、どのように1秒あたり550万行の速度でインデックス作成を実現しているのかを解説します。

DXF：分散実行フレームワーク

なぜDXFなのか？取り込みを活用したFast DDLによりトランザクションのボトルネックは解消されたものの、大規模なテーブルでは依然として単一ノードの制限に悩まされていました：

• 1つのDDLオーナーノードだけがADD INDEXジョブを実行するため、そのノードのCPUとI/Oが限界に達することがあります。
• クラスタ内の他のタスクとのリソース競合が発生します。
• 同時に1つのインデックスの構築しか実行できませんでした。

解決策：DXFは、単一のAdd Indexタスクを複数のサブタスクに分割し、それらを複数のTiDBノードにまたがってスケジューリングします。サブタスクは並列で実行されます。

仕組み：

図1：インデックスのタスクを各ノードに分配するスケジューラ

1. スケジューラは、テーブルのインデックスキーの範囲をサブタスクに分割します。
2. 各TiDBノードは、割り当てられたサブタスクを個別に処理し、ローカルでインデックスデータを構築してTiKVに取り込みます。
3. すべてのサブタスクが完了すると、TiDBは結果をマージしてコミットします。

メリット：

• インデックス構築のスループットは、ノード数に応じてほぼ線形にスケーリングします。
• 単一ノードに過度な負荷をかけることなく、大規模なテーブルのインデックス作成を大幅に高速化できます。

ケース	インデックス作成方法	行数	ノード数	平均時間	トランザクションDDL比の性能
1	Transaction Online トランザクションDDL	1,000,000,000	1	12h12時間21分	1倍
2	Fast DDL	1,000,000,000	1	30分	24倍
3	Fast DDL + (DXF)	1,000,000,000	2	14–15分	48倍
4	Fast DDL + (DXF)	1,000,000,000	3	10分	72倍

注：これらの数値は複数のインデックス作成方法の相対的な性能差を示すものであり、実際の環境によって結果が異なる場合があります。

グローバルソート：RocksDBへの影響を軽減

なぜグローバルソートが必要なのでしょうか。DXFは処理を分散しますが、新たな問題を引き起こします。ノード間でインデックスSSTファイルが重複することです。これにより次のような問題が発生します。

• RocksDBでコンパクションが頻繁に発生します。
• 書き込み増幅が増加します。
• TiKVに予測不能な負荷がかかります。

解決策として、グローバルソートはインデックスSSTファイルを取り込み前に全体で順序付けされた状態にします。

仕組み：

1. スキャンとメタデータの収集 – TiDBワーカーがテーブルをスキャンし、キーバリューデータのブロックをローカルでソートします。データブロックとともに、各ブロックのキー範囲とオフセットを記述したメタデータを生成します。これらをS3にアップロードすることで、クラスタ内のどのノードからでもアクセス可能になります。
2. グローバルパーティショニング – スケジューラがすべてのメタデータファイルを読み取り、グローバルマージを実行して、バランスの取れた、重複のないキーパーティションを決定します。各パーティションは連続したキー範囲に対応しており、スケジューラはそれを特定のワーカーに割り当てます。
3. 並列ソートとSST生成 – ワーカーは割り当てられたパーティションに属するデータブロックをダウンロードし、最終的なマージソートを実行します。これにより、キーの重複が発生せず、RocksDBへ安全に取り込める、グローバルに順序付けされたSSTファイルが生成されます。

メリット:

• SSTの重複を排除します。
• コンパクションと書き込み増幅を削減します。
• TiKVの性能を安定化させます。
• 単一テーブルあたり最大600TBの容量に対応します。

ジョブ ID	テーブルデータサイズ	行数	行サイズ	DXFノード数	ノード仕様	インデックスカラム	インデックス作成時間	性能
1	200 TB	80億	26.84 KB	25	8 vCPU, 32 GB	bigint	19分10秒	毎秒696万行

TiDB X：エラスティックなワーカークラスタとサイドローディング

なぜエラスティックなワーカーが必要なのでしょうか？DXFとグローバルソートを併用しても、本番環境のノードが依然としてワークロードの一部を処理するため、負荷の高いクラスタではQPSやレイテンシーに影響が出る可能性があります。

解決策：TiDB Xは、サイドローディングによりインデックス作成を分離しつつ、インデックス構築を処理するために、隔離されたエラスティックなワーカーノードを動的にプロビジョニングします。

図2：インデックス作成を切り離すTiDB Xのエラスティックなワーカーノード

• DXFは、追加するインデックスのサイズに基づいて、対応するTiDBワーカーとTiKVワーカーを自動的にスケールアウトします。
• TiDBワーカーは、インデックス列のスキャン、ソート、およびインデックスSSTの生成を処理します。
• TiKVワーカーはS3にSSTをアップロードし、テナントの本番用TiKVノードはインデックスSSTファイルを非同期でダウンロードします。
• スケジューラはタスクの進捗を監視し、ワーカーを動的にスケールインまたはスケールアウトします。

メリット：

• 計算処理の大部分が本番クラスタの外に移動されます。
• インデックス追加のピークスループットは最大で1秒あたり550万行です。
• オンラインのQPSおよびP99レイテンシーは安定したまま維持されます。

注：最終的なSSTファイルのダウンロード段階では、テナントの本番TiKVも処理に関与します。非常に大きなインデックスやリソース制約のあるテナントのTiKVノードでは、軽微なIOやネットワークの競合が発生する可能性があります。それでも、従来のワークフローと比較すると、影響は劇的に軽減されています。

結論：インデックスの追加はイチかバチかの不安な作業であってはならない

長年にわたり、大規模なテーブルにインデックスを追加する際は、決まった手順を踏む必要がありました。メンテナンスの時間帯を設定し、オンコールチームに通知し、何の問題も起きないことを祈る――そんな作業でした。しかし、そんな時代はもう終わりです。

DXF、グローバルソート、そしてエラスティックなワーカークラスタを備えたTiDB Xは、インデックスの作成を、不確実な懸念事項から日常的な操作へと変貌させました。550万行/秒の処理速度を実現しつつ、ユーザーが実際に重視するワークロードへの影響はほぼゼロです。メンテナンスウィンドウも、祈りを込めたデプロイも不要です。

これは、TiDBのオンラインDDLインフラストラクチャが真の分散実行に向けて再設計されたことで可能になった、ほんの一例に過ぎません。私たちはTiDB X全体に同じ原則を適用し、あらゆる大規模なスキーマ変更をより高速に、より安全に、そしてより予測可能にするよう取り組んでいます。

高速かつ低負荷なインデックス作成を体験してみませんか？TiDB Cloudでこれらの機能を試して、TiDB Xが本番環境のワークロードをどのように加速させるかをぜひ実感してください。