トランザクションが複数のオブジェクトにまたがらない場合、オブジェクトごとのオプティミスティック同時実行性は直列化可能性を意味しますか？

以下を提供するシステムを考えます：

• オブジェクトごとのオプティミスティックな同時実行制御/バージョン管理（CAS-Check-and-Setを使用）
• 単一のオブジェクト以上に及ぶ必要のないトランザクション。
• スナップショット分離

このシステムはシリアライズ可能と見なされますか？

スナップショット分離から

書き込みスキューの異常では、2つのトランザクション（T1およびT2）が重複するデータセット（値V1およびV2など）を同時に読み取り、互いに素な更新（T1更新V1、T2更新V2など）を同時に行い、最後に同時にコミットします。他方によって実行された更新。システムが直列化可能である場合、T1またはT2のいずれかが「最初に」発生し、もう一方に見える必要があるため、このような異常は不可能です。対照的に、スナップショット分離では、書き込みスキューの異常が許可されます。

具体的な例として、V1とV2が一人のPhilによって保持されている2つの天びんであることを想像してください。銀行は、V1またはV2のいずれかが赤字になることを許可します。ただし、両方の合計がマイナスになることはありません（つまり、V1 + V2≥0）。両方の残高は現在100ドルです。Philは2つのトランザクションを同時に開始します。T1はV1から200ドルを引き出し、T2はV2から200ドルを引き出します。

これに基づいて、書き込みスキューの可能性があることが、スナップショット分離がシリアル化可能でないことを保証するシステムの唯一の理由であると思われます。

ただし、トランザクションが複数のオブジェクトにまたがることを許可しないシステム（上記の例V1およびV2）では、書き込みスキューが発生することは不可能と思われます。

したがって、上記のシステムはシリアライズ可能です。これは正しいです？

いいえ、あなたの規定が直列化可能と考えるべきシステムをもたらすとは思いません。

スナップショット分離は、トランザクション全体でトランザクションが同じデータセットを参照できるようにする手法です。スナップショット分離はいくつかの保証を提供しますが、トランザクションが実際にどのように機能するかを理解するために必要なすべての特性を定義しません（スナップショット分離とMVCCを統合することを選択しない限り）。

スナップショット分離は、MVCC、Multi Version Consistency Controlを使用して最も一般的に実装されます。MVCCは、スナップショットのコンテキストでトランザクションの詳細を定義します。書き込みが競合する場合にのみ分離が必要であると言われています（実装のみにより、ロケーションのみ、またはロケーション+値）。MVCCは緩和された整合性モデルを提供し、書き込みスキューの影響を受けます。

緩和された整合性モデルは、分離なしと完全分離のハイブリッドのようなものであるため、理解するのが困難です。

したがって、最初に厳密な並行性モデルから始めましょう。2つのトランザクションは、一方が他方に読み取りまたは書き込みを行うデータに書き込む場合（およびその逆の場合）、互いに分離する必要があります。

トランザクションがデータを読み取る理由がわからない場合、異なる値の読み取りが関連するクライアントの動作を変更する可能性があると想定する必要があります。これが、トランザクションの重複の状態が分離を示す理由です。分離を行わないと、スナップショット内の古いデータの読み取りは容易に緩和された一貫性を示す可能性があります。

トランザクションによって読み書きされる正確なデータのみを考慮する必要があり、そのセット外のデータを考慮する必要はありません。ただし、トランザクションによって読み取られるデータについて話すときは、必ずすべての「メタ」データ（および制約のチェックなどのメタ操作によって読み取られるデータとメタデータ）を含める必要があることを認識することが重要です。メタデータの例/メタ操作は次のとおりです。一意の新しいプライマリキーの識別。もう1つは列全体の合計です。別の方法は、何かを検索することであり、それを見つけないことです。範囲検索または合計。これは、重複を防ぐことに関する@Matthewのコメントと、状態を考慮する@Tersosaurosの回答です。

たとえば、キー制約のチェックは主キー列全体の読み取りと同義であるため、2つのトランザクションが両方とも行を挿入する場合（一意の主キー制約を想定）、2つのトランザクションが重複する（分離が必要）ことを意味します。別の例として、何かを検索してそれを見つけることは、その1つの値を読むことに似ていますが、それを見つけないことは、列のすべての値を見るようなものです。

