どのシナリオでSERIALIZABLE分離レベルを使用しますか?ウェブサイトで、トランザクションを完全に分離したい場合は、通常、これを使用するという回答をいくつか見ました。
あなた自身の経験から知りたいのは、これをプロジェクトで使用したとき、またはこれが他のプロジェクトで使用されているのを見たとき、他の分離レベルでは満たされていない特定の要件は何かということです。 ?
どのシナリオでSERIALIZABLE分離レベルを使用しますか?ウェブサイトで、トランザクションを完全に分離したい場合は、通常、これを使用するという回答をいくつか見ました。
あなた自身の経験から知りたいのは、これをプロジェクトで使用したとき、またはこれが他のプロジェクトで使用されているのを見たとき、他の分離レベルでは満たされていない特定の要件は何かということです。 ?
SERIALIZABLE
複数のクエリを必要とする複雑なレポートを作成する場合に便利です。
READ COMMITTED
またはクエリはREPEATABLE READ
、トランザクションが開始されてから実行された瞬間までに行われた変更を確認できます。
pg_dump
、PostgreSQL
ダンプユーティリティは、発行からジョブを開始し、ダンプSET TRANSACTION ISOLATION LEVEL SERIALIZABLE
されるデータベースの状態がユーティリティが実行された瞬間の状態であり、データベースへのその後の変更がダンプに干渉しないことを保証します。
SERIALIZABLEトランザクションは、同時ロードでの正確さの簡単な証明が必要な場合に役立ちます。SQL標準でのシリアル化可能なトランザクション分離レベルの定義(SQL-92以降)では、シリアル化可能なトランザクションの同時セットの動作は、シリアル(一度に1つずつ)の実行順序と一致している必要があります。単独で実行されたときに正しいことを行うことを示すことができるトランザクションは、シリアル化可能なトランザクションの任意の組み合わせの一部として正しいことを行います。
この保護にはコストがかかります。シリアル化可能なトランザクションの分離を確実にするために、トランザクションをブロックまたはロールバックして再試行する必要があります。また、情報を追跡して、そのようなアクションを実行する必要がある時期を判断する必要があります。トランザクションタイプと開発者の数が少ない一部の開発環境では、厳密性の低い分離レベルを使用し、アプリケーションコードで競合状態を明示的に管理する方が費用効果が高いことがよくあります。数百のテーブルと数万のトランザクションタイプを持つスキーマに対して数十人のプログラマーが作業するようになると、競合状態が存在する場所を特定するコストは、それほど厳密ではない分離レベルで圧倒的になり、一般に、シリアル化可能なトランザクションを使用する方が費用効果が高くなります。 。
現在、直列化可能なトランザクションを提供するために最も頻繁に実装される方法は、厳密な2フェーズロック(S2PL)です。これは、各トランザクションの終了まで保持されるロックのブロックと、デッドロックを解除するためのロールバックによるデッドロックの検出に依存します。書き込み競合がほとんどない負荷では、楽観的同時実行制御(OCC)を使用できます。トランザクションの過程で「読み取りセット」を追跡し、他のトランザクションが読み取りセットを変更した場合はロールバックします。一部のデータベース製品では、スナップショットアイソレーションをシリアル化可能と呼んでいますが、SQL標準で必要とされる保証は実際には提供されていません。直列化可能スナップショットアイソレーション(SerializableSIまたはSSI)と呼ばれる新しい手法は、2008 ACM SIGMODで発表された学術論文で最初に説明され、PostgreSQLバージョン9.1以降で使用されています。スナップショットアイソレーションと読み取り/書き込み依存関係パターンの追跡を使用して、トランザクションをキャンセルする必要がある時期を判断します。本番環境ではあまり見られない他の手法があります。これらにはそれぞれ長所と短所があり、このような質問に対して異なる損益分岐点を提供します。