TiDBのスケーラビリティを最大化：次世代DDLの実現

※このブログは2025年8月25日に公開された英語ブログ ｢Unleashing TiDB Scalability: The Next Generation of DDL Execution｣ の拙訳です。

大規模なスキーマ変更を行うことは、SaaSアプリケーションにとって悪夢になり得ます。インデックス作成の遅延、長時間実行されるスキーマ変更、そしてスケーラビリティの制約は、運用を妨げ、リアルタイムでのデータベースの進化をほぼ不可能にしてしまいます。TiDBはこれらの課題に真正面から取り組み、継続的に分散SQLおよびDDL実行の限界を押し広げています。

昨年、私たちはインデックス作成速度を10倍に向上させ、大規模なスキーマ変更を最小限のダウンタイムで実現できるようにしました。現在、TiDBはスケーラビリティの面で分散SQL市場をリードしており、最大100万テーブルをサポートしています。これは他のベンダーが達成できない画期的な成果です。このことにより、マルチテナンシーや高スループットが求められる最新のSaaSアプリケーションにおいて、TiDBは真にスケーラブルな唯一の選択肢となりました。

業界が求める水準を先取りするため、私たちはDDLフレームワークの実行プロセスを再設計する作業に6か月を費やし、速度・安定性・スケーラビリティに重点を置きました。これらの改良により、TiDBは数百万のテーブルを管理する企業にとって最適なソリューションとしての地位をさらに確固たるものにしました。

このブログでは、次の内容を取り上げます。

• 大規模なスキーマ管理において直面する主な課題
• DDLパフォーマンスを向上させるために実装した革新的なソリューション
• 高スケール環境において、TiDBがどのようにMySQLやAuroraといった従来のデータベースを上回るのか

もしあなたが大規模なSaaS、分散SQL、またはデータベースのパフォーマンスチューニングに携わっているなら、この詳細な解説は必見です。

SaaSデータベースが直面する特有の課題

現代のSaaSプラットフォームはマルチテナント構成であり、各顧客 (テナント) は独立したデータベース環境内で動作します。この仕組みによりテーブル数が数百万に達することもあり、スケーラビリティが重大な課題となります。

SaaSデータベースが満たすべき要件は次のとおりです：

• 高いスケーラビリティ：従来の単一ノード型データベースは、数百万テーブルの処理時にスケーリングが困難です。
• シームレスなスキーマ進化：頻繁なスキーマ更新があっても、稼働中のユーザーに影響を与えてはなりません。
• 運用スループット：数千件規模のスキーマ変更 (DDL操作) を遅延なく実行する必要があります。
• 同時実行時の安定性：高負荷状態でもデータベースは一貫した性能を維持しなければなりません。

TiDBは、スキーマ変更を段階的に適用できるオンラインDDL実行によって、これらの要件に対応します。これによりダウンタイムゼロでスキーマ変更を段階的に適用可能とします。クラスタ全体で一貫性を保証するための主要コンポーネントは次のとおりです：

• PD (Placement Driver)：スキーマ変更をオーケストレーションし、全体の調整を担います。
• ETCD：ノード間でスキーマメタデータの一貫性を維持します。
• メタデータロック (MDL)：更新中に競合する変更が行われるのを防ぎます。

これらのメカニズムが連携することで、TiDBはサービスを中断することなく、大規模環境でのスキーマ進化を実現しています。

エンジニアリングアプローチとベストプラクティス：TiDBのDDLパフォーマンスを最適化した方法

TiDBの導入が数百万テーブル規模のデプロイメントへと拡大する中で、新たなパフォーマンスボトルネックに直面しました。私たちの最適化の取り組みは、次の3つの原則に基づいて進められました：

• 顧客中心のフォーカス：本番環境で最も影響の大きい問題の修正を優先する
• 段階的なデリバリー：改善をデプロイ可能なステップで順次リリースする
• 最小限の中断：互換性と安定性を全期間にわたって確保する

最適化ロードマップとマイルストーン

TiDBの採用が進み、数百万テーブル規模のデプロイメントへと拡大する中で、私たちは新たなパフォーマンスおよび安定性の課題に直面しました。これらを体系的に次のように対処しました：

