Accéder au contenu principal

Qu'est-ce qu'une transaction ACID ? Un guide complet pour les débutants

Vous êtes-vous déjà demandé comment les bases de données assurent la sécurité et la cohérence de vos données ? Ce guide présente les transactions ACID à l'aide d'explications simples, d'exemples et de bonnes pratiques.
Actualisé 20 févr. 2025  · 25 min de lecture

Imaginez un client qui appelle, confus, parce que son argent a été déduit mais n'a jamais été crédité au destinataire, ou parce qu'une commande a été passée sans que l'inventaire ne soit mis à jour. Ces problèmes surviennent lorsque l'intégrité des données n'est pas respectée. C'est là que les principes ACID entrent en jeu.

Les principes ACID sont appliqués pour garantir que chaque transaction est traitée de manière fiable, afin de préserver la sécurité des données et le bon fonctionnement des systèmes. La compréhension de ces principes est essentielle pour construire des systèmes fiables et tolérants aux pannes.

Dans ce guide, vous apprendrez : 

  • Pourquoi les transactions ACID sont importantes.
  • Comment ils assurent le bon fonctionnement des systèmes de base de données.
  • Des exemples concrets de leur utilisation.
  • Les meilleures pratiques pour travailler avec eux.

Allons-y ! 

Qu'est-ce qu'une transaction ACID ?

Les transactions ACID font référence à quatre propriétés qui garantissent le traitement fiable des transactions de la base de données. Les quatre principes sont les suivants : 

  • Atomicité
  • Consistance
  • Isolation
  • Durabilité

Ces principes garantissent l'exécution complète des transactions, sans mise à jour partielle ni corruption des données, même en cas de défaillance du système. Les transactions ACID sont essentielles dans les scénarios où l'intégrité des données est primordiale. 

Dans les transactions bancaires, ACID garantit que l'argent est transféré intégralement ou pas du tout, évitant ainsi des problèmes tels que les transferts partiels ou les doubles déductions. Dans le domaine du commerce électronique, les principes ACID garantissent que les commandes des clients sont traitées correctement, que les paiements sont effectués et que les mises à jour de l'inventaire reflètent les niveaux de stock en temps réel. De même, dans les systèmes de gestion des stocks, ACID maintient la cohérence en évitant les écarts de stocks dus à des transactions simultanées.

Décomposition des propriétés ACID

Chacune des quatre propriétés qui composent les principes ACID traite d'un aspect spécifique de la gestion des transactions.

Explorons ces propriétés pour comprendre comment elles contribuent à la robustesse des systèmes de base de données.

Atomicité

L'atomicité garantit qu'une transaction est traitée comme une unité unique et indivisible. Cela signifie que toutes les opérations d'une transaction doivent être achevées entièrement ou pas du tout. Si une partie de la transaction échoue, le système annule l'ensemble de la transaction, ce qui garantit qu'aucune mise à jour partielle n'est effectuée.

Exemple : Dans une transaction bancaire, l'atomicité garantit que les deux opérations sont menées à bien lorsque l'argent est débité d'un compte et crédité sur un autre. Si le débit ou le crédit échoue, la transaction est entièrement annulée.

Cohérence

La cohérence garantit qu'une transaction fait passer la base de données d'un état valide à un autre tout en respectant des règles ou des contraintes prédéfinies. Après avoir effectué une transaction, les données doivent satisfaire à toutes les règles d'intégrité de la base de données.

Exemple : Dans le domaine bancaire, la cohérence garantit que le solde total de tous les comptes reste inchangé après un transfert. Par exemple, si 100 dollars sont transférés d'un compte à l'autre, la somme des soldes des deux comptes reste la même afin de préserver les règles comptables.

L'isolement

L'isolation empêche les transactions d'interférer les unes avec les autres. Lorsque plusieurs transactions sont exécutées simultanément, l'isolation permet de s'assurer qu'elles n'affectent pas les résultats des autres. Chaque transaction doit être isolée pour éviter les conflits, en particulier dans les environnements à forte circulation.

