Modèle de vue matérialisée

Générez des vues préremplies sur des données dans un ou plusieurs magasins de données lorsque les données ne sont pas idéalement mises en forme pour les opérations de requête requises. Cette approche peut prendre en charge l’interrogation efficace et l’extraction de données et améliorer les performances des applications.

Contexte et problème

Lors du stockage des données, les développeurs et les administrateurs de données hiérarchisent souvent la façon dont les données sont stockées plutôt que la façon dont elles sont lues. Le format de stockage choisi reflète généralement le format des données, les exigences de gestion de la taille et de l’intégrité des données, ainsi que le type de magasin utilisé. Par exemple, lorsque vous utilisez un magasin de documents NoSQL, vous représentez souvent les données sous la forme d’une série d’agrégats, chacune contenant toutes les informations de cette entité.

Toutefois, cette approche peut avoir un effet négatif sur les requêtes. Lorsqu’une requête nécessite uniquement un sous-ensemble des données de certaines entités (par exemple, un résumé des commandes de plusieurs clients sans tous les détails des commandes), il faut extraire toutes les données des entités pertinentes afin d’obtenir les informations requises.

L’ajout d’index ou la modification des requêtes au moment de la lecture ne résout pas toujours cette inefficacité. De nombreux magasins ne peuvent pas être réindexés pour les modèles de lecture arbitraires sans affecter les performances d’écriture. L’agrégation inter-entités reste coûteuse au moment de la requête. Certains magasins ont des fonctionnalités de requête limitées par conception. En raison de ces contraintes, l’optimisation du chemin de lecture au sein du stockage source à elle seule est souvent insuffisante.

Solution

Pour prendre en charge l’interrogation efficace, une solution courante consiste à générer, à l’avance, une vue qui matérialise les données dans un format adapté au jeu de résultats requis. Le modèle de vue matérialisée décrit la génération de vues préremplies de données dans les environnements où la source de données n’est pas dans un format approprié pour les requêtes, où il est difficile de générer une requête appropriée et où les performances des requêtes sont faibles en raison de la nature de la les données ou du magasin de données.

Dans ce schéma, une vue matérialisée est un modèle en lecture ou une projection qui stocke de manière persistante des données dérivées d’un ou de plusieurs stockages sources. Un composant d’application dédié ou un pipeline de données peut gérer la projection, y compris entre les limites du magasin. Les consommateurs de requêtes traitent la projection en lecture seule. Ce concept architectural est plus large qu’un objet de vue matérialisée native de base de données, qu’un moteur de base de données définit, stocke et actualise en fonction de ses propres contraintes de caractéristiques.

Ces vues matérialisées, qui contiennent uniquement les données requises par une requête, permettent aux applications d’obtenir rapidement les informations dont elles ont besoin. En plus des jointures de tables ou de la combinaison des entités de données, les vues matérialisées peuvent inclure les valeurs actuelles des colonnes calculées ou des éléments de données, les résultats de la combinaison de valeurs ou de l’exécution de transformations sur les éléments de données, et les valeurs spécifiées dans le cadre de la requête. Une vue matérialisée peut même être optimisée pour une requête unique.

Un point clé est qu’une vue matérialisée et les données qu’elle contient peuvent être entièrement supprimées, car elles peuvent être reconstruites à partir des sources de données. Les consommateurs de requêtes ne mettent pas directement à jour l’affichage. Au lieu de cela, un composant dédié, un pipeline de données ou un moteur de base de données le gère. Il s’agit donc d’un cache spécialisé.

Lorsque les données sources de la vue changent, la vue doit être mise à jour pour inclure les nouvelles informations. Vous pouvez planifier cette mise à jour automatiquement ou lorsque le système détecte une modification des données d’origine. Dans certains cas, vous devrez peut-être régénérer la vue manuellement. La figure suivante montre un exemple de la façon dont le modèle De vue matérialisée peut être utilisé.

Diagramme montrant le modèle d’affichage matérialisé. Les magasins de données source alimentent un processus de génération de vue matérialisée, qui alimente une vue matérialisée que les applications interrogent directement au lieu d’interroger les magasins source.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

• Afficher la stratégie d’actualisation. Dans l’idéal, la vue se régénère en réponse à un événement indiquant une modification des données sources, bien que cette approche puisse entraîner une surcharge excessive si les données sources changent rapidement. Vous pouvez également envisager d’utiliser une tâche planifiée, un déclencheur externe ou une action manuelle pour régénérer la vue.

