TiDBにおけるPipelined DML：大規模トランザクション管理の革新

※このブログは2024年11月22日に公開された英語ブログ「Pipelined DML in TiDB: A Breakthrough for Managing Large Transactions」の拙訳です。

大規模トランザクションの管理は、分散型データベースにおいて常に難題でした。移行時の数百万件のレコード処理から、ETL (抽出、変換、ロード) のような複雑なワークフローへの取り組みに至るまで、企業は速さだけでなく、信頼性も兼ね備えたデータベースソリューションを必要としています。

TiDBは、分散SQLデータベースのイノベーションの最前線に長い間立ってきましたが、TiDB 8.1のPipelined DMLによって、再びその水準を引き上げようとしています。現在実験的な機能として提供されているこの新機能は、大規模トランザクションの処理方法を再定義し、シームレスでメモリ効率の高いアプローチを導入することで、これまで以上に簡単にスケールアップできるようになります。

このブログでは、Pipelined DMLを構築した理由、その仕組み、そして最新のデータ・ワークロードの管理にもたらす変革的なメリットについてご紹介します。

大規模トランザクションの課題と可能性

大規模なトランザクションは、多くの重要な業務のバックボーンとなっています。例えば、データの一括更新、システムの移行、数百万行の処理が必要なETLワークフローなどです。TiDBは分散SQLデータベースとして優れていますが、このようなトランザクションを大規模に扱うには2つの大きな課題がありました：

• メモリの制限：TiDB 8.1以前では、トランザクションのライフサイクルを通じて、トランザクションによる変更はすべてメモリ上に保持されていました。数百万行に及ぶトランザクションを処理する場合、メモリ使用量が多くなり、場合によっては利用可能なリソースがない場合にOOM (Out of Memory) エラーが発生する可能性がありました。
• パフォーマンスの低下：大規模なインメモリバッファの管理は、レッド・ブラックツリーに依存しており、計算オーバーヘッドが発生していていました。バッファが大きくなるにつれて、これらの構造に固有のO (NlogN) の複雑さにより、その操作が遅くなりました。

一般的な例：過去の売上データを別テーブルにアーカイブする方法

INSERT INTO sales_archive 
SELECT * FROM sales 
WHERE sale_date < '2023-01-01';

このようなシナリオでは、トランザクションがコミットされるまで数百万行のデータをメモリに保持することが、リソースに大きな負担をかけるだけでなく、速度にも悪影響を与えます。これらの課題は、スケーラビリティの向上、複雑さの軽減、そして信頼性の強化という明確な機会を浮き彫りにしました。最新のデータワークロードの増加に伴い、TiDBチームは大胆なソリューションを開発しました：Pipelined DMLは、大規模トランザクションの処理方法を変革するために設計されました。

既存の回避策：大規模トランザクションの解決に向けたステップ

Pipelined DMLが利用可能になる前に、TiDBは大規模トランザクションの問題を回避するために、いくつかの回避策を実装していました。これらの暫定的な解決策は、特定のシナリオでは有用でしたが、いくつかのトレードオフが伴いました：

1. Batch-DML (現在は非推奨)：TiDB v4.0で導入されたBatch-DMLは、トランザクションを分割して個々のコミットを行うことで、より大規模なデータ操作をサポートすることができました。しかし、TiDBがより堅牢なソリューションで進化したため、より高い信頼性を確保し、データの整合性を維持するためにBatch-DMLは非推奨となりました。現在は使用は推奨されません。
2. Non-Transactional DML：この機能はv6.1で初めて導入され、v6.5で一般公開となりました。TiDBはステートメントを複数に分割し、順次実行します。これはデータの整合性にとっては安全ですが、アトミック性に欠け、ユーザがSQLを修正する必要があるため、ユーザにとってさらなる複雑さを生む可能性があります。

これらの方法は、TiDBの柔軟性と、困難な状況下でもユーザーのニーズを重視する姿勢を示しています。しかし、アトミックでパフォーマンスが高く、使いやすい、よりシームレスなビルトインソリューションの必要性も強調されました。この気づきが、Pipelined DMLへの道を開いたのです。

Pipelined DML：大容量トランザクションの革命

TiDBチームは、増大する大規模データ操作の需要に対応するため、オリジナルのPercolatorプロトコルに変革をもたらす拡張機能であるPipelined DMLを開発しました。この機能は、コミットフェーズまでインメモリバッファのみに依存するのではなく、TiDBのストレージレイヤーであるTiKVへの継続的な書き込みを可能にすることで、ゲームに変化をもたらします。この変更により、効率的でスケーラブルかつ信頼性の高いトランザクション管理が実現します。Pipelined DMLが画期的である理由は以下の通りです：

