Modello di vista materializzata

Generare viste prepopolate sui dati in uno o più archivi dati quando i dati non sono idealmente formattati per le operazioni di query necessarie. Questo approccio può supportare query efficienti ed estrazione dei dati e migliorare le prestazioni dell'applicazione.

Contesto e problema

Quando si archiviano dati, gli sviluppatori e gli amministratori di dati spesso assegnano priorità alla modalità di archiviazione dei dati anziché alla modalità di lettura. Il formato di archiviazione scelto riflette in genere il formato dei dati, i requisiti per la gestione delle dimensioni dei dati e l'integrità dei dati e il tipo di archivio in uso. Ad esempio, quando si usa un archivio documenti NoSQL, spesso si rappresentano i dati come una serie di aggregazioni, ognuna contenente tutte le informazioni per tale entità.

Tuttavia, questo approccio può avere un effetto negativo sulle query. Quando una query richiede solo un subset dei dati di alcune entità, ad esempio un riepilogo degli ordini per diversi clienti senza tutti i dettagli degli ordini, è necessario estrarre tutti i dati per le entità rilevanti per ottenere le informazioni necessarie.

L'aggiunta di indici o la ridevisione delle query in fase di lettura non risolve sempre questa inefficienza. Molti archivi non possono essere reindicizzati per schemi di lettura arbitrari senza compromettere le prestazioni di scrittura. L'aggregazione tra più entità rimane costosa in fase di esecuzione della query. Alcuni archivi hanno capacità di query limitate per progettazione. A causa di questi vincoli, l'ottimizzazione del percorso di lettura all'interno dell'archivio di origine è spesso insufficiente.

Soluzione

Per supportare interrogazioni efficienti, una soluzione comune consiste nel generare preventivamente una vista che materializza i dati in un formato adatto all'insieme di risultati richiesto. Il modello di vista materializzata descrive la generazione di viste prepopolate dei dati in ambienti in cui i dati di origine non sono in un formato adatto per l'esecuzione di query, in cui è difficile generare una query appropriata o in cui le prestazioni di query sono scarse a causa della natura dei dati o dell'archivio dati.

In questo modello, una vista materializzata è un modello o una proiezione di lettura che rende persistenti i dati derivati da uno o più archivi di origine. Una pipeline di dati dedicata o un componente applicativo dedicato può mantenere la proiezione, anche tra archivi distinti. I componenti delle query trattano la proiezione come di sola lettura. Questo concetto di architettura è più ampio di un oggetto vista materializzato nativo del database, che un motore di database definisce, archivia e aggiorna in base ai propri vincoli di funzionalità.

Queste viste materializzate, che contengono solo i dati richiesti da una query, consentono alle applicazioni di ottenere rapidamente le informazioni necessarie. Oltre a unire le tabelle o combinare le entità di dati, le viste materializzate possono includere i valori correnti delle colonne calcolate o degli elementi di dati, i risultati della combinazione di valori o dell'esecuzione di trasformazioni sugli elementi di dati e i valori specificati come parte della query. Una vista materializzata può anche essere ottimizzata per una singola query.

Un punto chiave è che una vista materializzata e i dati che contiene possono essere completamente eliminati, perché possono essere interamente ricostruiti a partire dagli archivi dati sorgente. I consumer di query non aggiornano direttamente la vista. Al contrario, un componente dedicato, una pipeline di dati o un motore di database lo gestisce, quindi si tratta di una cache specializzata.

Quando i dati di origine per la vista cambiano, la vista deve essere aggiornata per includere le nuove informazioni. È possibile pianificare questo aggiornamento in modo che venga eseguito automaticamente o quando il sistema rileva una modifica ai dati originali. In alcuni casi, potrebbe essere necessario rigenerare manualmente la visualizzazione. Nella figura seguente viene illustrato un esempio di utilizzo del modello Visualizzazione materializzata.