• TiDB7.5 – 50万テーブルを超えるスケーラビリティのボトルネックを特定。この段階で、MySQL 8.0.32 (約2時間で100万テーブルを作成可能) と比較してパフォーマンスの低下が見られました。
• TiDB7.6 – テーブル作成を主要なパフォーマンスボトルネックとして特定し、DDL実行パスの最適化に向けた重点的な取り組みを開始しました。
• TiDB8.1 – テーブル作成速度を118倍改善し、100万テーブルの作成に必要な時間を約4時間まで短縮しました。
• TiDB8.3 – さらなる最適化によりテーブル作成時間を1.5～2時間に短縮し、MySQLと肩を並べる水準を達成。
• TiDB8.4 & 8.5 – 保守性とスケーラビリティを向上させるため、DDL実行コードをリファクタリングしました。
• 今後の目標 – 並列実行、インテリジェントなリソーススケジューリング、自動ワークロードバランシングを備えた完全分散型のネイティブDDL実行フレームワークを開発します。

図1：最適化ロードマップとマイルストーン

バージョン8.1までの最適化効果を示すデータセット

テーブル数	TiDB 7.5	TiDB 7.6	TiDB 8.0	MySQL 8.1.0	パフォーマンス向上率
100k (10万)	3時間30分	26分	9分39秒	5分30秒	21.76倍
300k (30万)	59時間20分	(推定)6時間以上	30分38秒	14分未満	118倍

主要な最適化領域

スキーマ変更パフォーマンスに影響を与えていた複数のボトルネックに対処しました：

• スケジューリングと並行性：スケジューリングの粒度を高め、DDLタスク全体を単位として実行できるようにしました。また、ワーカープールを拡張し、独立したジョブの並列実行を可能にしました。
• メタデータの最適化：メタデータキャッシュを導入し、TiKVへのフォールバック参照を削除することで、スキーマ検証時の冗長なI/Oを削減しました。
• 並列化とバッチ処理：テーブル作成をノード間で分散し、ジョブをバッチトランザクションとしてまとめることで、実行オーバーヘッドを大幅に削減しました。
• ダイレクト実行：DDL文を発行元ノード上で直接実行できるようにし、中央キューのボトルネックを解消しました。
• ターゲット型通知：ブロードキャスト通知を方向性のある更新 (ターゲット通知) に置き換え、不要な処理を削減しました。
• グローバル一意性チェック：インデックス化されたメタデータ構造を活用し、高い並行性の下でもテーブル名の一意性を効率的に検証できるようにしました。

画期的な実装

これらの変更の中で、最も大きな影響をもたらしたのは次の3つです：

1. DDLタスクのローカル実行：発行元ノード上で実行することで、キュー待ちの遅延を解消しました。
2. グローバル一意性のためのインデックス化メタデータ：名前の検証に伴う高コストなフルスキャンを排除しました。
3. バッチ実行：複数のテーブル作成ジョブを1つのトランザクションにまとめることで、効率を向上させました。

これらの強化が重要な理由

これらの最適化により、TiDBは以下のことが可能になります：

• 数百万テーブル規模へのシームレスなスケーリング
• 低遅延かつ高スループットでのスキーマ変更の実行
• MySQLやAuroraと単純な速度で直接競合しつつ、それらにはない分散スケーラビリティを提供

DDLエンジンの改良により、SaaS規模の分散スキーマ管理に対応可能な、将来を見据えた基盤を構築しました。

TiDB最適化のプロセスを深く掘り下げる

TiDB 8.1でテーブル作成パフォーマンスが大幅に向上した後、お客様はその効果をすぐに実感しました。 しかし、大規模デプロイメント全体での一般的なDDL実行には依然として課題が残っていました。これに対応するため、TiDB 8.2以降では最適化の取り組みをさらに拡大し、スループット、安定性、そして全体的な実行効率の向上に重点を置きました。

パフォーマンスボトルネックの特定

TiDBのDDL実行プロセスを詳細に分析したところ、特に数百万テーブルを扱う大規模マルチテナント環境で、複数のボトルネックが明らかになりました。これらの問題は、これまでの実装が短いサイクルで急速に更新されていたことと、よりスケーラブルな実行モデルの必要性に起因していました。

