L'utilisation d'applications en temps réel et d'appareils de l'Internet des objets (IoT), ainsi que la croissance exponentielle des actifs de données non structurées, font que les organisations 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 (SGBD) à gérer efficacement des ensembles de données volumineux et diversifiés, ainsi que l'analyse big data qui en découle. Cependant, nombreux sont ceux qui 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 SGBD NoSQL.
Table des matières
- Que sont les transactions 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 multidocuments MongoDB ?
- Quelles sont les meilleures pratiques pour les transactions dans MongoDB ?
- Prochaines étapes
- FAQ
Qu'est-ce qu'une transaction ACID ?
Transactions expliqué
À 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 incluent 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é (ACID). 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 de documents 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 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 replica sets 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 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 SGBD 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 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 préoccupation de lecture au niveau de la transaction. et une préoccupation d'écriture au niveau de la transaction. Les clients peuvent définir un niveau approprié de préoccupation en lecture et en écriture, le plus rigoureux étant une préoccupation en lecture instantanée combinée à une préoccupation en écriture majoritaire. Le souci de l'é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 la durabilité :
MongoDB crée un OpLog 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, l'OpLog 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 le SGBD
À 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 multi-documents ACID
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.
Le diagramme montre l'impact des propriétés ACID sur le flux de transfert d'argent d'un compte bancaire à un autre.
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.
Impacts à 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 façon d’implémenter des transactions, consultez les Démarrages rapides sur le Centre développeur MongoDB :
- Transactions ACID multi-documents dans MongoDB avec Golang
- Transactions ACID multi-documents dans MongoDB avec Java
- Transactions ACID multi-documents dans MongoDB avec Node.js
- Transactions ACID multi-documents dans MongoDB avec Python
Consultez 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 pouvant bénéficier 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).
La chaîne d'approvisionnement et les systèmes 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 problèmes de lecture et d'écriture appropriés sont configurés (notez qu'à partir de la version 5.0, MongoDB utilise par défaut le souci d'écriture majoritaire nécessaire).
Ajoutez une gestion appropriée des erreurs et réessayer 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.
Prochaines étapes
Prêt à en savoir plus ? MongoDB Atlas est la base de données entièrement gérée en tant que service de MongoDB et c'est le moyen le plus simple de se lancer dans l'aventure MongoDB. Commencez par les transactions en créant un cluster MongoDB Atlas gratuit.