Qu'est-ce qu'une base de données transactionnelle ?

Une base de données transactionnelle est une base de données conçue pour gérer de grands volumes d'opérations courtes et en temps réel qui lisent et écrivent des données. Ces opérations représentent des interactions petites mais critiques qui alimentent l'activité commerciale quotidienne, telles que le traitement des commandes clients, la mise à jour d'un solde de compte, la soumission d'un paiement ou la modification d'un enregistrement client. Étant donné que chaque interaction modifie l'état du système, les bases de données transactionnelles sont conçues pour garantir que chaque mise à jour est précise, complète et enregistrée en toute sécurité.

Au cœur de cette fiabilité se trouve la conformité ACID, un ensemble de propriétés qui garantit que chaque transaction se comporte de manière prévisible, même lorsque de nombreux utilisateurs ou applications accèdent à la base de données en même temps. Cela fait des bases de données transactionnelles le fondement des charges de travail de traitement transactionnel en ligne (OLTP), où la vitesse, l'exactitude et la cohérence sont essentielles.

Les bases de données transactionnelles utilisent généralement un modèle de stockage orienté ligne, qui organise les données sous forme d'enregistrements complets. Cette disposition est optimisée pour les charges de travail qui insèrent, mettent à jour ou récupèrent fréquemment des lignes individuelles, permettant aux applications d'accéder aux données exactes dont elles ont besoin avec une surcharge minimale.

Ensemble, ces caractéristiques font des bases de données transactionnelles un choix fiable pour les systèmes qui doivent refléter l'état actuel de l'entreprise à tout moment. Elles prennent en charge tout, des achats au détail aux systèmes bancaires en passant par les applications opérationnelles qui dépendent de changements de données rapides, précis et cohérents.

Comment fonctionnent les bases de données transactionnelles

Le cycle de vie d'une transaction

Une transaction représente une unité logique de travail unique qui doit être traitée de manière fiable du début à la fin. Même lorsqu'une transaction contient plusieurs étapes, la base de données traite toute la séquence comme une seule opération. Le cycle de vie comprend généralement trois étapes :

1. Début : L'application signale qu'une nouvelle transaction commence.
2. Exécution des opérations : La transaction effectue une ou plusieurs instructions de modification de données telles que INSERT, UPDATE ou DELETE.
3. Validation ou annulation : Si toutes les opérations se terminent avec succès, la transaction est validée et les modifications deviennent permanentes. Si une étape échoue, la base de données annule toute la transaction pour revenir à son état précédent.

Ce comportement tout ou rien empêche les mises à jour partielles qui pourraient laisser les données incohérentes. Par exemple, un virement bancaire met à jour deux comptes ensemble dans le cadre d'une seule transaction. La base de données garantit que le système ne se retrouve jamais avec seulement la moitié du travail appliqué.

Stockage basé sur les lignes

Les bases de données transactionnelles utilisent généralement un modèle de stockage orienté ligne, où chaque ligne contient tous les champs d'un enregistrement unique. Cette disposition est optimisée pour les charges de travail qui lisent ou modifient fréquemment des enregistrements individuels, car la base de données peut récupérer ou mettre à jour la ligne entière en une seule opération.

Cette conception contraste avec le stockage en colonnes, qui organise les données par colonne et est optimisé pour les charges de travail analytiques qui scannent de grands volumes de données sur quelques attributs. Alors que les systèmes en colonnes excellent dans les agrégations et les requêtes à grande échelle, ils sont moins efficaces pour les opérations de lecture/écriture petites et fréquentes courantes dans les systèmes transactionnels.

Le stockage basé sur les lignes s'aligne naturellement avec les modèles OLTP. Par exemple, les applications doivent souvent récupérer ou mettre à jour rapidement un enregistrement complet, tel qu'une commande, un profil client ou un compte. En stockant les données sous forme de lignes complètes, les bases de données transactionnelles minimisent les E/S et offrent des performances rapides pour les opérations en temps réel.

Explication des propriétés ACID

Les bases de données transactionnelles reposent sur quatre garanties — atomicité, cohérence, isolation et durabilité — collectivement appelées les propriétés ACID. Ces garanties garantissent que chaque transaction est traitée de manière sûre et prévisible, même en cas de forte concurrence ou de défaillances du système.

Atomicité