Diagramma che mostra un esempio di come può essere usato il modello visualizzazione materializzata.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente quanto segue:

  • Visualizzare la strategia di aggiornamento. Idealmente, la vista rigenera in risposta a un evento che indica una modifica ai dati di origine, anche se questo approccio può causare un sovraccarico eccessivo se i dati di origine cambiano rapidamente. In alternativa, è possibile usare un'attività pianificata, un trigger esterno o un'azione manuale per rigenerare la vista.

  • Comportamento di aggiornamento. Determinare se l'implementazione esegue una ricompilazione completa o applica le modifiche in modo incrementale. È anche necessario decidere se le operazioni di aggiornamento bloccano le letture.

    Queste decisioni determinano se le query restituiscono dati materializzati potenzialmente obsoleti, combinano dati materializzati con modifiche all'origine non elaborate per restituire i risultati correnti o continuano a servire l'ultima versione completa fino al termine dell'aggiornamento.

  • Aggiornare l'affidabilità del segnale. Se il segnale di attivazione che attiva la rigenerazione della visualizzazione viene perso o ritardato, ad esempio un evento di feed di modifiche perso o un'attività pianificata non riuscita, la visualizzazione fornisce automaticamente risultati non aggiornati. Monitorare la recenza dell'aggiornamento e avvisare quando l'età della vista supera l'intervallo di obsolescenza accettabile.

  • Aggiornare il costo di calcolo. La rigenerazione di una vista utilizza risorse di calcolo proporzionali al volume dei dati di origine e alla complessità delle trasformazioni. Per l'aggiornamento guidato dagli eventi sui dati di origine in rapida evoluzione o per le ricompilazione complete di viste analitiche di grandi dimensioni, il costo di calcolo dell'aggiornamento può essere un fattore di costo significativo. Dimensiona correttamente la frequenza e l'ambito dell'aggiornamento per bilanciare la freschezza dei dati con i costi di elaborazione.

  • Dipendenza da Event Sourcing In alcuni sistemi, ad esempio quando si usa il modello di origine eventi per mantenere un archivio solo degli eventi che hanno modificato i dati, le viste materializzate sono in genere necessarie. Prepopolare le viste esaminando tutti gli eventi per determinare lo stato corrente potrebbe essere l'unico modo per ottenere informazioni dall'archivio eventi. Se non utilizzi Event Sourcing, valuta se una vista materializzata può essere utile. Le viste materializzate tendono a essere personalizzate in modo specifico per una o un numero ridotto di query. Se si utilizzano molte query, le viste materializzate possono risultare in requisiti di capacità di archiviazione e costi di archiviazione inaccettabili.

  • Coerenza dei dati. Si consideri l'impatto sulla coerenza dei dati durante la generazione della vista e quando si aggiorna la vista se questo processo si verifica in base a una pianificazione. Se i dati di origine cambiano contemporaneamente alla visualizzazione, la copia dei dati nella vista non è completamente coerente con i dati originali. La finestra di decadimento massimo è una conseguenza diretta dell'intervallo di aggiornamento o del ritardo di elaborazione degli eventi, quindi definire lo decadimento accettabile prima di scegliere tra l'aggiornamento guidato dagli eventi, pianificato o manuale.

  • Visualizzare la posizione di archiviazione. La vista non deve necessariamente trovarsi nello stesso archivio o partizione dei dati originali. È possibile combinare subset da alcune partizioni diverse.

  • Ricostruisci in caso di perdita. Una visualizzazione può essere ricostruita se va persa. Pertanto, se la vista è temporanea e viene usata solo per migliorare le prestazioni delle query riflettendo lo stato corrente dei dati o per migliorare la scalabilità, è possibile archiviarla in una cache o in una posizione meno affidabile.

    Tuttavia, se il processo di aggiornamento stesso fallisce a metà, ad esempio se un'attività di rigenerazione pianificata si arresta in modo anomalo, occorre stabilire se il carico di lavoro debba mostrare la precedente vista completa, una vista parzialmente aggiornata oppure nessuna vista finché la rigenerazione non viene completata con successo.

    L'approccio più sicuro è in genere la pubblicazione atomica o la sostituzione con controllo delle versioni, in cui l'applicazione continua a usare l'ultima vista completa mentre crei e convalidi la nuova vista. Passare alla nuova visualizzazione al termine della convalida.

  • Colonne calcolate. Quando si definisce una vista materializzata, ottimizzarne il valore aggiungendo elementi di dati o colonne in base al calcolo o alla trasformazione degli elementi di dati esistenti, ai valori passati nella query o alle combinazioni di questi valori, quando appropriato.

  • Visualizza indicizzazione. Se il meccanismo di archiviazione lo consente, è possibile indicizzare la vista materializzata per migliorare ulteriormente le prestazioni. Molti database relazionali supportano l'indicizzazione per le viste. Tuttavia, la manutenzione dell'indice sulla vista aggiunge un sovraccarico nelle operazioni di scrittura durante ogni ciclo di aggiornamento, quindi occorre bilanciare i guadagni in prestazioni di lettura con il maggior tempo di aggiornamento e il costo di calcolo aggiuntivo.

  • Controllo di accesso nelle visualizzazioni. Quando una vista materializzata viene utilizzata per limitare quali sottoinsiemi di dati siano visibili a determinati utenti, ad esempio per motivi di sicurezza o privacy, l'archivio della vista deve applicare gli stessi controlli di accesso dei dati di origine, o controlli più restrittivi. La pipeline di aggiornamento deve escludere colonne o righe indesiderate, perché una vista che include accidentalmente dati oltre l'ambito previsto può esporre dati protetti.

  • Ciclo di vita dei dati nelle visualizzazioni. Applicare i requisiti di conservazione ed eliminazione dei dati di origine a ogni vista materializzata. Propagare eliminazioni di origine e redazioni entro il periodo richiesto e includere ogni visualizzazione nel monitoraggio della conformità. Per altre informazioni, vedere Governance dei dati e baseline di sicurezza con Microsoft Purview.

  • Visualizzare la gestione del ciclo di vita. Considerare le definizioni di visualizzazione come artefatti distribuibili gestiti tramite il controllo del codice sorgente e le pipeline CI/CD, soprattutto quando le viste vengono definite in modo dichiarativo. Senza la gestione del ciclo di vita, le definizioni delle viste possono differire tra gli ambienti, causando comportamenti incoerenti delle query tra sviluppo, staging e produzione.

