DBMSにおける同時実行制御：ロック、MVCC、オプティミスティック戦略によるデータ整合性の維持

同時実行制御とは、データ破損なしに同時トランザクションを管理するためにデータベース管理システム (DBMS) が使用するメカニズムのセットです。複数のユーザーまたはプロセスが同時に読み書きする場合、制御されないアクセスは、更新の消失、ダーティリード、および下流システムに連鎖する可能性のある一貫性のない結果などのデータ異常につながります。

同時実行制御は、ACID の「I」（アイソレーション）を強制します。つまり、同時トランザクションは、それらが順番に実行された場合と同じ結果を生成する必要があります。これはシリアライザビリティとして知られるプロパティです。これがないと、銀行アプリケーションは送金を失ったり、在庫システムは製品を売りすぎたり、分析パイプラインは不完全なデータに基づいてレポートを生成したりする可能性があります。

このガイドでは、コアとなる同時実行の問題、それらを解決するための主要なメカニズム（ロッキング、マルチバージョン同時実行制御 (MVCC)、楽観的および悲観的戦略）、アイソレーションレベル、デッドロック処理、およびワークロードに最適なアプローチを選択するための実践的なガイダンスについて説明します。

同時実行制御が重要な理由

最新のデータベースシステムは、通常、1秒あたり数千から数百万の同時トランザクションを処理します。ユーザーがクエリを送信したり、レコードを更新したり、ETL パイプラインを開始したりするたびに、DBMS はその操作を、その瞬間に発生している他のすべての操作と調整する必要があります。同時実行制御がないと、インターリーブされたトランザクションは予測不可能で不正確な結果を生み出します。

具体的なシナリオを考えてみましょう。2人のユーザーが同じ銀行口座残高を同時に更新します。ユーザーAは残高（1,000ドル）を読み取り、200ドルを差し引き、800ドルを書き込みます。ユーザーBも1,000ドルを読み取り、500ドルを追加し、1,500ドルを書き込みます。正しい結果は順序に依存しますが（800ドルまたは1,500ドル）、調整がないと、一方の書き込みがもう一方を単純に上書きします。これは古典的な更新の消失であり、同時実行制御が存在する理由の1つです。

同時実行制御はシリアライザビリティを強制します。つまり、同時実行の結果は、それらのトランザクションのいずれかのシリアル順序と一致する必要があります。これは、ACID の4つの保証（アトミック性（すべてか無か）、一貫性（有効な状態遷移）、アイソレーション（干渉なし）、永続性（コミットされた変更は永続的））すべてを直接サポートします。これにより、すべてのアプリケーションがデータへの信頼を築く基盤が保証されます。

解決すべき同時実行の問題

解決策を検討する前に、適切な制御なしに同時トランザクションが実行されるときに発生する特定のエラーを理解することが役立ちます。

• ダーティリード。 トランザクションが、コミットされていない別のトランザクションによって書き込まれたデータを読み取ります。その2番目のトランザクションがロールバックされた場合、最初のトランザクションは実際には存在しなかったデータに基づいてロジックを構築しました。ダーティリードは、意思決定にファントム状態を導入するため、最も危険なエラーの1つです。
• 更新の消失。 2つのトランザクションが同じデータ項目を読み取り、その後両方とも更新された値を書き込みます。2番目の書き込みは、最初の書き込みの変更を組み込むことなく上書きし、有効な更新を効果的に消去します。上記の銀行口座のシナリオは典型的な例です。
• 再現不可能な読み取り。 トランザクションが同じ行を2回読み取り、別のトランザクションが読み取りの間にその行を変更してコミットしたため、異なる値を取得します。これは、単一のトランザクション内で安定したデータに依存するロジックを破ります。
• ファントムリード。 トランザクションが範囲クエリを再実行し、別のトランザクションがその間隔で行を挿入または削除したため、異なる行セットを取得します。ファントムは、集計クエリとレポート作成ワークロードにとって特に問題となります。

これら4つのエラーは、すべての同時実行制御メカニズムの「理由」です。各メカニズムは、強制するアイソレーションレベルに応じて、それらのいくつかを防止します。

ロックベースの同時実行制御