L'atomicité garantit qu'une transaction est traitée comme une unité de travail unique et indivisible. Même si une transaction contient plusieurs étapes, la base de données doit appliquer toutes ces étapes ou aucune d'entre elles. Il n'y a aucun scénario où certains changements réussissent tandis que d'autres échouent. Si une opération au sein de la transaction rencontre une erreur, la base de données annule l'ensemble des modifications pour maintenir un état cohérent.

Par exemple, la création d'une commande et la mise à jour des stocks doivent se faire ensemble. Le système ne devrait jamais enregistrer la commande sans en réduire également le nombre d'articles.

Cohérence

La cohérence garantit que chaque transaction fait passer la base de données d'un état valide à un autre. Toutes les règles, contraintes et exigences d'intégrité des données doivent être satisfaites avant qu'une transaction puisse être validée. Si une transaction viole une contrainte, telle que l'insertion d'une clé primaire dupliquée ou la rupture d'une relation de clé étrangère, la base de données rejette la transaction et annule les modifications.

Cela garantit que la base de données reflète toujours des données conformes à sa structure définie et à ses règles métier. Aucune transaction n'est autorisée à introduire des informations invalides ou contradictoires.

Isolation

L'isolation garantit que les transactions concurrentes ne s'interfèrent pas mutuellement. Chaque transaction doit se comporter comme si elle s'exécutait seule, même lorsque de nombreuses transactions s'exécutent en même temps. Les modifications non validées effectuées par une transaction doivent rester invisibles pour les autres jusqu'à ce que la transaction soit validée.

Cela évite des problèmes tels que les lectures sales, les mises à jour perdues ou les états intermédiaires incohérents. Différentes bases de données implémentent l'isolation par divers mécanismes et niveaux d'isolation, mais l'idée principale reste la même : l'activité concurrente ne doit pas compromettre l'exactitude.

Durabilité

La durabilité garantit qu'une fois qu'une transaction est validée, ses modifications sont permanentes. Les données doivent persister même en cas de défaillances du système, de coupures de courant ou de plantages. Les bases de données obtiennent la durabilité grâce à des techniques telles que la journalisation anticipée (write-ahead logging), les points de contrôle et le stockage redondant. Une fois qu'une transaction est confirmée comme validée, le système garantit que ses effets survivront à toute défaillance ultérieure.

Contrôle de concurrence et récupération

Les bases de données transactionnelles doivent gérer de nombreuses opérations simultanées tout en protégeant les données contre la corruption ou la perte. Le contrôle de concurrence garantit que les lectures et écritures simultanées ne s'interfèrent pas, et les mécanismes de récupération garantissent que les données restent intactes même en cas de défaillance du système. Ensemble, cela permet aux applications à fort trafic de fonctionner en toute sécurité dans des conditions réelles.

Gestion de l'accès concurrentiel

Lorsque plusieurs utilisateurs ou processus interagissent avec la base de données en même temps, celle-ci ne doit pas permettre à leurs opérations d'entrer en conflit. Les bases de données utilisent des stratégies de verrouillage et des niveaux d'isolation pour coordonner l'accès aux données partagées. Les verrous garantissent qu'une seule transaction peut modifier une donnée à la fois, tandis que les niveaux d'isolation déterminent la visibilité des modifications non validées pour les autres transactions.

Sans ces contrôles, plusieurs problèmes peuvent survenir. Une lecture sale se produit lorsqu'une transaction voit des données non validées d'une autre transaction. Une mise à jour perdue se produit lorsque deux transactions écrasent les modifications l'une de l'autre. Une lecture fantôme apparaît lorsque de nouvelles lignes sont insérées ou supprimées par une autre transaction pendant une requête, provoquant des résultats qui changent de manière inattendue.

En pratique, le contrôle de concurrence est ce qui empêche une caisse d'e-commerce à fort trafic de facturer deux fois un client ou empêche une application bancaire d'afficher des soldes de compte incohérents. En coordonnant l'accès aux données partagées, la base de données garantit que chaque transaction se comporte de manière prévisible, même sous une forte charge.

Récupération après incident

Même les systèmes bien conçus peuvent subir des défaillances, c'est pourquoi les bases de données transactionnelles incluent des mécanismes pour restaurer un état cohérent après un incident. L'approche la plus courante est la journalisation anticipée (WAL), où chaque modification est enregistrée dans un journal avant d'être appliquée à la base de données. Cela garantit que le système dispose toujours d'un enregistrement fiable de ce qui était censé se produire.

