Transactions, ACID et niveaux d’isolation

Ce que promet une transaction

Une transaction regroupe plusieurs lectures et écritures en une seule unité qui prend effet entièrement (elle est validée, commit) ou pas du tout (elle est abandonnée et annulée, rollback). Le chapitre 0 a présenté l’idée avec un virement bancaire. Cette section porte sur ce que la plupart des développeurs comprennent mal : ce qui se passe quand de nombreuses transactions s’exécutent en même temps, quelles garanties les bases de données donnent réellement, et comment choisir. Les exemples utilisent SQL, mais le raisonnement vaut pour tout stockage qui propose des transactions.

Les transactions comptent pour l’architecture parce qu’elles déterminent où les règles métier peuvent être appliquées à moindre coût. Au sein d’une seule base de données, une transaction peut maintenir un registre équilibré ou empêcher qu’une table soit réservée deux fois, en quelques lignes de code. Entre services, cet outil n’existe pas, et c’est pourquoi la propriété des données et les sagas sont si importantes. Savoir exactement ce que garantit une seule base de données vous dit quelles règles doivent rester à l’intérieur du périmètre d’un seul propriétaire.

ACID en détail

L’acronyme ACID a été forgé par Theo Härder et Andreas Reuter en 1983, à partir des travaux antérieurs de Jim Gray. Chaque lettre est plus étroite qu’elle n’en a l’air. L’atomicité concerne les défaillances, pas la concurrence : si quelque chose tourne mal en cours de route (une panne, une violation de contrainte, un interblocage, ou l’application qui décide d’abandonner), toutes les modifications faites jusque-là sont annulées, si bien que l’application peut réessayer sans risque. Abandonnabilité serait un nom plus exact.

La cohérence signifie qu’une transaction fait passer la base de données d’un état valide à un autre, où valide signifie que vos invariants sont respectés : les débits égalent les crédits, le stock n’est jamais négatif, chaque commande a un client. La base de données peut appliquer elle-même certains invariants (clés, clés étrangères, contraintes CHECK, index uniques), mais la plupart sont des règles métier que seules les transactions de l’application maintiennent. La cohérence est donc une propriété de la façon dont l’application utilise l’atomicité et l’isolation, et non quelque chose que la base de données fournit à elle seule. Elle n’a d’ailleurs aucun rapport avec le C de CAP, qui désigne la linéarisabilité (chapitre 6).

L’isolation signifie que des transactions qui s’exécutent simultanément n’interfèrent pas entre elles. Dans sa forme la plus stricte, la sérialisabilité, le résultat de l’exécution concurrente des transactions est le même que si elles s’étaient exécutées l’une après l’autre dans un certain ordre. Les niveaux plus faibles tolèrent certaines interférences en échange de performances, et le reste de cette section explique précisément lesquelles. La durabilité signifie qu’une fois un commit confirmé, les données survivent aux pannes. Les bases de données à un seul nœud y parviennent grâce à un journal d’écriture anticipée écrit sur disque avant que le commit ne rende la main ; les bases de données répliquées y ajoutent des copies sur d’autres machines. La durabilité n’est jamais absolue : un disque peut mentir sur une écriture forcée, et la réplication asynchrone peut perdre les dernières écritures confirmées quand le leader tombe en panne (voir la réplication).

Ce qui tourne mal sans isolation

Les bugs de concurrence sont difficiles à trouver parce qu’ils dépendent du moment : ils passent tous les tests sur la machine tranquille d’un développeur et apparaissent au pic de l’heure du dîner. La façon la plus claire de comprendre les niveaux d’isolation est de passer par les anomalies précises (aussi appelées phénomènes) qu’ils permettent ou empêchent. La mise à jour perdue, ci-dessous, est la plus courante dans le code métier.

Les niveaux d’isolation de la norme SQL

La norme SQL (à partir de SQL-92) définit quatre niveaux d’isolation selon les phénomènes qu’ils interdisent parmi trois : les lectures sales, les lectures non répétables et les fantômes. La norme fait de serializable le niveau par défaut, mais presque aucun produit courant ne la suit sur ce point ; la plupart utilisent par défaut read committed ou repeatable read, pour les performances.