Exemple : Si deux clients tentent d'acheter le dernier article en stock en même temps, l'isolation garantit qu'une seule transaction aboutira et que l'inventaire sera correctement mis à jour pour refléter le changement.

Durabilité

La durabilité garantit qu'une fois qu'une transaction est terminée, ses modifications sont stockées en permanence dans la base de données (même si le système tombe en panne immédiatement après). Cela permet de garantir que les données restent intactes et accessibles après une panne.

Exemple : Dans un système de commerce électronique, la durabilité garantit que les données de la commande sont enregistrées dans la base de données une fois que le client a effectué son achat. Même si le serveur tombe en panne quelques instants plus tard, l'enregistrement de l'achat reste intact et peut être récupéré lorsque le système est restauré.

Propriétés ACID.

Propriétés ACID. Image par l'auteur

Transactions ACID dans les bases de données relationnelles

La plupart des bases de données relationnelles sont construites selon les principes ACID. Cela signifie qu'ils sont conçus pour maintenir la précision et la fiabilité des données.

Dans cette section, nous allons voir comment les bases de données mettent en œuvre les propriétés ACID.

Pour ceux qui découvrent les bases de données relationnelles, ce cours Introduction aux bases de données relationnelles en SQL est parfait pour construire une base solide.

Comment l'ACID est mis en œuvre dans les bases de données SQL

Les bases de données SQL traditionnelles appliquent les propriétés ACID par le biais de mécanismes de contrôle des transactions tels que les commandes SQL comme BEGIN, COMMIT et ROLLBACK. Ces commandes gèrent les transactions, tandis que les journaux de transactions et les verrous garantissent l'intégrité des données.

Par exemple :

  • L'atomicité est gérée à l'aide de ROLLBACK en cas d'erreurs, ce qui permet d'éviter les mises à jour partielles.
  • La cohérence est assurée par des contraintes (par exemple, clés étrangères, clés uniques) afin de maintenir l'intégrité des données.
  • L'isolation est mise en œuvre au moyen de verrous afin d'éviter les conflits entre les transactions simultanées.
  • La durabilité est assurée par la persistance des transactions, garantissant qu'elles ne sont pas perdues une fois validées, même en cas de défaillance.

Conformité ACID dans différents systèmes de base de données

La plupart des bases de données SQL sont dotées d'une conformité ACID intégrée pour maintenir l'intégrité transactionnelle. Des systèmes tels que MySQL, PostgreSQL, Oracle et Microsoft SQL Server utilisent des journaux de transactions (par exemple, Write-Ahead Logging dans PostgreSQL) et des protocoles de verrouillage (par exemple, verrouillage en deux phases) pour appliquer les propriétés ACID. Ces mécanismes permettent de préserver l'intégrité des données pour chaque transaction.

Plus précisément : 

  • MySQL: Utilise le moteur de stockage InnoDB, qui prend en charge les transactions conformes à la norme ACID. Il gère l'atomicité et la durabilité par l'intermédiaire d'un journal de réécriture qui peut annuler les transactions qui ont échoué et récupérer celles qui ont été validées.
  • PostgreSQL : Exploite le protocole WAL (Write-Ahead Logging) pour garantir la durabilité et la cohérence en enregistrant les modifications dans un journal avant de les appliquer à la base de données.
  • Oracle : Il utilise des segments de retour en arrière et des journaux d'annulation pour garantir l'atomicité et la durabilité, ce qui permet un contrôle solide des transactions.

Vous travaillez avec SQL Server ? Ce cours sur les transactions et la gestion des erreurs dans SQL Server est un excellent moyen de maîtriser le contrôle des transactions et de garantir l'intégrité des données.

Exemple de transaction SQL avec conformité ACID

Voici un exemple SQL simple d'une transaction dans PostgreSQL qui adhère aux principes ACID. 

Cet exemple montre comment transférer de l'argent entre deux comptes afin de s'assurer que la transaction est entièrement terminée ou qu'elle est entièrement annulée en cas d'échec : 

BEGIN;

