Partager via

Traitement transactionnel en ligne (OLTP)

La gestion des données transactionnelles à l’aide de systèmes informatiques est appelée traitement des transactions 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 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 (SGBDR), ce rollback se produit automatiquement lorsqu'une transaction ne peut pas se terminer. Cohérence signifie que les transactions laissent toujours les données dans un état valide. Ces transactions sont des descriptions informelles de l’atomicité et de la cohérence. Il existe des définitions plus formelles de ces propriétés, telles que atomiques, cohérentes, isolées et durables (ACID).

Les bases de données transactionnelles peuvent prendre en charge une cohérence forte pour les transactions à l’aide de différentes stratégies de verrouillage, telles que le verrouillage pessimiste. Ces stratégies permettent de s’assurer que toutes les données restent cohérentes dans le contexte de la charge de travail, pour tous les utilisateurs et processus.

L’architecture de déploiement la plus courante qui utilise des données transactionnelles est le niveau de magasin de données dans une architecture à trois niveaux. Une architecture à trois niveaux se compose généralement d’un niveau présentation, d’un niveau logique métier et d’un niveau de magasin de données. Une architecture de déploiement associée est l’architecture de niveau N , qui peut avoir plusieurs niveaux intermédiaires de gestion de la logique métier.

Caractéristiques des données transactionnelles classiques

Les données transactionnelles ont tendance à avoir les caractéristiques suivantes.

Condition requise Descriptif
Normalisation Très normalisées
schéma Schéma en écriture, 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
Flexibilité de requête Très flexible
Échelle Petites (Mo) à grande taille (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 a un effet négatif sur les opérations quotidiennes de l’entreprise.

Les systèmes OLTP sont conçus pour traiter et stocker efficacement les transactions et interroger les données transactionnelles. L’objectif de traiter et de stocker efficacement des transactions individuelles par un système OLTP est partiellement réalisé par le biais de la normalisation des données, ce qui décompose les données en blocs plus petits et moins redondants. Cette étape permet au système OLTP de traiter un grand nombre de transactions indépendamment. Il évite également des processus supplémentaires requis pour maintenir l’intégrité des données en présence de données redondantes.

Défis

Un système OLTP peut créer quelques défis :

  • Lorsque vous exécutez des analyses sur les données qui s’appuient sur des calculs agrégés sur des millions de transactions individuelles, il est très gourmand en ressources pour un système OLTP. Ils peuvent être lents à exécuter et entraîner un ralentissement en bloquant d’autres transactions dans la base de données. Par conséquent, les systèmes OLTP ne sont pas toujours idéaux pour la gestion des agrégats sur de grandes quantités de données distribuées. Toutefois, il existe des exceptions, comme un schéma bien planifié.

  • Lorsque vous effectuez des analyses et des rapports sur des données hautement normalisées, les requêtes sont généralement complexes, car la plupart des requêtes doivent dénormaliser les données à l’aide de jointures. La normalisation accrue peut compliquer l’interrogation des utilisateurs professionnels sans l’aide d’un administrateur de base de données (DBA) ou d’un développeur de données.

  • Lorsque vous stockez l’historique des transactions indéfiniment ou stockez trop de données dans n’importe quelle table, cela peut entraîner un ralentissement des performances des requêtes, en fonction du nombre de transactions que vous stockez. La solution courante consiste à maintenir une fenêtre de temps pertinente (par exemple, l’exercice actuel) dans le système OLTP et à décharger les données historiques sur d’autres systèmes, comme un entrepôt de données 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 s’exécutant dans App Service et les applications mobiles ou de bureau communiquent généralement avec le système OLTP à l’aide d’un intermédiaire d’API REST.

Dans la pratique, la plupart des charges de travail ne sont pas entièrement OLTP. Ils incluent souvent un composant analytique et nécessitent des rapports en temps réel, tels que l’exécution de rapports sur le système opérationnel. Cette charge de travail est appelée traitement transactionnel et analytique hybride (HTAP). Pour plus d’informations, consultez Traitement analytique en ligne (OLAP)

Dans Azure, les magasins de données suivants répondent aux exigences principales pour OLTP et la gestion des données transactionnelles :

Critères de sélection principaux

Pour limiter 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é microsoft SQL Server, MySQL ou PostgreSQL ? Votre application peut limiter les magasins de données que vous pouvez choisir en fonction des pilotes qu’elle prend en charge pour communiquer avec le magasin de données, ou les hypothèses qu’elle fait sur quelle base de données est utilisée.

  • Vos besoins en débit d’écriture sont-ils élevés ? Si c’est le cas, choisissez une option qui fournit des tables en mémoire ou des fonctionnalités de distribution globales telles qu’Azure Cosmos DB.

  • Votre solution est-elle mutualisée ? Si c’est le cas, tenez compte des options qui prennent en charge les pools de capacité. Plusieurs instances de base de données proviennent d’un pool élastique de ressources, au lieu de ressources fixes par base de données. Les pools élastiques peuvent vous aider à mieux répartir la capacité sur toutes les instances de base de données et à rendre votre solution plus rentable. Azure Cosmos DB offre plusieurs modèles d’isolation pour les scénarios multilocataires.

  • Vos données doivent-elles être lisibles avec une faible latence dans plusieurs régions ? Si c’est le cas, choisissez une option qui prend en charge les réplicas secondaires lisibles ou la distribution globale.

  • 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 charge de travail nécessite-t-elle des transactions ACID garanties ? Si vous travaillez avec des données non relationnelles, envisagez Azure Cosmos DB, qui fournit des garanties ACID par le biais d’opérations de traitement par lots transactionnelles dans une partition logique.

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

  • Votre solution nécessite-t-elle des transactions distribuées ? Si c’est le cas, envisagez des transactions élastiques dans Azure SQL Database et SQL Managed Instance. SQL Managed Instance prend également en charge les appels traditionnels via Microsoft Distributed Transaction Coordinator (MSDTC).

Étapes suivantes

  • Last updated on