ロッキングは、同時実行制御の最も古く、最も直感的なアプローチです。DBMS は、トランザクションがデータ項目（行、ページ、またはテーブル全体）にアクセスできるようにする前に、それらにロックを割り当てます。ロックはゲートキーパーとして機能します。別のトランザクションが既に競合するロックを保持している場合、要求するトランザクションは待機する必要があります。

共有ロックと排他ロック

• 共有（読み取り）ロック は、複数のトランザクションが同時に同じデータを読み取ることを許可します。誰もデータを変更していないため、同時読み取りは安全です。
• 排他（書き込み）ロック は、単一のトランザクションにデータ項目への排他的アクセスを許可します。排他ロックが保持されている間、他のトランザクションはその項目を読み取ったり書き込んだりすることはできません。これは更新の消失やダーティリードを防ぎますが、同時実行性も制限します。

ロックの粒度は重要なトレードオフをもたらします。行レベルロックは、無関係な行がアクセス可能であるため、同時実行性を最大化しますが、システムは多数の個々のロックを追跡する必要があるため、オーバーヘッドが増加します。テーブルレベルロックは管理が簡単で安価ですが、無関係なトランザクションを待機させるため、スループットが低下します。

ツーフェーズロック (2PL)

ツーフェーズロックは、ロックを通じてシリアライザビリティを保証するための標準プロトコルです。各トランザクションを2つのフェーズに分割します。グローイングフェーズ中に、トランザクションは必要なすべてのロックを取得しますが、決して解放しません。最初のロックを解放すると、シュリンキングフェーズに入り、新しいロックを取得することはできず、ロックを解放することしかできません。このルールにより、トランザクションがデータ項目をロックする順序が一貫していることが保証され、それによってシリアル可能なスケジュールが保証されます。

Strict 2PL は、トランザクションがコミットされるまですべてのロックを保持する一般的なバリアントです。これにより、カスケードロールバック（1つのアボートされたトランザクションが、そのコミットされていないデータを読み取った他のトランザクションをアボートさせる状況）を防ぐことができます。ロックベースの同時実行制御を使用するほとんどのリレーショナルデータベースは、Strict 2PL の一種を実装しています。

2PL の欠点は、ブロッキング（トランザクションは他のトランザクションが保持するロックを待機する必要がある）を引き起こし、デッドロックの条件を作り出すことです。

マルチバージョン同時実行制御 (MVCC)

MVCC は根本的に異なるアプローチを採用しています。アクセスをブロックするのではなく、各データ項目の複数のバージョンを維持することで、各トランザクションがデータベースの一貫したスナップショットを表示できるようにします。トランザクションが行を書き込むとき、MVCC は既存のバージョンを上書きするのではなく、新しいバージョンを作成します。リーダーは、トランザクションが開始されたときに現在のバージョンを引き続き表示します。

主な利点は、リーダーがライターをブロックせず、ライターがリーダーをブロックしないことです。これは読み取り負荷の高いワークロードにとって大きなパフォーマンス上の利点であり、MVCC が最新のデータベースで主流の同時実行制御メカニズムである理由です。PostgreSQL、MySQL/InnoDB、Oracle、およびほとんどの現代のOLTP およびOLAP システムは、MVCC の一種を使用しています。

書き込み競合はコミット時に検出されます。2つのトランザクションが同じ行を変更した場合、最初にコミットした方が勝ち、2番目のトランザクションは再試行する必要があります。書き込み競合解決に対するこの楽観的なアプローチは、競合がまれである場合にスループットを高く保ちます。通常、競合はまれです。

スナップショットアイソレーション は、最も一般的な MVCC ベースのアイソレーションレベルです。各トランザクションは、トランザクションが開始されたときのデータベースを表示し、ダーティリードや再現不可能な読み取りを防ぎます。ただし、スナップショットアイソレーションでは、書き込みスキュー と呼ばれる微妙なエラーが発生する可能性があります。これは、2つのトランザクションがそれぞれ重複するデータを読み取り、読み取ったデータに基づいて書き込みを行い、その結果、どちらのトランザクションも単独では生成しなかった状態になることです。シリアル可能スナップショットアイソレーション (SSI) は、追加のオーバーヘッドを犠牲にしてこのギャップを埋めます。