主なボトルネックは次の通りです：

• 非効率なDDLタスクスケジューリング：DDLタスクが順次処理され、不要なスケジューリングのオーバーヘッドが発生していました。
• データベース／テーブル存在チェックの遅さ：スキーマ検証が、一部の場合で低速なフォールバックメカニズムに依存していました。
• 計算リソースの未活用：TiDBノードが並列実行のために十分に活用されていませんでした。
• 非効率なブロードキャスト方式：スキーマ変更がノード間に伝播する際、不要な遅延が生じていました。

これらの課題を体系的に解決することで、TiDBのDDL実行は高効率で分散型のプロセスへと進化しました。

DDLタスクスケジューリングの最適化

TiDBの従来のスケジューリング戦略では、各DDL文の細かい粒度のステートマシンのステップを順次処理しており、過剰なスケジューリングオーバーヘッドが発生していました。

• スケジューリング粒度の調整：細かい粒度のステートマシンのステップを処理する代わりに、DDLタスク全体を単位として処理することで、オーバーヘッドを削減し効率を向上
• 並列性の強化：独立したDDLタスクを並列で実行可能にし、システムリソースの活用を最大化、全体の実行時間を短縮
• 実行リソースの拡張：一般DDLタスク用のワーカープール数を増加させ、複数タスクの同時実行を可能にし、スループットを大幅に向上
• スケジューリングロジックの簡素化：アルゴリズムを最適化することでスケジューリングの複雑さを低減し、全体的な効率を改善

これらの変更により、DDLタスクのスケジューリング効率が大幅に向上するとともに、リソース消費も削減されました。

データベース／テーブル存在チェックの最適化

テーブルの存在を効率的に確認することは、TiDBのDDL実行パフォーマンスにとって極めて重要です。現在、TiDBはテーブルの存在を確認するために、メモリ上のスキーマキャッシュを照会する方法と、必要に応じてTiKVへのフォールバックを行う方法の2つを使用しています。キャッシュによる確認は概ね十分ですが、高い並行性のワークロード下では、TiKVへのフォールバックが不要な遅延を生じさせます。

パフォーマンスを最適化するため、直接TiKVを参照する方法を廃止し、テーブル存在確認はスキーマキャッシュのみに依存するようにしました。この決定の理由は以下の通りです：

• 信頼性の高いスキーマキャッシュ同期：DDLオーナーノード上のスキーマキャッシュは常に更新されており、正確性が保証されます。
• ジョブ依存関係の計算：実行前にDDLジョブ間の依存関係を分析し、同じテーブルの同時作成を防ぎます。
• 順次ジョブ実行：TiDBはDDLジョブを順序通りに処理し、後続ジョブの実行前にスキーマ更新が正しく伝播することを保証します。
• DDLオーナー向けスキーマ再読み込み：ノードがDDLオーナーになると、TiKVと同期を保つためにスキーマメタデータを再読み込みします。

スキーマキャッシュのみに依存することで、TiKVへの不要なクエリを大幅に削減し、特に大規模デプロイメントにおける実行速度と効率を向上させました。

以下の関数は、最適化されたテーブルの存在確認ロジックを示しています：

func checkTableNotExists(d *ddlCtx, t *meta.Meta, schemaID int64, tableName string) error {
        // Try to use memory schema info to check first.
        currVer, err := t.GetSchemaVersion()
        if err != nil {
                return err
        }
        is := d.infoCache.GetLatest()
        if is.SchemaMetaVersion() == currVer {
                return checkTableNotExistsFromInfoSchema(is, schemaID, tableName)
        }

        return checkTableNotExistsFromStore(t, schemaID, tableName)
}

私たちは単一タスクを使用して、ワーカーが実行する汎用DDLジョブを順次処理します。そのため、ほとんどの場合、存在確認は最初の分岐を通過し、スキーマキャッシュが利用されます。しかし、並列ジョブが実行される場合、ノードのスキーマバージョンがTiKVより遅れることがあり、その結果、第二の分岐にフォールバックせざるを得ず、テーブル数が増えるにつれて実行が遅くなります。

スキーマキャッシュのみに依存する