En cas de défaillance, la base de données rejoue le journal pour récupérer les transactions validées et annule celles qui étaient incomplètes. Ce processus garantit que la base de données ne reflète que les modifications valides et entièrement traitées.

La durabilité dépend du bon fonctionnement de ces mécanismes de récupération. En combinant WAL, les journaux de transactions et une logique de rejeu soignée, la base de données garantit que les données validées persistent même en cas d'interruptions imprévues.

Base de données transactionnelle vs. Base de données analytique

Les bases de données transactionnelles et analytiques sont conçues pour des charges de travail fondamentalement différentes. Les systèmes transactionnels se concentrent sur des mises à jour rapides et fiables des enregistrements individuels, tandis que les systèmes analytiques se concentrent sur des requêtes à grande échelle qui scannent et agrègent les données. Comprendre les différences entre ces systèmes permet de clarifier pourquoi la plupart des organisations utilisent les deux : l'un pour capturer l'activité en temps réel et l'autre pour analyser les tendances au fil du temps.

Bases de données transactionnelles

Les bases de données transactionnelles prennent en charge de nombreuses opérations de lecture/écriture courtes et en temps réel. Elles sont optimisées pour un accès à faible latence aux enregistrements individuels, ce qui les rend idéales pour les applications qui doivent refléter l'état actuel de l'entreprise à tout moment. Les systèmes OLTP utilisent généralement un stockage orienté ligne, ce qui permet à la base de données de récupérer ou de mettre à jour efficacement un enregistrement complet.

Ces systèmes privilégient la vélocité des données. Ainsi, ils excellent à capturer et appliquer les changements aussi rapidement et en toute sécurité que possible. Les exemples incluent le traitement des commandes, les mises à jour des stocks, les modifications de profils utilisateurs et les transactions financières.

Bases de données analytiques

Les bases de données analytiques sont conçues pour un nombre limité de requêtes complexes qui portent sur de grands ensembles de données. Au lieu de se concentrer sur des enregistrements individuels, les systèmes de traitement analytique en ligne (OLAP) prennent en charge les agrégations, l'analyse des tendances et les rapports historiques. Ils utilisent généralement un stockage orienté colonnes, ce qui permet au moteur d'analyser des attributs spécifiques sur des millions, voire des milliards de lignes avec un débit élevé.

Les systèmes OLAP privilégient le volume de données. Ainsi, l'un de leurs avantages est la capacité de traiter efficacement de grandes quantités de données historiques ou chargées par lots. Ils alimentent généralement les tableaux de bord, les modèles de prévision, les outils de business intelligence et les charges de travail analytiques à grande échelle.

Relation entre les systèmes OLTP et OLAP

Ces systèmes ne s'excluent pas mutuellement. Dans la plupart des organisations, les données transactionnelles sont répliquées en continu ou périodiquement dans les systèmes analytiques. Cette séparation permet aux applications opérationnelles de rester rapides et réactives, tandis que les charges de travail analytiques s'exécutent indépendamment sans affecter les performances en temps réel.

Le tableau ci-dessous illustre les différences internes entre les systèmes OLTP et OLAP — et pourquoi les organisations s'appuient sur les deux — en les comparant selon plusieurs dimensions. Cela inclut les types de charges de travail pour lesquelles chacun est le mieux adapté, ainsi que certaines différences architecturales importantes.

Base de données transactionnelle vs. Base de données relationnelle

Les bases de données relationnelles et transactionnelles sont souvent discutées ensemble, mais elles décrivent des aspects différents d'un système. Une base de données relationnelle est définie par son modèle de données : des tables composées de lignes et de colonnes, des clés qui appliquent les relations, et un schéma structuré qui organise la façon dont les données sont stockées. Une base de données transactionnelle, en revanche, est définie par ce pour quoi elle est optimisée, à savoir gérer des opérations de lecture/écriture à volume élevé et en temps réel avec de fortes garanties ACID.

La différence fondamentale est simple : « relationnel » décrit la façon dont les données sont structurées, tandis que « transactionnel » décrit la fonction de la base de données. Un système peut être relationnel sans être transactionnel, ou transactionnel sans être relationnel, ou les deux, en fonction de sa conception et de sa charge de travail.

Bases de données relationnelles

Les bases de données relationnelles utilisent un modèle tabulaire pour représenter les données et les relations entre les entités. Cette structure facilite l'application des contraintes, le maintien de l'intégrité référentielle et l'interrogation des données à l'aide de SQL. Des systèmes comme MySQL, PostgreSQL, Oracle et SQL Server sont tous relationnels car ils stockent les données dans des tables et s'appuient sur un schéma pour définir comment ces données sont organisées.