• Comportement d’actualisation. Déterminez si l’implémentation effectue une reconstruction complète ou applique les modifications de manière incrémentielle. Vous devez également décider si les opérations d’actualisation bloquent les lectures.

  Ces décisions déterminent si les requêtes retournent des données matérialisées potentiellement obsolètes, combinent des données matérialisées avec des modifications de source non traitées pour retourner les résultats actuels ou continuent de servir la dernière version complète jusqu’à la fin de l’actualisation.

• Actualisez la fiabilité du signal. Si le signal d’activation qui déclenche la régénération de la vue est perdu ou retardé — par exemple, en cas d’événement du flux de modifications manqué ou de tâche planifiée qui a échoué — la vue renvoie discrètement des résultats obsolètes. Surveillez la fraîcheur de l’actualisation et déclenchez une alerte lorsque l’ancienneté de la vue dépasse le délai de péremption acceptable.

• Actualisez le coût de calcul. La régénération d’une vue consomme des ressources de calcul proportionnelles au volume de données sources et à la complexité des transformations. Pour l’actualisation pilotée par les événements sur la modification rapide des données sources ou pour les reconstructions complètes de vues analytiques volumineuses, le coût de calcul de l’actualisation peut être un facteur de coût important. Dimensionner correctement la fréquence et l’étendue d’actualisation pour équilibrer l’actualisation des données par rapport aux dépenses de calcul.

• Dépendance à Event Sourcing Dans certains systèmes, comme lorsque vous utilisez le modèle d’approvisionnement en événements pour conserver un magasin uniquement des événements qui ont modifié les données, les vues matérialisées sont généralement nécessaires. Le préremplissage des vues en examinant tous les événements pour déterminer l’état actuel peut être la seule façon d’obtenir des informations à partir du magasin d’événements. Si vous n’utilisez pas l’Event Sourcing, demandez-vous si une vue matérialisée peut être utile. Les vues matérialisées ont tendance à être spécifiquement adaptées à un ou à un petit nombre de requêtes. Si de nombreuses requêtes sont utilisées, les vues matérialisées peuvent entraîner des besoins en capacité de stockage et des coûts de stockage inacceptables.

• Cohérence des données. Tenez compte de l’impact sur la cohérence des données lors de la génération de la vue et lors de la mise à jour de la vue si ce processus se produit selon une planification. Si les données sources changent en même temps que la vue est générée, la copie des données de la vue n’est pas entièrement cohérente avec les données d’origine. La fenêtre d’obsolescence maximale est une conséquence directe de l’intervalle d’actualisation ou du décalage de traitement des événements. Définissez donc l’obsolescence acceptable avant de choisir entre l’actualisation planifiée ou manuelle pilotée par les événements.

• Afficher l’emplacement de stockage. La vue ne doit pas forcément se trouver dans le même magasin ou la même partition que les données d’origine. Vous pouvez combiner des sous-ensembles à partir de quelques partitions différentes.

• Reconstruire après une perte. Une vue perdue peut être reconstruite. Par conséquent, si la vue est temporaire et est utilisée uniquement pour améliorer les performances des requêtes en reflétant l’état actuel des données ou pour améliorer l’extensibilité, vous pouvez la stocker dans un cache ou dans un emplacement moins fiable.

  Toutefois, si le processus d’actualisation lui-même échoue à mi-chemin ( par exemple, si une tâche de régénération planifiée se bloque), déterminez si la charge de travail doit servir l’affichage complet précédent, une vue partiellement mise à jour ou aucune vue du tout jusqu’à ce que la régénération réussisse.

  L’approche la plus sûre est généralement une publication atomique ou un remplacement versionné, où votre charge de travail continue à desservir et à utiliser la dernière vue complète tandis que vous créez et validez la nouvelle vue. Échangez vers la nouvelle vue une fois la validation terminée.

• Colonnes calculées. Lors de la définition d’une vue matérialisée, optimisez sa valeur en ajoutant des éléments de données ou des colonnes en fonction du calcul ou de la transformation d’éléments de données existants, des valeurs passées dans la requête ou des combinaisons de ces valeurs le cas échéant.