パフォーマンス向上のため、第二の分岐を排除し、スキーマキャッシュのみに依存することを提案します。この変更は、以下の主要な観察に基づいています：

• スキーマキャッシュの信頼性：オーナーノード上のキャッシュは適切に同期されており、存在確認には最新の情報が使用されます。
• 事前計算されたジョブ依存関係：実行前に依存関係を分析し、同一スキーマオブジェクトの同時テーブル作成を防ぎます。
• 実行順序の一貫性：ジョブはジョブIDの順に実行され、更新が順次処理されることで冗長な確認を回避します。
• オーナーシップ移行時のスキーマ同期：ノードがDDLオーナーの役割を引き継ぐ際、TiKVと整合するようにスキーマメタデータを再読み込みします。

スキーマキャッシュのみに依存することで、不要なTiKV参照を排除し、実行遅延を削減するとともにシステムのスループットを向上させます。この改善により、DDL操作はワークロード増加に応じて効果的にスケールしつつ、一貫性と正確性を維持できます。

この最適化は、DDL実行の効率とシステムの安定性を大幅に向上させます。追加の施策としては以下が含まれます：

• インデックス最適化：将来的なデータディクショナリプロジェクトでは、テーブル名やスキーマ名の検索を高速化するためのインデックスが導入されます。
• フォールトトレランス機構：スキーマキャッシュの検証は概ね信頼できますが、極端な同期問題に対応するための追加の安全策も用意されます。

コンピューティングリソースの利用効率向上

TiDBのスキーマ同期機構は当初、定期ポーリングに依存しており、システムは一定間隔でスキーマの更新を繰り返しチェックしていました。この方法では、頻繁なスキーマ変更やスキーマロードの遅延により、不要な無効チェックが多発し、システムの処理速度が低下するという非効率が生じていました。

これを解決するために、ETCDのWatch機構を採用しました。定期的なポーリングの代わりに、TiDBはETCDのリアルタイム変更を監視します。スキーマバージョンに変更があった場合、ETCDは即座にTiDBに通知し、オンデマンドで同期が行われます。この改善により：

• 不要なポーリングが排除され、システム負荷が軽減されます。
• 応答時間が改善され、スキーマ変更の伝播がより迅速になります。
• リソース効率が向上し、TiDBは繰り返しのチェックではなく実行処理に計算資源を集中できるようになります。

DDL完了通知のブロードキャスト方式の置き換え

従来、TiDBはDDL完了を通知するためにブロードキャスト通知を使用していました。この方法では、複数のサブミッションスレッドが同じ通知を処理しようとするため、不要な処理遅延が発生するという非効率が生じていました。

最適化後の実装では、これを方向性通知 (directional notifications) に置き換え、特定のDDLジョブを担当するスレッドのみが完了イベントを受け取るようにしました。この変更により：

• 冗長な処理が防止され、全体的な実行オーバーヘッドが削減されます。
• DDL完了が高速化され、処理を投入したスレッドは迅速に実行を終了できます。
• スループットが向上し、TiDBが大量のスキーマ変更を処理する能力が改善されます。

将来のスケーラビリティに向けたDDLフレームワークのリファクタリング

既存のDDLフレームワークは、時間の経過とともに技術的負債が蓄積され、進化するビジネスニーズに柔軟に対応しにくくなっていました。TiDBを将来にわたって対応可能にするため、私たちはDDLフレームワークの包括的なリファクタリングを開始しました。

旧フレームワークの課題

この全面的な見直しが必要となった主な理由は以下の通りです：

• 設計の老朽化：フレームワークの元々の設計は柔軟性とスケーラビリティに限界がありました。
• コードの保守性の低さ：長年の修正や局所的な最適化により、高い結合度、冗長なロジック、読みづらいコードが増加していました。
• テストの不十分さ：包括的な単体テストや統合テストが不足しており、リグレッションのリスクが高まっていました。
• 反復速度の遅さ：複雑なコード構造により、修正には時間がかかり、エラーが発生しやすくなっていました。

リファクタリングの目的

リファクタリングの目的は以下の通りです：

