PostgreSQLのトランザクション分離レベルの例

エントリー

SQL標準では、トランザクション分離の4つのレベル-コミットされていない読み取り、コミットされた読み取り、反復可能な読み取り、およびシリアル化可能について説明しています。 この記事では、分離レベルがRead committedおよびSerializableである4つの並行トランザクションのライフサイクルについて説明します。

読み取りコミット分離レベルでは、データの読み取りに関する次の特別な条件が許容されます。

繰り返し不可の読み取り -トランザクションは以前と同じデータを再読み取りし、別のトランザクション（最初の読み取り後に終了した）によって変更されたことを検出します。

幻像読み取り -トランザクションは、特定の条件の行セットを返すクエリを繰り返し実行し、この時間内に完了したトランザクションによって条件を満たしている行セットが変更されたことを検出します。

Serializableに関しては、この分離レベルは最も厳格であり、データ読み取り現象はありません。

ACIDまたは4つのトランザクションプロパティ

トランザクションの分離レベルを数語で検討する前に、トランザクションシステムの基本的な要件を思い出してみましょう。

アトミック性 （アトミック性）-トランザクションを全体として完了する必要があるか、まったく完了しない必要があるという事実で表現されます。

一貫性 -トランザクションが完了すると、データが一貫した状態から別の状態に移行することを保証します。つまり、トランザクションはデータの相互一貫性を破壊できません。

分離 -ユーザープロセスの分離とは、データベースへのアクセスを競合するトランザクションが、互いに分離して順次物理的に処理されることを意味しますが、ユーザーにとっては、並列に実行されているように見えます。

耐久性 -エラートレランス-トランザクションが正常に完了した場合、データの変更はどのような状況でも失われることはありません。

コミットされた分離レベルの読み取り

デフォルトでは、PostgreSQLにはRead Committed分離レベルがあります。 このレベルの分離により、正常に完了したトランザクションによって行われた変更を、残りの並列オープントランザクションで常に確認できます。 このレベルで実行されているトランザクションでは、SELECTクエリ（FOR UPDATE / SHARE句なし）は、クエリの開始前にコミットされたデータのみを参照します。 コミットされていないデータや、並列トランザクションによる要求の実行中に行われた変更は表示されません。 基本的に、SELECTクエリは、クエリの開始時にデータベースのスナップショットを参照します。 ただし、SELECTは、まだコミットされていない場合でも、同じトランザクションで以前に行われた変更の結果を確認します。 また、最初のSELECTの後に他のトランザクションが変更をコミットすると、2つの連続したSELECTステートメントが同じトランザクション内でも異なるデータを見ることができることに注意してください。

Read Committed分離レベルの本質を図1に示します。

注：テーブルには、データの最初のバージョン（v1）のレコードが既に含まれています。 SELECT v1コマンドを受け入れてください。 -バージョンv1のデータを返し、v1をv2に更新するコマンドとして。 -最初のバージョンから2番目のバージョンにデータを更新するコマンドとして。

ご注意 この図は、INSERTクエリの効果を示していません。 この分離レベル内では、たとえばステップ3で最初のトランザクションに追加された行は、最初のトランザクションの完了後に他のトランザクションから見えるようになります。

Read Committedモードで提供される部分的なトランザクション分離は、多くのアプリケーションで受け入れられます。 このモードはすばやく簡単に使用できますが、すべての場合に適しているわけではありません。 複雑なクエリと変更を実行するアプリケーションでは、Serializableなど、データのより一貫した表示が必要になる場合があります。

シリアライズ可能な分離レベル

シリアライズ可能な分離は、SELECTクエリを使用して妨げられないトランザクションデータベースアクセスを提供します。 ただし、UPDATEおよびDELETEクエリを使用するトランザクションの場合、Serializableの分離レベルでは、異なるトランザクション内で同じ行を変更できません。 このレベルの分離では、すべてのトランザクションは、すべて順番に（次々に）開始されたかのように処理されます。 2つの同時トランザクションが同じ行を更新しようとすると、これは不可能になります。 この場合、PostgreSQLはトランザクションを強制的に実行し、2番目以降のすべてのトランザクションをキャンセルするように行を変更しようとしました（ロールバック-ROLLBACK）。

