Traitement transactionnel en ligne (OLTP)

  • Article

La gestion des données transactionnelles à l’aide de systèmes informatiques est appelée « traitement transactionnel en ligne » (OLTP). Les systèmes OLTP enregistrent les interactions de l’entreprise lorsqu’elles se produisent dans les opérations quotidiennes de l’organisation et prennent en charge l’interrogation de ces données pour faire des inférences.

Données transactionnelles

Les données transactionnelles sont des informations qui assurent le suivi des interactions relatives aux activités d’une organisation. Ces interactions sont généralement des transactions commerciales, tels que les paiements reçus des clients, les paiements effectués aux fournisseurs, le déplacement de produits dans le cadre de l’inventaire, les commandes prises ou les services fournis. Les événements transactionnels, qui représentent les transactions proprement dites, contiennent une dimension de temps, des valeurs numériques et des références à d’autres données.

Les transactions doivent généralement être atomiques et cohérentes. Atomicité signifie qu’une transaction complète réussit ou échoue toujours en tant que seule unité de travail et n’est jamais laissée dans un état à moitié terminé. Si une transaction ne peut pas être effectuée, le système de base de données doit restaurer toutes les étapes qui ont déjà été effectuées dans le cadre de cette transaction. Dans un système de gestion de base de données relationnelle traditionnel, cette restauration a lieu automatiquement si une transaction ne peut pas être effectuée. Cohérence signifie que les transactions laissent toujours les données dans un état valide. (Il s’agit de descriptions très informelles de l’atomicité et de la cohérence. Il existe des définitions plus formelles de ces propriétés, comme ACID.)

Les bases de données transactionnelles peuvent prendre en charge une cohérence forte pour les transactions grâce à différentes stratégies de verrouillage, tels que le verrouillage pessimiste, pour garantir que toutes les données sont fortement cohérentes dans le contexte de l’entreprise, pour tous les utilisateurs et les processus.

L’architecture de déploiement la plus courante utilisant des données transactionnelles est le niveau de magasin de données dans une architecture à 3 couches. Une architecture à 3 couches se compose généralement d’une couche de présentation, d’une couche de logique métier et d’une couche de magasin de données. L’architecture multiniveau est une architecture de déploiement associée pouvant avoir plusieurs couches intermédiaires qui gèrent la logique métier.

Caractéristiques des données transactionnelles classiques

Les données transactionnelles ont tendance à présenter les caractéristiques suivantes :

Condition requise Description
Normalisation Très normalisées
schéma Schéma lors de l’écriture, fortement appliqué
Cohérence Cohérence forte, garanties ACID
Intégrité Intégrité élevée
Utilisent des transactions Oui
Stratégie de verrouillage Pessimiste ou optimiste
Peut être mise à jour Oui
Modifiable Oui
Charge de travail Haut volume d’écriture, volume de lecture modéré
Indexation Index primaires et secondaires
Taille de donnée Petite à moyenne taille
Modèle Relationnel
Forme des données Tabulaire
Flexibilité de requête Très flexible
Scale Petite (Mo) à grande (quelques To)

Quand utiliser cette solution ?

Choisissez OLTP lorsque vous avez besoin de traiter et stocker efficacement les transactions commerciales et les rendre immédiatement disponibles pour les applications clientes de manière cohérente. Utilisez cette architecture lorsque tout retard tangible dans le traitement peut avoir un impact négatif sur les opérations quotidiennes de l’entreprise.

Les systèmes OLTP sont conçus pour traiter et stocker efficacement des transactions, ainsi que les données transactionnelles de requête. L’objectif de traiter et de stocker efficacement des transactions individuelles par un système OLTP est atteint en partie par la normalisation des données, c’est-à-dire, le fractionnement des données en blocs plus petits qui sont moins redondants. Cela prend en charge l’efficacité en permettant au système OLTP de traiter indépendamment une grande quantité de transactions et en évitant le traitement supplémentaire nécessaire pour maintenir l’intégrité des données en présence de données redondantes.

Défis

La mise en œuvre et l’utilisation d’un système OLTP peuvent créer quelques défis :

  • Les systèmes OLTP ne sont pas toujours appropriés pour gérer des agrégats sur de grandes quantités de données, bien qu’il existe des exceptions, notamment une solution SQL Server correctement planifiée. L’analytique des données qui s’appuient sur des calculs d’agrégation pour des millions de transactions individuelles exige, pour un système OLTP, de très nombreuses ressources. Elles peuvent s’exécuter lentement et entraîner un ralentissement en bloquant les autres transactions dans la base de données.
  • Lors de la réalisation d’analyses et la création de rapports sur les données très normalisées, les requêtes ont tendance à être complexes, car la plupart doivent dénormaliser les données à l’aide de jonctions. En outre, les conventions d’affectation de noms pour les objets de base de données dans les systèmes OLTP ont tendance à être laconique et concise. La normalisation accrue couplée à des conventions d’affectation de noms laconiques complique l’interrogation des systèmes OLTP par les utilisateurs professionnels, sans l’aide d’un développeur de base de données ou développeur des données.
  • Le stockage indéfini de l’historique des transactions et le stockage de trop de données dans une table peuvent entraîner le ralentissement des performances de requêtes, en fonction du nombre de transactions stockées. La solution courante consiste à maintenir une période pertinente (par exemple, l’année fiscale en cours) dans le système OLTP et décharger les données historiques vers d’autres systèmes, par exemple un mini-data Warehouse ou un entrepôt de données.

