50倍のパフォーマンス向上を実現：TiDB DDLフレームワークの最適化に関する詳細分析

従来のデータベースでスキーマの変更を管理すると、ダウンタイムやブロック、運用の複雑さにつながることがよくあります。TiDBは、オンラインDDL機能によってこのプロセスを簡素化し、開発者がアプリケーションを中断することなくデータベースを進化させることを可能にしてきました。

ユーザーベースとデータ量の増加に伴い、インデックス作成がパフォーマンスのボトルネックになりつつありました。これに対処するために、まずインデックス作成において10倍の速度向上を達成しました。その後、インデックス作成を分散フレームワークに移行することで、大規模テーブルのインデックス作成の効率をさらに向上させました。

現在、SaaSアプリケーションの普及と、単一のTiDBクラスタ内で数百万のテーブルを管理するという課題に直面し、TiDBのDDLフレームワークはさらに大きな要求に応える必要があります。そこで我々は、スケーラビリティとDDL実行効率を最優先事項とし、TiDBが高い処理能力で大規模な操作を実行できるようにする一方で、高い並行性と負荷の下でも揺るぎない安定性を維持できるようにしています。このブログで紹介する以下の結果は、これらのこれらの重要な進歩を浮き彫りにしています。

TiDB 8.2：平均DDL QPSが5倍向上

広範なパフォーマンステストの結果、 TiDB 8.2 DDL は TiDB 8.1と比較して平均QPSが5倍向上し、7から38 (ピーク時80) になり、DDLの最適化に成功したことが実証されました。

TiDB 8.3：平均DDL QPSがさらに4倍向上

TiDB 8.3 のDDLパフォーマンスにおいても、顕著な改善が見られました。このリリースではTiDB 8.2の5倍近い、平均約180、ピーク約200のQPSを達成し、DDLの最適化と安定性の向上がを実証しました。

TiDB 8.5：テーブル作成時間が50倍高速化

TiDB 8.5 では、特に多数のデータベースに対するDDLパフォーマンスが大幅に向上しました。テーブル作成を高速にする最適化を有効にすると、DDLのQPSと全体のスループットが2倍になります。100万テーブルテストでは、TiDB 8.5はTiDB 7.5よりも50倍高速にテーブルを作成しています。以下のクラスタでテストしたところ、下記の結果が得られました：

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

注：テスト中の統計情報のメモリ要件により、16コア32GBのTiDBノードが使用されています。現在、統計情報のメモリ使用量を削減する取り組みが積極的に行われています。テーブル数は利用するTiDBノードの性能に基づいて調整してください。

TiDB DDL：基本原則の概要

最適化戦略を検討する前に、TiDBがどのようにDDLを実行を理解することが重要です。オンラインDDL機能を持つ分散SQLデータベースであるTiDBは、トランザクションを中断することなくスキーマの変更を可能にします。このセクションでは、SQLの解析、ジョブの作成からバックグラウンドでの実行まで、オンラインDDLプロセスの概要を説明し、最適化について議論するための準備を整えます。

DDLステートメントタスク実行プロセス

図1. TiDB DDLの実行フローを示す図

TiDBは、CREATE TABLEステートメントを処理する際に、SQLの解析、DDLタスクの作成、ジョブワーカーによるスケジューリングと実行 (再編成タスクの場合は並列の可能性あり)、進行状況の追跡、結果の返却という手順を踏みます。

オンライン・スキーマ変更の紹介

図2. TiDBにおけるオンラインスキーマ変更の仕組みを表した図

ジョブワーカーはTiDBのonline schema changesを実行し、シングルステップのスキーマ変更を適用します。また、Placement Driver(PD) に通知を行い、PDは全TiDBノード間での更新を調整します (etcdを使用)。この際、ノードはメタデータロック (MDL) を取得する必要があります。最後に、ジョブワーカーは全てのノードが同期することを確認し次のステップに進む前に、一貫した状態を保ち進行中のトランザクションへの中断を防ぎます。

エンジニアリングのベストプラクティスの探究

図3. TiDB DDLのマイルストーン

TiDBのDDL最適化ロードマップは、お客様のニーズ、反復的なアプローチ、最小限の影響という原則に基づき、複雑なタスクを独立した提供可能なサブタスクに分割し、継続的な改善とターゲットとするソリューションの迅速な提供を可能にします。

最適化アプローチ

大規模なテーブル作成のボトルネックに直面したTiDBは、戦略的にDDLオペレーションの最適化を行いました。主に｢迅速なテーブル作成｣に焦点を当て、ターゲットを絞った改善、継続的な反復 (百万テーブルの作成時間を4時間以上から1.5〜2時間に短縮)、コードのリファクタリング、そして今後の分散DDLフレームワークによるパフォーマンス向上を進めました。

以下の表は、TiDB 8.1で達成された最適化を示しています。

TiDBの最適化の歩み：詳細な検討

TiDB 8.1でのテーブル作成の改善に続き、TiDB 8.2以降のバージョンは、大規模デプロイメント向けの一般的なDDL実行の最適化に注力し、スループット、安定性、効率の向上を目指しました。

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

TiDBのDDL実行、特に数百万のテーブルを持つ大規模なマルチテナント環境での実行を分析した結果、迅速な反復処理に起因するパフォーマンスのボトルネックと、よりスケーラブルなモデルの必要性が明らかになりました。主なボトルネックは以下の通りです：

