Vues matérialisées

S’applique à : ✅Microsoft Fabric✅Azure Data Explorer

Les vues matérialisées exposent une requête d’agrégation sur une table source ou sur une autre vue matérialisée.

Les vues matérialisées retournent toujours un résultat à jour de la requête d’agrégation (toujours frais). L’interrogation d’une vue matérialisée est plus performante que l’exécution de l’agrégation directement sur la table source.

Remarque

• Pour déterminer si les vues matérialisées conviennent pour vous, passez en revue les cas d’utilisation des vues matérialisées.
• Les vues matérialisées présentent certaines limitations. Avant d’utiliser la fonctionnalité, passez en revue les considérations relatives aux performances.
• Envisagez d’utiliser des stratégies de mise à jour le cas échéant. Pour plus d’informations, consultez Vues matérialisées et stratégies de mise à jour.
• Surveillez l’intégrité de vos vues matérialisées en fonction des recommandations dans Surveiller les vues matérialisées.

Pourquoi utiliser des vues matérialisées ?

En investissant des ressources (stockage de données, cycles processeur en arrière-plan) pour des vues matérialisées d’agrégations couramment utilisées, vous bénéficiez des avantages suivants :

• Amélioration des performances : l’interrogation d’une vue matérialisée fonctionne généralement mieux que l’interrogation de la table source pour les mêmes fonctions d’agrégation.

• Actualisation : une requête de vue matérialisée retourne toujours les résultats les plus à jour, indépendamment du moment où la matérialisation a eu lieu pour la dernière fois. La requête combine la partie matérialisée de la vue avec les enregistrements de la table source, qui n’ont pas encore été matérialisées (la delta partie), fournissant toujours les résultats les plus à jour.

• Réduction des coûts : l’interrogation d’une vue matérialisée consomme moins de ressources que d’effectuer l’agrégation sur la table source. La stratégie de rétention de la table source peut être réduite si seule l’agrégation est requise. Cette configuration réduit les coûts de cache chauds pour la table source.

Pour obtenir des exemples de cas d’usage, consultez les cas d’utilisation de l’affichage matérialisé.

Fonctionnement des vues matérialisées

Une vue matérialisée est constituée de deux composants :

• Partie matérialisée : table contenant des enregistrements agrégés de la table source, qui ont déjà été traitées. Cette table contient toujours un enregistrement unique par combinaison de groupes d’agrégation.
• Delta : les enregistrements nouvellement ingérés dans la table source qui n’ont pas encore été traités.

L’interrogation de la vue matérialisée combine la partie matérialisée avec la partie delta, fournissant un résultat à jour de la requête d’agrégation. Le processus de matérialisation hors connexion ingère de nouveaux enregistrements du delta vers la table matérialisée et met à jour les enregistrements existants. Si l’intersection entre le delta et la partie matérialisée est importante et que de nombreux enregistrements nécessitent des mises à jour, cela peut avoir un impact négatif sur le processus de matérialisation. Consultez surveiller les vues matérialisées sur la façon de résoudre ces situations.

Requêtes de vues matérialisées

Il existe 2 façons d’interroger une vue matérialisée :

• Interrogez l’intégralité de la vue : lorsque vous interrogez la vue matérialisée par son nom, de la même façon que l’interrogation d’une table, la requête de vue matérialisée combine la partie matérialisée de la vue avec les enregistrements de la table source qui n’ont pas encore été matérialisées (le delta).

  • L’interrogation de la vue matérialisée retourne toujours les résultats les plus à jour, en fonction de tous les enregistrements ingérés dans la table source. Pour plus d’informations sur les parties matérialisées et non matérialisées en mode matérialisé, consultez le fonctionnement des vues matérialisées.
  • Cette option peut ne pas s’avérer optimale, car elle doit matérialiser la partie pendant le delta temps de la requête. Les performances dans ce cas dépendent de l’âge de la vue et des filtres appliqués dans la requête. La section optimiseur de requête de vue matérialisée comprend des façons possibles d’améliorer les performances des requêtes lors de l’interrogation de l’ensemble de la vue.

• Interroger la partie matérialisée uniquement : une autre façon d’interroger la vue consiste à utiliser la materialized_view() fonction. Cette option prend en charge l’interrogation uniquement de la partie matérialisée de la vue, tout en spécifiant la latence maximale que l’utilisateur est prêt à tolérer.

  • Cette option n’est pas garantie de retourner les enregistrements les plus à jour, mais elle doit toujours être plus performante que d’interroger l’intégralité de l’affichage.
  • Cette fonction est utile pour les scénarios dans lesquels vous êtes prêt à sacrifier une certaine fraîcheur pour les performances, par exemple pour les tableaux de bord de télémétrie.

Conseil

Les requêtes sur la partie matérialisée fonctionnent toujours mieux que d’interroger l’intégralité de la vue. Utilisez toujours la fonction quand elle s’applique materialized_view() à votre cas d’usage.

• Les vues matérialisées participent à des requêtes inter-Eventhouse ou inter-bases de données, mais ne sont pas incluses dans des unions génériques ou des recherches.

  • Les exemples suivants incluent tous les affichages matérialisés par le nom ViewName:

  cluster("<serviceURL>").database('db').ViewName
  cluster("<serviceURL>").database('*').ViewName
  database('*').ViewName
  database('DB*').ViewName
  database('*').materialized_view('ViewName')
  database('DB*').materialized_view('ViewName')
  

  • Les exemples suivants n’incluent pas d’enregistrements à partir de vues matérialisées :

  cluster("<serviceURL>").database('db').*
  database('*').View*
  search in (*)
  search * 
  

Optimiseur de requête de vue matérialisée

Lors de l’interrogation de l’intégralité de la vue, la partie matérialisée est combinée avec le temps de delta requête. Cela inclut l’agrégation et la delta jointure à la partie matérialisée.