-- Step 1: Debit $500 from Account A
UPDATE accounts 
SET balance = balance - 500 
WHERE account_id = 'A';

-- Step 2: Credit $500 to Account B
UPDATE accounts 
SET balance = balance + 500 
WHERE account_id = 'B';

-- Commit the transaction if both steps succeed
COMMIT;

-- Rollback the transaction if an error occurs
ROLLBACK;

Dans cette transaction :

  • Si l'une des mises à jour échoue, la transaction est annulée.
  • La base de données reste valide, car le solde total des deux comptes est inchangé.
  • Si une autre transaction tente de modifier ces comptes simultanément, le verrouillage garantit que l'une se termine avant l'autre.
  • Une fois la transaction validée, les modifications sont enregistrées de manière permanente, même si le système se bloque par la suite.

Si vous débutez avec SQL, ce cours d' introduction à SQL vous aidera à comprendre les principes fondamentaux et à commencer à écrire des requêtes en toute confiance.

ACID vs. Transactions BASE dans les bases de données NoSQL

Si les transactions ACID ont longtemps constitué la norme de référence pour garantir l'intégrité des données dans les bases de données relationnelles, les bases de données NoSQL privilégient souvent la flexibilité et l'évolutivité plutôt que la stricte cohérence transactionnelle. Cette évolution a conduit à l'adoption de BASE comme alternative à ACID dans certains cas d'utilisation. 

Examinons BASE, ses différences avec ACID et les cas où chaque approche est préférable.

Qu'est-ce que BASE ?

BASE est un acronyme pour Basically Available, Soft state, Eventual consistency. Il définit un ensemble de propriétés conçues pour les bases de données NoSQL, privilégiant la disponibilité et la flexibilité à la stricte cohérence.

Définissons les principes :

  • En principe disponible : Le système garantit la disponibilité, ce qui signifie qu'il répondra aux demandes même si certaines parties du système sont en panne ou inaccessibles.
  • État mou : En raison des mises à jour asynchrones, l'état du système peut changer au fil du temps, même en l'absence de données.
  • Cohérence à terme : Les données finiront par devenir cohérentes, mais il peut y avoir des périodes où elles sont temporairement incohérentes.

Différences entre ACID et BASE

Les principales différences entre ACID et BASE concernent les compromis faits en termes de cohérence, de disponibilité et de performance :

Cohérence

ACID garantit que la base de données est toujours cohérente après une transaction, avec des règles strictes pour maintenir l'intégrité des données. D'autre part, BASE sacrifie la cohérence stricte en faveur de la disponibilité et de la performance. Cela permet des incohérences temporaires jusqu'à ce que le système atteigne un état cohérent.

Disponibilité

Les systèmes ACID privilégient la cohérence et la durabilité par rapport à la disponibilité, de sorte qu'ils peuvent devenir indisponibles en cas de défaillance. Les systèmes BASE sont conçus pour une haute disponibilité. Cela garantit que le système reste réactif même en cas de partitions ou de pannes du réseau.

Évolutivité

Les systèmes ACID peuvent être confrontés à des difficultés lors de l'extension horizontale des systèmes distribués, car le maintien d'une cohérence stricte peut nécessiter beaucoup de ressources. Les systèmes BASE sont plus évolutifs et sont souvent conçus pour s'adapter horizontalement afin de gérer de grands volumes de données et de trafic, en accordant moins d'importance à la cohérence immédiate.

Cas d'utilisation pour ACID et BASE

Les transactions ACID sont idéales lorsque la cohérence des données est essentielle, par exemple :

  • Transactions financières : L'exactitude et la cohérence sont essentielles lorsque vous transférez de l'argent ou traitez des paiements.
  • Systèmes d'inventaire : Il est essentiel de veiller à ce que les niveaux de stock soient mis à jour avec précision afin d'éviter les surventes ou les divergences.
  • Traitement des commandes : Pour satisfaire les clients dans le cadre du commerce électronique, les commandes doivent être traitées correctement et de manière cohérente.