Serializable分離レベルの本質を図2に示します。

ご注意 この図は、INSERTクエリの効果を示していません。 この分離レベル内では、たとえばステップ3で最初のトランザクションに追加された行は、最初のトランザクションの完了後、2番目、3番目、および4番目のトランザクションに使用できません。 また、ROLLBACKの結果は図に示されていません（ステップ8および11）。 2番目と3番目のトランザクションがロックされていないデータに変更を加えた場合、トランザクションが失敗するため、これらのすべての変更はコミットされません（プロパティの本質はAtomicityです）。

Serializableの分離レベルは、トランザクションの影響を受けるすべてのデータが他のトランザクションによって変更されないようにします。 このレベルでは、「ファントム」の出現は除外されるため、複雑な競争的操作が可能になります。 実際には、会計システムではこのレベルの分離が必要です。

SELECTクエリのみを含むトランザクションの場合、現在のトランザクションの操作中に並列に完了したトランザクションによって行われた変更を見たくない場合、Serializableの分離レベルを使用することで正当化されます。

シリアル化の異常（最新の更新）

データを読み取る別の現象は、トランザクションのグループを正常に修正した結果が、これらのトランザクションを順番に実行するためのあらゆる種類のオプションと矛盾するという事実によって説明されます。

シリアル化の異常と失われた更新が関連する現象であるという事実に間違われている場合は、コメントに私を向けてください。

PostgreSQL PRO Webサイトのドキュメントには、Read Committedで「シリアル化の異常」が許可されていると書かれています。 国内のウィキペディアは、テーブルが特にPostgreSQLを参照していると主張するのではなく、Read Commited はシリアライゼーションの異常を防ぐと書いています。 英語版ウィキペディアでは、このデータ読み取りの現象については言及していません。 しかし、ドイツのウィキペディアは、表のバージョンで「失われた更新」現象を引用しており、カーソルによる追加の保護（カーソル安定性）により、Read Committedが更新の損失を受けない可能性があることを示しています。 ウクライナのウィキペディアはロシア語版の記事をサポートし、スペイン語のウィキペディアは英語版の記事をサポートしています。 英語版のPostgreSQLドキュメントは、PostgreSQL PROドキュメントと違いはありません 。

カーソルの安定性は、rcカーソルに新しい読み取り操作（フェッチ）を追加し（読み取りカーソル、つまりカーソルからの読み取り）、現在のカーソル要素にロックを設定することを要求することにより、SQLカーソルのREAD COMMITEDレベルのロック動作を拡張します。 ロックは、カーソルが移動する（現在の要素が変更されるまで）か、おそらくはコミット操作によって閉じられるまで保持されます。 当然、カーソルによるトランザクションの読み取りは現在の行を変更できます（wc-カーソルによる書き込み）。この場合、カーソルを移動してから次の行をフェッチした後でも、トランザクションがコミットされるまでこの行の書き込みロックは保持されます。

おわりに

トランザクション分離レベルを理解することは、マルチユーザーDBMSでデータを処理する際の重要な側面です。 分離レベルには、明確に定義された特性と動作があります。 分離レベルが高いと、並列処理機能が低下し、プロセスのデッドロックのリスクが高まります。 したがって、論理データの整合性、速度、および並列マルチユーザー処理の可能性を確保するための要件に応じて、アプリケーションのタスクに応じたレベルの正しい使用が常に開発者の選択になります。

文学

» MVCCマスクなし

「 13.2。 トランザクション分離

» 分離レベルの批判

» SQLのトランザクション分離のレベル。 チートシート

» トランザクション分離レベル

» ...失われた更新現象