Scegliere un tipo di materializzazione per le visualizzazioni delle metriche

Questa pagina descrive come selezionare tra materializzazioni aggregate e non raggruppate per le visualizzazioni delle metriche in base ai modelli di query. Per informazioni su ogni tipo e sul relativo funzionamento, vedere Tipi di materializzazioni per le visualizzazioni delle metriche.

Usare la tabella seguente per trovare l'approccio corretto per la situazione. Le sezioni che seguono rispondono in dettaglio a ogni domanda.

Materializzazioni aggregate

Una materializzazione aggregata è una tabella di risposte predefinita per un tipo specifico di domanda. Gestisce le query corrispondenti più velocemente restituendo risultati pre-calcolati invece di analizzare i dati di origine.

Gli esempi seguenti utilizzano una vista metrica dei dati di vendita con i campi region, category e order_date e le misure total_revenue (SUM), order_count (COUNT) e unique_customers (COUNT(DISTINCT)).

Come è possibile velocizzare l'esecuzione di una query con frequenza?

Crea una materializzazione aggregata per questo. Una query eseguita quotidianamente è un buon candidato, perché la materializzazione restituisce risultati pre-calcolati anziché analizzare i dati di origine. Si supponga, ad esempio, di eseguire questa query ogni mattina:

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

Se si interrogano spesso region e order_date insieme, includi entrambi i campi in un'unica materializzazione:

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

La materializzazione a una granularità più fine (regione e data anziché solo regione) significa che qualsiasi query con raggruppamento per region soltanto, per order_date soltanto o per entrambi può utilizzare questa materializzazione. L'inclusione di misure additive, order_count ad esempio, consente alla stessa materializzazione di gestire le query per tali misure, quindi non è necessario crearne una separata per ognuna.

Come è possibile sapere se una materializzazione esistente copre una nuova query?

Confronta le dimensioni della query GROUP BY con quelle della materializzazione. Se la materializzazione non include una dimensione in base alla quale si effettua il raggruppamento, la query non può usarla. Si supponga, ad esempio, di voler ottenere ricavi per category, ma l'unica materializzazione è l'esempio revenue_by_region_date illustrato in precedenza. Poiché non include category, le query che eseguono il raggruppamento in base a category ricorrono a una materializzazione non aggregata (se presente) o alle tabelle di origine.

Se esegui spesso query per category, crea una materializzazione separata. Se la query è poco frequente o già abbastanza veloce, non crearne una. Ogni materializzazione aggiunge costi di archiviazione e aggiornamento.

Come posso velocizzare una query con una misura non additiva?

Creare una materializzazione aggregata le cui dimensioni corrispondono esattamente alla query GROUP BY . Le misure non additive, come COUNT(DISTINCT), non possono essere aggregate a partire da una materializzazione a granularità più fine, quindi una materializzazione con una granularità diversa non sarà utile. Si supponga, ad esempio, che questa query sia lenta:

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

unique_customers utilizza COUNT(DISTINCT), che non è additivo. La revenue_by_region_date materializzazione illustrata in precedenza ha dimensioni diverse, quindi non può gestire questa query. Creare una materializzazione con dimensioni corrispondenti:

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

Materializzazioni non raggruppate

Una materializzazione non raggruppata è un punto di partenza predefinito, non una risposta predefinita. Esegue una sola volta l'operazione onerosa di join tra tabelle e di applicazione dei filtri, così che le query possano eseguire aggregazioni sul risultato della join invece di dover unire nuovamente le tabelle di origine a ogni esecuzione.

L'aggregazione avviene ancora in fase di query, quindi le materializzazioni non raggruppate non sono veloci quanto quelle aggregate. Sono più veloci che rifare il join dalle tabelle sorgente grezze a ogni query.

Gli esempi seguenti usano una visualizzazione metrica che unisce tre tabelle e applica un filtro:

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

Quale tipo è consigliabile usare per i modelli di query imprevedibili?

Usare una materializzazione non raggruppata. Quando si eseguono costantemente query ad hoc e non è possibile prevedere il GROUP BY, è difficile definire materializzazioni di aggregazione che includano i campi giusti. Una materializzazione non aggregata aggira questo problema: materializza una sola volta il set di dati risultante dalla join e dal filtro, e qualsiasi query può utilizzarlo indipendentemente dalla sua struttura.

materialized_views:
  - name: baseline
    type: unaggregated

Devo materializzare una singola tabella senza join?

Una materializzazione non raggruppata in una singola tabella senza join o filtri duplica la tabella senza alcun vantaggio. Usare materializzazioni aggregate per i modelli di query noti o ignorare completamente la materializzazione.

È possibile usare entrambi i tipi di materializzazione insieme?

Yes. Usare una materializzazione non aggregata come soluzione di ripiego e materializzazioni aggregate per le query ad alto traffico già note. Questo schema è adatto a una vista delle metriche con join onerosi e a una dashboard di widget già noti. La riscrittura delle query privilegia, quando possibile, le materializzazioni aggregate (con corrispondenza esatta o rollup) e per tutto il resto ripiega su quelle non aggregate.

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

Quando si creano materializzazioni, dare priorità innanzitutto alle query più lente o con il traffico più elevato. Aggiungi altre materializzazioni se noti che le query tornano a usare l'origine. Per verificare se una query usa una materializzazione, vedere Verificare che una query usi viste materializzate.