MVCCは重複または競合する書き込みに対してのみ保護しますが、読み取りに対しては保護しません（そのトランザクションによって書き込まれない限り）。したがって、MVCCで一貫性エラーを取得するために必要なことは、他のトランザクションが古いデータを使用して継続している間に、別のトランザクション（前者のスナップショットが取得された後で他のトランザクションが発生する場合）によって変更されたものを読み取ることです最新のデータと比較して、古いデータに基づいて異なる決定を行います。あなたが思うよりも引き起こすのは簡単です。

一貫性の緩和は、潜在的に一貫性のない、またはエラーを起こしやすいと言う別の方法です。（緩和された一貫性は、結果の一貫性と混同されるべきではありません。これは、「NoSQL」から生じやすいエラーの別の一般的な形式です。）

あなたの質問で、トランザクションが複数のオブジェクトにまたがる必要はないと言うとき、これは読み取りと書き込みの両方、および整合性チェック、列全体の集約、不在チェック、範囲検索などを含むメタデータ（およびメタ操作）に適用する必要があります。 。：そうだとすれば、これまでのところとても良い。

しかしながら...

私はあなたが（オブジェクトのロックではなく）個々のオブジェクトにスナップショット分離（MVCC）を使用しているというあなたの質問からそれを取る。（CASについても言及しています。比較とスワップ、およびテストとセットについて聞いたことがありますが、チェックとセットではありませんが、似ていると思います）。

あなたの質問を書くと、「オブジェクト」には複数のフィールドがあることが示唆されます。そうでなければ、質問の規定は不要です。

したがって、snapshott'ed / MVCCで処理されるオブジェクトには複数のフィールドがあるため、単一のオブジェクト内にスキューを書き込む傾向があります。2つのトランザクションが同じオブジェクトを同時に更新する場合、同じオブジェクト上の他の同時トランザクションによって古くなったオブジェクトの値のフィールドを読み取って、潜在的な不整合（エラー）を知らずに続行する可能性があります。

代わりにオブジェクトのロックを使用できます。これにより、2つのトランザクション（更新用）が同じオブジェクトを見ることができなくなります。

MVCCの壊れた書き込みセットのみの比較モデルを使用せずに、代替形式のスナップショット分離を実行できると考えています。そのため、（アルゴリズム的に）比較セットを書き込み専用から昇格させて、読み取りセットも含めることができます。その場合、同じオブジェクトを更新する2つのトランザクションは書き込みスキューを引き起こすことができません（後でコミットしようとするトランザクションは中止されるため）。これは、あなたが説明している問題に対する適切な解決策かもしれないと思います。なぜなら、マルチオブジェクトトランザクションを排除することで、MVCCが私たちを購入するメリットのほとんどをすでに得ているからです。

（読み取りまたは書き込みの正確で特定の項目/フィールドのみを考慮する必要がありますが、書き込み操作（エラーなど）を防ぐために、メタ操作中にそれらをメタデータとして含める必要があります。 、またはメタデータ（メタ操作で使用される可能性がある）を考慮しない場合、エラーを許容するモデルがあります。）

私はと、考えて@ pjc50、述べ^{強調追加（:)}「場合、その後「答えはイエスである」トランザクションは、単一のオブジェクトを読み取り/書き込みに制限されています」。しかし、これがどこに落ちてくるかは、単一のオブジェクトのアイデアにあると思います。

スナップショット分離から取得した例では、T1とT2は値を共有しません。しかし、彼らはまだ書き込みスキューのための潜在的なされているので、「どちらも[あり]更新は他で行わ見た」^ソース。したがって、能力他のすべての更新プログラムを参照するには、トランザクションのコミットする前に、トランザクションが本当に直列化可能になり、その。

シリアライズ可能性から：

スケジュールの直列化可能性とは、同じトランザクションでのシリアルスケジュール（つまり、時間的にトランザクションが重複しないシーケンシャル）と同等（結果、データベース状態、データ値）を意味します。

残念ながら、このため（そして@Matthew Mark Millerが指摘しているように）、値だけでなく状態も考慮する必要があります。この考慮により、OCCを使用する2つのトランザクションは、データベースの状態が書き込まれるたびに書き込みスキューの可能性があります。