分離レベル（WriteSerializable と Serializable）
Databricks上のDelta Lake特定のテーブルでの並列操作の相互作用を制御する 2 つの分離レベルをサポートしています。
isolationLevel | 説明 |
|---|---|
シリアル化可能 | 最も強力な分離レベル。コミットされた書き込み操作とすべての読み取りがSerializable であることを保証します。一度に 1 つずつ実行すると、表に示されているものと同じ結果が生成される連続シーケンスがある限り、操作は許可されます。書き込み操作の場合、この連続シーケンスはテーブルの履歴に表示される順序と同じです。 |
WriteSerializable （デフォルト） | Serializable よりも弱い分離レベル。書き込み操作（読み取り操作ではない）のみがシリアル化可能であることを保証します。これはスナップショット分離よりも強力です。ほとんどの一般的な操作に対して、データの一貫性と可用性の適切なバランスを提供します。 |
分離レベルが読み取りに与える影響
読み取り操作では常にスナップショット分離が使用されます。書き込み分離レベルは、履歴によれば「存在しなかった」テーブルのスナップショットをリーダーが表示できるかどうかを決定します。
- シリアル化可能 : 読者は常に履歴に準拠したテーブルのみを参照します
- WriteSerializable : 読者はDeltaに存在しないテーブルの状態を見ることができます
例: 削除と挿入
長時間実行される削除トランザクションと挿入トランザクションが同時に開始され、バージョンv0を読み取るシナリオを考えてみましょう。挿入トランザクションが最初にコミットされ、バージョンv1が作成されます。その後、削除トランザクションはv2をコミットしようとします。
t0: deleteTxn_START
t1: insertTxn_START
t2: insertTxn_COMMIT(v1)
t3: deleteTxn_COMMIT(v2)
このシナリオでは、 deleteTxn insertTxnによって挿入されたデータを確認せず、削除も行いませんでした。
- シリアル化可能 :
deleteTxnはコミットが許可されていないため、競合が発生します - WriteSerializable : トランザクションを順序付けることができるため、
deleteTxnコミットが許可されます。結果のテーブルの状態は、insertTxndeleteTxn後に発生した場合と同じになるため、挿入された行はテーブルの一部になります。ただし、 Delta履歴には物理的なコミット順序 (v1 のinsertTxnの前に v2 のdeleteTxn) が表示されます。
分離レベルを設定する
ALTER TABLEコマンドを使用して分離レベルを設定します。
ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = <level-name>)
ここで、 <level-name>はSerializableまたはWriteSerializableです。
例：
-- Change from default WriteSerializable to Serializable
ALTER TABLE my_table SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')
Delta Lake はいつテーブルを読み取らずにコミットしますか?
Delta Lake INSERTまたは追加操作では、次の条件が満たされている場合、コミット前にテーブルの状態を読み取りません。
- ロジックは
INSERTSQLロジックまたは追加モードを使用して表現されます - ロジックには、書き込み操作の対象となるテーブルを参照するサブクエリや条件文は含まれません。
他のコミットと同様に、 Delta Lakeトランザクション ログ メタデータを使用してコミット時にテーブル バージョンを検証および解決しますが、テーブルのバージョンは実際には読み取られません。
多くの一般的なパターンでは、 MERGE操作を使用して、テーブル条件に基づいてデータを挿入します。このロジックをINSERTステートメントを使用して書き換えることは可能ですが、条件式がターゲット テーブルの列を参照する場合、これらのステートメントにはMERGEと同じ同時実行制限が適用されます。