En 1995, Hal Berenson, Phil Bernstein, Jim Gray, Jim Melton, Elizabeth O’Neil et Patrick O’Neil ont publié A Critique of ANSI SQL Isolation Levels. Ils ont montré que les définitions de la norme, rédigées en anglais courant, étaient ambiguës, qu’interdire les trois phénomènes ne suffit pas à garantir la sérialisabilité, et que les niveaux de la norme ne décrivaient pas les niveaux d’isolation qu’utilisaient les produits réels. Ils ont ajouté des phénomènes que la norme avait oubliés, notamment l’écriture sale, la mise à jour perdue, le read skew et le write skew, et ont défini l’isolation par instantané (snapshot isolation) : chaque transaction lit dans un instantané cohérent des données validées tel qu’il était à son début, et une transaction ne peut pas valider l’écriture d’une ligne qu’une transaction concurrente a déjà modifiée et validée (le premier qui valide l’emporte). L’isolation par instantané empêche les lectures sales, les lectures non répétables, le read skew et les mises à jour perdues, ainsi que les fantômes qui touchent les lectures, mais elle permet le write skew : elle n’est donc pas sérialisable. Elle s’insère mal entre les niveaux de la norme, et c’est pourquoi les produits l’étiquettent différemment.

MVCC : comment fonctionnent les instantanés

La plupart des bases de données modernes mettent en œuvre les lectures sur instantané avec le contrôle de concurrence multiversion (MVCC). Au lieu d’écraser une ligne sur place, une écriture crée une nouvelle version marquée de l’identifiant de la transaction qui l’écrit, et l’ancienne version est conservée jusqu’à ce qu’aucune transaction en cours ne puisse encore en avoir besoin. Chaque lecteur reçoit un instantané, c’est-à-dire en substance la liste des transactions qui avaient été validées à son démarrage, et ne voit que les versions créées par ces transactions. Le grand avantage est que les lecteurs n’attendent jamais les écrivains et que les écrivains n’attendent jamais les lecteurs ; seuls deux écrivains sur la même ligne entrent en conflit.

Le prix à payer, c’est l’entretien. Les anciennes versions doivent être nettoyées : PostgreSQL les garde dans la table et les supprime avec vacuum, tandis qu’Oracle et MySQL InnoDB conservent les images avant modification dans des journaux d’annulation (undo logs). Une transaction laissée ouverte pendant des heures retient les anciennes versions, si bien que les tables et les journaux d’annulation gonflent et que les performances se dégradent. Les transactions de longue durée sont donc un signal d’alerte opérationnel dans toute base de données MVCC, et une raison de tenir les requêtes analytiques à l’écart de la base de données opérationnelle. En read committed avec MVCC, chaque instruction reçoit un nouvel instantané ; en isolation par instantané, toute la transaction en utilise un seul.

Les valeurs par défaut réelles, et pourquoi les noms induisent en erreur

Les noms des niveaux d’isolation ne sont pas portables. Le même mot peut désigner des garanties différentes selon les produits, et les valeurs par défaut diffèrent. Le projet Hermitage de Martin Kleppmann a testé le comportement réel de nombreuses bases de données face aux anomalies ci-dessus ; la documentation des éditeurs confirme les valeurs par défaut. Considérez ce tableau comme un point de départ et vérifiez la documentation de la version que vous utilisez.

Obtenir la sérialisabilité

Les bases de données qui offrent une véritable sérialisabilité utilisent l’une de trois techniques. L’exécution réellement en série exécute les transactions une par une sur un seul thread, ce qui est rapide si chaque transaction est courte et si les données sont en mémoire (VoltDB, ainsi que les scripts et transactions Redis, fonctionnent ainsi). Le verrouillage à deux phases (2PL), utilisé par les niveaux serializable de SQL Server et de MySQL, fait prendre aux lecteurs des verrous partagés et aux écrivains des verrous exclusifs, y compris des verrous sur des plages pour arrêter les fantômes, et les conserve jusqu’à la fin de la transaction ; c’est correct, mais lecteurs et écrivains se bloquent mutuellement, le débit chute en cas de contention et les interblocages sont fréquents. L’isolation par instantané sérialisable (SSI), décrite par Michael Cahill, Uwe Röhm et Alan Fekete en 2008 et utilisée dans PostgreSQL depuis la version 9.1 (CockroachDB utilise une technique optimiste apparentée), exécute les transactions sur des instantanés sans blocage, suit les dépendances lecture-écriture entre elles et abandonne une transaction quand un motif dangereux apparaît.

