ACID vs BASE

Résumé

ACID et BASE décrivent deux manières de répondre à la question : que garantit la base quand plusieurs écritures arrivent en même temps, ou quand un nœud tombe ? ACID garantit des transactions qui laissent toujours les données dans un état valide. BASE accepte que des copies divergent un moment pour rester disponible. La frontière n’est pas celle de SQL contre NoSQL : plusieurs bases NoSQL et NewSQL offrent aujourd’hui des transactions ACID.

Prérequis

Savoir ce qu’est une transaction (un groupe d’opérations traité comme un tout) et ce que veut dire répliquer des données sur plusieurs machines.

Le fil rouge : un virement

Un virement de 100 € du compte A vers le compte B se compose de deux écritures : débiter A, créditer B. Toutes les garanties ci-dessous se lisent sur cet exemple.

ACID

Modèle transactionnel des bases relationnelles (PostgreSQL, MySQL, Oracle) et de plusieurs bases distribuées récentes.

Lettre	Garantie	Sur le virement
Atomicité	La transaction passe entièrement ou pas du tout	Pas de débit sans crédit, même si le serveur tombe entre les deux
Cohérence	Une transaction valide fait passer la base d’un état respectant ses règles (contraintes, clés étrangères) à un autre état qui les respecte	Un solde ne devient pas négatif si la règle l’interdit
Isolation	Des transactions concurrentes ne voient pas les états intermédiaires les unes des autres	Une lecture du total de A et B ne tombe pas entre le débit et le crédit
Durabilité	Une transaction validée survit à une panne	Le virement confirmé reste après un redémarrage

Deux sens du mot « cohérence »

Le C d’ACID est la préservation des règles d’intégrité de la base. La cohérence forte des systèmes distribués (CAP, linéarisabilité) est autre chose : tous les clients voient la même valeur la plus récente, comme s’il n’existait qu’une copie. La seconde ressemble davantage au I d’ACID (sérialisabilité). Cette série de notes emploie « cohérence forte » uniquement au sens distribué.

L’isolation est un réglage, pas un interrupteur

Les bases proposent plusieurs niveaux d’isolation, du plus permissif au plus strict : read committed, snapshot isolation (que certaines bases appellent repeatable read, par exemple PostgreSQL ; les deux ne sont pas équivalents partout), serializable. Plus le niveau est strict, plus il y a de verrous ou de conflits à résoudre, donc de latence. Le niveau par défaut varie d’une base à l’autre : à vérifier dans la documentation du moteur utilisé.

BASE

Acronyme forgé en opposition à ACID pour décrire des systèmes qui distribuent les données sur de nombreux nœuds et acceptent un retard de cohérence.

• BA, Basically Available : le système répond même quand une partie des nœuds est en panne. Une panne partielle n’est pas une panne totale.
• S, Soft state : l’état peut encore changer sans nouvelle écriture, parce que les copies sont en train de converger.
• E, Eventual consistency : sans nouvelle écriture, toutes les copies finiront par avoir la même valeur, sans promesse sur le délai.

Sur le virement : A et B peuvent vivre sur deux nœuds. Pendant quelques instants, une lecture peut encore montrer l’ancien solde de B.

Ce que « BASE » classe mal

Cassandra et Riak sont bâtis autour de la cohérence éventuelle. MongoDB (transactions multi-documents depuis la 4.0 pour les replica sets, la 4.2 pour les clusters shardés) et DynamoDB (transactions depuis 2018) proposent aujourd’hui des transactions ACID, avec des limites propres à chaque produit. Spanner et CockroachDB sont distribués et transactionnels. Classer un produit « ACID » ou « BASE » sans préciser la version et l’opération est donc trompeur.¹

Pourquoi ce compromis : CAP et PACELC

Le théorème CAP (conjecture de Brewer, démontrée par Gilbert et Lynch en 2002)² dit que, lorsqu’une partition réseau coupe le système en deux, il faut choisir entre rester cohérent (refuser des requêtes pour ne pas diverger) et rester disponible (répondre quitte à diverger). PACELC (Abadi, 2012)² ajoute le cas sans panne : même alors, il faut arbitrer entre latence et cohérence, parce que confirmer une écriture sur plusieurs réplicas prend du temps.

Ce coût grandit avec la distance entre les nœuds. Il n’est pas insurmontable (les bases NewSQL le paient en conscience), mais il existe.

Le spectre de cohérence

Modèle	Garantie	Disponibilité sous partition	Coordination
Cohérence forte	Toute lecture voit la dernière écriture	Faible	Élevée
Cohérence éventuelle forte (SEC)	Les nœuds ayant reçu les mêmes mises à jour sont dans le même état, sans conflit	Élevée	Faible à moyenne
Cohérence éventuelle	Les copies convergent un jour, sans garantie de délai	Très élevée	Faible

Cohérence éventuelle : les conflits sont réglés après coup, souvent par last-write-wins (la dernière écriture, selon l’horloge, écrase l’autre). Exemple : la propagation d’une entrée DNS.

Cohérence éventuelle forte : obtenue avec des CRDT (Conflict-free Replicated Data Types), des structures (Shapiro et al., 2011)² conçues pour que deux copies qui ont reçu les mêmes mises à jour convergent vers le même état, sans coordination. Dans la variante par états, la fusion de deux copies est commutative, associative et idempotente ; la variante par opérations exige en revanche une livraison respectant la causalité. Exemple : un compteur de « j’aime » réparti sur trois nœuds. Chaque nœud compte ses propres incréments, et la valeur affichée est la somme : peu importe l’ordre dans lequel les nœuds échangent leurs compteurs. Riak propose des types CRDT, en plus de son mode par défaut.

Pourquoi un data engineer s’en soucie

• Une source répliquée en cohérence éventuelle peut fournir une lecture légèrement ancienne à un job d’ingestion : prévoir une marge ou un recalcul.
• Les formats de table des lakehouses (Iceberg, Delta) réintroduisent l’atomicité sur de l’object storage : voir Data lake vs lakehouse.

Une ingestion rejouable doit aussi être idempotente : voir Idempotence et backfill.

Notes liées

• Schema-on-Write vs Schema-on-Read : un autre axe, la structure des données et non leur cohérence. Les deux axes sont indépendants : Delta Lake offre l’ACID sur des fichiers, MongoDB accepte des documents sans schéma fixe.
• Data lake vs lakehouse : l’atomicité sur de l’object storage.
• Idempotence et backfill : rendre un traitement rejouable.
• OLTP vs OLAP et stockage en colonnes : les deux grandes charges de travail.
• Glossaire data engineering : idempotence, CRDT, ELT.
• MOC Data Engineering : carte du vault.

Notes de bas de page

1. Statuts et versions à revérifier avant usage : ils évoluent d’une version à l’autre de chaque produit. ↩

2. Références originales : Seth Gilbert et Nancy Lynch, « Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services » (2002) ; Daniel Abadi, « Consistency Tradeoffs in Modern Distributed Database System Design » (2012) ; Marc Shapiro et al., « Conflict-free Replicated Data Types » (2011). Le texte du papier d’Abadi est consultable à l’adresse cs.umd.edu/~abadi/papers/abadi-pacelc.pdf ; les deux autres références sont citées de mémoire pour le titre et l’année, sans lien : à vérifier avant citation. ↩ ↩² ↩³