MVCC は独自のトレードオフをもたらします。複数のバージョンを維持すると追加のストレージが消費され、システムは不要になったバージョンを定期的にガベージコレクションする必要があります。これは PostgreSQL では VACUUM と呼ばれるプロセスです。書き込み競合が激しい場合、再試行コストとバージョン管理のオーバーヘッドが大きくなる可能性があります。

楽観的 vs. 悲観的同時実行制御

ロッキングや MVCC の具体的なメカニズムを超えて、同時実行制御戦略は、悲観的と楽観的という2つの哲学的な陣営に分類されます。どちらの陣営がワークロードに適しているかを理解することは、データチームが行うことができる最も重要なアーキテクチャ上の決定の1つです。

悲観的制御

悲観的同時実行制御は、競合が発生しやすいと仮定し、データにアクセスする前にロックを取得することで競合を防ぎます。このアプローチは、競合が頻繁に発生し、トランザクションのロールバックと再試行のコストが高い書き込み負荷の高いワークロードに最適です。すべての書き込みを順序付けして検証する必要がある金融元帳システムは、典型的なユースケースです。

欠点はブロッキングです。同時実行性が高い場合、トランザクションはロックを待機してキューイングされ、スループットが低下します。最悪の場合、競合するロック要求はデッドロックを引き起こします。

楽観的制御

楽観的同時実行制御は、競合はまれであると仮定します。トランザクションはロックを取得せずに自由に実行され、データのプライベートコピーで操作されます。コミット時に、システムはトランザクションの読み取りと書き込みが他のコミットされたトランザクションと競合するかどうかを検証します。競合が見つからない場合、トランザクションはコミットされます。競合が検出された場合、トランザクションはロールバックして再試行されます。

この3段階モデル — 読み取り、検証、書き込み — は、ほとんどのトランザクションが同じデータに触れない環境で特に有効です。コンテンツ管理システム、カタログ閲覧アプリケーション、レポートダッシュボードなどが典型的な例です。

欠点は、無駄な作業が発生することです。競合が頻繁に発生する場合、トランザクションは何度も完全なロジックを実行しますが、検証時にロールバックされ、結果を生み出すことなくリソースを消費します。

どちらを使うべきか

悲観的制御と楽観的制御の選択は、ワークロードの特性によって決まります。書き込み競合が高く、トランザクションが短く、リトライに対する許容度が低い場合は、悲観的制御が適しています。読み取り中心のワークロードで競合の可能性が低く、高い同時実行性が要求される場合は、楽観的アプローチまたはMVCCベースのアプローチが有利です。

実際には、多くの本番システムでは両方の戦略が組み合わされています。一般的なパターンでは、一般的な読み取りと書き込みにはMVCCを使用し、既知のホットスポット行には悲観的ロックを適用します。例えば、複数のトランザクションが同時に競合する可能性のある特定の行をロックするためにSELECT ... FOR UPDATEを使用するなどです。

分離レベルとそのトレードオフ

分離レベルは、トランザクションがどのような同時実行性の異常に遭遇する可能性があるかを定義します。より厳格なレベルはより多くの異常を防ぎますが、同時実行性を低下させます。SQL標準では4つのレベルが定義されており、ほとんどのデータベースはそれらのいずれかのバリアントを実装しています。

• Read uncommitted は最大の同時実行性を提供しますが、ダーティリードを含むすべての異常を許容します。リスクがパフォーマンス上の利点をはるかに上回るため、本番環境ではほとんど使用されません。
• Read committed は、トランザクションが各ステートメントの実行前にコミットされたデータのみを参照するようにすることで、ダーティリードを防ぎます。再現不能読み取りとファントムを許容しますが、これはほとんどのWebアプリケーションや汎用ワークロードにとって許容できるトレードオフです。PostgreSQLとOracleはこのレベルをデフォルトとして使用しています。
• Repeatable read は、トランザクション中に読み取られた行が再度読み取られた場合に同じ値が返されることを保証することで、ダーティリードと再現不能読み取りを防ぎます。ファントムは依然として発生する可能性があります。MySQL/InnoDBはこのレベルをデフォルトとしています。
• Serializable はすべての異常を防ぎます。トランザクションは、あるシリアル順で、一度に1つずつ実行されたかのように動作します。これは最も高い一貫性保証ですが、最も低い同時実行性しか提供しません。絶対的な正確性が譲れない金融、コンプライアンス、または安全クリティカルなワークロードに通常予約されています。

