TiDBはどのようにしてオンラインDDLのパフォーマンスを10倍向上させたのか

※このブログは2023年3月9日に公開された英語ブログ「How TiDB Achieves 10x Performance Gains in Online DDL」の拙訳です。

データベース管理では、アプリケーション、クエリワークロード、およびデータ形式の変更により、テーブルスキーマの変更が頻繁に行われます。これらの変更は完了するまでに数時間から数日かかる場合があり、システムリソースを占有し、アプリケーションのスループットを低下させる可能性があります。テーブルが大きくなると、データ定義言語 (DDL) 操作による変更にかかる時間が長くなります。これはアプリケーションに潜在的なリスクをもたらし、ビジネスの成長に深刻な影響を与える可能性があります。

この投稿では、TiDBの高速オンラインDDLがオンラインインデックス作成のパフォーマンスを10倍向上させる方法を共有します。また、Amazon AuroraおよびCockroachDBとのTiDBのDDLパフォーマンスの比較も提供します。

Fast Online DDLはTiDBでどのように機能するのか？

顧客はスループットに影響を与えない、高速なオンラインDDL操作を望んでいます。TiDB 2.1は分散SQLデータベースとして、GoogleのF1論文に基づいたオンライン非同期スキーマ変更アルゴリズムを導入しました。この実装により、読み取り/書き込み操作をブロックすることなく、オンラインでテーブルスキーマを変更できます。これにより、外部スキーマ変更ツールやソースとレプリカ間の切り替えが完全に不要になります。この基盤を発展させて、TiDB 6.5長期サポート (LTS) リリースではFast Online DDLが導入されました。

TiDB独自のオンラインDDLアプローチを分析した結果、プロセスの最も遅い部分はインデックスデータ作成のためのテーブル全体のスキャンプロセスであることがわかりました。インデックス作成における大きなボトルネックは、トランザクション結果に基づいてインデックスを一括埋めする方法でした。そこで、インデックス作成モード、データ送信、並行インポートの3つの側面でプロセスを改善することで、このパフォーマンスの問題を解決することにしました。

インデックス作成モードの変換

変更の背後にある理論的根拠を理解するために、次の比較図を見てみましょう。

図1. Fast Online DDLの前と後でのインデックス作成モード

左側の図はオンラインDDL中のインデックス作成のTiDB独自のアプローチを示しています。元のアプローチでは、テーブルデータ全体をスキャンしてキーと値 (KV) ペアとして表されるインデックスレコードを構築します。これらのKVペアは、tidb_ddl_reorg_batch_sizeで設定されたバッチサイズを使用してトランザクションでTiKVにコミットされます。ただし、このアプローチでは次の2種類のオーバーヘッドが発生し、パフォーマンスに悪影響を及ぼします。

• インデックスレコードの2フェーズコミット (2PC) プロセスによってもたらされる時間のオーバーヘッド。通常、各インデックストランザクションのデータバッチサイズは256行以下であるため、多数のインデックスレコードをTiKVにコミットするための合計トランザクション時間が膨大になる可能性があります。
• インデックストランザクションとユーザートランザクション間の競合によるロールバックと再試行によって発生する時間のオーバーヘッド。トランザクションでコミットされたインデックスレコードがユーザートランザクションによって更新されたインデックスレコードと競合すると、ユーザートランザクションまたはインデックスバックフィルトランザクションのロールバックと再試行がトリガーされます。これは最終的にパフォーマンスに影響します。

これらの問題に対処するために、上の図の右側に示すようにファイルベースのバッチインポートモードを採用することで、元のアプローチのトランザクションバッチ書き込みモードを改善しました。私たちは依然としてテーブルデータ全体をスキャンすることから始め、次にスキャンされたデータに基づいてインデックスKVペアを構築し、それらをTiDBのローカルストレージに保存します。インデックスKVペアがTiDBでソートされると、取り込みモードを使用してTiKVに書き戻されます。この新しい方法により、上記2種類のオーバーヘッドが排除され、パフォーマンスが大幅に向上します。

データ送信の最適化

インデックス作成の元のアプローチでは、TiDBはテーブルスキャン中にデータの行全体を返します。次に、インデックスのKVペアを構築するためにインデックスに必要な列を選択します。新しいアプローチでは、データがTiKVからTiDBに返される前に、インデックスに必要な列が抽出されます。これにより、全体のデータ転送量とインデックス作成時間が大幅に削減されます。

インデックスの取り込みの並列化

最後に、インデックスレコードがTiKVに並列して取り込まれ、TiKVへのデータの書き込み効率が向上します。ただし、TiKVのオンライン処理負荷は増加します。現在、通常のワークロードを処理する負荷に負担を与えることなく、TiKVのアイドル帯域幅を最大限に活用するための一連のフロー制御手段を開発中です。

DDLベンチマーク：TiDB vs 一般的なデータベース

私たちの作業を検証するために、Sysbench を使用してベンチマークテストを実施し、インデックス作成の最も一般的なシナリオにおけるDDL実行の効率を比較しました。TiDB 6.1.0、Aurora 3.02.2、CockroachDB 22.2、TiDB 6.5.0をクラウド上のおおよそのコストで比較しました。このベンチマークはデータ量が異なるテーブルの特定のINTフィールドにセカンダリインデックスを作成するときのパフォーマンスの向上率を測定します。テスト構成は次のとおりです。

データベース	バージョン	クラスター構成	コスト ($/時間)
TiDB	6.1.0/6.5.0	TiDB: (16c core + 32 GB) * 2 TiKV: (16c core + 64 GB + 1 TB) * 9	21.32
Aurora	3.02.2	db.r5.8xlarge * 2	21.00
CockroachDB	22.2	(16c core + 60 GB + 1 TB) * 6	21.17

• ワークロードがアイドル状態の時にオンラインインデックス作成をベンチマークすると、TiDB 6.5.0は前世代のTiDB 6.1.0よりも10倍高速なパフォーマンスを示しました。また、CockroachDB 22.2よりも2〜 3倍、Aurora 3.02.2よりも約2.7倍高速です。

図2.アイドル状態のワークロードでのFast Online DDLの処理倍率

• 10K QPSのsysbench OLTP_READ_WRITEシナリオ中にオンラインインデックス作成をベンチマークすると、TiDB 6.5.0はTiDB 6.1.0の8～13倍、CockroachDB 22.2を約3倍上回りました。ただし、プライマリインスタンスでDDLステートメントを実行すると、関連付けられたAuroraレプリカでのデータベース接続が中断される可能性があるため、Auroraでは同じテストを実行しませんでした。加えてAuroraユーザーはgh-ost、pt-osc、osc などのツールを使用してスキーマ変更をするほうが好みでしょう。

図3. 高負荷なワークロード時のFast Online DDLの処理倍率

• 次のグラフはポート、様々な並列度の設定下でFast Online DDLによってパフォーマンスがどのように変化するかを示しています。( tidb_ddl_reorg_worker_cnt パラメーターをそれぞれ1、2、4、8、および16に設定しています)

図4. TiDB6.5.0とTiDB 6.1.0でのFast Online DDLの処理倍率

結論

新しいバッチインポートモード、最適化されたデータ転送、および並行インポートの組み合わせにより、TiDB 6.5のFast Online DDL機能はオンラインDDL操作を大幅に高速化し、効率を高めました。

TiDB 6.5 LTSを開始してFast Online DDLを体験したり、当社の技術専門家にデモをリクエストしたりできます。さらに、SlackのコミュニティやTiDBフォーラムに参加して意見やフィードバックを共有してください。