Le traitement des transactions en ligne (OnLine Transaction Processing, OLTP) est un type de traitement des données qui exécutant un certain nombre de transactions survenant simultanément, (e.g. opérations bancaires en ligne, achats, saisie de commandes ou l’envoi de messages texte). Ces transactions sont généralement des transactions économiques ou financières, enregistrées et sécurisées afin qu’une entreprise puisse accéder à tout moment aux informations à des fins de comptabilité ou de reporting.
Par le passé, OLTP était limité aux interactions réelles entraînant un changement — monnaie, produits, informations, demande de services, etc. Toutefois, la définition de la transaction dans ce contexte a évolué au fil des années, surtout depuis l’avènement d’Internet, pour englober tout type d’interaction numérique ou d’engagement avec une entreprise qui peut être déclenchée de n’importe où dans le monde et via n’importe quel capteur connecté au Web. Elle inclut également tout type d’interaction ou d’action, comme le téléchargement de fichiers journaux sur une page Web, l’affichage d’une vidéo spécifique, ou des déclencheurs de maintenance automatique ou des commentaires sur les canaux sociaux qui peuvent être essentiels pour qu’une entreprise enregistre des informations afin de mieux servir ses clients.
La définition principale des transactions (économiques ou financières) reste la base de la plupart des systèmes OLTP. Le traitement des transactions en ligne implique donc généralement l’insertion, la mise à jour et/ou la suppression de petites quantités de données dans une banque de données pour collecter, gérer et sécuriser ces transactions. Généralement, une application Web, mobile ou d’entreprise effectue le suivi de toutes ces interactions ou transactions avec les clients, les fournisseurs ou les partenaires et les met à jour dans la base de données OLTP. Ces données de transaction stockées dans la BDD sont essentielles pour les entreprises, étants utilisées pour la génération de rapports ou analytique pour la prise de décision axée sur les données.
L’architecture la plus courante d’un système OLTP qui utilise des données transactionnelles est une architecture à trois niveaux consistant généralement en
- Le niveau de présentation
C’est le composant de front-end, où les transactions provient d’une interaction humaine ou sont générée automatiquement. - Le niveau de logique métier
Le niveau logique se compose de règles vérifiants les transactions et s’assurent que toutes les données requises pour terminer les transactions sont disponibles. - Le niveau de banque de données
Le niveau du magasin de données stocke les transactions et toutes les données qui leur sont associées.
- La conformité ACID
Car les systèmes OLTP doivent s’assurer que l’intégralité des transactions est enregistrée correctement. Une transaction est généralement l’exécution d’un programme pouvant nécessiter plusieurs étapes ou opérations. Elle est complète notamment lorsque toutes les parties concernées accusent réception de la transaction, lorsque le produit/service est livré ou lorsqu’un certain nombre de mises à jour sont apportées aux tables spécifiques de la base de données. Une transaction est enregistrée correctement uniquement si toutes les étapes nécessaires sont exécutées et enregistrées. Si l’une des étapes comporte une erreur, l’intégralité de la transaction doit être abandonnée et toutes les étapes doivent être supprimées du système. Ainsi, les systèmes OLTP doivent respecter des propriétés d’Atomicité, de Cohérence, d’Isolement et de Durabilité (ACID) garantissant la précision des données du système.- L’atomicité
Les contrôles d’atomicité garantissent que toutes les étapes d’une transaction sont exécutées avec succès en tant que groupe.
Si une étape entre les transactions échoue, toutes les autres étapes doivent également échouer ou être annulées. La réussite d’une transaction est appelée validation (commit). L’échec d’une transaction est appelé un abandon. - La cohérence La transaction préserve la cohérence interne de la base de données. En exécutant la transaction seule sur une base de données initialement cohérente, la base de données continue d’être cohérente lorsque la transaction est achevée.
- L’isolation
la transaction s’exécute comme si elle était exécutée seule, sans aucune autre transaction.
L’exécution d’un ensemble de transactions se fait une à une. Ce comportement est la sérialisabilité. La sérialisabilité est généralement implémenté en verrouillant des lignes spécifiques de la table. - La durabilité
Les résultats de la transaction ne seront pas perdus en cas d’échec.
- L’atomicité
- L’accès simultané
Les OLTP permettent un nombre d’utilisateurs extrêmement élevé et de nombreuses requêtes d’accès simultanées aux mêmes données. Le système doit s’assurer que tous les utilisateurs qui tentent de lire ou d’écrire dans le système puissent le faire simultanément. Les contrôles d’accès simultanés permettent d’éviter à deux utilisateurs d’accéder simultanément aux mêmes données du système de base de données pour les modifier et faire en sort qu’un utilisateur patiente que l’autre ait fini sa requête avant de modifier les mêmes données. - L’évolutivité
Parce que les OLTP doivent pouvoir évoluer instantanément pour gérer le volume de transactions en temps réel et exécuter simultanément des transactions, quel que soit le nombre d’utilisateurs y accédant. - La disponibilité
Un OLTP doit toujours être disponible 24/7 et prêt à accepter les transactions qui pouvant être exécutées depuis n’importe où dans le monde et à tout moment.
L’échec d’une transaction peut entraîner une perte de revenu et avoir des conséquences juridiques. - Le débit élevé et courte latence
Ils requièrent des temps de réponse de l’ordre de la nanoseconde voire inférieurs pour maintenir la productivité des utilisateurs professionnels et répondre aux attentes croissantes des clients. - La fiabilité
Ces systèmes lisent et manipulent généralement de petites quantités de données hautement sélectives. Il est primordial que les données soient fiables à tout moment pour les utilisateurs et les applications y accédant. - La sécurité
Stockants des données de transaction client hautement sensibles, la sécurité des données est essentielle. Toute compromission peut s’avérer très coûteuse pour l’entreprise. - La récupération possible
Il est indispensable de pouvoir effectuer une récupération en cas de panne matérielle ou logicielle.
Les bases de données relationnelles ont été spécialement conçues pour les applications de transaction. Contenants tous les éléments essentiels pour le stockage et le traitement d’importants volumes de transactions, tout en étant continuellement mises à jour avec de nouvelles fonctionnalités afin d’extraire plus de valeur de ces données de transactions riches. Les BDDR sont conçues de A à Z pour fournir les plus hautes disponibilités vélocités. Elles assurent une simultanéité d’accès aux données ainsi que la conformité ACID afin que les données soient précises, disponibles en permanence et facilement accessibles. Elles stockent les données dans des tables après avoir extrait les relations entre les données afin qu’elles puissent être utilisées par n’importe quelle application, avec à la clé une source unique d’informations fiables.
Les transactions se sont complexifiées, émanant désormais de nombreuses sources et provenant mondialement de terminaux. Les bases de données relationnelles traditionnelles ne répondent plus suffisamment aux besoins des flux de travail transactionnels. Il a fallu les faire évoluer pour gérer les transactions modernes, les données hétérogènes, la mondialisations, et surtout pour exécuter des workloads mixtes. Les bases de données relationnelles ont cédé la place aux bases de données multimodales stockant et traitant non seulement des données relationnelles, mais aussi tous les autres types de données, y compris xml, html, JSON, Apache Avro et Parquet ainsi que des documents sous leur forme native, sans aucune transformation importante.
Les bases de données relationnelles devaient également ajouter davantage de fonctionnalités, telles que le clustering et le sharding, pour pouvoir être distribuées à l’échelle internationale, s’adaptant à l’infini afin de stocker et de traiter des volumes de données de plus en plus grands et d’exploiter un stockage moins cher sur le cloud. Avec d’autres fonctionnalités telles que les analyses avancées en mémoire, la visualisation et les files d’attente d’événements des transactions, ces bases de données peuvent désormais exécuter plusieurs charges de travail, telles que l’exécution d’analyses sur les données de transaction ou le traitement de la transmission en continu, notamment pour l’Internet des objets (IoT) ou l’exécution d’analyses spatiales et de graphes.
Les bases de données relationnelles modernes (multimodales) intégrées au cloud automatisent une grande partie des aspects opérationnels et de gestion de la base de données, les rendant plus faciles à provisionner et à utiliser. Elles automatisent le provisionnement, la sécurité, la récupération, la sauvegarde et la mise à l’échelle. En conséquence les administrateurs de base de données et les équipes informatiques gagne un temps considérable à la maintenance.
Ces BDD multimodales utilisent également de l’intelligence embarquée pour ajuster et indexer automatiquement les données afin que les performances des requêtes restent constantes indépendamment de la quantité de données, du nombre d’utilisateurs simultanés ou de la complexité des requêtes. Ces bases de données cloud incluent également des fonctionnalités en libre-service et des API REST afin que les développeurs et les analystes puissent facilement accéder aux données et les utiliser. Le développement d’applications est simplifié. Les développeurs ont plus de flexibilité et peuvent créer plus facilement de nouvelles fonctionnalités et personnalisations dans leurs applications. Les analyses s’avèrent également plus aisées, ce qui permet aux analystes et analystes de données d’utiliser plus facilement les données pour extraire des informations.
Source
Oracle