ほとんどのアプリケーションは、Read CommittedまたはRepeatable Readで安全に動作します。Serializableを選択することは、デフォルトとして使用するのではなく、特定のビジネス要件によって推進されるべき、意図的なトレードオフです。

デッドロック：防止と解決

デッドロックは、2つ以上のトランザクションが互いに必要なロックを保持し、相互待機のサイクルを形成したときに発生します。どちらのトランザクションも進行できず、介入がなければ、両方とも無限に待機することになります。

• 検出。 ほとんどのデータベースは、待機グラフ（どのトランザクションがどのロックを待っているかをマッピングするデータ構造）内のサイクルを定期的にチェックすることでデッドロックを検出します。サイクルが見つかると、DBMSは「犠牲者」トランザクションを選択して中止し、ロックを解放して残りのトランザクションが続行できるようにします。
• 防止。 最も効果的な防止戦略は、すべてのトランザクションで一貫した予測可能な順序でロックを取得することです。すべてのトランザクションが同じ順序でリソースをロックする場合、循環待機条件は形成されません。ロックタイムアウトは追加の安全網を提供します。トランザクションが長時間待機しすぎると、潜在的なデッドロックに寄与するのではなく中止されます。
• 解決。 中止された犠牲者トランザクションはロールバックされ、通常はアプリケーションによって自動的にリトライされます。デッドロックは通常まれであるため、リトライのコストはわずかです。

デッドロックを最小限に抑えるための実践的なヒント：トランザクションをできるだけ短く保つ、予測可能な順序でリソースにアクセスする、適切なロックタイムアウト値を設定する、システム正常性のシグナルとしてデッドロックの頻度を監視する。

適切な同時実行制御アプローチの選択

普遍的な答えはありません。適切なメカニズムは、ワークロードの特性、一貫性の要件、および運用のトレードオフによって異なります。いくつかの要因が意思決定を導きます。

• 読み取り対書き込み比率。 読み取りが支配的なワークロードは、同時読み取りをブロックなしで可能にするMVCCまたは楽観的制御の恩恵を受けます。書き込み中心のワークロードは、頻繁なリトライのコストを回避するために、悲観的ロックを必要とすることがよくあります。
• 競合の頻度。 競合がまれな場合（ほとんどのアナリティカルワークロードやWebワークロードのように）、楽観的制御はより良いスループットを提供します。競合が頻繁な場合、リトライのオーバーヘッドにより、悲観的制御の方が全体的により効率的になります。
• トランザクションの期間。 短いトランザクションはロックを短時間保持するため、ロックとうまく機能します。長時間実行されるトランザクションは、長時間のブロッキングを回避するMVCCの恩恵を受けます。
• 一貫性の要件。 厳格な要件（金融、コンプライアンス）は、2PLによるSerializable分離を支持します。中程度の要件（Webアプリケーション、カタログ）は、MVCCによるRead Committedでうまく対応できます。
• 分散 vs. 単一ノード。 分散システムは、同時実行制御をより複雑で高価にする調整オーバーヘッド（ネットワーク遅延、パーティション耐性、合意要件）を導入します。

多くの本番システムは戦略を組み合わせています。MVCCをデフォルトとし、既知のホットスポット行には悲観的ロックを、楽観的競合解決にはアプリケーションレベルのリトライロジックを使用します。

分散システムおよび分析システムにおける同時実行制御

分散データベースは、追加の調整課題に直面します。ノード間のネットワーク遅延、パーティション耐性の必要性、および合意要件はすべて、同時実行制御のコストと複雑さを増大させます。アプローチには、分散2PL、グローバルタイムスタンプを備えた分散MVCC（Google SpannerのTrueTimeシステムで使用されているようなもの）、およびRaftやPaxosのような合意プロトコルが含まれます。

