Que sont les bases de données transactionnelles ?

Les bases de données transactionnelles sont optimisées pour les systèmes de production, des sites Web aux banques et magasins. Elles sont idéales pour la lecture et l'écriture très rapides de lignes individuelles tout en préservant l'intégrité des données.

Les bases de données transactionnelles ne sont pas spécifiquement conçues pour l'analytique, mais elles se retrouvent souvent dans un environnement analytique dans le cadre de leur utilisation en tant que bases de données de production. Étant donné qu'elles existent depuis plusieurs dizaines d'années, elles sont bien connues, accessibles et omniprésentes.

Si votre organisation ne dispose pas d'une pile analytique existante, l'un des moyens les plus rapides de vous lancer dans l'analytique est de créer une réplique de votre base de données transactionnelle. Cela permet d'assurer que les requêtes analytiques n'entravent pas accidentellement les requêtes de production essentielles et ne nécessitent qu'une installation minimale. L'inconvénient de ces bases de données, c'est qu'elles sont conçues pour traiter des transactions et non pour l'analytique. Il s'agit d'un bon point de départ pour l'analyse, mais on atteint vite les limites du système et il faut plus rapidement contourner les problèmes qu'avec une installation conçue pour l'analytique.

Les bases de données transactionnelles sont organisées en lignes, ce qui signifie que les données sont enregistrées sur le disque sous forme de lignes plutôt que de colonnes. C'est idéal lorsqu'on souhaite, par exemple, tout savoir au sujet d'un client de la table des utilisateurs car il est possible de n'extraire que les données nécessaires. C'est toutefois moins pratique lorsque l'on tente de compter le nombre de clients qui partagent un même code postal, car il faut alors non seulement charger la colonne des codes postaux, mais aussi les colonnes nomadresse et user_id.

Dans quel cadre les bases de données transactionnelles sont-elles idéales ?

Assurer l'intégrité des données