1. 継続的な書き出し：メモリ管理の向上を実現するインクリメンタルライト

Pipelined DMLは、管理可能な小さなバッチでTiKVにデータを書き込み、メモリ使用量を大幅に削減します。これにより、大規模なトランザクションでもスムーズな処理を実現し、メモリ不足 (OOM) エラーのリスクを排除します。

例：膨大な売上データセットをTiDBのアーカイブテーブルに移行する場合を考えてみましょう。これまでは、コミットする前にデータセット全体をメモリに保存する必要があり、リソースが枯渇するリスクがありました。しかし、Pipelined DMLでは、処理に応じてデータをTiKVにインクリメンタルに書き込むため、メモリ使用量は安定し、ワークフローは中断されません。

2. 非同期バッファ管理：レイテンシー短縮のための並列処理

トランザクションの実行とストレージへの書き込みを切り離すことで、Pipelined DMLはTiDBがデータの処理と書き込みを同時に行うことを可能にします。この並列処理により、トランザクションの待ち時間が短縮され、リソースの利用率が最適化されます。

例：分析システムのために何百万ものログエントリをリアルタイムで処理することを想像してみてください。Pipelined DMLを使用すると、システムは新しいエントリを処理する間に、完了したログをストレージに書き込むことができるため、スループットが向上し、大量のワークロードをシームレスに処理できます。

3. CPUおよびI/O利用の平準化：一貫したリソース効率

従来のバッチ処理では、リソースの使用量が急増し、他の処理が遅くなることがよくありました。Pipelined DMLは、作業負荷を均等に分散し、TiKVが安定した速度でデータを処理することを保証します。

例：小売プラットフォームの製品の価格データを更新する作業は、リソースを多く消費することがあります。Pipelined DMLは、これらの更新が段階的に行われるようにし、突然のCPUやI/Oのボトルネックを回避し、システムの安定性を維持します。

これらの革新的な技術により、Pipelined DMLは、TiDBが最新のデータワークロードの需要に対応するための基盤となっています。これにより、企業は大規模なトランザクションを安心して管理することができ、スケーラブルで効率的、かつ信頼性の高いソリューションを提供することができます。

図1：従来の2PCプロセスは、コミットフェーズまですべての書き込みをメモリに保持します。(左) 一方で、 Pipelined DMLは、生成された書き込みをTiKVに段階的に書き出し、メモリ使用量を最小限に抑えます (右)。

Pipelined DMLの仕組み：大規模トランザクションを管理するためのステップバイステップ

Pipelined DMLはTiDBのアーキテクチャにシームレスに統合され、既存のワークフローを中断することなくトランザクション処理を強化します。トランザクションライフサイクルの各フェーズをどのように最適化するのかを説明します：

1. 実行フェーズ：効率的なトランザクションの開始

従来の2段階コミット (2PC) と同様に、トランザクションはSQL文の解析、計画、実行から始まります。しかし、Pipelined DMLでは、すべての書き込みをメモリに保持する代わりに、生成された書き込みを即座にTiKVに書き出すという重要な違いがあります。このアプローチにより、数百万行を含むトランザクションであっても、使用されるメモリの蓄積を防ぎ、効率的な処理を維持することができます。

2. 書き出しメカニズム：安定性のためのインクリメンタル書き込み

TiKVへの書き込みは、管理しやすい小さなバッチで送信されます。このメカニズムには2つの重要な機能があります：

• 永続性：TiKVに書き込みを段階的に保存することで、Pipelined DMLはメモリ使用量を大幅に削減し、大規模トランザクションの安定運用を保証します。
• レートリミット：TiDBのエクゼキュータがTiKVの処理能力を超える速度の書き込みを生成した場合、システムは動的にプロデューサの処理速度を低下させます。これにより、メモリの過負荷や処理のボトルネックを回避し、スムーズな運用を実現します。

3. コミットフェーズ：整合性を保つ信頼性の高い最終処理

TiDBは、すべての書き込みを終了した後、コミットフェーズに移行します。この段階では、書き出しされたデータに関連するロックをスキャンしてコミットし、トランザクションの一貫性を確保します。このアプローチは、非常に複雑で大規模なワークロードであっても、TiDBのACID保証を維持します。

メモリバッファの強化：継続的な書き出しのサポート

Pipelined DMLを実現するために、TiDBのインメモリデータベース (MemDB) は、継続的な書き出しをサポートするようにアップグレードされました。

この強化されたアーキテクチャは、以下の7つの原則で構成されています：