Quando usare questo modello

Usare questo modello quando:

  • È necessario creare viste sui dati difficili da eseguire direttamente o in cui le query devono essere molto complesse per estrarre i dati archiviati in modo normalizzato, semistrutturato o non strutturato.
  • Si desidera creare proiezioni ricompilabili o temporanee memorizzate nella cache che migliorano le prestazioni delle query o che consentono di costruire oggetti di trasferimento dei dati per un'interfaccia utente, un report o una visualizzazione.
  • È necessario supportare scenari occasionalmente connessi o disconnessi in cui la connessione all'archivio dati non è sempre disponibile. In questo caso, è possibile memorizzare nella cache la visualizzazione in locale.
  • Si vogliono semplificare le query ed esporre i dati per la sperimentazione in modo da non richiedere la conoscenza del formato dei dati di origine. Ad esempio, unendo tabelle diverse in uno o più database o uno o più domini in archivi NoSQL e quindi formattando i dati in base all'uso previsto.
  • Si vuole fornire l'accesso a subset specifici dei dati di origine che, per motivi di sicurezza o privacy, non devono essere generalmente accessibili, aperti alla modifica o completamente esposti agli utenti.
  • Si vogliono collegare diversi archivi dati per sfruttare le singole funzionalità. Ad esempio, è possibile usare un archivio cloud efficiente per la scrittura come archivio dati di riferimento e un database relazionale che offre buone prestazioni di query e lettura per contenere le viste materializzate.
  • Quando si utilizzano i microservizi, è opportuno mantenerli debolmente accoppiati, compreso il relativo archivio dati. Le viste materializzate consentono di consolidare i dati provenienti dai servizi. Se le viste materializzate non sono adatte alla tua architettura di microservizi o al tuo scenario specifico, valuta la possibilità di definire confini ben definiti in linea con il domain-driven design (DDD) e di aggregarne i dati su richiesta.

