Partager via

Niveaux d’isolation (WriteSerializable et Serializable)

Delta Lake sur Azure Databricks prend en charge deux niveaux d’isolation qui contrôlent la façon dont les opérations simultanées sur une table donnée interagissent :

Niveau d’isolation Description
Sérialisable Niveau d’isolation le plus fort. Garantit que les opérations d’écriture validées et toutes les lectures sont sérialisables. Les opérations sont autorisées tant qu’il existe une séquence série qui, lorsqu’elles sont exécutées un par un, génèrent le même résultat que celui affiché dans la table. Pour les opérations d’écriture, cette séquence série est identique à l’ordre affiché dans l’historique de la table.
WriteSerializable (par défaut) Niveau d’isolation plus faible que Serializable. Garantit que seules les opérations d’écriture (pas les lectures) sont sérialisables. C'est encore plus fort que l'isolation instantanée. Fournit un bon équilibre entre cohérence et disponibilité des données pour les opérations les plus courantes.

Impact des niveaux d’isolation sur les lectures

Les opérations de lecture utilisent toujours l’isolation par instantané. Le niveau d’isolation d’écriture détermine si un lecteur peut voir un instantané d’une table qui, selon l’historique, « n’existait jamais ».

  • Serializable : un lecteur voit toujours uniquement les tables conformes à l’historique
  • WriteSerializable : un lecteur peut voir un état de table qui n’existe pas dans le journal Delta

Exemple : suppression simultanée et insertion

Envisagez un scénario où une transaction de suppression à longue durée et une transaction d’insertion démarrent en même temps et lisent la version v0. La transaction d’insertion valide en premier et crée la version v1. Après cela, la transaction de suppression tente de valider v2:

t0: deleteTxn_START
t1: insertTxn_START
t2: insertTxn_COMMIT(v1)
t3: deleteTxn_COMMIT(v2)

Dans ce scénario, deleteTxn ne voyait pas les données insérées insertTxn et ne les supprimaient pas :

  • Sérialisable : deleteTxn n’est pas autorisé à valider et un conflit se produit
  • WriteSerializable : deleteTxn est autorisé à valider une transaction, puisque l'ordre des transactions peut être établi. L’état de la table résultant est comme s’il insertTxn s’est produit après deleteTxn, de sorte que les lignes insérées font partie de la table. Toutefois, l’historique Delta affiche l’ordre de validation physique (insertTxn à v1 avant deleteTxn v2).

Définir le niveau d’isolation

Définissez le niveau d’isolation à l’aide de la ALTER TABLE commande :

ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = <level-name>)

Où <level-name> est Serializable ou WriteSerializable.

Exemple :

-- Change from default WriteSerializable to Serializable
ALTER TABLE my_table SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')

Quand Delta Lake valide-t-il sans lire la table ?

Les opérations de Delta Lake INSERT ou d’ajout ne lisent pas l’état de la table avant la validation si les conditions suivantes sont remplies :

  1. La logique est exprimée à l’aide d’une INSERT logique SQL ou d’un mode d’ajout
  2. La logique ne contient aucune sous-requête ou condition qui référence la table ciblée par l’opération d’écriture

Comme pour d’autres validations, Delta Lake utilise les métadonnées du journal des transactions pour valider et résoudre les versions de table lors de la validation, mais aucune version de la table n’est réellement lue.

Note

De nombreux modèles courants utilisent des opérations MERGE pour insérer des données en fonction des conditions de la table. Bien qu’il soit possible de réécrire cette logique à l’aide d’instructions INSERT, si une expression conditionnelle fait référence à une colonne de la table cible, ces déclarations ont les mêmes limitations de concurrence que les MERGE.

Étapes suivantes

  • Last updated on