Le traitement des données en temps réel est un aspect fondamental de la gestion d’entreprises modernes axées sur la technologie. Les clients veulent des résultats plus rapides que jamais et feront défaut à la moindre occasion d’obtenir des résultats plus rapides. Par conséquent, les organisations sont de nos jours dans une chasse continue pour réduire les millisecondes de leurs réponses.
Le traitement en temps réel prend en charge la plupart des aspects qui étaient auparavant traités à l’aide du traitement par lots. Le traitement en temps réel nécessite l’exécution d’une logique métier sur un flux de données entrant. Cela contraste fortement avec la manière traditionnelle de stocker les données dans une base de données, puis d’exécuter des requêtes analytiques. De telles applications ne peuvent pas se permettre le retard impliqué dans le chargement des données d’abord dans une base de données traditionnelle, puis dans l’exécution des requêtes. Cela prépare le terrain pour les bases de données en continu. Les bases de données en continu sont des magasins de données qui peuvent recevoir des données à grande vitesse et les traiter en déplacement sans une base de données traditionnelle dans le mélange. Ils ne remplacent pas la base de données traditionnelle, mais sont bons pour gérer les données à grande vitesse. Cet article couvrira les quatre principes de conception clés et les garanties des bases de données en streaming.
Comprendre les bases de données de streaming
Les bases de données en continu sont des bases de données qui peuvent collecter et traiter une série entrante de points de données (c’est-à-dire un flux de données) en temps réel. Une base de données traditionnelle stocke les données et attend des utilisateurs qu’ils exécutent des requêtes pour récupérer des résultats basés sur les dernières données. Dans le monde moderne, où le traitement en temps réel est un critère clé, attendre les requêtes n’est pas une option. Au lieu de cela, les requêtes doivent s’exécuter en continu et toujours renvoyer les données les plus récentes. Les bases de données de streaming facilitent cela.
Dans le cas des bases de données en continu, les requêtes ne sont pas exécutées mais plutôt enregistrées car l’exécution n’est jamais terminée. Ils s’exécutent pendant une durée infinie, réagissant aux nouvelles données qui arrivent. Les applications peuvent également effectuer des requêtes dans le temps pour avoir une idée de la façon dont les données ont changé au fil du temps.
Par rapport à une base de données traditionnelle, une base de données en streaming fait tout le travail au moment de la rédaction. Y parvenir comporte de nombreux défis. D’une part, il existe un minimum de durabilité et d’exactitude que l’on attend d’une base de données traditionnelle. Le maintien de ce type de durabilité et d’exactitude nécessite des conceptions compliquées lorsque les données sont toujours en mouvement. Ensuite, il y a le défi de permettre aux utilisateurs d’interroger les données en mouvement. SQL est depuis longtemps la norme pour toutes les exigences d’interrogation. Il est naturel que les bases de données en continu prennent également en charge SQL, mais la mise en œuvre de constructions telles que le fenêtrage, l’agrégation, etc., est complexe lorsque les données sont toujours en mouvement.
Une requête persistante est une requête qui opère sur le déplacement de données. Ils s’exécutent indéfiniment et continuent de générer des lignes de sortie. Les requêtes sans fin posent des défis uniques dans la mise à jour de la logique. La question clé concerne le comportement lors du remplacement de la requête par une requête améliorée. Fonctionne-t-elle sur toutes les données arrivées jusque-là ou uniquement sur le prochain ensemble de données ? Le nom du premier mode de fonctionnement est le remplissage et le second est le traitement exactement une fois. Pour implémenter le traitement exactement une fois, le moteur d’exécution doit avoir un magasin local. Parfois, les requêtes peuvent alimenter d’autres flux de données. Une telle opération est appelée mode cascade.
Maintenant que les concepts sont clairs, passons un peu de temps sur les détails architecturaux d’une base de données de streaming. Une base de données de streaming est généralement construite au-dessus d’un système de traitement de flux qui fonctionne sur la base du paradigme producteur-consommateur. Un producteur est une entité qui crée les événements. Un consommateur consomme les événements et les traite. Les événements sont généralement regroupés en partitions logiques de rubriques pour faciliter la mise en œuvre de la logique métier.
Il y a un courtier qui se trouve entre eux qui assure la fiabilité des flux et des conversions de format nécessaires pour les producteurs et les consommateurs. Broker est généralement distribué sur une plate-forme distribuée pour garantir une disponibilité et une robustesse élevées. Un moteur de requête de flux réside au-dessus de la plate-forme de traitement. Une couche d’abstraction SQL qui convertit les requêtes SQL en logique de traitement de flux est également présente. En assemblant tout, l’architecture se présente comme ci-dessous.
Maintenant que nous comprenons le concept de bases de données en streaming et de requêtes persistantes, passons un peu de temps sur les cas d’utilisation typiques pour eux.
Plateformes IdO
Les plates-formes IoT gèrent un grand nombre d’événements poussés à partir d’appareils à travers le monde. Ils doivent générer des alertes basées sur un traitement en temps réel et avoir des SLA stricts en ce qui concerne les temps de réaction. Les plates-formes IoT doivent également stocker tous les événements reçus pour toujours et nécessitent des agrégations basées sur des fenêtres sur les données de streaming à des fins d’analyse. Les bases de données en continu et les requêtes persistantes conviennent bien ici.
Recherche d’événements
L’approvisionnement en événements est un paradigme où la logique d’application est exécutée en termes d’événements qui se sont produits au fil du temps plutôt qu’en fonction de l’état final des entités. Cela contribue à améliorer la durabilité et la fiabilité de l’application puisque l’état de l’application peut être recréé à tout moment en répondant aux événements. Ceci est utile dans les cas où une piste d’audit est une exigence obligatoire.
Cliquez sur Analyse de flux
Les plates-formes d’analyse de flux de clics traitent les événements de clic générés dans le cadre de l’utilisation de l’application. Les données des événements de clic sont parfois directement transmises aux modèles d’apprentissage automatique qui fournissent des recommandations et des suggestions aux clients. Les événements persistants et le traitement en temps réel des flux de clics sont une partie importante de la gestion d’une entreprise comme le commerce électronique.
Systèmes de négociation
Les systèmes de négociation traitent des millions de demandes commerciales par seconde et les comparent à l’équation de l’offre et de la demande pour régler les transactions. Une piste d’audit est une exigence obligatoire dans de tels cas où le moindre retard peut entraîner d’énormes pertes financières pour les parties concernées.
Systèmes de détection de fraude
Les systèmes de détection de fraude doivent agir immédiatement une fois qu’ils ont détecté des scénarios qui correspondent étroitement au début typique d’une fraude. Ils doivent également tenir un registre des alertes déclenchées et des événements consécutifs à l’incident. Considérez un système de détection de fraude dans le système financier qui détecte la fraude en fonction des habitudes de dépenses du propriétaire légitime. Il doit fournir les caractéristiques des événements à un modèle de détection de fraude en temps réel et agir immédiatement lorsqu’il signale une éventuelle violation. Les bases de données en temps réel sont d’excellentes solutions pour mettre en œuvre de tels cas d’utilisation.
Surveillance des systèmes informatiques
La surveillance centralisée aide les organisations à maintenir leurs systèmes informatiques toujours en cours d’exécution. Les bases de données de streaming sont souvent utilisées pour collecter les journaux des systèmes et générer des alertes lorsque des conditions spécifiques sont remplies. Les alertes en temps réel et les pistes d’audit générées par le stockage des événements sont des éléments clés de la mise en œuvre observable du système.
Le marché des bases de données en streaming n’est pas encombré et il n’y a qu’une poignée de bases de données qui sont aguerries pour gérer les charges de travail de production. Kafka, Materialise, Memgraph, etc., sont quelques-uns des plus stables. Choisir celui qui correspond à un cas d’utilisation nécessite une comparaison élaborée de leurs caractéristiques et une dissection des cas d’utilisation.
Concentrons-nous maintenant sur l’apprentissage des principaux principes de conception de base de données et des garanties derrière les bases de données en continu.
4 principes et garanties de conception de bases de données de streaming clés
L’exhaustivité d’un système de base de données est souvent représentée en termes de conformité de la base de données à ACID. La plainte ACID constitue la base de bons principes de conception de bases de données. La conformité ACID est synonyme d’atomicité, de cohérence, d’isolation et de durabilité. L’atomicité fait référence à la garantie qu’un groupe d’instructions faisant partie d’une opération logique échouera correctement si l’une des instructions contient une erreur. Un tel groupe d’instructions est appelé une transaction. Au début des bases de données en streaming, la prise en charge des transactions et donc l’atomicité manquaient souvent. Mais les nouvelles versions prennent en charge les transactions.
La cohérence fait référence au respect des règles appliquées par la base de données, telles que les contraintes de clé unique, les contraintes de clé étrangère, etc. Une base de données cohérente annulera la transaction si l’état résultant ne respecte pas ces règles. L’isolement est le concept d’exécution de transactions séparées de sorte qu’une transaction n’affecte pas l’autre. Cela permet l’exécution parallèle des transactions. Les bases de données telles que KSQLDB prennent en charge une cohérence forte et l’exécution parallèle des requêtes. La durabilité consiste à récupérer des points de défaillance. La nature distribuée de l’architecture assure une forte durabilité pour les bases de données de streaming modernes.
La garantie dans le cas d’une base de données en continu fait référence à l’assurance sur la gestion des événements. Les données étant en mouvement continu, il est difficile d’assurer l’ordre de traitement des événements ou d’éviter un traitement en double. Veiller à ce que toutes les données soient traitées exactement une fois est une opération coûteuse et nécessite un stockage d’état et des accusés de réception. De même, s’assurer que les messages sont traités dans le même ordre qu’ils ont été reçus nécessite une architecture complexe dans le cas d’une application distribuée.
Examinons maintenant les principes de conception de base et comment ils sont accomplis dans les bases de données en continu.
1. Récupération automatique
La récupération automatique est l’un des principes de conception de base de données les plus critiques dans le cas d’une base de données en continu. Les bases de données en continu sont utilisées dans des domaines hautement réglementés comme les soins de santé, les systèmes financiers, etc. Dans ces domaines, il n’y a aucune excuse pour les échecs, et les incidents peuvent entraîner d’énormes pertes monétaires ou même des pertes de vie. Imaginez une base de données de streaming intégrée dans le cadre d’une plate-forme IoT de soins de santé. Les capteurs surveillent les paramètres vitaux des patients et les envoient à une base de données de streaming hébergée dans le cloud. Un tel système ne peut jamais tomber en panne et les requêtes qui génèrent des alertes basées sur des valeurs de seuil doivent s’exécuter indéfiniment.
Étant donné que l’échec n’est pas une option pour les bases de données en continu, elles sont souvent implémentées sur la base d’une architecture distribuée. Les bases de données en streaming conçues sur la base d’un cluster de nœuds fournissent de grands défauts …