La plupart des bases de données relationnelles prennent également en charge les charges de travail transactionnelles, c'est pourquoi les termes sont parfois confondus. Mais être relationnel ne rend pas intrinsèquement un système transactionnel, cela définit simplement la structure des données.

Bases de données transactionnelles

Les bases de données transactionnelles sont conçues pour traiter de nombreuses opérations courtes et en temps réel de manière sûre et efficace. Elles privilégient les lectures et écritures à faible latence, appliquent les propriétés ACID et garantissent que chaque modification est appliquée de manière prévisible, même en cas de forte concurrence. Bien que de nombreux systèmes transactionnels soient relationnels, la catégorie est plus large.

Plusieurs bases de données NoSQL, y compris MongoDB, CockroachDB et ScyllaDB, prennent également en charge les transactions ACID. Ces systèmes peuvent ne pas utiliser un modèle relationnel, mais ils fournissent néanmoins les garanties nécessaires pour un OLTP fiable.

Principaux avantages des bases de données transactionnelles

Les bases de données transactionnelles sont conçues pour prendre en charge les opérations commerciales en temps réel de manière sécurisée et efficace. Leur architecture et leurs garanties les rendent bien adaptées aux applications qui nécessitent des mises à jour cohérentes et fiables des enregistrements individuels sous forte charge. Les avantages ci-dessous soulignent pourquoi ces systèmes restent fondamentaux pour l'OLTP.

Intégrité des données

La conformité ACID garantit que chaque transaction est appliquée complètement et correctement. Cela évite les écritures partielles, les mises à jour conflictuelles et d'autres formes de corruption de données. En appliquant les propriétés ACID, les bases de données transactionnelles maintiennent un enregistrement précis et fiable de l'activité commerciale.

Fiabilité

Les mécanismes de récupération intégrés permettent aux systèmes de bases de données de récupérer proprement après des pannes ou des défaillances inattendues. Ces fonctionnalités, telles que WAL et la relecture des transactions, garantissent que les données validées sont préservées et que les opérations incomplètes sont annulées, maintenant ainsi la base de données dans un état cohérent.

Performance en temps réel

Les bases de données transactionnelles sont optimisées pour des temps de réponse de l'ordre de la milliseconde sur les opérations de lecture et d'écriture individuelles. Cela les rend idéales pour les applications qui doivent refléter immédiatement l'état le plus récent, telles que la passation de commandes, les mises à jour de compte ou les changements d'inventaire.

Accès concurrentiel

Les systèmes transactionnels sont également conçus pour prendre en charge des milliers d'utilisateurs simultanés sans conflits. Les mécanismes de contrôle de concurrence coordonnent l'accès aux données partagées, garantissant que chaque transaction se comporte de manière prévisible, même lorsque de nombreuses opérations se produisent simultanément.

Auditabilité

Les journaux de transactions complets fournissent un historique complet des modifications. Ces journaux prennent en charge les exigences de conformité, simplifient le débogage et permettent une analyse forensique lors de l'investigation de comportements inattendus ou de problèmes système.

Limitations courantes

Les bases de données transactionnelles sont optimisées pour les opérations en temps réel, mais ces mêmes choix de conception peuvent introduire des contraintes lorsque les charges de travail se déplacent vers l'analytique, les jointures à grande échelle ou l'évolution rapide des schémas. Comme ces systèmes sont conçus pour des lectures et écritures rapides au niveau du point, ils peinent avec les requêtes analytiques qui scannent ou agrègent de grands ensembles de données. Des opérations telles que les agrégations de plusieurs millions de lignes ou les analyses historiques étendues peuvent submerger le moteur de stockage et ralentir les charges de travail opérationnelles.

Leurs schémas rigides rendent également les changements coûteux. Les tables, les contraintes et les relations bien définies qui garantissent l'intégrité des données nécessitent une planification minutieuse lors de l'ajout de colonnes, de la modification de contraintes ou de la refonte de relations. Les migrations doivent être coordonnées pour éviter les temps d'arrêt ou les incohérences, ce qui peut limiter l'agilité à mesure que les modèles de données évoluent.