• コード品質の向上：モジュール化された疎結合な構造を採用し、可読性と保守性を高めます。
• テストカバレッジの強化：単体テスト、統合テスト、E2Eテストを導入し、システムの安定性を確保し不具合発生率を低減します。
• アーキテクチャの最適化：マイクロサービスやドメイン駆動設計 (DDD) などの最新のアーキテクチャパターンを採用し、スケーラビリティと耐障害性を向上させます。

リファクタリング戦略

私たちは、リスクを最小限に抑えつつ継続的な改善を行うため、段階的リファクタリングアプローチを採用しました：

• 小さく、段階的な変更：リファクタリング作業を小さなステップに分割し、各変更を検証しながら進めます。
• 継続的インテグレーション (CI)：自動ビルドと自動テストを活用し、問題を早期に検出します。
• コードレビュー：厳格なレビューを実施し、コード品質の維持とチーム内での知識共有を促進します。

期待される成果

今回のリファクタリングによって、以下の成果が期待されています：

• より高い安定性：コード品質の向上によりバグが減少し、システムの信頼性が向上
• 開発効率の向上：クリーンなコードベースによって、変更やデバッグのスピードが向上
• 優れたスケーラビリティ：新しいアーキテクチャ設計により、将来的な拡張や新機能の追加に柔軟に対応

潜在的なリスクと対策

リファクタリングには課題が伴いますが、慎重な計画によってリスクを軽減しています：

• リスク：新たなバグの混入
  • 対策：小規模で段階的な変更を行い、徹底的なテストを実施します。
• リスク：新機能開発の遅延
  • 対策：ビジネス要件とリファクタリングを連携させ、影響を最小限に抑えます。

最適化プロセスから得られた主要な成果

この複数フェーズにわたる最適化プロジェクトを通じて、私たちは次の成果を達成しました：

• スケジューリングと並行処理の最適化により、DDL実行スループットを向上
• 不要なスキーマ検証によるボトルネックを排除し、実行時間を短縮
• クラスタ全体の同期処理を改善し、高負荷環境下でのパフォーマンスを向上
• 将来のスケーラビリティを見据えてフレームワークをリファクタリングし、TiDBが今後のビジネスニーズにも柔軟に対応できる基盤を確立

TiDBのDDL実行プロセスを継続的に改善することで、次世代の分散スキーマ管理に向けた基盤を着実に築いています。

TiDB DDL最適化の効果測定

TiDB 8.2および8.3でこれらの最適化を実装した後、その効果を測定するために大規模なベンチマークテストを実施しました。その結果、DDL実行スループット、スケーラビリティ、安定性の大幅な向上が確認され、TiDBは大規模環境でのデプロイにおいて、さらに強力で信頼性の高い選択肢となりました。

TiDB8.2：DDLパフォーマンス全般の向上

TiDB 8.1と8.2におけるDDLタスク実行時のQPS (Queries Per Second：1秒あたりのクエリ数) を比較すると、大幅なパフォーマンス向上が見られました。TiDB 8.1では平均QPSがおよそ7でしたが、TiDB 8.2では平均QPSが38に上昇し、ピーク時には80QPSに達しました。これは約5倍の改善に相当します。

図2：TiDB8.1とTiDB8.2におけるQPS

このデータから、TiDB 8.2では実行効率が大幅に最適化され、DDLのパフォーマンスが格段に向上したことが確認できます。

TiDB 8.3：さらなるパフォーマンス向上

TiDB 8.3では、さらなる改良によって一層大きな性能向上が実現しました。TiDB 8.2と比較すると、TiDB 8.3では最大QPSがおよそ200に達し、平均QPSも180を記録しました。また、パフォーマンスの安定性も向上しており、DDL実行最適化の継続的な進歩が確認されました。

図3：TiDB8.2とTiDB8.3におけるQPS

さらに、Fast Create Table機能を有効にすることで、DDL操作のQPSがさらに2倍に向上し、システム全体のスループットが大幅に強化されました。

TiDB 8.5：MySQLおよびAuroraとのベンチマーク比較

TiDB 8.5におけるDDLパフォーマンスを包括的に評価するため、以下のハードウェア構成を備えた専用のテストクラスタを構築しました。

ノードタイプ	台数	仕様
PD	1台	88コア・16GBメモリ
TiDB	3台	16コア・32GBメモリ
TiKV	3台	8コア・32GBメモリ