L'architecture des bases de données transactionnelles est conçue pour être conforme à la norme ACID, assurant la réussite ou l'échec de la rédaction des données, ce qui préserve un haut niveau d'intégrité des données lors de la rédaction dans la base de données. Les bases de données transactionnelles sont donc essentielles pour les transactions commerciales nécessitant un haut niveau d'intégrité des données (avec l'exemple typique des banques, qui ont besoin que l'ensemble de la transaction, débit d'un compte et crédit sur un autre, réussisse ou échoue).

Faible latence

Comme les bases de données transactionnelles sont conçues pour soutenir les systèmes de production, elles sont très efficaces pour les opérations qui doivent être traitées en quelques millisecondes. Si vous effectuez des analyses sur une réplique de votre base de données de production, la réplique sera probablement presque synchronisée avec votre base de données de référence (latence de moins d'une seconde).

Surveillance des systèmes opérationnels

L'usage des données d'une base de données transactionnelle pour obtenir un aperçu en temps réel des opérations est un cas d'usage analytique idéal pour les bases de données transactionnelles car la réplique offre une latence très faible. Si vous cherchez à surveiller les tâches d'assistance, l'inventaire ou un autre système opérationnel et que vous devez prendre des décisions fondées sur des données à jour, la réplique de la base de données de production est probablement la meilleure option.

Bases de données transactionnelles populaires

Architecture

Stockage sous forme de lignes

Les bases de données transactionnelles sont organisées en lignes, ce qui signifie que les lignes de données sont enregistrées ensemble, et l'on présume que lorsqu'un utilisateur souhaite lire une ligne de données, il recherche toutes les données de la ligne. Les requêtes exécutées sur une base de données transactionnelle examinent chaque ligne de données avant de n'afficuer que les colonnes sélectionnées par la requête.

Les entrepôts de données analytiques, quant à eux, sont organisés en colonnes, et ils stockent chaque champ de manière indépendante. Les entrepôts de données analytiques sont donc optimisés pour la lecture des données mais pas pour l'écriture, car cette opération représente de nombreuses écritures dans plusieurs colonnes.

Cependant, cela signifie aussi que les bases de données analytiques sont généralement plus efficaces et rapides pour l'exécution d'agrégats. Pour regrouper le jeu de données d'une base de données transactionnelle, il faut examiner chaque ligne avant d'exécuter l'opération. Il est plus efficace de n'examiner que la colonne à regrouper, les entrepôts de données analytiques conviennent donc mieux aux analyses complexes.

Pour les entreprises qui disposent d'un faible volume de données, ce problème ne se présente pas vraiment, mais au fil de l'augmentation des données disponibles, ces différences se ressentent davantage.

Transactions ACID

ACID désigne un ensemble de propriétés qui décrivent l'architecture des bases de données transactionnelles et la préservation de l'intégrité des données lors de l'écriture.

Propriété Description
Atomicité Si la moindre partie de la transaction échoue, toute la transaction échoue. Cela permet d'assurer que chaque transaction ajoutée à la base de données soit réussie à 100 %.
Cohérence Soit la transaction est rédigée dans la base de données (ce qui fait passer la base de données d'un état valide à un autre), soit elle est annulée.
Isolation Les transactions qui ne sont pas encore achevées ne peuvent pas être utilisées/modifiées par d'autres transactions.
Durabilité Une fois une transaction inscrite dans la base de données, elle y reste, même en cas d'échec de la base de données.

Retrouvez ci-dessous un exemple qui illustre l'importance des propriétés ACID pour la conception des bases de données transactionnelles. Imaginez que deux personnes souhaitent réserver le même siège d'un vol.

La Personne A réserve un siège, et la Personne B réserve plusieurs sièges à la fois.

  • Atomicité - Si la Personne A finalise effectivement sa transaction, la transaction de la Personne B échoue car l'un des sièges de son panier a déjà été réservé.
  • Cohérence - La Personne A et la Personne B ne peuvent pas avoir un billet pour le même siège.
  • Isolation - La transaction de la Personne B ne sera annulée que si la transaction de la Personne A est réussie et rédigée dans la base de données, et vice versa.
  • Durabilité - En cas d'échec de la base de données après réservation d'un siège par la Personne A, la Personne A pourra toujours obtenir son billet à l'aéroport.

Emplacement dans la pile de données

Lorsqu'une base de données analytique est utilisée pour des services d'analyse, elle est configurée comme réplique de la base de données de production. Cette configuration est bien documentée et sa programmation est accessible à la plupart des administrateurs et ingénieurs de bases de données.

Les fournisseurs de bases de données dans le cloud offrent des moyens faciles d'obtention d'une réplique. Il est recommandé d'utiliser cette configuration plutôt que d'exécuter les analyses sur la base de données de production, car les requêtes analytiques peuvent employer beaucoup de ressources et réduire la performance de votre base de données de production, qui doit être dédiée à la rédaction de données. Dans la plupart des cas, la réplique de la base de données n'a qu'un maximum de quelques secondes de retard par rapport à la base de données de production.

Contraintes

Si vous utilisez une réplique de votre base de données de production pour exécuter des analyses sur votre base de données transactionnelle, vous ne pourrez pas toujours rédiger des données dans cette réplique. Cela est dû au fait que la réplique a pour objet de refléter exactement la base de données de production, et que l'écriture de données dans la réplique ne se reflétera pas dans la base de données de référence.

Il y a toutefois des exceptions, car il est possible de créer une partie de la réplique dans laquelle on peut rédiger des données, mais il s'agit clairement d'une contrainte qu'il convient de prendre en compte et qui peut compliquer certaines opérations.

Optimisation

Niveau d'isolement

En matière d'optimisation de votre base de données transactionnelle pour l'analytique, la première étape est de réduire le niveau d'isolement. Ce dernier contrôle les types d'opérations qui « verrouillent » une table, la réduction du niveau d'isolement réduit donc la latence de la réplique et limite le verrouillage de la base de données. Comme vous ne modifiez ces paramètres que pour la réplique en lecture seule, cette opération devrait être sans risque.

Indexage

Le meilleur moyen d'améliorer la performance de votre base de données transactionnelle est de créer des index de qualité. Les index sont, comme leur nom l'indique, le moyen que les bases de données utilisent pour ordonner les colonnes afin de savoir immédiatement où les différentes lignes se trouvent sur le disque. L'indexage des clés pour les tableaux couramment liés et de l'horodatage des tableaux temporels permet d'améliorer considérablement la performance des requêtes analytiques en réduisant le nombre de lignes à examiner.

L'inconvénient de l'ajout des index est que chaque index occupe de l'espace sur le disque. Une bonne stratégie d'indexage consiste donc à trouver l'équilibre entre la performance et l'espace disque disponible.

Réduction de la redondance

La réduction de la redondance des données permet aussi d'améliorer la performance des tableaux en lecture seule. Le stockage des données en troisième forme normale est une manière courante d'y parvenir. Cela permet de réduire la largeur des lignes communes et de transférer les éléments les moins utilisés vers leurs propres tableaux, qui peuvent ensuite être joints si nécessaire.

Matrice de données

Une matrice de données creuse peut avoir un impact important sur la performance. Les jeux de données les plus courants avec une matrice creuse sont les dossiers médicaux, les journaux de serveur et les collections de données non structurées. Les bases de données en colonnes sont conçues pour traiter une matrice de données creuse.

Si vous utilisez un système sous forme de lignes, vous devrez probablement trouver des approches alternatives. L'une de ces dernières est de fragmenter les colonnes de votre tableaux en plusieurs tableaux. Cette stratégie réduit le nombre de colonnes utilisées par requête. La création d'un modèle entité-attribut-valeur peut également être utile si vous disposez d'une matrice extrêmement creuse, mais cela augmente toutefois la complexité des requêtes analytiques. Un outil offrant une couche de modélisation robuste, comme Looker, peut soutenir cette stratégie, tandis que l'écriture de l'opération en SQL peut être fastidieuse.

Transformations des données

L'un des autres moyens d'optimiser les requêtes et d'exécuter des calculs dans SQL avant de lancer la requête. Utilisez les transformations de données pour traiter les lignes brutes et créer des agrégats ou DISTINCT avant l'exécution des requêtes afin d'accélérer l'opération. L'inconvénient, c'est que cette méthode réduit la résolution et doit être constamment mise à jour lorsque vous ajoutez de nouvelles données.

Prenez goût à l'analytique

Business intelligence, analyse de big data ou vue client à 360° :
quels que soient vos besoins, Looker peut vous aider. Parlez à nos experts en données.

Demander une démo