1. 2つのMemDBステート：各トランザクションは1つの変更可能なMemDBと、最大1つの変更不可なMemDBを使用します。
2. 書き込み：すべての書き込み操作は、変更可能なMemDBに向けられます。
3. 読み取り：読み込み操作は、すべてのアクティブなMemDBからデータを集約し、正確な結果を得ます。
4. 書き出し：変更不可なMemDBは、書き出し操作を専任で担当します。
5. トランジション：変更不可なMemDBが存在しない場合、変更可能なMemDBが変更不可に変わり、新しい変更可能なMemDBが作成されます。
6. メモリの解放：書き出しが完了すると、変更不可なMemDBは破棄されます。
7. フロー制御：変更可能なMemDBが大きくなりすぎて安定性を維持できなくなると、書き込みは一時停止されます。

これらの機能強化により、TiDBはメモリ使用量を抑制しながら、同時並行の読み取り、書き込み、ディスクへの書き出し操作を効率的に管理できるようになりました。

図2：オリジナルのメモリ・バッファを置き換えるために設計された、継続的な書き出しをサポートする、最新のバッファ構造。

Pipelined DMLにおける課題の克服

Pipelined DMLのような革新的な機能を導入するには、独自の技術的ハードルに取り組む必要があります。TiDBチームは、シームレスで信頼性の高い運用を実現するために、3つの主要な課題を特定し、解決しました。

課題１：順不同の書き出し操作

分散システムでは、ネットワークの不安定性が原因で書き出された操作が失われたり、遅延したり、順番が乱れたりすることがあり、データの整合性にリスクをもたらします。

TiDBの解決策：生成番号

各書き出し操作には重複しない順番がつけられた番号が割り当てられ、次のことが保証されます：

• 正しい順序：TiKVは生成番号に基づいて書き込みを順番に処理します。
• 古い書き込みの防止：遅延した操作が新しい操作の後に到着した場合、TiKVはそれを拒否し、データの整合性を保ちます。
  
  例：書き出し操作1 (世代1) とフラッシュ操作2 (世代2) が正しく送信されても、順番が逆に到着することがあります。TiKVは世代2を処理し、古い世代1を破棄することで、データの整合性を確保します。

課題２：遅いポイントリード操作

要求されたキーと値のペアがすでにTiKVに書き出され、TiDBのメモリ上にない場合、それを取り出すにはTiKVへのリモートプロシージャコール (RPC) が必要となり、レイテンシーが増大します。

TiDBの解決策は？

1. 遅延チェック：キーの存在しないことを確認する必要がある場合、チェックは実際の書き込み時にTiKVで行われるように遅延されます。新しい buffer.GetLocal(key) メソッドは、メモリ内のデータのみを検索対象とし、不必要なRPCを避けます。
2. プリフェッチ (Prefetching)：一括更新のようなシナリオでは、TiDBは BatchGet を使用してキーと値のペアをキャッシュにプリロードします。このキャッシュにより、後続の buffer.Get(key) 操作はメモリ内キャッシュにアクセスするようになり、高コストなRPCを実行する必要がなくなります。

課題3：ノード間のステージング

TiDBのステージングメカニズムでは、一時的なバッファ (ステージ) を使用して、コミットまたはロールバックされた変更を保持します。これはメモリのみのセットアップでは単純ですが、TiDBとTiKVのノード間で拡張すると複雑さが増します。

TiDBはどのようにステージングを簡素化するのか？

ステージング操作を書き出す時点の間でのみ行うよう制限することで、システムは次のことを保証します：

• ステージングされたすべての変更は、TiKVがデータを書き出す前に解決 (コミットまたはロールバック) されます。
• メモリのみのステージングが保持され、実装が簡素化されるとともに、ON DUPLICATE KEY UPDATE などの重要な機能も維持されます。

パフォーマンス強化：TiDBが大規模トランザクションで新たな高みへ

Pipelined DMLにより、TiDBは大規模トランザクション処理の新たな標準を打ち立て、速度、メモリ効率、スループットを大幅に改善しました。TiDB 8.4とTiDB 7.5を比較した広範なベンチマークテストは、実際の運用シナリオでのこれらの進化を際立たせています。

テスト環境のハイライト

すべてのベンチマークは以下のパラメータに基づいて実施されました：

• ワークロード：YCSBテーブル (1,000万行)
• テスト環境：GCP n2-standard-16マシン
• クラスタサイズ：3 TiKVノード

結果は、TiDBによるスケーリング操作のためのPipelined DMLの実用的な適用を実証しています。

主な改善点

