PolarDB:トランザクション分離

リードコミッティドのトレードオフ

リードコミッティドでは、単一のコマンドが一貫性のないスナップショットを参照できます。つまり、処理中の行に対する同時更新は参照できますが、データベース内の他の行に対する同時更新は参照できません。このため、複雑な検索条件を持つコマンドには不向きですが、単純なケースではうまく機能します。

例: 銀行残高振替 (正しく機能する場合)

BEGIN;
UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 7534;
COMMIT;

各コマンドは所定の行のみに影響するため、更新された行バージョンを参照しても一貫性のない状態は発生しません。

例: DELETE のエッジケース (予期せぬ動作)

website テーブルに hits の値が9と10の2つの行がある場合:

BEGIN;
UPDATE website SET hits = hits + 1;
-- 別のセッションから実行: DELETE FROM website WHERE hits = 10;
COMMIT;

DELETE は、UPDATE の前後で hits = 10 の行が存在していたにもかかわらず、効果がありませんでした。DELETE スナップショットによって更新前の値9はスキップされ、UPDATE がコミットされた後、行の値は11となり、WHERE hits = 10 の条件に一致しなくなります。

リードコミッティドは、多くのアプリケーションに対して十分な分離を提供し、高速に利用できます。より一貫性のあるビューを必要とする複雑なクエリや更新を伴うアプリケーションの場合は、リピータブルリードまたは直列化可能を使用してください。

例: シリアル化アノマリー

初期データが次のようになっている mytab テーブルがある場合:

 class | value
-------+-------
     1 |    10
     1 |    20
     2 |   100
     2 |   200

直列化可能トランザクションAは次を計算します。

SELECT SUM(value) FROM mytab WHERE class = 1;

そして、結果 (30) を class = 2 の新しい行として挿入します。同時に、直列化可能トランザクションBは次を計算します。

SELECT SUM(value) FROM mytab WHERE class = 2;

そして、結果 (300) を class = 1 の新しい行として挿入します。両方のトランザクションがコミットしようとします。リピータブルリードでは、両方がコミットされます。直列化可能では、一方のみがコミットされ、もう一方はシリアル化エラーでロールバックされます。これは、AとBのシリアル順序のいずれも両方の結果を生成しないためです。

述語ロックの仕組み

真の直列化可能性を保証するために、PolarDB for PostgreSQL は述語ロックを使用します。述語ロックは、書き込みが同時実行トランザクションからの以前の読み取りの結果に影響を与えたであろう時点を追跡します。これらのロックは次のとおりです。

• ブロッキングを引き起こさず、デッドロックも発生させません。

• pg_locks システムビューに mode が SIReadLock として表示されます。

• メモリを管理するために、よりきめ細かいロック (タプルロック) からより粗い粒度のロック (ページロック) に統合される場合があります。

READ ONLY トランザクションは、それ以上の競合が発生しない場合、SIReadロックを早期に解放することがあります。SERIALIZABLE READ ONLY DEFERRABLE トランザクションは、データを読み取る前にシリアル化の競合が不可能であることを確立できるまでブロックします。これは、直列化可能がブロックするがリピータブルリードがブロックしない唯一のケースです。SERIALIZABLE READ ONLY DEFERRABLE トランザクション内で読み取られたデータは、読み取られるとすぐに有効であることがわかります。これは、トランザクションがデータを読み取る前に、そのような問題がないことが保証されたスナップショットを取得できるまで待機するためです。読み書きトランザクションの SIReadロックは、重複する読み書きトランザクションが完了するまで、トランザクションコミット後も保持されることがよくあります。

アノマリーを防止するために直列化可能トランザクションに依存する場合、永続的なユーザーテーブルから読み取られたデータは、それを読み取ったトランザクションが正常にコミットされるまで有効とみなしてはなりません。遅延可能な読み取り専用トランザクション以外のすべての場合において、アプリケーションは後で中止されたトランザクション中に読み取られた結果に依存してはなりません。代わりに、トランザクションが成功するまでリトライする必要があります。

同時開発の簡素化

直列化可能トランザクションを一貫して使用することで、アプリケーション開発を簡素化できます。正常にコミットされた同時実行の直列化可能トランザクションのセットが、それらが1つずつ実行された場合と同じ効果を持つという保証は、次のことを意味します。単一のトランザクションが単独で実行されたときに正しく機能する場合、直列化可能トランザクションの任意の組み合わせでも正しく機能するか、またはコミットされません。これにより、すべての可能な同時実行インタラクションについて推論する必要がなくなります。

パフォーマンスに関する考慮事項

直列化可能トランザクションで最適なパフォーマンスを得るには、次の点に注意してください。

• 可能な場合は、トランザクションを READ ONLY として宣言します。

• アクティブ接続の数を制御します。ビジーなシステムでは接続プールを使用します。

• 整合性のため、トランザクションは必要なだけ短く保ちます。

• 必要以上にトランザクション内で接続をアイドル状態にしないようにします。idle_in_transaction_session_timeout を使用して、残存するセッションを自動的に切断します。

• 直列化可能トランザクションは同等の保護を自動的に提供するため、不要になった明示的なロック、SELECT FOR UPDATE、および SELECT FOR SHARE を削除します。

• 述語ロックテーブルメモリが枯渇した場合、システムはページレベルロックをリレーションレベルロックに統合し、シリアル化失敗率が増加します。これを回避するには、max_pred_locks_per_transaction、max_pred_locks_per_relation、および/または max_pred_locks_per_page を増やしてください。

• シーケンシャルスキャンは常にリレーションレベルの述語ロックを必要とし、失敗率を増加させます。インデックススキャンを促進するには、random_page_cost を減らすか、および/または cpu_tuple_cost を増やしてください。ロールバックの削減とクエリ実行時間の全体的な変化とのバランスを取ります。

一意制約に関する考慮事項

直列化可能分離は、真のシリアル実行では発生しない場合に一意制約違反を引き起こす可能性があります。これは、重複する直列化可能トランザクションが両方ともキーを挿入しようとする場合に発生します。たとえ、それぞれが挿入前にキーが存在しないことを確認していたとしてもです。これを回避するには、競合する可能性のあるキーを挿入するすべての直列化可能トランザクションが、最初にキーの存在を明示的に確認するようにしてください。

直列化可能分離は、スナップショット分離にシリアル化アノマリーのチェックを追加することで構築された Serializable Snapshot Isolation (SSI) を使用して実装されています。