OLTP dans Azure

Les applications telles que les sites Web hébergés dans App Service Web Apps, les API REST en cours d’exécution dans l’App Service ou les applications de bureau ou mobiles communiquent avec le système OLTP, en général via une API REST intermédiaire.

Dans la pratique, la plupart des charges de travail ne sont pas purement OLTP. Généralement, elles comportent également un composant analytique. En outre, il existe une demande croissante de rapports en temps réel, telles que l’exécution des rapports à partir du système d’exploitation. Cela est également appelé HTAP (Traitement transactionnel et analytique hybride). Pour plus d’informations, consultez Traitement analytique en ligne (OLAP).

Dans Azure, tous les magasins de données suivants répondront aux principales exigences du traitement OLTP et de la gestion des données transactionnelles :

Critères de sélection principaux

Pour restreindre les choix, commencez par répondre aux questions suivantes :

  • Préférez-vous opter pour un service géré plutôt que de gérer vos propres serveurs ?

  • Votre solution a-t-elle des dépendances spécifiques pour la compatibilité de Microsoft SQL Server, MySQL ou PostgreSQL ? Votre application peut limiter les magasins de données que vous pouvez choisir en fonction des pilotes pris en charge pour la communication avec le magasin de données, ou du magasin de données supposé être utilisé.

  • Vos exigences de débit d’écriture sont-elles particulièrement élevées ? Si oui, choisissez une option qui fournit des tables en mémoire.

  • Votre solution est-elle mutualisée ? Dans ce cas, envisagez des options prenant en charge des pools de capacité, où plusieurs instances de base de données proviennent d’un pool élastique de ressources, et non de ressources fixes par base de données. Ceci vous permet de mieux distribuer la capacité sur toutes les instances de base de données et d’améliorer la rentabilité de votre solution.

  • Vos données doivent-elles être lisibles avec une faible latence dans plusieurs régions ? Si oui, choisissez une option prenant en charge des réplicas secondaires lisibles.

  • Votre base de données doit-elle être hautement disponible dans plusieurs régions géographiques ? Si oui, choisissez une option prenant en charge la réplication géographique. Envisagez également les options qui prennent en charge le basculement automatique du réplica principal vers un réplica secondaire.

  • Votre base de données a-t-elle des besoins de sécurité spécifiques ? Si oui, examinez les options qui fournissent des fonctionnalités telles que la sécurité au niveau des lignes, le masquage de données et le chiffrement transparent des données.

Matrice des fonctionnalités

Les tableaux suivants résument les principales différences entre les fonctionnalités.

Fonctionnalités générales

Fonctionnalité Azure SQL Database SQL Server sur une machine virtuelle Azure Azure Database pour MySQL Azure Database pour PostgreSQL
Est un service géré Oui No Oui Oui
S’exécute sur la plateforme N/A Windows, Linux, Docker N/A N/A
Programmabilité 1 T-SQL, .NET, R T-SQL, .NET, R, Python SQL SQL, PL/pgSQL, PL/JavaScript (v8)

[1] sans prise en charge des pilotes client, ce qui permet de se connecter à de nombreux langages de programmation et d’utiliser le magasin de données OLTP.

Fonctionnalités d’évolutivité

Fonctionnalité Azure SQL Database SQL Server sur une machine virtuelle Azure Azure Database pour MySQL Azure Database pour PostgreSQL
Taille maximale de l’instance de la base de données 4 To 256 To 16 TO 16 TO
Prend en charge les pools de capacité Oui Oui No Non
Prend en charge la mise à l’échelle des clusters Non Oui No Non
Évolutivité dynamique (montée en puissance) Oui No Oui Oui

Fonctionnalités de la charge de travail analytique

Fonctionnalité Azure SQL Database SQL Server sur une machine virtuelle Azure Azure Database pour MySQL Azure Database pour PostgreSQL
Tables temporelles Oui Oui No Non
Tables en mémoire (optimisées en mémoire) Oui Oui No Non
Prise en charge de ColumnStore Oui Oui No Non
Traitement de requêtes adaptatif Oui Oui No Non

Fonctionnalités de disponibilité

Fonctionnalité Azure SQL Database SQL Server sur une machine virtuelle Azure Azure Database pour MySQL Azure Database pour PostgreSQL
Bases de données secondaires accessibles en lecture Oui Oui Oui Oui
Réplication géographique Oui Oui Oui Oui
Basculement automatique vers la base de données secondaire Oui No Non Non
Restauration dans le temps Oui Oui Oui Oui

Fonctionnalités de sécurité

Fonctionnalité Azure SQL Database SQL Server sur une machine virtuelle Azure Azure Database pour MySQL Azure Database pour PostgreSQL
Sécurité au niveau des lignes Oui Oui Oui Oui
Masquage de données Oui Oui No Non
Chiffrement transparent des données Oui Oui Oui Oui
Restreindre l’accès à des adresses IP spécifiques Oui Oui Oui Oui
Restreindre l’accès pour autoriser l’accès au seul réseau virtuel Oui Oui Oui Oui
Authentification Microsoft Entra Oui No Oui Oui
Authentification Active Directory Non Oui No Non
Authentification multifacteur Oui No Oui Oui
Prend en charge Always Encrypted Oui Oui No Non
IP privée Non Oui No Non

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Étapes suivantes