Isolation levels | Databricks on AWS [2021/6/11時点]の翻訳です。
本書の内容は古くなっています。Databricksにおけるアイソレーションレベルと書き込みの競合をご覧ください。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
テーブルのアイソレーションレベルは、同時トランザクションによる変更から、どのトランザクションを分離すべきかの度合いを定義します。DatabricksのDelta Lakeでは、2つのアイソレーションレベルをサポートしています。SerializableとWriteSerializableです。
-
Serializable: 最も強いアイソレーションレベルです。コミットされる書き込みオペレーションと全ての読み込みがシリアライズ可能であることを保証します。テーブル履歴で確認されるのと同じ結果を生成する、一度に一回のポリシーに基づく処理の実行に順序が存在する場合に限りオペレーションは許可されます。書き込みオペレーションにおいては、テーブルの履歴と全く同じ順序で実行されます。
-
WriteSerializable(デフォルト): Serializableよりも弱いアイソレーションレベルです。書き込みオペレーションのみがシリアライズ可能であることを保証します。しかし、これはスナップショットアイソレーションよりも強いものです。WriteSerializableは、多くの一般的なオペレーションにおいてデータの一貫性と可用性の優れたバランスを提供するため、デフォルトのアイソレーションレベルとなっています。
このモードでは、Deltaテーブルの中身はテーブル履歴で確認される一連のオペレーションに期待されるものと異なる場合があります。これは、このモードにおいては、特定の組み合わせの同時書き込み(例えば、オペレーションXとオペレーションY)を、履歴上はXのあとにYがコミットされたように表示されたとしても、YがXの前に実行された(すなわち、これらの間でシリアライズが可能)ような結果となるように処理を進めることを許可します。この並び替えを許可しないようにするためには、テーブルアイソレーションレベルをSerializableに設定して、エラーを起こすようにします。
読み込みオペレーションは常にスナップショットのアイソレーションを使用します。この書き込みアイソレーションレベルは、readerが履歴によれば「存在したことがない」テーブルのスナップショットを参照できるかどうかを決定します。
Serializableレベルにおいては、readerは常に履歴に準拠するテーブルのみを常に参照します。WriteSerializableレベルにおいては、Deltaログに存在しないテーブルを参照する場合があります。
例えば、長時間削除を行なっているtxn1と、txn1によって削除されたデータをインサートするtxn2を考えてみます。txn2とtxn1が完了し、履歴順に記録されたとします。履歴によれば、txb2によってインサートされたデータはテーブルに存在すべきではありません。Serializableレベルでは、readerはtxn2によってインサートされたデータを参照することはありません。しかし、WriteSerializableレベルでは、readerはある時点でtxn2によってインサートされたデータを参照する場合があります。
どのタイプのオペレーションが、それぞれのアイソレーションレベルで競合するのか、潜在的なエラーを引き起こすのかについては、コンカレンシーコントロールを参照ください。
アイソレーションレベルの設定
ALTER TABLEコマンドを用いてアイソレーションレベルを設定します。
ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = <level-name>)
ここで、<level-name>はSerializableかWriteSerializableとなります。
例えば、デフォルトのWriteSerializableからSerializableに変更するには、以下を実行します。
ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')