• Afficher l’indexation. Si le mécanisme de stockage le prend en charge, pensez à indexer la vue matérialisée pour améliorer davantage les performances. De nombreuses bases de données relationnelles prennent en charge l’indexation pour les vues. Toutefois, la maintenance de l’index sur la vue ajoute une surcharge de chemin d’écriture pendant chaque cycle d’actualisation. Équilibrez donc les gains de performances en lecture par rapport au temps d’actualisation et au coût de calcul supplémentaires.

• Contrôle d’accès sur les vues. Lorsqu’une vue matérialisée est utilisée pour restreindre les sous-ensembles de données visibles par certains consommateurs, par exemple pour des raisons de sécurité ou de confidentialité, le magasin d’affichage doit appliquer les mêmes contrôles d’accès que les données sources. Votre pipeline d’actualisation doit exclure des colonnes ou des lignes involontaires, car une vue qui inclut accidentellement des données au-delà de son étendue prévue peut exposer des données protégées.

• Cycle de vie des données sur les vues. Appliquez les exigences de rétention et de suppression des données sources à chaque vue matérialisée. Répercutez les suppressions et les caviardages de la source dans le délai requis, et incluez chaque vue dans le suivi de conformité. Pour plus d’informations, consultez La gouvernance des données et les bases de référence de sécurité avec Microsoft Purview.

• Affichez la gestion du cycle de vie. Traitez les définitions d’affichage comme des artefacts déployables gérés via le contrôle de code source et les pipelines CI/CD, en particulier lorsque les vues sont définies de manière déclarative. Sans gestion du cycle de vie, les définitions d’affichage peuvent dériver entre les environnements, provoquant un comportement de requête incohérent entre le développement, la préproduction et la production.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

• Vous devez créer des vues sur des données difficiles à interroger directement ou où les requêtes doivent être très complexes pour extraire des données stockées de manière normalisée, semi-structurée ou non structurée.
• Vous souhaitez créer des projections mises en cache reconstructibles ou temporaires qui améliorent les performances des requêtes ou qui mettent en forme les données utilisées pour construire des objets de transfert de données destinés à une interface utilisateur, à un rapport ou à un affichage.
• Vous devez prendre en charge des scénarios avec connexion intermittente ou sans connexion, où l’accès au stockage de données n’est pas toujours disponible. Vous pouvez mettre en cache l’affichage localement dans ce cas.
• Vous souhaitez simplifier les requêtes et exposer des données à des fins d’expérimentation d’une manière qui ne nécessite pas de connaissance du format de données source. Par exemple, jointure de tables différentes dans une ou plusieurs bases de données, ou un ou plusieurs domaines dans des banques NoSQL, puis formatage des données en fonction de leur éventuelle utilisation.
• Vous souhaitez fournir l’accès à des sous-ensembles spécifiques des données sources qui, pour des raisons de sécurité ou de confidentialité, ne doivent pas être généralement accessibles, ouverts à la modification ou entièrement exposés aux utilisateurs.
• Vous souhaitez relier différentes sources de données afin de tirer parti de leurs capacités propres. Par exemple, vous pouvez utiliser un magasin cloud efficace pour l’écriture en tant que magasin de données de référence et une base de données relationnelle qui offre de bonnes performances de requête et de lecture pour contenir les vues matérialisées.
• Lorsque vous utilisez des microservices, gardez-les faiblement couplés, y compris leur stockage de données. Les vues matérialisées peuvent vous aider à consolider les données de vos services. Si les vues matérialisées ne sont pas appropriées dans votre architecture de microservices ou dans un scénario spécifique, envisagez d’avoir des limites bien définies qui s’alignent sur la conception pilotée par le domaine (DDD) et agrègent leurs données à la demande.

Ce modèle peut ne pas convenir lorsque :

• La source de données est simple et facile à interroger.
• La source de données change très rapidement ou est accessible sans utilisation d’une vue. Dans ces cas, évitez le surcoût de traitement lié à la création de vues.
• La cohérence est une priorité élevée. Parfois, les vues ne sont pas entièrement cohérentes avec les données d’origine.

Conception de la charge de travail

Un architecte doit évaluer comment le modèle de Vue Matérialisée peut être utilisé dans la conception de leur charge de travail pour répondre aux objectifs et principes couverts par les piliers d’Azure Well-Architected Framework. Par exemple:

