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 :

Quand changer le niveau d’isolation

Gardez le niveau d’isolation par défaut de WriteSerializable pour la plupart des charges de travail.

Avec WriteSerializable, un DELETE, UPDATE ou MERGE qui commence avant une insertion concurrente peut toujours être validé après celle-ci. Les lignes de l’insertion ne sont pas affectées, même si elles correspondent à la condition de l’opération. L’historique du tableau indique toujours l’insertion en premier, donc le contenu du tableau ne correspond pas au résultat de la réexécution des commits dans l’ordre de l’historique. Voir exemple : suppression et insertion simultanées.

Changez une table en Sérialisable si votre charge de travail ne peut pas accepter ce résultat. Par exemple, si une opération DELETE doit supprimer toutes les lignes correspondantes existantes lors de la validation, ou si les processus en aval reconstituent le contenu de la table à partir de l’ordre de validation dans l’historique. Avec Serializable, l’opération suivante échoue à cause d’un conflit, et vous devez la réessayer.

Serializable réduit le débit pour les écritures concurrentes. Les appends qui ne lisent pas la table ne sont jamais en conflit sous WriteSerializable mais peuvent entrer en conflit sous Serializable. Consultez la concurrence au niveau des lignes.

Impact des niveaux d’isolement sur les lectures

Les opérations de lecture utilisent toujours l’isolement d’instantané. Le niveau d’isolement en écriture détermine si un lecteur peut voir un instantané d’une table qui, d’après l’historique, n’a « jamais existé ».

• 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

Pour définir le niveau d’isolation, utilisez la commande ALTER TABLE :

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 effectue-t-il une validation sans lire la table ?

Les opérations Delta Lake INSERT ou append ne lisent pas l’état de la table avant de valider si ces conditions 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.

Ressources supplémentaires

• Concurrence au niveau des lignes
• Transactions
• Niveaux d’isolation et conflits d’écriture