Des problèmes de performance surviennent également lorsque les requêtes reposent fortement sur des jointures. Bien que les bases de données transactionnelles puissent exécuter des jointures, les jointures multi-tables profondes ou fréquentes augmentent les E/S et la contention de verrouillage à mesure que les ensembles de données augmentent. Cela rend les charges de travail analytiques axées sur les jointures peu pratiques à grande échelle, surtout lorsqu'elles entrent en concurrence avec les opérations en temps réel.

La mise à l'échelle introduit une autre limitation. La plupart des moteurs transactionnels s'adaptent verticalement en ajoutant plus de CPU, de mémoire ou de stockage à un seul nœud. La mise à l'échelle horizontale est possible, mais elle est beaucoup plus complexe que dans les systèmes NoSQL conçus dès le départ pour le fonctionnement distribué. À mesure que le trafic ou la taille des ensembles de données augmente, cette contrainte architecturale devient plus restrictive.

Même lorsque les organisations déchargent l'analytique vers des réplicas de lecture, les moteurs transactionnels atteignent éventuellement des plafonds de performance. Les réplicas s'appuient toujours sur un stockage orienté lignes et sur le même modèle d'exécution que le primaire, ce qui limite leur capacité à gérer efficacement de grandes charges de travail analytiques sans affecter les performances opérationnelles.

Cas d'utilisation et exemples de bases de données

Cas d'utilisation courants

Les bases de données transactionnelles alimentent un large éventail de systèmes opérationnels où la précision, la vitesse et la cohérence sont essentielles. Dans les services bancaires et financiers, elles prennent en charge les virements, les paiements et les mises à jour de compte en temps réel, garantissant que chaque modification est enregistrée de manière fiable. Les plateformes de commerce électronique dépendent d'elles pour le traitement des commandes, la gestion des stocks et les flux de paiement, où chaque action doit être reflétée immédiatement.

Les systèmes de santé utilisent des bases de données transactionnelles pour gérer les dossiers des patients, la planification des rendez-vous et la facturation, qui nécessitent tous une intégrité stricte et des informations à jour. Les systèmes de réservation pour les compagnies aériennes, les hôtels et les événements s'appuient sur des garanties transactionnelles pour éviter les réservations multiples et maintenir une disponibilité précise. Les fournisseurs de télécommunications les utilisent pour suivre les enregistrements d'appels, gérer les données des abonnés et prendre en charge les opérations de facturation à grande échelle.

Bases de données transactionnelles populaires

Un large éventail de moteurs de bases de données prend en charge les charges de travail transactionnelles. Parmi les systèmes relationnels, MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server et IBM Db2 sont largement utilisés pour leurs implémentations ACID matures et leur solide support d'écosystème. Plusieurs bases de données NoSQL offrent également des garanties transactionnelles, notamment MongoDB, CockroachDB, Amazon DynamoDB et ScyllaDB, offrant une flexibilité dans les modèles de données tout en prenant en charge des mises à jour multi-opérations fiables.

Les services gérés dans le cloud tels qu'Amazon Aurora, Google Cloud SQL, Azure SQL Database et Cloud Spanner étendent ces capacités avec une mise à l'échelle automatisée, une haute disponibilité et des opérations gérées, ce qui facilite l'exécution des charges de travail transactionnelles sans maintenir l'infrastructure sous-jacente. Pour les équipes qui développent des applications sur Databricks, consultez comment utiliser Lakebase comme couche de données transactionnelle pour les applications Databricks.

Choisir la bonne base de données pour votre charge de travail

Les bases de données transactionnelles restent essentielles pour les applications qui nécessitent des mises à jour rapides et fiables des enregistrements individuels. Leurs garanties ACID, leurs performances en temps réel et leur capacité à prendre en charge un grand nombre d'utilisateurs simultanés en font l'épine dorsale des systèmes opérationnels dans toutes les industries. Dans le même temps, leurs contraintes architecturales, en particulier concernant les charges de travail analytiques, l'évolution des schémas et la mise à l'échelle horizontale, soulignent pourquoi les organisations les associent à des systèmes conçus pour l'analyse à grande échelle. Comprendre la différence entre les modèles relationnels et transactionnels, ainsi que les forces et les limites spécifiques des moteurs transactionnels, aidera les équipes à choisir la bonne base de données pour chaque charge de travail et à construire des architectures qui équilibrent intégrité, performance et évolutivité à long terme. Pour les équipes qui cherchent à exécuter des charges de travail transactionnelles au sein d'une architecture de données unifiée, Databricks Lakebase apporte une base de données opérationnelle au sein de la plateforme Databricks et est intégrée au lakehouse.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original