Vues matérialisées

  • Article

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 à jour). L’interrogation d’une vue matérialisée est plus performante que l’exécution de l’agrégation directement sur la table source.

Notes

Pourquoi utiliser des vues matérialisées ?

En investissant des ressources (stockage de données, cycles de processeur en arrière-plan) pour les vues matérialisées des 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.

  • Fraîcheur: Une requête d’affichage matérialisé retourne toujours les résultats les plus à jour, indépendamment de la date de la dernière matérialisation. 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és (la delta partie), en 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 à partir du cluster 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 à chaud pour la table source.

Pour obtenir des exemples de cas d’usage, consultez Cas d’usage de la vue matérialisée.

Fonctionnement des vues matérialisées

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

  • Une partie matérialisée : table contenant les enregistrements agrégés de la table source, qui ont déjà été traités. Cette table contient toujours un seul enregistrement par combinaison group-by de l’agrégation.
  • Delta : 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, ce qui fournit 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 dans 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 pour savoir comment résoudre de telles situations.

Requêtes de vues matérialisées

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

  • Interroger l’ensemble de la vue : lorsque vous interrogez la vue matérialisée par son nom, de la même façon que pour interroger 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és (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 dans la vue matérialisée, consultez le fonctionnement des vues matérialisées.
    • Cette option peut ne pas fonctionner de manière optimale, car elle doit matérialiser la partie au moment de la delta requête. Dans ce cas, les performances 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 inclut des moyens 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 l’interrogation de l’ensemble de la vue.
    • Cette fonction est utile pour les scénarios dans lesquels vous êtes prêt à sacrifier une certaine actualisation 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 l’interrogation de la vue entière. Utilisez toujours la fonction lorsqu’elle materialized_view() est applicable à votre cas d’usage.

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

    • Les exemples suivants incluent tous des vues matérialisées par le nom ViewName:
    cluster('cluster1').database('db').ViewName
cluster('cluster1').database('*').ViewName
database('*').ViewName
database('DB*').ViewName
database('*').materialized_view('ViewName')
database('DB*').materialized_view('ViewName')
    • Les exemples suivants n’incluent pas d’enregistrements provenant de vues matérialisées :
    cluster('cluster1').database('db').*
database('*').View*
search in (*)
search *

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

Lors de l’interrogation de l’ensemble de la vue, la partie matérialisée est combinée avec le pendant la 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 est plus efficace 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 les stratégies de synthèse/jointure qui sont censées améliorer les performances des requêtes. Par exemple, la décision de mélanger ou non 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ée 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 falsesur , désactive les optimisations de synthèse/de jointure dans les requêtes d’affichage matérialisée. Utilise des stratégies par défaut. La valeur par défaut est true.
materialized_view_shuffle dynamic Forcer la lecture aléatoire de la requête d’affichage matérialisé et (éventuellement) fournir des clés spécifiques à utiliser. Consultez les exemples ci-dessous.

Exemples

  1. Interrogez l’ensemble de la vue. Les enregistrements les plus récents de la table source sont inclus :

    ViewName

  2. Interrogez uniquement la partie matérialisée de la vue, 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 « conseil » pour utiliser shuffle la stratégie. Les enregistrements les plus récents de la table source sont inclus :

    • Exemple n°1 : lecture aléatoire basée sur la Id colonne (de la même façon que pour l’utilisation de hint.shufflekey=Id) :
    set materialized_view_shuffle = dynamic([{"Name" : "ViewName", "Keys" : [ "Id" ] }]);
ViewName
    • Exemple n°2 : lecture aléatoire basée sur toutes les clés (de la même façon que l’utilisation de hint.strategy=shuffle) :
    set materialized_view_shuffle = dynamic([{"Name" : "ViewName" }]);
ViewName

Considérations relatives aux performances

Les main contributeurs qui peuvent avoir un impact sur l’intégrité d’une vue matérialisée sont les suivants :

  • Ressources de cluster : Comme tout autre processus en cours d’exécution sur le cluster, les vues matérialisées consomment des ressources (processeur, mémoire) du cluster. Si le cluster est surchargé, l’ajout de vues matérialisées peut entraîner une dégradation des performances du cluster. Surveillez l’intégrité de votre cluster à l’aide des métriques d’intégrité du cluster. Actuellement, la mise à l’échelle automatique optimisée ne prend pas en compte l’intégrité des vues matérialisées dans le cadre des règles de mise à l’échelle automatique.

  • Chevauchement avec les données matérialisées : Pendant la matérialisation, tous les nouveaux enregistrements ingérés dans la table source depuis la dernière matérialisation (le 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 sont mauvaises. Une vue matérialisée fonctionne mieux si le nombre d’enregistrements mis à jour (par exemple, dans arg_max la vue) est un petit sous-ensemble de la table source. Si la totalité ou la plupart des enregistrements d’affichage matérialisés doivent être mis à jour dans chaque cycle de matérialisation, la vue matérialisée risque de 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 toujours bien fonctionner. Les performances dépendent de la taille du cluster, des ressources disponibles et de la quantité d’intersection avec les données existantes.

  • Nombre de vues matérialisées dans le cluster : Les considérations ci-dessus s’appliquent à chaque vue matérialisée individuelle définie dans le cluster. Chaque vue consomme ses propres ressources, et de nombreux affichages sont en concurrence entre eux sur les ressources disponibles. Bien qu’il n’existe aucune limite codée en dur au nombre de vues matérialisées dans un cluster, le cluster peut ne pas être en mesure de gérer toutes les vues matérialisées, lorsqu’il y en a beaucoup définis. La stratégie de capacité peut être ajustée s’il existe plusieurs vues matérialisées dans le cluster. Augmentez la valeur de ClusterMinimumConcurrentOperations dans la stratégie pour exécuter des vues plus matérialisées simultanément.

  • Définition de vue matérialisée : la définition de la vue matérialisée doit être définie conformément aux meilleures pratiques de requête pour de meilleures performances de requête. Pour plus d’informations, consultez Créer des conseils sur les performances des commandes.

Vue matérialisée sur 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 toutes les fonctions d’agrégation prises 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 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 Requêtes de vues matérialisées.

Contenu connexe