Pilier	Comment ce modèle soutient les objectifs des piliers.
L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes par le biais d’optimisations de la mise à l’échelle, des données et du code.	Les vues matérialisées stockent les résultats de calculs ou de requêtes complexes sans nécessiter que le moteur de base de données ou le client les recalculent à chaque demande. Cette conception réduit la consommation globale des ressources. - PE :08 Performance des données

Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.

Exemple

Considérez une application de vente qui stocke les entités Order, OrderItem et Customer dans Azure Table Storage. Les commandes sont partitionnés par ID client, articles de commande par ID de commande et clients par région. Ces clés prennent en charge les modèles d’accès opérationnel de l’application, mais un rapport commercial regroupé par produit doit lire les données entre les partitions et les combiner dans le code de l’application.

La figure suivante montre une vue matérialisée qui stocke la valeur totale des ventes et le nombre de clients d’achat distincts pour chaque produit de la catégorie Électronique. Les lignes sources et les valeurs récapitulatives ne sont pas un jeu de données d’entrée complet pour les totaux affichés.

Trois tableaux apparaissent à gauche : Commande en haut, OrderItem au milieu et Customer en bas. Leurs clés de partition sont respectivement l’ID client, l’ID de commande et la région. Une grande flèche va des tables source vers une vue matérialisée à droite. La vue utilise la catégorie de produit comme clé de partition et l’ID de produit comme clé de ligne. Chaque ligne contient un nom de produit, une valeur de vente totale et un nombre de clients. La vue illustrée comporte deux rangées de produits dans la partition « Electronics ».

Un processus en arrière-plan lit les entités sources requises, associe les articles de commande à leurs commandes et clients, et agrège les ventes par produit. Il compte chaque client une fois par produit, même lorsque ce client a plusieurs commandes ou lignes de commande. Le processus écrit les résultats dans une table récapitulative distincte, avec la catégorie de produit comme PartitionKey et l’ID de produit comme RowKey. Ce tableau récapitulative est une projection gérée par l’application, et non une vue matérialisée native de base de données.

Un tableau de bord peut ensuite interroger la partition Electronics au lieu de répéter les lectures et l’agrégation entre partitions pour chaque requête. Une recherche d’un produit fournit les deux clés. Pour connaître l’impact de ces clés sur les performances des requêtes, consultez Concevoir pour les requêtes.

Actualisez le résumé selon une planification qui répond à la fenêtre d’obsolescence acceptable du rapport. Générez et validez une nouvelle version avant de la publier, afin que les lecteurs continuent à utiliser la version complète précédente lors d’une reconstruction. L’actualisation entraîne toujours des coûts de lecture et d’agrégation entre partitions, mais les requêtes de rapport répétées réutilisent le résultat. Les modifications sources ne sont pas visibles tant qu’une actualisation ultérieure ne les inclut pas.

Étapes suivantes

• Créer des vues indexées décrit comment les bases de données SQL peuvent conserver les résultats de la vue calculée en créant un index sur une vue.
• Les modèles de conception de flux de modification dans Azure Cosmos DB pour NoSQL décrivent comment les consommateurs de flux de modification peuvent conserver des vues matérialisées.
• La vue d’ensemble des vues matérialisées décrit les vues matérialisées dans Azure Data Explorer.
• Azure Managed Redis peut mettre en cache les résultats de requête précomputés en tant que couche optimisée en lecture devant les magasins de données persistants.
• Azure Table Storage pouvez stocker les données de vue précomputées générées par la logique d’application ou un processus en arrière-plan.

Ressources associées

Les modèles suivants peuvent également être pertinents lors de l’implémentation de ce modèle :

• Modèle de séparation des responsabilités en matière de commande et de requête (CQRS). Utilisez ce modèle pour mettre à jour les informations contenues dans une vue matérialisée en réponse aux événements qui se produisent lorsque les valeurs de données sous-jacentes changent.
• Modèle d'approvisionnement en événements. Utilisez ensemble le modèle CQRS pour conserver les informations dans une vue matérialisée. Lorsque les valeurs de données d’une vue matérialisée sont basées sur la modification, le système peut déclencher des événements qui décrivent ces modifications et les enregistrer dans un magasin d’événements.
• Modèle de table d’index. Les données d’une vue matérialisée sont généralement organisées par clé primaire, mais les requêtes doivent parfois récupérer les informations de cette vue en examinant les données d’autres champs. Utilisez ce modèle pour créer des index secondaires sur des jeux de données pour les magasins de données qui ne prennent pas en charge les index secondaires natifs.