Les transactions BASE sont privilégiées lorsque l'évolutivité, la haute disponibilité et les performances l'emportent sur la nécessité d'une cohérence stricte, par exemple :

  • Flux de médias sociaux : La cohérence des données est moins critique et des incohérences temporaires dans les messages ou les mentions "J'aime" sont acceptables tant que le système reste réactif.
  • Réseaux de diffusion de contenu : Servir le contenu aux utilisateurs avec un temps de latence minimal est une priorité par rapport à la cohérence. 

ACIDE vs BASE : Un tableau comparatif

Fonctionnalité

ACID

BASE

Formulaire complet

Atomicité, cohérence, isolement, durabilité

Disponible à la base, État mou, Éventuellement cohérent

Principe de base

Garantit des transactions fiables et cohérentes

Priorité à la disponibilité et à la performance plutôt qu'à une cohérence stricte

Modèle de cohérence

Cohérence stricte

Cohérence à terme

Intégrité des données

Élevé - Garantit l'intégrité des données à tout moment

Plus bas - Permet des incohérences temporaires

Traitement des transactions

Les transactions doivent être achevées entièrement ou pas du tout

Transactions au mieux - peuvent être incomplètes ou incohérentes temporairement

Évolutivité

Limité - Fonctionne mieux avec des bases de données relationnelles monolithiques ou traditionnelles.

Élevé - Conçu pour les systèmes distribués et évolutifs

Temps de latence

Plus élevé - En raison d'exigences strictes en matière de cohérence

Plus bas - Permet des temps de réponse plus rapides

Cas d'utilisation

Transactions financières, gestion des stocks, traitement des commandes

Plateformes de médias sociaux, analyse en temps réel, réseaux de diffusion de contenu

Si vous êtes curieux de savoir comment les principes de BASE s'appliquent aux bases de données NoSQL, consultez ce cours NoSQL Concepts - c'est un excellent point de départ pour comprendre les compromis.

Problèmes courants liés aux transactions ACID

La mise en œuvre de transactions ACID n'est pas sans poser de problèmes. Ces défis sont particulièrement évidents dans les environnements où les transactions sont nombreuses, dans les systèmes distribués et lors de la gestion de transactions simultanées. 

Dans cette section, nous allons nous pencher sur les principaux problèmes rencontrés lors de l'utilisation de transactions ACID.

Coûts de performance des transactions ACID

L'un des principaux compromis lors de l'utilisation de transactions ACID est la performance. Garantir l'atomicité, la cohérence et la durabilité a un coût, en particulier lorsque la base de données gère des volumes de transactions élevés. 

Les exigences liées à l'entretien de ces propriétés peuvent ralentir les opérations de la manière suivante :

  • L'atomicité exige que toutes les étapes d'une transaction soient exécutées comme une seule unité, ce qui signifie que le système doit garantir que si une partie de la transaction échoue, l'ensemble de la transaction est annulée. Ce processus de retour en arrière peut être gourmand en ressources.
  • La cohérence exige que les transactions amènent toujours la base de données à un état valide, ce qui implique souvent de vérifier les contraintes, les déclencheurs et les règles de gestion. Ces contrôles supplémentaires peuvent augmenter le temps de traitement de chaque transaction.
  • La durabilité garantit que les modifications sont sauvegardées de manière permanente une fois qu'une transaction est validée, ce qui nécessite souvent des écritures à plusieurs endroits, notamment dans les journaux de transactions et sur le disque. Ce processus de stockage persistant peut ralentir le débit global du système.

Au fur et à mesure que le volume des transactions augmente, ces processus peuvent entraîner des goulets d'étranglement qui limitent l'évolutivité et la réactivité du système.

Difficulté à faire évoluer les bases de données conformes à la norme ACID dans les systèmes distribués