• L’interrogation de l’ensemble de la vue s’effectue mieux si la requête inclut des filtres sur le groupe par clés de la requête de vue matérialisée. Consultez d’autres conseils sur la création de votre vue matérialisée, en fonction de votre modèle de requête, dans la section conseils sur les .create materialized-view performances.
• L’optimiseur de requête choisit des stratégies de synthèse/jointure qui sont censées améliorer les performances des requêtes. Par exemple, la décision d’effectuer un shuffle de la requête est basée sur le nombre d’enregistrements en delta partie. Les propriétés de requête client suivantes fournissent un certain contrôle sur les optimisations appliquées. Vous pouvez tester ces propriétés avec vos requêtes de vue matérialisées et évaluer leur impact sur les performances des requêtes.

Nom de la propriété de requête du client	Type	Description
materialized_view_query_optimization_costbased_enabled	bool	Si la valeur est définie false, désactive les optimisations de synthèse/jointure dans les requêtes de vue matérialisées. Utilise des stratégies par défaut. La valeur par défaut est true.
materialized_view_shuffle	dynamic	Forcez le shuffling de la requête de vue matérialisée, et (éventuellement) fournissez des clés spécifiques pour effectuer une lecture aléatoire. Consultez les exemples ci-dessous.

ingestion_time() fonction dans le contexte des vues matérialisées

ingestion_time() fonction retourne des valeurs Null, lorsqu’elle est utilisée dans le contexte d’une vue matérialisée, si vous interrogez l’intégralité de la vue. Lors de l’interrogation de la partie matérialisée de la vue, la valeur de retour dépend du type de vue matérialisée :

• Dans les vues matérialisées qui incluent une agrégation uniquearg_max()/arg_min()take_any()/, elle ingestion_time() est égale à l’enregistrement ingestion_time() correspondant dans la table source.
• Dans toutes les autres vues matérialisées, la valeur est ingestion_time() approximativement le temps de matérialisation (voir comment fonctionnent les vues matérialisées).

Exemples

1. Interrogez l’intégralité de l’affichage. Les enregistrements les plus récents de la table source sont inclus :

   ViewName
   

2. Interrogez la partie matérialisée de la vue uniquement, quel que soit le moment où elle a été matérialisée pour la dernière fois.

   materialized_view("ViewName")
   

3. Interrogez l’ensemble de la vue et fournissez un « indicateur » pour utiliser la shuffle stratégie. Les enregistrements les plus récents de la table source sont inclus :

   • Exemple n°1 : shuffle basé sur la Id colonne (de la même façon que l’utilisation hint.shufflekey=Id) :

   set materialized_view_shuffle = dynamic([{"Name" : "ViewName", "Keys" : [ "Id" ] }]);
   ViewName
   

   • Exemple n°2 : aléatoire en fonction de toutes les clés (de la même façon que l’utilisation hint.strategy=shuffle) :

   set materialized_view_shuffle = dynamic([{"Name" : "ViewName" }]);
   ViewName
   

Considérations relatives aux performances

Les principaux contributeurs qui peuvent avoir un impact sur l’intégrité de la vue matérialisée sont les suivants :

• Chevauchement avec les données matérialisées : lors de la matérialisation, tous les nouveaux enregistrements ingérés dans la table source depuis la dernière matérialisation (delta) sont traités et matérialisés dans la vue. Plus l’intersection entre les nouveaux enregistrements et les enregistrements déjà matérialisés est élevée, plus les performances de la vue matérialisée seront pires. Une vue matérialisée fonctionne mieux si le nombre d’enregistrements mis à jour (par exemple, en arg_max mode) est un petit sous-ensemble de la table source. Si tous ou la plupart des enregistrements de vue matérialisés doivent être mis à jour dans chaque cycle de matérialisation, la vue matérialisée peut ne pas fonctionner correctement.

• Taux d’ingestion : il n’existe aucune limite codée en dur sur le volume de données ou le taux d’ingestion dans la table source de la vue matérialisée. Toutefois, le taux d’ingestion recommandé pour les vues matérialisées n’est pas supérieur à 1 à 2 Go/s. Des taux d’ingestion plus élevés peuvent encore s’effectuer correctement. Les performances dépendent de la taille de la base de données, des ressources disponibles et de la quantité d’intersection avec les données existantes.

• Définition de vue matérialisée : la définition de vue matérialisée doit être définie en fonction des meilleures pratiques de requête pour optimiser les performances des requêtes. Pour plus d’informations, consultez créer des conseils sur les performances des commandes.

Vue matérialisée sur la vue matérialisée

Une vue matérialisée peut être créée sur une autre vue matérialisée si la vue matérialisée source est une vue de déduplication. Plus précisément, l’agrégation de la vue matérialisée source doit être take_any(*) pour dédupliquer les enregistrements sources. La deuxième vue matérialisée peut utiliser n’importe quelle fonction d’agrégation prise en charge. Pour plus d’informations sur la création d’une vue matérialisée sur une vue matérialisée, consultez .create materialized-view la commande.

Conseil

Lors de l’interrogation d’une vue matérialisée définie sur une autre vue matérialisée, nous vous recommandons d’interroger la partie matérialisée uniquement à l’aide de la materialized_view() fonction. L’interrogation de l’ensemble de la vue n’est pas performante lorsque les deux vues ne sont pas entièrement matérialisées. Pour plus d’informations, consultez les requêtes de vues matérialisées.

Contenu connexe

• Stratégies de vues matérialisées
• Limitations des vues matérialisées et problèmes connus
• Cas d’utilisation des vues matérialisées
• Superviser les vues matérialisées
• .create materialized view
• .alter materialized-view
• {.disable | .enable} materialized-view