Partage via

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 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

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 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 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-clusters 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('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 à partir 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’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.

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 :

  • Ressources de cluster : comme tout autre processus s’exécutant sur le cluster, les vues matérialisées consomment des ressources (processeur, mémoire) à partir 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 : 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 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 nombreuses vues se concurrencent les unes avec les autres 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, il se peut que le cluster ne puisse pas gérer toutes les vues matérialisées, lorsqu’il existe de nombreux éléments définis. La stratégie de capacité peut être ajustée s’il existe plus d’une vue matérialisée unique dans le cluster. Augmentez la valeur de ClusterMinimumConcurrentOperations 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 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