1. 非効率的なDDLタスクのスケジューリング：DDLタスクが順次処理され、不要なスケジューリングオーバーヘッドが発生していました。
2. データベース/テーブル存在チェックに時間がかかる：スキーマ検証を、より低速なフォールバックメカニズムに依存することがありました。
3. コンピュータリソースの活用不足：TiDBノードが並行実行に十分活用されていませんでした。
4. 非効率的なブロードキャストメカニズム：スキーマ変更がノード間で非効率的に伝搬され、遅延を引き起こしていました。

これらの領域に対する体系的な改善により、TiDBのDDL実行は非常に効率的な分散型プロセスに生まれ変わりました。

最適化の概要

TiDBの初期のスケジューリング戦略では、各DDLステートメントに対して細かいステートマシンのステップを処理していたため、スケジューリングのオーバーヘッドが発生していました。これを解決するために、いくつかの重要な最適化が実装されました：

1. スケジューリングの粒度の調整：個々のステップではなく、DDLタスク全体を単一のユニットとして扱うようになり、オーバーヘッドが大幅に削減され、効率が向上しました。
2. 同時実行性の向上：独立したDDLタスクが並列で実行されるようになり、リソースの活用が最大化され、全体の実行時間が短縮されました。
3. 実行リソースの拡張：一般的なDDLタスク専用のワーカープールが拡張され、複数のタスクの同時実行が可能になり、スループットが劇的に向上しました。
4. スケジューリングロジックの簡素化：最適化されたアルゴリズムにより、スケジューリングプロセスが合理化され、さらに効率が向上しました。

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

効率的なテーブル存在チェックは、TiDBのDDLパフォーマンスにおいて極めて重要です。以前、TiDBはインメモリのスキーマキャッシュを使用し、TiKVへのフォールバックを行っていましたが、多くの処理が同時に行われる状況では遅延が発生していました。これを最適化するために、TiKVへのフォールバックを終了させ、スキーマキャッシュのみに依存するようにしました。これには、DDLオーナーノードでの信頼性の高いスキーマキャッシュ同期、並行テーブル作成を防止するための事前計算されたジョブ依存関係、正しいスキーマ更新を保証するための順次ジョブ実行、そしてノードがDDLオーナーになる際のスキーマの再読み込みが裏付けとなっています。

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)
}

TiKVルックアップを削除することで、特に大規模なデプロイメントにおいて、実行速度と効率が大幅に改善されました。この最適化により、DDLのスケーラビリティが向上し、整合性と正確性が維持されます。将来的な機能強化としては、テーブル/スキーマ名のインデックス作成とスキーマキャッシュのフォールトトレランス機構が含まれます。

コンピューティングリソースの有効活用

TiDBのスキーマ同期メカニズムは、当初、システムが一定の間隔でスキーマの更新を繰り返しチェックする定期的なポーリングに依存していました。このアプローチには非効率であり、スキーマの頻繁な変更やスキーマの読み込みが遅い場合、無駄な無効チェックが繰り返され、システムの処理速度が低下していました。

これを解決するために、私たちはETCDの監視メカニズムを採用しました。定期的なポーリングの代わりに、TiDBはETCDのリアルタイムの変更を監視するようになり、スキーマバージョンが変更されると、ETCDがTiDBに即座に通知し、オンデマンドで同期を可能にします。この改善により以下が実現しました：

• 不要なポーリングを排除し、システムのオーバーヘッドを削減します。
• レスポンスタイムが改善され、スキーマ変更の伝播が速くなります。
• コンピュータリソースの効率が向上し、TiDBの計算能力をチェックの繰り返しではなく実行に集中させることができます。

DDL完了通知のブロードキャストメカニズムの置き換え

TiDBのDDL完了通知メカニズムの最適化には、非効率なブロードキャスト通知を一方向の通知に置き換える必要がありました。これにより、DDL完了イベントを処理するのは担当スレッドだけとなり、冗長な処理が防止され、完了が速くなり、大量のスキーマ変更に対するスループットが向上します。

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

TiDBのDDLフレームワークが柔軟かつ効率的であり続けるため、包括的なリファクタリングが実施されました。従来のフレームワークは、技術的負債を抱え、設計の老朽化、コードの保守性の低さ、テストの不十分さ、イテレーションの遅さに悩まされていました。

今回のリファクタリングでは、モジュール化と疎結合を通じてコード品質を向上させ、テストカバレッジを強化し、スケーラビリティとフォールトトレランスを向上させるためにアーキテクチャを最適化に重点を置きました。検証済みの小さな変更、継続的インテグレーション、コードレビューを取り入れた段階的なアプローチにより、リスクを最小限に抑えました。

リファクタリングされたフレームワークは、より高い安定性、開発効率の向上、スケーラビリティの改善を実現しました。これにより、スケジューリング、並行処理、スキーマ検証の以前の最適化と相まって、TiDBのDDLパフォーマンスを大幅に向上させ、進化する需要と将来の成長に対応する能力を確保しました。

TiDBのDDL実行の継続的な改善により、次世代の分散スキーマ管理の基礎を築いています。

結論

TiDB DDLフレームワークのリファクタリングは複雑な作業でした。しかし、その結果、大きな利益を得ることができました。安定性、効率性、スケーラビリティが改善されたことで、将来の成長に向けた強固な基盤ができました。

TiDBのDDL実行機能についてご質問がありましたら、X(旧Twitter)、LinkedIn、またはSlack Channelでお気軽にご連絡ください。