Quelle que soit la technique, les transactions sérialisables peuvent échouer avec une erreur de sérialisation (SQLSTATE 40001 dans PostgreSQL et CockroachDB) ou un interblocage, et l’application doit alors relancer toute la transaction. C’est le coût caché du niveau le plus fort : chaque chemin de code transactionnel a besoin d’une boucle de nouvelles tentatives qui puisse être répétée sans risque, ce qui exclut tout effet de bord, comme l’envoi d’e-mails ou l’appel de prestataires de paiement, à l’intérieur de la transaction.

Contrôle de concurrence pessimiste et optimiste

En pratique, la plupart des applications s’exécutent en read committed ou en repeatable read et protègent explicitement certains chemins lecture-modification-écriture. Il existe trois outils. Le meilleur, quand c’est possible, est une mise à jour atomique qui laisse la base de données faire le calcul et la vérification en une seule instruction, comme UPDATE accounts SET balance = balance - 30 WHERE id = 7 AND balance >= 30, puis vérifier qu’exactement une ligne a changé. En read committed dans PostgreSQL, une mise à jour concurrente fait attendre la seconde instruction, qui réévalue ensuite sa condition sur la nouvelle ligne : aucune mise à jour n’est perdue.

Lorsque la décision exige une logique que la base de données ne peut pas exprimer, utilisez le verrouillage pessimiste : verrouillez les lignes que vous lisez avec SELECT ... FOR UPDATE, afin que les transactions concurrentes qui en ont besoin attendent votre commit. C’est simple et adapté aux opérations courtes et très disputées (affecter un livreur à une commande). Les coûts sont l’attente, le risque d’interblocages (verrouillez les lignes dans un ordre constant, par exemple par id croissant) et un débit réduit. Parmi les variantes figurent NOWAIT, qui échoue immédiatement au lieu d’attendre, et SKIP LOCKED, qui saute les lignes déjà verrouillées et constitue la façon classique de construire une file de tâches fiable sur une table relationnelle.

BEGIN;
-- Lock the row: other FOR UPDATE readers and writers must wait
SELECT balance FROM accounts WHERE id = 7 FOR UPDATE;
-- application checks: balance (100) >= 30, so allow it
UPDATE accounts SET balance = 70 WHERE id = 7;
INSERT INTO ledger (account_id, amount, kind)
  VALUES (7, -30, 'withdrawal');
COMMIT;  -- lock released; the waiting transaction now sees 70

Le contrôle de concurrence optimiste ne prend aucun verrou pendant que l’utilisateur ou le code réfléchit. Chaque ligne porte un numéro de version (ou un horodatage, ou une empreinte). L’écrivain ne met à jour que si la version est toujours celle qu’il a lue, et l’incrémente. Si aucune ligne ne change, quelqu’un d’autre est passé avant, et l’application recharge et réessaie, ou prévient l’utilisateur. Cela convient aux données peu disputées et aux longs temps de réflexion : le gérant d’un restaurant qui modifie une carte dans un navigateur pendant cinq minutes ne doit pas garder un verrou de base de données tout ce temps. HTTP intègre la même idée, avec les ETags et l’en-tête If-Match.

-- Read (no lock); remember version = 12
SELECT id, name, price, version FROM menu_items WHERE id = 501;

-- Later, write only if the version is unchanged
UPDATE menu_items
   SET price = 11.00, version = version + 1
 WHERE id = 501 AND version = 12;

-- Rows affected = 1: success.
-- Rows affected = 0: a concurrent edit won; reload and retry
-- or show the user the other change.

Choisir une stratégie d’isolation

Il n’existe pas un seul bon niveau ; il existe un bon niveau pour chaque élément de logique. Une approche pratique part des invariants, pas des paramètres.

En règle générale, read committed avec verrouillage explicite ou vérifications de version est un choix par défaut solide et rapide pour la plupart des applications métier, à condition que l’équipe repère avec rigueur les chemins lecture-modification-écriture. Serializable est le choix par défaut le plus sûr quand les règles sont complexes, que l’équipe est grande ou que la violation d’un invariant coûte cher (argent, médecine, sûreté), et de nombreuses équipes l’utilisent aujourd’hui pour les chemins critiques, en acceptant les nouvelles tentatives. Les praticiens sont réellement en désaccord sur ce point : certains soutiennent que serializable par défaut évite toute une classe de bugs que la revue de code ne détectera jamais ; d’autres estiment que ses nouvelles tentatives et sa contention coûtent trop cher et que le verrouillage explicite rend l’intention visible. Les deux positions se défendent si le choix est délibéré et testé.