Les principes ACID sont traditionnellement conçus pour des systèmes centralisés ou à nœud unique, où l'intégrité des données et la cohérence transactionnelle sont plus faciles à gérer. Toutefois, à mesure que les bases de données prennent de l'ampleur, en particulier dans les clusters géographiquement distribués, le maintien des propriétés ACID devient plus complexe.

  • Transactions distribuées : Dans un environnement distribué, les transactions peuvent s'étendre sur plusieurs nœuds ou sites. Il peut être difficile de s'assurer que tous les nœuds participants sont d'accord sur le résultat d'une transaction, en particulier en cas de latence ou de partition du réseau. Des techniques telles que le protocole de validation en deux phases sont souvent utilisées, mais elles peuvent entraîner une surcharge et une complexité accrues.
  • Réplication des données : Les bases de données conformes à la norme ACID répliquent souvent les données sur plusieurs serveurs afin d'en assurer la pérennité. Cependant, la synchronisation de ces données et la garantie de la cohérence de toutes les répliques peuvent s'avérer lentes et gourmandes en ressources. Les retards de réseau et les pannes de serveur peuvent encore compliquer la cohérence des données répliquées.

La mise à l'échelle des bases de données conformes à la norme ACID nécessite une gestion minutieuse de la cohérence et de la durabilité sur tous les nœuds, ce qui est problématique (en particulier pour les systèmes hautement dynamiques ou distribués à l'échelle mondiale).

Gérer les transactions simultanées tout en préservant l'isolation

Les transactions simultanées constituent un autre défi pour les bases de données conformes à la norme ACID dans les environnements multi-utilisateurs. L'isolation garantit que les transactions concurrentes n'interfèrent pas les unes avec les autres, mais cela nécessite des mécanismes de gestion et de contrôle de l'accès aux données. 

La méthode la plus courante pour gérer la concurrence consiste à utiliser des mécanismes de verrouillage, mais ceux-ci posent leurs propres problèmes :

  • Verrouillage : Les bases de données utilisent des verrous (par exemple, des verrous au niveau des lignes et des tableaux) pour empêcher des transactions conflictuelles d'accéder simultanément aux mêmes données. Le verrouillage garantit l'isolation mais peut entraîner des blocages, lorsque deux transactions ou plus attendent que l'autre libère les verrous.
  • Contrainte de verrouillage : Des niveaux élevés de concurrence peuvent entraîner une contention des verrous, où les transactions se bloquent fréquemment les unes les autres, ce qui ralentit le système dans son ensemble. Lorsque le nombre de transactions augmente, la gestion des verrous devient plus complexe et peut avoir un impact négatif sur les performances.
  • Annulation de la transaction : Si une impasse se produit ou si un conflit est détecté, l'une des transactions peut devoir être annulée, ce qui entraîne un gaspillage de ressources et une réduction du débit.

Bonnes pratiques pour travailler avec des transactions ACID

L'application des meilleures pratiques peut considérablement améliorer la longévité de votre système dans les systèmes à haut volume ou les environnements complexes. 

Voici quelques pratiques clés pour travailler efficacement avec des transactions ACID.

Mettre en œuvre une gestion adéquate des transactions

L'une des meilleures pratiques les plus importantes consiste à ne mettre en œuvre des transactions que lorsque cela est nécessaire. Oui, les propriétés ACID sont essentielles pour les opérations qui requièrent l'intégrité des données, mais l'utilisation de transactions pour chaque opération de base de données peut entraîner des frais généraux inutiles et des goulets d'étranglement au niveau des performances.

  • Réduire l'étendue de la transaction : Limitez le champ d'application de chaque transaction aux opérations critiques qui requièrent absolument l'atomicité et la cohérence. Évitez d'inclure des opérations en lecture seule inutiles.
  • Utilisez des transactions plus petites : Si possible, divisez les opérations complexes et de grande envergure en transactions plus petites. Cela peut réduire la quantité de travail effectuée par transaction. 
  • Engagez-vous ou revenez en arrière rapidement : Veillez toujours à ce que les transactions soient validées ou annulées dès que possible afin de libérer des ressources et d'éviter les blocages de longue durée.

Il s'agit essentiellement de se concentrer sur les opérations critiques. Cela permet de garantir l'intégrité de votre base de données sans entraîner de frais généraux excessifs.

Optimiser la concurrence

