Choisir un type de matérialisation pour les vues de mesures

Cette page explique comment sélectionner entre les matérialisations agrégées et non agrégées pour les vues de métriques en fonction de vos modèles de requête. Pour ce que chaque type est et comment il fonctionne, consultez Types de matérialisations pour les vues de métriques.

Utilisez le tableau suivant pour trouver la bonne approche pour votre situation. Les sections qui suivent répondent en détail à chaque question.

Matérialisations agrégées

Une matérialisation agrégée est une table de réponses prédéfinie pour un type spécifique de question. Il répond aux requêtes plus rapidement en retournant des résultats pré-calculés au lieu d’analyser les données sources.

Les exemples suivants utilisent une vue métrique des données de vente avec les champs region, category et order_date, ainsi que les mesures total_revenue (SUM), order_count (COUNT) et unique_customers (COUNT(DISTINCT)).

Comment accélérer une requête que j’exécute fréquemment ?

Créer une matérialisation agrégée correspondante. Une requête que vous exécutez quotidiennement est un bon candidat, car la matérialisation retourne des résultats pré-calculés au lieu d’analyser les données sources. Par exemple, supposons que vous exécutez cette requête tous les matins :

SELECT region, MEASURE(total_revenue) FROM sales_mv GROUP BY ALL

Si vous interrogez souvent region et order_date ensemble, incluez les deux champs dans une seule matérialisation :

- name: revenue_by_region_date
  type: aggregated
  dimensions:
    - region
    - order_date
  measures:
    - total_revenue
    - order_count

Une matérialisation à une granularité plus fine (par région et par date, au lieu de la seule région) signifie que toute requête regroupant par region seul, par order_date seul, ou par les deux peut exploiter cette matérialisation. L’inclusion de mesures additives telles que order_count permet d’utiliser la même matérialisation pour les requêtes portant sur ces mesures, de sorte que vous n’avez pas besoin de créer une matérialisation distincte pour chacune d’elles.

Comment savoir si une matérialisation existante couvre une nouvelle requête ?

Comparez les dimensions de la requête GROUP BY à celles de la matérialisation. Si la matérialisation n’inclut pas une dimension utilisée dans le regroupement, la requête ne peut pas l’utiliser. Par exemple, supposons que vous souhaitiez connaître le chiffre d’affaires par category, mais que la seule matérialisation dont vous disposez soit l’exemple revenue_by_region_date présenté précédemment. Étant donné qu’il n’inclut pas category, les requêtes qui regroupent par category se rabattent sur une matérialisation non agrégée (le cas échéant) ou sur les tables sources.

Si vous effectuez souvent des requêtes sur category, créez une matérialisation distincte pour celui-ci. Si la requête est peu fréquente ou déjà assez rapide, ne créez pas celle-ci. Chaque matérialisation entraîne un coût de stockage et de rafraîchissement.

Comment accélérer une requête avec une mesure non additive ?

Créez une matérialisation agrégée dont les dimensions correspondent exactement à la requête GROUP BY . Les mesures non additives, telles que COUNT(DISTINCT), ne peuvent pas être agrégées à partir d’une matérialisation issue d’un niveau de granularité plus fin ; une matérialisation à un niveau de granularité différent ne sera donc d’aucune aide. Par exemple, supposons que cette requête soit lente :

SELECT region, MEASURE(unique_customers) FROM sales_mv GROUP BY ALL

unique_customers utilise COUNT(DISTINCT), qui n’est pas additif. La revenue_by_region_date matérialisation présentée précédemment a des dimensions différentes, de sorte qu’elle ne peut pas servir cette requête. Créez une matérialisation avec des dimensions qui correspondent :

- name: customers_by_region
  type: aggregated
  dimensions:
    - region
  measures:
    - unique_customers

Matérialisations non agrégées

Une matérialisation non agrégée est un point de départ prédéfini, et non une réponse prédéfinie. Il effectue le travail coûteux de jointure de tables et d’application de filtres une seule fois, afin que les requêtes puissent agréger à partir du résultat joint au lieu de joindre à nouveau les tables sources sur chaque exécution.

L’agrégation se produit toujours lors de la requête, de sorte que les matérialisations non agrégées ne sont pas aussi rapides que celles qui sont agrégées. Ils sont plus rapides que de refaire les jointures à partir des tables sources brutes à chaque requête.

Les exemples suivants utilisent une vue de métrique qui joint trois tables et applique un filtre :

source: raw_events
filter: event_type = 'purchase'
joins:
  - name: customers
    source: dim_customers
    on: customers.id = source.customer_id
  - name: products
    source: dim_products
    on: products.id = source.product_id

Quel type dois-je utiliser pour les modèles de requête imprévisibles ?

Utilisez une matérialisation non agrégée. Lorsque vous exécutez des requêtes ad hoc en permanence et que vous ne pouvez pas prédire le GROUP BY, il est difficile de définir des matérialisations agrégées qui couvrent les champs appropriés. Une matérialisation non agrégée dissocie ce problème : il matérialise le jeu de données joint, filtré une seule fois et toute requête peut l’utiliser indépendamment de sa forme.

materialized_views:
  - name: baseline
    type: unaggregated

Dois-je matérialiser une table unique sans jointure ?

Une matérialisation non agrégée d’une seule table, sans jointures ni filtres, duplique la table sans aucun avantage. Utilisez des matérialisations agrégées pour les modèles de requête connus ou ignorez entièrement la matérialisation.

Puis-je utiliser les deux types de matérialisation ensemble ?

Yes. Utilisez une matérialisation non agrégée en solution de repli, et des matérialisations agrégées pour vos requêtes connues à fort trafic. Ce schéma correspond à une vue de métriques comportant des jointures coûteuses, ainsi qu’à un tableau de bord de widgets prédéfinis. La réécriture de requêtes privilégie les matérialisations agrégées (correspondance exacte ou par sur-agrégation) lorsque cela est possible et se rabat sur des matérialisations non agrégées dans tous les autres cas.

materialized_views:
  - name: baseline
    type: unaggregated
  - name: revenue_by_region_date
    type: aggregated
    dimensions:
      - region
      - order_date
    measures:
      - total_revenue

Lors de la création de matérialisations, commencez par cibler vos requêtes les plus lentes ou les plus sollicitées. Ajoutez davantage de matérialisations lorsque vous constatez que des requêtes reviennent à la source. Pour vérifier si une requête utilise une matérialisation, consultez Vérifier qu’une requête utilise des vues matérialisées.