分析プラットフォームおよびレイクハウスプラットフォームは、従来のOLTPデータベースとは異なる方法で同時実行性を処理します。これらのシステムは、トランザクションシステムで一般的な行レベルのロックパターンではなく、スナップショット分離を備えた読み取り中心の大規模スキャンワークロードに最適化されています。

DatabricksとDelta Lakeは、同じテーブルへの同時書き込みに楽観的な同時実行制御を使用します。書き込みは3段階のプロセスに従います。最新のテーブルバージョンを読み取って影響を受けるファイルを特定し、新しいデータファイルを書き込み、コミット時に競合する変更が発生しなかったことを検証します。トランザクションが競合しない場合、成功します。競合が検出された場合、自動リトライまたは競合解決が残りを処理します。Delta Lakeは非ロックMVCCモデルを実装しているため、リーダーは常に一貫したスナップショットを参照し、ライターは独立して進行します。

Delta Lakeテーブル上のACIDトランザクションは、複数のパイプライン、ユーザー、クエリが同時に同じデータにアクセスする場合でも、データの一貫性を保証します。実稼働環境での行レベルの同時実行性がどのように機能するかを詳しく知るには、Databricksエンジニアリングブログで基盤となるメカニズムを深く掘り下げています。

このアプローチは、複数のライターとリーダーが共有データセットで動作するデータエンジニアリング、ETL、およびMLワークロードに、従来のOLTPを超えて同時実行性保証を拡張します。楽観的な同時実行制御、スナップショット分離、および自動競合解決を組み合わせることで、最新のレイクハウスプラットフォームは、データベースグレードのトランザクションの信頼性をクラウドデータレイクのスケーラビリティと柔軟性にもたらします。

複雑さなしの同時実行制御：Databricksの処理方法

同時実行制御の理論を理解することは一つの課題です。分散データ、複数のライター、多様なワークロード全体でそれを確実に実装することは別の課題です。独自の同時実行戦略を管理するチームは、分離レベルの設定、ロック動作のチューニング、およびリトライロジックの構築に多くのエンジニアリング時間を費やしており、その時間は実際の作業を進めることには使われません。

Databricks Lakebaseはその運用上の負担を排除します。Databricks Data Intelligence Platform上に構築されたLakebaseは、完全に管理されたクラウドネイティブデータベースであり、チームが同時実行制御を実装または設定する必要なしに、レイクハウスにトランザクションの信頼性をもたらします。すぐに使える状態で、楽観的な同時実行制御、読み取りのスナップショット分離、および書き込みの書き込みシリアライザブル分離を提供します。これらは、この記事でカバーされているのと同じメカニズムが自動的に適用されます。

LakebaseはDelta Lake上で楽観的同時実行制御を使用しているため、管理すべきロックはなく、デバッグすべきデッドロックもありません。同時書き込みは、このガイドの早い段階で説明したリード・バリデート・コミット・パターンに従います。各トランザクションは最新のテーブルバージョンを読み取り、新しいデータファイルを書き込み、コミット時に競合する変更が発生しなかったことを検証します。複数のパイプライン、ユーザー、またはクエリが同じテーブルに書き込む場合、Delta Lakeの行レベルの競合検出により、重複しない変更が自動的に解決されます。これは、同時MERGE、UPDATE、DELETE操作の場合でも同様です。リーダーは、進行中の書き込みの影響を受けない一貫したスナップショットを常に確認できます。

これは分析ワークロードに限定されません。Lakebaseは、トランザクション保証を運用ワークロード、データエンジニアリング、ETLパイプライン、MLにまで拡張します。これらすべてが同じプラットフォーム上で実行されます。レイクハウスの隣に個別のOLTPデータベースを維持し、カスタム統合コードでそれらを連携させる代わりに、チームは単一の管理されたアーキテクチャを通じてすべてを実行します。データは低コストのクラウドストレージ上のオープンフォーマットのままですが、トランザクションコンピューティングレイヤーは独立して実行されます。

その結果、この記事で説明されているすべての同時実行制御の概念（MVCC、楽観的検証、スナップショット分離、競合解決）は、Databricks上でデフォルトで機能します。チームは、同時実行戦略ではなく、データとワークロードに集中できます。Lakebaseを探索して、それが実際にどのように機能するかを確認してください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事