L'optimisation de la configuration des bases de données et l'application de contrôles de concurrence sont essentielles pour maintenir les performances tout en garantissant que plusieurs transactions peuvent être exécutées simultanément sans compromettre la propriété d'isolation.

  • Niveaux d'isolation des transactions : Choisissez le niveau d'isolation approprié en fonction des besoins de votre application. Par exemple, READ COMMITTED convient à de nombreuses applications, mais SERIALIZABLE peut être nécessaire pour des scénarios où une isolation stricte est requise. Sachez que des niveaux d'isolation plus élevés peuvent augmenter la contention et réduire le débit.
  • Mécanismes de verrouillage : Configurer correctement les mécanismes de verrouillage pour garantir l'intégrité des données tout en permettant des niveaux élevés de concurrence. Par exemple, le verrouillage au niveau des lignes (au lieu du verrouillage au niveau des tableaux) permet d'éviter les goulets d'étranglement lorsque plusieurs transactions tentent d'accéder aux mêmes données.
  • Contrôle optimiste de la concurrence : Dans certains cas, vous pouvez mettre en œuvre un contrôle optimiste de la concurrence afin d'éviter tout verrouillage. Cette approche suppose que les conflits seront rares et ne valide les données qu'au moment de la validation, ce qui peut s'avérer plus efficace que le verrouillage des enregistrements pendant la transaction.

L'optimisation de la concurrence protège votre système et lui permet de rester réactif (même lorsque vous traitez des transactions simultanées). 

Contrôler et enregistrer les transactions

La surveillance et l'enregistrement doivent être effectués pour vous tenir informé de la santé et de l'efficacité de votre système de base de données.

  • Contrôler les performances des transactions : Utilisez des outils pour suivre les performances des transactions en temps réel. Recherchez des requêtes lentes, des blocages excessifs ou des retours en arrière fréquents, qui pourraient indiquer des problèmes de gestion des transactions ou de configuration de la base de données.
  • Enregistrez les erreurs et les exceptions : Veillez à ce que tous les échecs, retours en arrière et conflits de transactions soient enregistrés pour une analyse ultérieure. Cela permet d'identifier les problèmes récurrents, de les résoudre et d'apporter des améliorations.
  • Analyser le débit des transactions : Coulez le nombre de transactions en cours de traitement et évaluez si le système gère efficacement la charge. Si le nombre de transactions dépasse la capacité du système, il se peut que vous deviez optimiser votre configuration ou répartir la charge de manière plus homogène.

Une surveillance et un enregistrement efficaces vous permettent de gérer votre base de données de manière proactive. Plus vous en savez sur votre système de base de données, plus vous pouvez le mettre à jour pour qu'il continue à répondre aux exigences de votre application.

Conclusion

Dans cet article, nous avons exploré les principes essentiels des transactions ACID. Nous avons examiné l'importance de ces propriétés dans des scénarios tels que les transactions financières, les commandes de commerce électronique et les systèmes d'inventaire, et nous avons montré comment elles sont mises en œuvre dans les bases de données SQL les plus courantes.

En outre, nous avons examiné les différences entre les transactions ACID et BASE, les défis posés par la mise à l'échelle des systèmes conformes à l'ACID et les meilleures pratiques pour gérer efficacement les transactions.

Si vous souhaitez approfondir le fonctionnement des transactions ACID dans PostgreSQL, je vous recommande vivement ce cours sur les transactions et la gestion des erreurs dans PostgreSQL.

Devenez ingénieur en données

Faites la preuve de vos compétences en tant qu'ingénieur en données prêt à l'emploi.
Accélérer ma carrière dans les données

FAQ

Comment les transactions ACID fonctionnent-elles dans les bases de données distribuées ?

Dans les bases de données distribuées, il peut s'avérer difficile de respecter strictement la norme ACID en raison des retards du réseau et des problèmes de partitionnement. Des technologies telles que Two-Phase Commit (2PC) et Three-Phase Commit (3PC) permettent de coordonner les transactions entre plusieurs nœuds, garantissant ainsi la cohérence. Cependant, elles introduisent des temps de latence et des goulets d'étranglement potentiels, ce qui explique pourquoi certaines bases de données distribuées préfèrent BASE à ACID. Les approches plus récentes, comme Spanner et CockroachDB de Google, utilisent des protocoles de consensus distribués tels que Paxos ou Raft pour maintenir une forte cohérence tout en s'adaptant à l'échelle mondiale.

