Un guide des propriétés ACID dans les systèmes de gestion de bases de données
L’utilisation d’applications en temps réel et d'appareils de l’Internet des objets (IdO), ainsi que la croissance exponentielle des ressources de données non structurées, font que les entreprises sont de plus en plus nombreuses à passer aux bases de données NoSQL. En fait, le marché NoSQL devrait atteindre 74,5 milliards de dollars américains d’ici 2032, avec un taux de croissance (CAGR) de 24,9 % entre 2024 et 2032 (IMARC group, 2024).
Cette croissance n’est pas surprenante étant donné la capacité des systèmes de gestion de bases de données NoSQL à gérer efficacement des ensembles de données volumineux et diversifiés, ainsi que l’analyse des « big data » qui en découle.
Cependant, beaucoup pensent encore que les SGBD NoSQL ne sont pas en mesure de répondre à une exigence clé de nombreuses organisations : la gestion et la conformité des transactions ACID. La bonne nouvelle est que certains SGBD NoSQL le peuvent !
Dans cet article, nous verrons ce que sont les transactions ACID, leurs propriétés, pourquoi ces transactions sont importantes, et un exemple de transaction ACID dans un système de gestion de base de données NoSQL.
Sommaire
- Brève histoire des transactions ACID
- Qu’est-ce qu’une transaction ACID ?
- Pourquoi les transactions ACID sont-elles importantes ?
- Exemple de transactions ACID dans un SGBD
- Comment fonctionnent les transactions ACID dans MongoDB ?
- Quand dois-je utiliser les transactions multi-documents MongoDB ?
- Quelles sont les meilleures pratiques pour les transactions dans MongoDB ?
- FAQ
Brève histoire des transactions ACID
Le concept de transactions ACID occupe une place centrale dans l’évolution des systèmes de bases de données modernes depuis la fin des années 1970.
À mesure que les entreprises et les établissements de recherche ont commencé à s’appuyer davantage sur les données numériques, le besoin de moyens fiables pour traiter des opérations complexes sur plusieurs enregistrements est devenu évident. Les premières bases de données relationnelles telles que le système R d’IBM et Oracle ont été parmi les premières à expérimenter l’application de garanties plus strictes en matière d’intégrité des données et de fiabilité des transactions.
En 1983, les informaticiens Andreas Reuter et Theo Härder ont formellement défini les quatre propriétés ACID (l'atomicité, la cohérence, l'isolation et la durabilité) dans un article de référence. Leurs travaux ont offert à la communauté des bases de données un langage commun pour décrire les exigences relatives à des transactions de base de données fiables. Chaque propriété visait à répondre à un défi spécifique afin de garantir que les données restent valides et soient traitées de manière fiable, même en cas de défaillance :
- L’atomicité garantit que plusieurs opérations au sein d’une transaction agissent comme une seule unité : soit toutes réussissent, soit toutes échouent.
- La cohérence garantit que la base de données reste dans un état valide qui respecte les règles et les contraintes définies.
- L'isolation empêche les transactions simultanées d'interférer les unes avec les autres.
- La durabilité permet de s'assurer qu'une fois la transaction validée, les résultats sont permanents, même après des défaillances du système.
Ce cadre est devenu la référence en matière de systèmes de gestion de bases de données relationnelles, surtout lorsque les entreprises les ont adoptés pour le secteur bancaire, le commerce de détail et les télécommunications, des secteurs où les transactions financières et la conformité réglementaire exigent une précision absolue.
Tout au long des années 1990 et au début des années 2000, les bases de données relationnelles comme Oracle, IBM DB2 et Microsoft SQL Server ont continué d’affiner la manière dont les garanties ACID étaient mises en œuvre, en utilisant souvent des techniques telles que la journalisation en amont, les verrous et le contrôle d’accès simultané multi-version.
Ces méthodes ont permis aux organisations de traiter des millions d’opérations de base de données tout en maintenant une cohérence stricte.
Avec l’essor des bases de données NoSQL dans les années 2010, certains se sont demandé si les garanties ACID pouvaient être préservées dans des systèmes conçus pour l’évolutivité horizontale et la haute disponibilité. Les premières plate-formes NoSQL ont souvent assoupli la cohérence au profit des performances et de la disponibilité, laissant penser que la conformité ACID et l’évolutivité NoSQL étaient mutuellement exclusives.
Cependant, à mesure que la demande d’intégrité des données dans les systèmes distribués augmentait, des fournisseurs comme MongoDB ont prouvé qu’il était possible de supporter les transactions multi-documents tout en assurant la mise à l’échelle sur plusieurs nœuds.
Aujourd'hui, les transactions ACID restent plus que jamais d'actualité. Elles constituent la base du maintien de l'intégrité des données dans les secteurs où les erreurs sont inacceptables, des virements bancaires aux dossiers de santé.
Dans le même temps, des plateformes modernes comme MongoDB ont étendu les garanties ACID à des données flexibles et non structurées, ainsi qu'à des opérations complexes réalisées sur des clusters distribués. Cette association de fiabilité et d'évolutivité garantit que les principes ACID, définis il y a plus de 40 ans, continuent de définir l'avenir de la gestion de base de données.
Qu’est-ce qu’une transaction ACID ?
Les transactions expliquées
À leur niveau le plus élémentaire, les transactions de base de données sont un groupe d'opérations de lecture et d'écriture de base de données qui ont été effectuées avec succès conformément aux définitions du SGBD (par exemple, des critères de transaction définis). Il existe deux principaux types de transactions :
- Transactions uniques : une transaction unique fait référence à une série d'une ou de plusieurs opérations sur la base de données qui se traduisent par une action, menée à bien. Une fois terminée, la transaction est acceptée et peut être retrouvée dans un journal des transactions. Un exemple courant de transaction unique est le retrait d’argent à un distributeur automatique de billets.
- Multi-transactions : une multi-transaction, parfois appelée transaction distribuée, se compose de plusieurs transactions interdépendantes réparties sur différentes bases de données et systèmes (par exemple, des systèmes distribués). Les enregistrements de ces transactions se trouvent également dans un journal des transactions. Un exemple de ces transactions est le transfert d'argent d'un compte à un autre ou la délivrance par un employeur à un nouvel employé d'un badge de sécurité avec photo.
Il est important de noter que certaines transactions doivent respecter des normes strictes en matière d'intégrité des données (par exemple, les données sont complètes et correctes) et de cohérence des données (par exemple, la valeur est la même dans toutes les tables/bases de données). C'est souvent le cas lorsqu'il s'agit de responsabilité fiduciaire ou de conformité réglementaire.
Les exemples comprennent les services bancaires commerciaux, le courtage en investissement et les règlements juridiques.
Dans ces situations, le respect standard des définitions du SGBD ne suffit pas, et des transactions ACID sont requises.
transactions ACID
ACID est un acronyme qui signifie atomicité, cohérence, isolation et durabilité. Ensemble, les propriétés ACID garantissent qu’un ensemble d’opérations de base de données (regroupées dans une transaction) laisse la base de données dans un état valide, même en cas d’erreurs inattendues.
De plus, les transactions ACID offrent le niveau de garanties transactionnelles exigé par de nombreux organismes de réglementation.
Vous trouverez ci-dessous une vue d’ensemble de chaque élément de transaction ACID, ainsi qu’une description de la façon dont une base de données documentaire NoSQL est capable de traiter cet élément ACID. Aux fins de cet article, MongoDB Atlas sera utilisé.
Atomicité
L’atomicité garantit que toutes les commandes qui composent une transaction sont traitées comme une seule unité et réussissent ou échouent ensemble. Ceci est important en cas de défaillance du système ou de panne de courant, car si une transaction n’a pas été complètement traitée, elle sera supprimée et la base de données conservera son intégrité des données.
Comment MongoDB gère-t-il l’atomicité ?
Dans MongoDB, une opération d’écriture est atomique au niveau d’un seul document, même si l’opération modifie plusieurs documents incorporés au sein d’un seul document.
Pour les situations qui nécessitent l’atomicité des lectures et des écritures dans plusieurs documents (dans une seule collection ou plusieurs collections), MongoDB prend en charge les transactions distribuées, y compris les transactions sur les jeux de répliques et les clusters partitionnés.
Cohérence
La cohérence garantit que les modifications apportées au sein d’une transaction sont renseignées dans l’ensemble du système de base de données (par exemple, les nœuds) et alignées sur les contraintes SGBD. Si la cohérence des données est affectée négativement par une transaction dans un état incohérent, l’intégralité de la transaction échouera.
Comment MongoDB gère-t-il la cohérence ?
MongoDB offre la possibilité de normaliser ou de dupliquer les données afin d’optimiser les applications. Si les données sont dupliquées dans le schéma, le développeur doit décider comment maintenir la cohérence des données dupliquées dans plusieurs collections. Certaines applications nécessitent que les données dupliquées soient immédiatement mises en cohérence, tandis que d’autres applications peuvent tolérer la lecture de données obsolètes. Voici quelques exemples :
Remarque : en savoir plus sur la cohérence des données.
Isolation
Chaque transaction est isolée des autres transactions pour éviter les conflits de données. Cela facilite également les opérations de base de données en ce qui concerne la gestion des entrées multiples et des transactions à plusieurs niveaux.
Par exemple, si deux utilisateurs tentent de modifier les mêmes données (ou même la même transaction), le système de gestion de base de données utilise un mécanisme appelé gestionnaire de verrouillage pour suspendre les autres utilisateurs jusqu’à ce que les modifications effectuées par le premier utilisateur soient terminées.
Comment MongoDB gère-t-il l’isolation ?
MongoDB utilise une technique appelée isolation par instantané (par exemple, chaque transaction semble opérer sur un instantané personnel de la base de données choisi au début de la transaction). Les transactions peuvent lire les données à partir de l’« instantané » des données validées au moment où la transaction commence, et toute mise à jour conflictuelle entraînera l’abandon de la transaction.
En outre, les transactions MongoDB prennent en charge une option générale d’écriture au niveau de la transaction. Les clients peuvent définir un niveau approprié d’option générale de lecture et d’écriture, la plus rigoureuse étant une option générale de lecture instantanée combinée à une option générale d’écriture majoritaire. L’option générale d’écriture majoritaire signifie que les opérations d’écriture ont été engagées durablement sur une majorité calculée de nœuds porteurs de données (configurable par le développeur).
Durabilité
La durabilité garantit qu’une fois la transaction terminée et les modifications écrites dans la base de données, elles sont conservées. Cela garantit que les données contenues dans le système seront conservées même en cas de défaillance du système, par exemple en cas de panne ou de coupure de courant. Le concept de durabilité est un élément clé de la fiabilité des données.
Comment MongoDB gère-t-il la durabilité ?
MongoDB crée un journal opérationnel contenant l’emplacement du disque et les octets modifiés pour chaque « écriture ». En cas d’évènement imprévu (par exemple, une panne de courant) pendant l’écriture de la transaction, le journal opérationnel peut être utilisé lorsque le système redémarre pour rejouer toutes les écritures qui n’ont pas été transférées sur le disque avant l’interruption.
En outre, les opérations sont modifiées avant d'être écrites dans l'OpLog, de sorte qu'elles sont idempotentes et peuvent être répétées plusieurs fois. Par défaut, les transactions, ou « écritures », sont transférées sur le disque environ toutes les 60 secondes par défaut.
Pourquoi les transactions ACID sont-elles importantes ?
Les transactions ACID contribuent à maintenir l'intégrité et la fiabilité des données, tout en garantissant que les données vitales soumises à une réglementation gouvernementale ou sectorielle (compte bancaire, portefeuille d'actions, etc.) répondent aux normes requises. En outre, la conformité ACID est souvent une condition préalable à la mise en œuvre de la réplication des données et à l'obtention d'une haute disponibilité dans les systèmes de bases de données distribuées.
Exemple de transaction ACID dans un système de gestion de base de données
À l'aide de la base de données de documents NoSQL MongoDB Atlas, voici un exemple de la manière dont les transactions multi-documents ACID sont gérées et de la manière dont les transactions ACID garantissent l'alignement sur les normes minimales de propriété ACID.
Transactions ACID multi-documents
Imaginez que vous créez une fonction pour transférer de l’argent d’un compte bancaire à un autre où chaque compte est son propre enregistrement. Si l'argent est prélevé avec succès sur le compte source mais qu'il n'est jamais crédité sur le compte de destination, cela crée un grave problème de comptabilité. Inversement, si le compte de destination est crédité mais que le compte source n'est jamais débité, un autre problème majeur se pose.
Ces deux opérations d'écriture doivent être effectuées toutes les deux ou ne pas se produire toutes les deux pour assurer la cohérence du système et de ses données. En outre, cela signifie que si l'une des commandes de la transaction échoue, la base de données doit revenir en arrière (c'est-à-dire annuler) toutes les modifications qu'elle a écrites au cours de la transaction.
Note : Pour en savoir plus, consultez le référentiel GitHub de démarrage rapide Node.js pour obtenir une copie de l’exemple de code complet et l’exécuter vous-même.
Les conséquences à retenir
Lorsque vous gérez des transactions multi-documents dans un système distribué, n’oubliez pas que cela a un impact sur les performances qui peut affecter les contraintes de ressources et les objectifs de performance. En outre, étant donné que la base de données doit « verrouiller » les ressources concernées pour empêcher les écritures concurrentes d’interférer les unes avec les autres (par exemple, l’échec d’une transaction), d’autres clients essayant d’écrire des données peuvent être bloqués en attendant la fin de la transaction, ce qui peut avoir un impact sur la latence de l’application et sur l’expérience de l’utilisateur.
Comment fonctionnent les transactions ACID dans MongoDB ?
Le modèle de document de MongoDB permet de stocker des données connexes dans un seul document. Le document model, combiné à des mises à jour atomiques de documents, élimine le besoin de transactions dans la majorité des cas d’utilisation. Néanmoins, dans certains cas, de véritables transactions MongoDB multi-documents et multi-collections constituent le meilleur choix.
Les transactions MongoDB fonctionnent de la même manière que les transactions dans d'autres bases de données. Pour utiliser une transaction, démarrez une session MongoDB via un pilote. Utilisez ensuite cette session pour exécuter votre groupe d'opérations sur la base de données. Vous pouvez exécuter n'importe quelle opération CRUD (création, lecture, mise à jour et suppression) sur plusieurs documents, collections et ensembles.
Pour obtenir des exemples de code spécifiques sur la manière d’implémenter les transactions, consultez les démarrages rapides suivants :
- Transactions ACID multi-documents dans MongoDB avec Golang
- Transactions multi-documents ACID dans MongoDB avec Java
- Transactions ACID multi-documents dans MongoDB avec Node.js
- Transactions ACID multi-documents dans MongoDB avec Python
Visitez la documentation sur les pilotes MongoDB pour obtenir des guides spécifiques à chacune des langues officiellement prises en charge par MongoDB. Vous pouvez également consulter une liste des meilleures pratiques en matière de transactions et des considérations relatives à la production.
Quand dois-je utiliser les transactions multi-documents MongoDB ?
Les applications qui nécessitent des transactions ont généralement des cas d'utilisation où des valeurs sont échangées entre différentes parties. Il s’agit généralement d’applications de type « système d’enregistrement » ou « secteur d’activité ».
Voici quelques exemples d'applications qui peuvent tirer parti des transactions multi-documents :
- Systèmes qui transfèrent des fonds d'un compte à un autre (par exemple, applications bancaires, systèmes de traitement des paiements, plateformes de trading).
- Systèmes de chaîne d’approvisionnement et de réservation où la propriété des biens et des services est transférée d’une partie à l’autre.
- Systèmes de facturation qui stockent les informations dans des enregistrements détaillés ainsi que dans des enregistrements récapitulatifs.
Quelles sont les meilleures pratiques pour les transactions dans MongoDB ?
En général, il est recommandé de modéliser les données de manière à ce que les données auxquelles on accède ensemble soient stockées ensemble. Lorsque les données sont modélisées de cette manière, non seulement les performances sont meilleures, mais les transactions ne sont pas nécessaires.
Pour les applications qui nécessitent des transactions, respectez les bonnes pratiques suivantes :
- Divisez les transactions de longue durée en plusieurs parties afin qu'elles ne dépassent pas le délai par défaut de 60 secondes. (Notez que ce délai peut être prolongé.) Veillez à ce que les opérations effectuées dans les transactions utilisent des index afin qu'elles s'exécutent rapidement.
- Limitez chaque transaction à 1 000 modifications de documents.
- Assurez-vous que les préoccupations en matière de lecture et d'écriture appropriées sont configurées (notez qu'à partir de la version 5.0, MongoDB utilise par défaut la préoccupation en matière d'écriture majoritaire nécessaire).
- Ajoutez une gestion appropriée des erreurs et réessayez les transactions qui échouent en raison d’erreurs transitoires.
- Souvenez-vous du coût de performance des transactions affectant plusieurs fragments. Pour plus d'informations sur ces bonnes pratiques, consultez le livre blanc sur les transactions ACID multi-documents sur MongoDB ainsi que la documentation de MongoDB sur les transactions.