クラスタサイズ	ワークロードタイプ	レイテンシー (TiDB 7.5)	レイテンシー (TiDB 8.4 Pipelined DMLを使用時)	データスループット	パフォーマンス向上
3 TiKVノード	YCSBインサート (10M行)	368秒	159秒	75.3 MiB/秒	2.31倍
3 TiKVノード	YCSBアップデート (10M行)	255秒	131秒	91.5 MiB/秒	1.95倍
3 TiKVノード	YCSBデリート (10M行)	136秒	42秒	285 MiB/秒	3.24倍

これらの向上が実際のシナリオにどのように活かされるか

• インサート操作：売上レコードや顧客プロファイルのTiDBへのインポートなど、新しいデータセットのロードに最適です。継続的な書き出しにより、迅速でリソース効率の高いパフォーマンスを実現します。
• アップデート操作：大量の更新を処理する際に便利です。例えば、大規模な在庫データの価格更新などで、これらのアップデートはより高速で、メモリ消費も少なくなっています。
• デリート操作：古い記録のアーカイブや削除に最適です。例えば、ログのクリーンアップなどにおいて、TiDBの新しい機能が素晴らしい速度と効率を発揮します。

安定性向上のためのリソース利用の最適化

Pipelined DMLの際立った利点の1つは、CPUとI/Oの利用率が安定することです。従来の2フェーズコミット (2PC) では、コミットフェーズでリソースのピークが発生することが多いのに対し、Pipelined DMLは処理全体を通して安定したパフォーマンスを維持します。この安定性により、特にピーク時の負荷が高い場合でもシステムの信頼性が向上します。

レイテンシーとスケーラビリティ：大規模トランザクション処理に迫る

大規模なトランザクションを最小限の遅延で処理するために、Pipelined DMLはプロデューサ・コンシューマモデルを採用し、TiDBとTiKV間で効率的にデータが流れることを確保します。

• プロデューサー：TiDBの実行エンジンがTiKVのためにデータを生成します。
• コンシューマー：TiKVが受信した書き込みリクエストを処理します。
• チャネル：書き出し操作が仲介となり、プロデューサとコンシューマ間の円滑な通信を維持します。

一貫したパフォーマンスのためのレイテンシーの管理

需要の高いシナリオでは、プロデューサ (TiDBエクゼキュータ) がコンシューマ (TiKV) の処理能力を超える速さでデータを生成することがあります。システムが過負荷にならないように、Pipelined DMLはプロデューサを一時的に停止させ、安定性を保ち、メモリのスパイクを防ぎます。このプロセスは「フラッシュウェイト」と呼ばれ、全体のレイテンシーに影響を与える3つの要因のうちの1つです。

レイテンシーの公式：

全体のレイテンシー = 実行時間 + フラッシュウェイト + プライマリキーのコミット時間

それぞれの要素がどのように寄与するかは以下の通りです：

• 実行時間：TiDBがトランザクションのためにデータを生成する時間。
• フラッシュウェイト：プロデューサがコンシューマに追いつくために一時的に停止することによる遅延。
• プライマリキーのコミット時間：トランザクションが準備できた後、プライマリキーをコミットするために必要な時間。この時間は大規模なトランザクションではほとんど無視できるほど短いです。

シンプルなスケーラビリティ

TiKVノードを直接スケールアウトすることで、フラッシュウェイトの時間が短縮され、システムはより大きな負荷を効率的に処理できるようになります。ベンチマークでは、クラスタにTiKVノードを追加することでレイテンシーが大幅に削減され、TiDBがいかに容易に需要の増加に適応できるかが示されています。

使用例

例えば、あるeコマースプラットフォームが大規模なセールイベントに備えており、注文の一括更新や在庫調整など、トランザクションの急増を予測しているとします。事前にTiKVノードのスケーリングを行うことで、プラットフォームはレイテンシーを増加させることなく、これらのオペレーションをシームレスに処理することができます。

結論：TiDBで大規模トランザクションを解き放つ

Pipelined DMLは、TiDBが大規模トランザクション管理の再定義に向けて進む中で、革新的な一歩を踏み出したことを意味します。メモリ制約やトランザクションのレイテンシーといった長年の課題に取り組むことで、この機能は組織が膨大なデータセットを自信を持って効率的に処理できるようにします。

実行時間の短縮、メモリ使用量の劇的な削減、そして比類のないスケーラビリティを実現することで、TiDBは、企業が最新のデータ・ワークロードの要求を満たすことを保証します。インフラストラクチャの拡張、ETLパイプラインの合理化、トラフィック量の多いオペレーションの最適化など、Pipelined DMLはTiDBをデータ管理の未来に向けた先進的で信頼性の高いソリューションとして位置づけます。

Pipelined DMLについて質問があれば、ぜひ X (旧Twitter)、LinkedIn、またはSlackチャンネルでお気軽にご連絡ください。