Les modèles transactionnels
modèle ACID
Les propriétés ACID sont un ensemble de caractéristiques essentielles qui garantissent la fiabilité et la cohérence des transactions dans une base de données. Ces propriétés sont particulièrement importantes pour les systèmes de gestion de bases de données relationnelles (SGBDR) afin de maintenir l'intégrité des données dans un environnement multi-utilisateurs.
Les propriétés ACID sont les suivantes :
1. Atomicité (Atomicity)
L'atomicité assure que toutes les opérations d'une transaction sont exécutées de manière indivisible et tout ou rien. Si une partie de la transaction échoue, toutes les opérations effectuées jusqu'à ce point sont annulées, et la base de données est ramenée à son état initial. Cela garantit que la base de données reste cohérente en cas d'erreur ou d'interruption.
Si un problème survient (panne, erreur, crash), la base de données annule les opérations partielles → retour à l’état initial.
Exemple : Débiter 100 € du compte A et créditer le compte B. Si le débit réussit mais le crédit échoue, la transaction est annulée → le compte A n’est finalement pas débité.
2. Cohérence (Consistency)
La cohérence garantit que la base de données passe d'un état valide à un autre état valide après l'exécution d'une transaction.
Cela signifie que chaque transaction doit respecter toutes les règles d'intégrité et de contraintes définies dans la base de données. Si une transaction viole l'une de ces règles, elle est annulée, et la base de données ne sera pas laissée dans un état incohérent.
Exemple : Si la règle dit qu’un solde de compte bancaire ne peut pas être négatif, la transaction ne pourra pas valider un débit qui rendrait le solde négatif.
3. Isolation (Isolation)
L'isolation assure que chaque transaction s'exécute de manière isolée des autres transactions en cours. Cela signifie que les résultats d'une transaction ne sont visibles aux autres transactions qu'une fois la transaction terminée et validée.
Cela évite les conflits d'accès concurrents et garantit que chaque transaction agit comme si elle était exécutée individuellement, même si plusieurs transactions sont en cours simultanément.
Cela évite des effets indésirables comme :
- Lecture sale (Dirty Read) : lire des données modifiées par une transaction non validée.
- lecture non reproductible (Non Repeatable Read) : Une transaction relit des données qu'elle a lues précédemment et trouve que les données ont été modifiées par une autre transaction (validée depuis la première lecture)
- Lecture fantôme (Phantom Read) : voir un enregistrement apparaître/disparaître pendant une transaction.
- Anomalie de sérialisation : Le résultat de la validation réussie d'un groupe de transactions est incohérent avec tous les ordres possibles d'exécutions de ces transactions, une par une. A un moment donné une contrainte ne valide pas une transaction, alors qu'elle réussissent toutes si elles sont exécutées "en même temps".
- Mise à jour perdue (Lost Update) : écraser une mise à jour concurrente.
Les bases de données offrent différents niveaux d’isolation (Read Uncommitted, Read Committed, Repeatable Read, Serializable) qui correspondent à ce que l'on veut éviter comme effets indésirables.
4. Durabilité (Durability)
La durabilité garantit que les résultats d'une transaction validée sont définitifs et restent disponibles même en cas de panne du système, de redémarrage du serveur ou de tout autre événement imprévu. Une fois qu'une transaction est confirmée, ses modifications sont écrites de manière permanente dans la base de données et ne peuvent pas être perdues.
Cela repose sur des mécanismes de journalisation (log des écritures) et de reprise après incident.
Exemple : Si un virement est validé et que le serveur tombe en panne juste après, au redémarrage la transaction sera retrouvée et appliquée correctement.
En respectant ces propriétés ACID, les SGBDR garantissent l'intégrité, la fiabilité et la cohérence des données, ce qui est essentiel pour les applications critiques où l'exactitude des informations est primordiale. Cependant, dans certaines situations, la stricte application des propriétés ACID peut entraîner une baisse de performance, notamment dans les systèmes à haute concurrence. Dans ces cas, certains systèmes de bases de données utilisent des mécanismes de contrôle de la concurrence moins stricts, appelés propriétés BASE (Basically Available, Soft-state, Eventually-consistent).
modèle BASE
Basically Available
Le système garantit une disponibilité élevée : les requêtes reçoivent toujours une réponse (même si ce n’est pas forcément la donnée la plus récente).
Cela découle du théorème CAP : en cas de partition réseau, BASE privilégie Availability (disponibilité) plutôt que Consistency stricte.
Exemple : Sur Amazon DynamoDB, même si une réplique est momentanément inaccessible, on répond avec une autre copie des données.
Soft state
L’état de la base peut changer même sans nouvelles écritures, car les mécanismes de réplication et de synchronisation entre nœuds tournent en arrière-plan.
Cela signifie que les données visibles peuvent être temporairement incohérentes selon le nœud interrogé.
Exemple : Dans un cluster Cassandra, une donnée écrite sur un nœud peut ne pas encore être propagée aux autres, donc la lecture peut donner un résultat différent selon le serveur interrogé.
Eventually Consistent
À terme, toutes les répliques convergent vers un état cohérent, mais pas forcément immédiatement.
La cohérence est relâchée pour gagner en performance et en disponibilité.
Exemple : Sur un réseau social, après avoir modifié sa photo de profil, il est possible que certains amis voient encore l’ancienne photo quelques secondes/minutes, le temps que la réplication se propage.
L'approche BASE offre plusieurs avantages par rapport à l'ACID dans certains contextes.
Tout d'abord, elle privilégie la disponibilité des données, même en cas de panne partielle ou de partition réseau. Grâce à la réplication asynchrone, une panne de nœud n’empêche pas le système de continuer à fonctionner. Les données se resynchronisent automatiquement une fois le nœud rétabli.
Les bases BASE sont conçues pour être distribuées sur des dizaines ou centaines de serveurs. Elles gèrent facilement des volumes massifs de données et un grand nombre de requêtes concurrentes.
BASE est plus flexible, elle permet de s’adapter à des scénarios où la cohérence absolue n’est pas critique. Elle manipule des données semi-structurées ou non-structurée qui ne requièrent pas un schéma strict ou une cohérence immédiate.
Conclusion
ACID = fiabilité stricte, transactions sûres.
BASE = souplesse, disponibilité et performance, au prix d’une cohérence plus faible à court terme.
Le théorème CAP
Le théorème CAP, également connu sous le nom de théorème de Brewer, est un principe fondamental en informatique distribuée. Il énonce qu'il est impossible pour un système informatique distribué de garantir simultanément les trois propriétés suivantes :
-
Cohérence (Consistency) : Tous les nœuds voient les mêmes données en même temps. En d'autres termes, toutes les lectures reçoivent la même réponse la plus récente.
-
Disponibilité (Availability) : Chaque demande reçoit une réponse, même en cas de défaillance d'un noeud. Il n'y a pas de garantie que cette réponse soit la plus récente.
-
Tolérance au partitionnement (Partition Tolerance) : Le système continue de fonctionner même en cas de défaillance d'un noeud ou de perte de communication entre les noeuds du système.
Une partition réseau se produit lorsque le cluster de serveurs est divisé en sous-groupes qui ne peuvent plus communiquer entre eux, même si chaque nœud continue à fonctionner individuellement.
Le théorème CAP stipule que dans tout système distribué, il est possible d'optimiser seulement deux des trois propriétés à la fois, mais jamais les trois simultanément. Cela signifie qu'un système distribué doit faire un compromis en fonction de ses priorités :
-
CA (Cohérence et Disponibilité) : Le système est cohérent et disponible, mais peut ne pas tolérer les partitions du réseau. Un système qui favorise la cohérence et la disponibilité pourrait être une base de données relationnelle traditionnelle, qui nécessite une connexion constante pour assurer l'intégrité des transactions.
-
CP (Cohérence et Tolérance au Partitionnement) : Le système est cohérent et peut tolérer les partitions du réseau, mais peut ne pas toujours être disponible. Un système qui favorise la cohérence et la tolérance au partitionnement pourrait être un système bancaire, où il est crucial que toutes les transactions soient enregistrées de manière cohérente même en cas de problèmes réseau, au prix de la disponibilité temporaire.
-
AP (Disponibilité et Tolérance au Partitionnement) : Le système est disponible et tolère les partitions du réseau, mais peut ne pas toujours être cohérent. Un système qui favorise la disponibilité et la tolérance au partitionnement pourrait être un service de réseau social où la disponibilité est essentielle, même si cela signifie que certaines lectures ne sont pas toujours à jour.
Le théorème PACELC
Le théorème PACELC est une extension du théorème CAP. Là où CAP dit qu’en cas de partition réseau (P), il faut choisir entre Disponibilité (A) et Cohérence (C), PACELC complète en disant que même sans partition, il existe un compromis permanent entre Latence (L) et Cohérence (C).
PACELC affine le modèle CAP en montrant que le dilemme disponibilité/cohérence n’apparaît pas seulement en cas de panne réseau, mais aussi dans le fonctionnement normal.
PACELC est l'acronyme de Partition, Availability, Consistency, Else, Latency, Consistency
Réconciliation
En informatique et en bases de données distribuées, une réconciliation désigne le processus qui consiste à résoudre les divergences entre plusieurs copies de données afin de retrouver un état cohérent dans tout le système.
Pourquoi la réconciliation est nécessaire ?
Dans un système distribué (NoSQL, bases BASE, microservices), il arrive que les données soient :
- Répliquées sur plusieurs nœuds (pour disponibilité et performance).
- Modifiées en parallèle pendant une partition réseau ou une panne.
Résultat : les copies ne contiennent pas toujours les mêmes informations d'où incohérences des données.
La réconciliation est le mécanisme qui permet à un système distribué ou déconnecté de résoudre les conflits de données après une divergence, afin de maintenir la cohérence globale.
Elle est donc cruciale dans les systèmes AP (Availability + Partition tolerance) où l’on accepte des incohérences temporaires en échange de performance et de disponibilité.
Stratégies de réconciliation
Last Write Wins (LWW)
La modification la plus récente (selon le timestamp) écrase l’autre.
Simple mais perte des données potentielles.
Merge automatique
Les champs sont fusionnés si possible (par exemple, deux utilisateurs modifie des données différentes d'une même fiche, un l'adresse, l'autre le n° de téléphone).
Conflit manuel
Le système détecte le conflit et demande à un utilisateur ou administrateur de trancher.
CRDT (Conflict-free Replicated Data Types)
Structures de données mathématiques qui permettent une fusion sans ambiguïté, utilisées dans certains systèmes modernes (CouchDB, Riak, Redis CRDT).
Cette stratégie peut être divisée en deux sous stratégie :
State-based CRDT (CvRDT – Convergent Replicated Data Types)
Chaque nœud garde l’état de sa structure.
Lors de la synchronisation, il fusionne son état avec celui des autres via une opération commutative, associative et idempotente.
Exemple : un G-Counter (compteur croissant) → chaque nœud garde son propre compteur et à la fusion on prend le maximum.
Operation-based CRDT (CmRDT – Commutative Replicated Data Types)
Chaque mise à jour est envoyée comme une opération (plutôt que l’état complet).
Les opérations sont conçues pour être commutatives (l'ordre d’arrivée n’a pas d’importance).
Exemple : un PN-Counter (Positive-Negative Counter) → on envoie les incréments/décréments et le résultat final est la somme.