Apache Cassandra 6 : l'arrivée des transactions ACID distribuées avec Accord
Historiquement conçu autour d'un modèle de cohérence à terme, le SGBD distribué Apache Cassandra évolue avec sa version 6. Grâce au nouveau protocole Accord, la base de données prend désormais en charge des transactions ACID multi-partitions strictement sérialisables.
Fil « Implémentation des transactions ACID dans Apache Cassandra 6 »
L'évolution de la cohérence dans Apache Cassandra
Depuis ses débuts, Apache Cassandra privilégie la haute disponibilité et le partitionnement horizontal (sharding, le découpage et la distribution des données sur plusieurs nœuds) au détriment des garanties ACID (Atomicité, Cohérence, Isolation, Durabilité). Pour contourner cette contrainte, les applications devaient dénormaliser leurs structures de données pour adapter le modèle aux requêtes de lecture, exposant le système à des risques de désynchronisation en cas d'écritures concurrentes.
De l'atomicité BATCH aux transactions Paxos monopartition
L'introduction des opérations BATCH a permis de grouper plusieurs requêtes au sein d'une même partition. Cependant, Cassandra tranchait les conflits d'écriture au niveau des colonnes en utilisant les horodatages générés par les clients via la règle LWW (Last Write Wins, la dernière écriture l'emporte), risquant de mélanger des données issues de batchs concurrents en cas d'égalités. Cassandra a ensuite intégré les LWT (Lightweight Transactions, transactions légères) basées sur l'algorithme de consensus Paxos. Ce système a apporté des opérations atomiques de type CAS (Compare-And-Swap, comparaison et permutation), mais restait strictement limité aux requêtes ciblant une seule partition.
-- Exemple de requête conditionnelle LWT basée sur Paxos
UPDATE lab.accounts
SET balance = balance - 100
WHERE customer = 1 AND account_id = 1
IF balance >= 100;
Le protocole Accord : l'ACID distribué multi-partitions
Avec la version Cassandra 6, l'architecture intègre le protocole Accord, conçu pour gérer des transactions ACID couvrant plusieurs partitions distribuées. Accord garantit un niveau d'isolation strictement sérialisable (le niveau d'isolation le plus élevé, où l'exécution de transactions simultanées produit le même résultat qu'un traitement séquentiel) sans dépendre de verrous globaux ni bloquer les performances globales du cluster.
Impact pour l'outillage et l'architecture backend
Pour les développeurs gérant des données financières ou des états distribués, cette évolution permet d'exécuter des mises à jour atomiques complexes entre plusieurs entités distantes sans surcouche applicative. L'option s'active directement au niveau de la configuration des nœuds dans le fichier cassandra.yaml via la clé accord.enabled: true.