Les transactions ACID peuvent-elles être optimisées en termes de performances ?

Oui, les optimisations de performance pour les transactions ACID comprennent :

  • Opérations de mise en lots : Le regroupement de plusieurs écritures en une seule transaction réduit les frais généraux.
  • Utiliser efficacement les index : L'optimisation des requêtes grâce à une indexation appropriée permet de réduire la durée des transactions.
  • Contrôle optimiste de la concurrence : Réduit la contention des verrous en supposant que les transactions n'entreront pas en conflit et en validant au moment de la validation.
  • Réglage des niveaux d'isolation : Des niveaux d'isolation inférieurs (par exemple, Read Committed au lieu de Serializable) peuvent améliorer les performances tout en équilibrant les besoins de cohérence.

Quelle est la différence entre les transactions ACID et les opérations idempotentes ?

Les transactions ACID garantissent que chaque transaction est exécutée exactement une fois et entièrement terminée (ou entièrement annulée). En revanche, les opérations idempotentes garantissent que des exécutions répétées produisent le même résultat sans effets secondaires imprévus. Par exemple, la mise à jour d'un enregistrement (UPDATE users SET balance = 100 WHERE id = 1) est idempotente, mais l'incrémentation d'un solde (UPDATE users SET balance = balance + 100 WHERE id = 1) ne l'est pas, à moins qu'elle ne soit intégrée dans une transaction ACID pour éviter les conditions de concurrence.

Comment les bases de données modernes équilibrent-elles les principes ACID et BASE ?

De nombreuses bases de données modernes mettent en œuvre une approche hybride, offrant une cohérence forte là où elle est nécessaire et une cohérence éventuelle là où l'évolutivité est prioritaire.

  • Les bases de données NewSQL telles que Google Spanner, CockroachDB et YugabyteDB utilisent des architectures distribuées tout en maintenant la conformité ACID.
  • MongoDB et Cassandra suivent principalement BASE mais offrent un support transactionnel pour les opérations multi-documents.
  • Les bases de données telles que PostgreSQL prennent en charge la réplication logique et les configurations multi-maîtres pour offrir une haute disponibilité sans sacrifier totalement les garanties ACID.

Quels sont les compromis entre les transactions ACID et les architectures événementielles ?

Dans les architectures pilotées par les événements, les microservices communiquent souvent par l'intermédiaire de journaux d'événements (par exemple, Kafka) plutôt que par des transactions ACID strictes. Les compromis sont les suivants :

  • Évolutivité : Les systèmes événementiels s'adaptent horizontalement, tandis que les transactions ACID introduisent des problèmes de contention et de verrouillage.
  • Cohérence : ACID garantit une cohérence forte, tandis que les systèmes pilotés par les événements favorisent une cohérence éventuelle.
  • La complexité : Les architectures événementielles exigent l'idempotence, la déduplication des messages et le traitement "exactly-once" pour éviter les problèmes que les transactions ACID gèrent naturellement.
  • La résilience : ACID garantit la durabilité grâce aux journaux transactionnels, tandis que les systèmes axés sur les événements maintiennent la fiabilité grâce à des mécanismes tels que l'approvisionnement en événements et les modèles de saga.
Kurtis Pykes 's photo
Author
Kurtis Pykes
LinkedIn
Sujets
Ingénierie des données
SQL

Apprenez-en plus sur l'ingénierie des données et les bases de données grâce à ces cours !

Certification disponible

cours

Introduction à l'ingénierie des données

4 hr
116.7K
Découvrez le monde de l'ingénierie des données dans ce cours de courte durée, couvrant des outils et des sujets tels que l'ETL et le cloud computing.
Afficher les détailsRight Arrow
Commencer le cours
Voir plusRight Arrow