Questo modello potrebbe non essere adatto quando:

  • I dati di origine sono semplici ed è facile eseguire query su di essi.
  • I dati di origine cambiano molto rapidamente oppure è possibile accedervi senza usare una vista. In questi casi, evitare il sovraccarico di elaborazione della creazione di visualizzazioni.
  • La coerenza è molto importante. Le viste potrebbero non essere sempre completamente coerenti con i dati originali.

Progettazione del carico di lavoro

Un architetto deve valutare il modo in cui il modello di vista materializzato può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Per esempio:

Pilastro Come questo modello supporta gli obiettivi di pilastro
l'efficienza delle prestazioni consente al carico di lavoro soddisfare in modo efficiente le richieste tramite ottimizzazioni di ridimensionamento, dati e codice. Le viste materializzate archiviano i risultati di calcoli o query complessi senza richiedere al motore di database o al client di ricompilare per ogni richiesta. Questa progettazione riduce l'utilizzo complessivo delle risorse.

- Prestazioni dei dati PE:08

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Example

Si consideri un'applicazione di vendita che archivia le entità Order, OrderItem e Customer in Archiviazione tabelle di Azure. Gli ordini vengono partizionati in base all'ID cliente, agli elementi dell'ordine in base all'ID ordine e ai clienti in base all'area geografica. Queste chiavi supportano i modelli di accesso operativo dell'applicazione, ma un report di vendita raggruppato per prodotto deve leggere i dati tra le partizioni e combinarli nel codice dell'applicazione.

La figura seguente mostra una visualizzazione materializzata che archivia il valore totale delle vendite e il numero di clienti di acquisto distinti per ogni prodotto nella categoria Electronics. Le righe di origine e i valori di riepilogo sono illustrativi, non un set di dati di input completo per i totali visualizzati.

Diagramma che mostra le tabelle Order, OrderItem e Customer combinate in un riepilogo delle vendite materializzato partizionato per categoria di prodotti.

Un processo in background legge le entità sorgente richieste, associa le voci d’ordine ai rispettivi ordini e clienti e aggrega le vendite per prodotto. Conta ogni cliente una volta per prodotto, anche quando il cliente ha più ordini o righe di ordine. Il processo scrive i risultati in una tabella di riepilogo separata con categoria di prodotto come PartitionKey e ID prodotto come RowKey. Questa tabella di riepilogo è una proiezione gestita dall'applicazione, non una vista materializzata nativa del database.

Un dashboard può quindi eseguire una query sulla partizione Electronics invece di ripetere le letture e l'aggregazione tra partizioni per ogni richiesta. Una ricerca per un prodotto fornisce entrambe le chiavi. Per le implicazioni relative alle prestazioni delle query di queste chiavi, vedere Progettare per l'esecuzione di query.

Aggiornare il riepilogo in base a una pianificazione che soddisfi la finestra di decadimento accettabile del report. Compilare e convalidare una nuova versione prima di pubblicarla, in modo che i lettori continuino a usare la versione completa precedente durante una ricompilazione. L'aggiornamento comporta comunque costi di lettura e aggregazione tra partizioni, ma le query di report ripetute riutilizzano il risultato. Le modifiche all'origine non sono visibili fino a quando non vengono incluse da un aggiornamento successivo.

Passaggi successivi

I modelli seguenti possono essere rilevanti anche quando si implementa questo modello:

  • Modello CQRS (Command and Query Responsibility Segregation, separazione di responsabilità per query e comandi). Usare questo modello per aggiornare le informazioni contenute in una vista materializzata rispondendo agli eventi che si verificano quando i valori dei dati sottostanti cambiano.
  • Modello Event Sourcing. Usare insieme al modello CQRS per mantenere le informazioni in una vista materializzata. Quando i valori dei dati di una vista materializzata sono basati sulla modifica, il sistema può generare eventi che descrivono queste modifiche e salvarli in un archivio eventi.
  • Modello di tabella degli indici. I dati in una vista materializzata sono organizzati in genere in base a una chiave primaria, ma le query potrebbero dover recuperare le informazioni da questa vista esaminando i dati in altri campi. Usare questo modello per creare indici secondari su set di dati per gli archivi dati che non supportano indici secondari nativi.
  • Last updated on