テスト結果は以下の通りです：

操作内容	TiDB 7.5	TiDB 8.5	説明
10万テーブルの作成	3時間49分	11分 (20倍高速) / Fast Create Table 有効時は4分 (50倍高速)	単一のデータベース内にテーブルを作成
100万テーブルの作成	2日以上	1時間30分 (50倍高速)	各スキーマに100テーブルを含む1万スキーマを作成
10万スキーマの作成	88時間27分	15分 (32倍高速)	ー
10万テーブルにカラム追加 (Add Column)	時間11分	32分 (11倍高速)	すべてのテーブルを単一のデータベース内に作成

ベンチマーク比較：TiDB vs. MySQL vs. Amazon Aurora 

MySQLおよびAmazon Auroraとの直接比較において、TiDBは大規模なDDL操作に対して優れたスケーラビリティを示しました。

一般的なDDLを実行するEC2	c5a.2xlarge  (8コア16GB)
Amazon Aurora	Db.r6g.2xlarge (8コア64GB) Aurora I/O最適化 Aurora MySQL3.05.2 (MySQL8.0.32互換)
MySQL	Db.m5.2xlarge (8コア32GB) AWS RDS MySQL MySQL8.0.39 単一DBインスタンス Standardクラス (mクラス含む) Provisioned IOPS SSD (io2)

ベンチマークテスト結果：

操作内容	TiDB 8.5	Amazon Aurora	MySQL
10個のDBにそれぞれ100テーブル作成 (合計100万テーブル)	1時間30分	1時間24分	1時間46分
4つのDBに100万テーブル作成	2時間10分	1時間59分	2時間15分
単一DBに10万テーブル作成	8分55秒	8分31秒	12分41秒
10万テーブルに1カラム追加	31分47秒	13分35秒	6分3秒

これらの結果は、TiDBのDDL実行能力が向上していることを示しており、従来バージョンに比べて大幅な改善が見られるとともに、従来型データベースに対しても競争力のある性能を発揮していることを確認できます。この進展は、TiDBが分散データベース技術におけるさらなるイノベーションを続けるための強固な基盤となります。

ベンチマーク結果のまとめ

この結果から、TiDBのDDL実行性能が大幅に向上しており、同時に高いスケーラビリティも維持していることが確認されました。

• TiDBのマルチテナント機能により、数百万のテーブルを効率的に扱うことが可能です。
• スキーマ操作の高速化により、SaaSプロバイダーにとって機能リリースの迅速化が可能になります。
• DDL性能はAuroraなどの主要クラウドデータベースと肩を並べるレベルになりつつあり、TiDBの分散環境での柔軟性も維持されています。

TiDB DDL実行の今後

今後の重点領域は以下の3つです：

• DDLアーキテクチャの改良：フレームワークをより直感的で保守しやすくし、変化するワークロードへの適応性も高めることを目指します。
• 安定性と性能のさらなる向上：スケジューリング機構、メタデータ管理、並列実行戦略の最適化を進め、TiDBが高性能ワークロードの要求に引き続き応えられるようにします。
• 高スループットな分散実行サブシステムの構築：次世代DDL実行システムを開発し、分散環境全体でのスキーマ変更を効率的に処理できる高い線形スケーラビリティを実現することを最終目標とします。

長期的な目標として、完全分散型・並列化されたDDL実行フレームワークを開発し、以下を実現します：

• スキーマ変更の信頼性を高める最適化されたトランザクション処理
• ワークロードに応じて動的にリソースを割り当てるインテリジェントなリソーススケジューリング
• マルチテナント環境での急速な成長に対応する線形スケーラビリティ

参加のご案内

TiDBコミュニティ、データベース開発者、コミュニティメンバーの皆様には、DDL実行の未来を共に形作るためのご参加をお願いしています。皆様の知見、フィードバック、ご協力は、私たちのアプローチの改善と継続的なイノベーションの推進において非常に重要な役割を果たします。

TiDBのDDL機能の進化にぜひご参加ください。GitHubでの開発協力や、TiDB Cloudへのサインアップで今日から無料で利用開始、またはチームへのお問い合わせを通じて直接つながることも可能です。