.create materialized-view

Articolo
10/15/2024

Si applica a: ✅Microsoft Fabric✅Azure Esplora dati

Una vista materializzata è una query di aggregazione su una tabella di origine. Rappresenta una singola summarize istruzione.

Esistono due modi possibili per creare una vista materializzata, come indicato dall'opzione backfill nel comando :

Creare la vista materializzata da ora in poi:

La vista materializzata viene creata vuota. Include solo i record inseriti dopo la creazione della visualizzazione. La creazione di questo tipo restituisce immediatamente e la vista è immediatamente disponibile per la query.

Creare la vista materializzata in base ai record esistenti nella tabella di origine:

Vedere Riempimento di una vista materializzata.
Il completamento della creazione potrebbe richiedere molto tempo, a seconda del numero di record nella tabella di origine. La vista non sarà disponibile per le query fino al completamento del riempimento.
Quando si usa questa opzione, il comando create deve essere async. È possibile monitorare l'esecuzione usando il .show operations comando .
È possibile annullare il processo di backfill usando il .cancel operation comando .

Importante

Nelle tabelle di origine di grandi dimensioni, l'opzione backfill potrebbe richiedere molto tempo. Se questo processo ha esito negativo temporaneamente durante l'esecuzione, non verrà ritentato automaticamente. È quindi necessario eseguire di nuovo il comando create. Per altre informazioni, vedere Backfill a materialized view.For more information, see Backfill a materialized view.

Autorizzazioni

Questo comando richiede autorizzazioni di amministratore del database. L'autore della visualizzazione materializzata diventa l'amministratore di esso.

Sintassi

.create[async] [ifnotexists] materialized-view [ with(PropertyName = PropertyValue,...)] Query MaterializedViewName SourceTableName { on table }

Altre informazioni sulle convenzioni di sintassi.

Parametri

Nome	Digita	Obbligatorio	Descrizione
PropertyName, PropertyValue	`string`		Elenco di proprietà sotto forma di coppie nome e valore, dall'elenco delle proprietà supportate.
MaterializedViewName	`string`	✔️	Nome della vista materializzata. Il nome della vista non può essere in conflitto con i nomi di tabella o di funzione nello stesso database e deve rispettare le regole di denominazione degli identificatori.
SourceTableName	`string`	✔️	Nome della tabella di origine in cui è definita la vista.
Query	`string`	✔️	Definizione di query della vista materializzata. Per altre informazioni e limitazioni, vedere la sezione Parametri di query.

Nota

Se la vista materializzata esiste già:

Se viene specificato il ifnotexists flag, il comando viene ignorato. Non viene applicata alcuna modifica, anche se la nuova definizione non corrisponde alla definizione esistente.
Se il ifnotexists flag non è specificato, viene restituito un errore.
Per modificare una vista materializzata esistente, usare il comando .alter materialized-view .

Proprietà supportate

Nella clausola PropertyName = PropertyValue) sono supportate le with (proprietà seguenti. Tutte le proprietà sono facoltative.

Nome	Tipo	Descrizione
Recupero	`bool`	Se creare la vista in base a tutti i record attualmente in `SourceTable` (`true`) o a crearla da ora in poi (`false`). Il valore predefinito è `false`. Per altre informazioni, vedere Backfill a materialized view.For more information, see Backfill a materialized view.
effectiveDateTime	`datetime`	Rilevante solo quando si usa `backfill`. Se è impostata, la creazione esegue il backfill solo con i record inseriti dopo datetime. `backfill` deve anche essere impostato su `true`. Questa proprietà prevede un valore letterale datetime; ad esempio . `effectiveDateTime=datetime(2019-05-01)`
updateExtentsCreationTime	`bool`	Rilevante solo quando si usa `backfill`. Se è impostato su `true`, l'ora di creazione extent viene assegnata in base alla chiave datetime group-by durante il processo di backfill. Per altre informazioni, vedere Backfill a materialized view.For more information, see Backfill a materialized view.
lookback	`timespan`	Valido solo per `arg_max`//`arg_mintake_any` le viste materializzate. Limita il periodo di tempo in cui sono previsti duplicati. Ad esempio, se viene specificato un lookback di 6 ore in una `arg_max` vista, la deduplicazione tra i record appena inseriti e quelli esistenti prenderà in considerazione solo i record inseriti fino a 6 ore fa. Il lookback è relativo a ingestion_time(). Se la query di visualizzazione materializzata non mantiene il `ingestion_time()` valore, il lookback non può essere definito nella vista. Vedere limitazioni delle viste materializzate e problemi noti. La definizione del periodo di lookback in modo errato potrebbe causare duplicati nella vista materializzata. Ad esempio, se un record per una chiave specifica viene inserito 10 ore dopo l'inserimento di un record per la stessa chiave e il lookback è impostato su 6 ore, tale chiave sarà duplicata nella visualizzazione. Il periodo di ricerca viene applicato sia durante il tempo di materializzazione che il tempo di query.
autoUpdateSchema	`bool`	Indica se aggiornare automaticamente la vista in base alle modifiche apportate alla tabella di origine. Il valore predefinito è `false`. Questa opzione è valida solo per le viste di tipo `arg_max(Timestamp, )`//`arg_min(Timestamp, )take_any()` (solo quando l'argomento della colonna è ).`` Se questa opzione è impostata su `true`, le modifiche apportate alla tabella di origine verranno riflesse automaticamente nella vista materializzata.
dimensionTables	array	Argomento dinamico che include una matrice di tabelle delle dimensioni nella vista. Vedere Parametro di query.
cartella	`string`	Cartella della vista materializzata.
docString	`string`	Stringa che documenta la vista materializzata.
allowMaterializedViewsWithoutRowLevelSecurity	`bool`	Consente di creare una vista materializzata su una tabella con i criteri di sicurezza a livello di riga abilitati.

Avviso

Il sistema disabiliterà automaticamente una vista materializzata se le modifiche apportate alla tabella di origine della vista materializzata o le modifiche apportate ai dati comportano l'incompatibilità tra la query di vista materializzata e lo schema previsto della vista materializzata.
Per evitare questo errore, la query della vista materializzata deve essere deterministica. Ad esempio, il plug-in bag_unpack o pivot genera uno schema non deterministico.
Quando si usa un'aggregazione arg_max(Timestamp, *) e quando autoUpdateSchema è false, anche le modifiche apportate alla tabella di origine possono causare mancate corrispondenze dello schema. Evitare questo errore definendo la query di visualizzazione come arg_max(Timestamp, Column1, Column2, ...)o usando l'opzione autoUpdateSchema .
L'uso autoUpdateSchema di potrebbe causare una perdita irreversibile di dati quando vengono eliminate colonne nella tabella di origine.
Monitorare la disabilitazione automatica delle viste materializzate usando la metrica MaterializedViewResult.
Dopo aver risolto i problemi di incompatibilità, è consigliabile riabilitare in modo esplicito la visualizzazione usando il comando abilita visualizzazione materializzata.

Creare una vista materializzata sulla vista materializzata

È possibile creare una vista materializzata su un'altra vista materializzata solo quando la vista materializzata di origine è un'aggregazione take_any(*) (deduplicazione). Per altre informazioni, vedere Visualizzazione materializzata su vista materializzata ed esempi.

Sintassi:

.create[async] [ifnotexists] materialized-view [ with(PropertyName = PropertyValue,...)] MaterializedViewName SourceMaterializedViewName { Query on materialized-view }

Parametri:

Nome	Digita	Obbligatorio	Descrizione
PropertyName, PropertyValue	`string`		Elenco di proprietà sotto forma di coppie nome e valore, dall'elenco delle proprietà supportate.
MaterializedViewName	`string`	✔️	Nome della vista materializzata. Il nome della vista non può essere in conflitto con i nomi di tabella o di funzione nello stesso database e deve rispettare le regole di denominazione degli identificatori.
SourceMaterializedViewName	`string`	✔️	Nome della vista materializzata di origine in cui è definita la vista.
Query	`string`	✔️	Definizione di query della vista materializzata.

Esempi

Creare una visualizzazione vuota arg_max che materializzerà solo i record inseriti da ora in poi:

.create materialized-view ArgMax on table T
{
    T | summarize arg_max(Timestamp, *) by User
}

Creare una vista materializzata per le aggregazioni giornaliere con l'opzione backfill usando async:

.create async materialized-view with (backfill=true, docString="Customer telemetry") CustomerUsage on table T
{
    T 
    | extend Day = bin(Timestamp, 1d)
    | summarize count(), dcount(User), max(Duration) by Customer, Day 
}

Creare una vista materializzata con backfill e effectiveDateTime. La vista viene creata in base ai record solo datetime.

.create async materialized-view with (backfill=true, effectiveDateTime=datetime(2019-01-01)) CustomerUsage on table T 
{
    T 
    | extend Day = bin(Timestamp, 1d)
    | summarize count(), dcount(User), max(Duration) by Customer, Day
}

Creare una vista materializzata che deduplica la tabella di origine, in base alla EventId colonna, usando un lookback di 6 ore. I record verranno deduplicati in base solo ai record inseriti 6 ore prima dei record correnti.
```
.create materialized-view with(lookback=6h) DeduplicatedTable on table T
{
    T
    | summarize take_any(*) by EventId
}
```

Creare una vista materializzata di downcampionamento basata sulla vista materializzata precedente DeduplicatedTable :

.create materialized-view DailyUsage on materialized-view DeduplicatedTable
{
    DeduplicatedTable
    | summarize count(), dcount(User) by Day=bin(Timestamp, 1d)
}

La definizione può includere operatori aggiuntivi prima dell'istruzione summarize , purché summarize sia l'ultima:

.create materialized-view CustomerUsage on table T 
{
    T 
    | where Customer in ("Customer1", "Customer2", "CustomerN")
    | parse Url with "https://contoso.com/" Api "/" *
    | extend Month = startofmonth(Timestamp)
    | summarize count(), dcount(User), max(Duration) by Customer, Api, Month
}

Ecco le viste materializzate che si uniscono a una tabella delle dimensioni:

.create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T
{
    T
    | lookup DimUsers on User  
    | summarize arg_max(Timestamp, *) by User 
}

.create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T 
{
    DimUsers | project User, Age, Address
    | join kind=rightouter hint.strategy=broadcast T on User
    | summarize arg_max(Timestamp, *) by User 
}

Osservazioni:

Query parameter (Parametro di query)

Le regole seguenti limitano la query usata nel parametro Query della vista materializzata:

La query deve fare riferimento a una singola tabella dei fatti che rappresenta l'origine della vista materializzata. Deve includere un singolo summarize operatore e una o più funzioni di aggregazione aggregate aggregate da uno o più gruppi per espressioni. L'operatore summarize deve essere sempre l'ultimo operatore nella query.

Una vista materializzata che include solo una singola arg_maxarg_mintake_any//aggregazione potrebbe offrire prestazioni migliori rispetto a una vista materializzata che include queste aggregazioni insieme ad altre aggregazioni , ad esempio .count/dcount/avg Ciò è dovuto al fatto che alcune ottimizzazioni sono rilevanti solo per questi tipi di viste materializzate. Non si applicano quando la vista include funzioni di aggregazione miste (in cui le aggregazioni miste sono entrambe etake_any arg_max/arg_min/altre nella stessa visualizzazione).
La query non deve includere operatori che dipendono da now(). Ad esempio, la query non deve avere where Timestamp > ago(5d). Usare i criteri di conservazione nella vista materializzata per limitare il periodo di tempo a cui si riferisce la visualizzazione.
Gli operatori seguenti non sono supportati nella query di visualizzazione materializzata: sort, top-nestedtop, partition. serialize
Le aggregazioni composite non sono supportate nella definizione della vista materializzata. Ad esempio, invece di usare SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Id, definire la vista materializzata come : SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id. Durante il tempo di query di visualizzazione, eseguire MaterializedViewName | project Id, Result=a/b. L'output richiesto della vista, inclusa la colonna calcolata (a/b), può essere incapsulato in una funzione archiviata. Accedere alla funzione archiviata anziché accedere direttamente alla vista materializzata.

Le query tra cluster e tra database non sono supportate.

Le query cross-eventhouse e tra database non sono supportate.

I riferimenti a external_table() e externaldata non sono supportati.
La query di visualizzazione materializzata non può includere callout che richiedono la rappresentazione. In particolare, tutti i plug-in di connettività delle query che usano la rappresentazione non sono consentiti.
Oltre alla tabella di origine della vista, la query può fare riferimento a una o più tabelle delle dimensioni. Le tabelle delle dimensioni devono essere evidenziate in modo esplicito nelle proprietà della vista. È importante comprendere il comportamento seguente quando si esegue il join con le tabelle delle dimensioni:
- I record nella tabella di origine della vista (tabella dei fatti) vengono materializzati una sola volta. Gli aggiornamenti alle tabelle delle dimensioni non hanno alcun impatto sui record che sono già stati elaborati dalla tabella dei fatti.
- Una latenza di inserimento diversa tra la tabella dei fatti e la tabella delle dimensioni potrebbe influire sui risultati della visualizzazione.
  
  Esempio: una definizione di vista include un inner join con una tabella delle dimensioni. Al momento della materializzazione, il record della dimensione non è stato completamente inserito, ma è già stato inserito nella tabella dei fatti. Questo record verrà eliminato dalla visualizzazione e non verrà mai elaborato di nuovo.
  
  Analogamente, se il join è un outer join, il record della tabella dei fatti verrà elaborato e aggiunto per visualizzare con un valore Null per le colonne della tabella delle dimensioni. I record che sono già stati aggiunti (con valori Null) alla vista non verranno elaborati di nuovo. I relativi valori, nelle colonne della tabella delle dimensioni, rimarranno Null.

Funzioni di aggregazione supportate

Sono supportate le funzioni di aggregazione seguenti:

Suggerimenti per incrementare le prestazioni

Usare una chiave di raggruppamento datetime: le viste materializzate con una colonna datetime come una delle chiavi group-by sono più efficienti di quelle che non lo fanno. Il motivo è che alcune ottimizzazioni possono essere applicate solo quando è presente una chiave datetime group-by. Se l'aggiunta di una chiave datetime group-by non modifica la semantica dell'aggregazione, è consigliabile aggiungerla. Questa operazione può essere eseguita solo se la colonna datetime non è modificabile per ogni entità univoca.

Ad esempio, nell'aggregazione seguente:
```
    SourceTable | summarize take_any(*) by EventId
```
Se EventId ha sempre lo stesso Timestamp valore e quindi l'aggiunta Timestamp non modifica la semantica dell'aggregazione, è preferibile definire la visualizzazione come:
```
    SourceTable | summarize take_any(*) by EventId, Timestamp
```
Suggerimento

I dati in arrivo in ritardo in una chiave datetime group-by possono avere un impatto negativo sulle prestazioni della vista materializzata. Si supponga, ad esempio, che una vista materializzata usi bin(Timestamp, 1d) come una delle relative chiavi group-by e che i record appena inseriti nella tabella di origine abbiano valori precedenti Timestamp . Questi record potrebbero influire negativamente sulla vista materializzata.

Se si prevede che i record in arrivo in ritardo vengano inseriti nella tabella di origine, modificare i criteri di memorizzazione nella cache della vista materializzata di conseguenza. Ad esempio, se i record con timestamp di sei mesi fa devono essere inseriti nella tabella di origine, il processo di materializzazione dovrà analizzare la vista materializzata per i sei mesi precedenti. Se questo periodo si trova nella cache a freddo, la materializzazione riscontrerà errori nella cache che avranno un impatto negativo sulle prestazioni della visualizzazione.

Se tali record in arrivo in ritardo non sono previsti, è consigliabile filtrare questi record nella query di visualizzazione materializzata o normalizzare i relativi valori di timestamp in base all'ora corrente.
Definire un periodo di lookback: se applicabile allo scenario, l'aggiunta di una lookback proprietà può migliorare significativamente le prestazioni delle query. Per informazioni dettagliate, vedere Proprietà supportate.
Aggiungere colonne usate di frequente per filtrare come chiavi di raggruppamento: le query di visualizzazione materializzate vengono ottimizzate quando vengono filtrate in base a una delle chiavi raggruppate della vista materializzata. Se si sa che il modello di query spesso filtra in base a una colonna non modificabile in base a un'entità univoca nella vista materializzata, includerla nelle chiavi group-by della vista materializzata.

Ad esempio, una vista materializzata espone arg_max in base a un ResourceId valore che spesso verrà filtrato in base SubscriptionIda . Supponendo che un ResourceId valore appartenga sempre allo stesso SubscriptionId valore, definire la query di visualizzazione materializzata come:
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
}
```
La definizione precedente è preferibile rispetto a quanto segue:
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by ResourceId 
}
```

Usare i criteri di aggiornamento, se appropriato: la vista materializzata può includere trasformazioni, normalizzazione e ricerche nelle tabelle delle dimensioni. È tuttavia consigliabile spostare queste operazioni in un criterio di aggiornamento. Lasciare solo l'aggregazione per la vista materializzata.

Ad esempio, è preferibile definire i criteri di aggiornamento seguenti:

.alter-merge table Target policy update 
@'[{"IsEnabled": true, 
    "Source": "SourceTable", 
    "Query": 
        "SourceTable 
        | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)", 
        | lookup DimResources on ResourceId
        | mv-expand Events
    "IsTransactional": false}]'

Definire la visualizzazione materializzata seguente:

.create materialized-view Usage on table Events
{
    Target 
    | summarize count() by ResourceId 
}

L'alternativa, di includere i criteri di aggiornamento come parte della query di visualizzazione materializzata, potrebbe comportare prestazioni peggiori e pertanto non consigliate:

.create materialized-view Usage on table SourceTable
{
    SourceTable
    | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)
    | lookup DimResources on ResourceId
    | mv-expand Events
    | summarize count() by ResourceId
}

Suggerimento

Se sono necessarie prestazioni ottimali per il tempo di query, ma è possibile tollerare una certa latenza dei dati, usare la funzione materialized_view().

Riempimento di una vista materializzata

Quando si crea una vista materializzata usando la backfill proprietà , la vista materializzata verrà creata in base ai record disponibili nella tabella di origine. In alternativa, verrà creato in base a un subset di tali record, se si usa effectiveDateTime.

In background, il processo di backfill suddivide i dati per il backfill in più batch ed esegue diverse operazioni di inserimento per riempire nuovamente la visualizzazione. Il processo potrebbe richiedere molto tempo quando il numero di record nella tabella di origine è elevato. La durata del processo dipende dalle dimensioni del database. Tenere traccia dello stato di avanzamento del riempimento usando il .show operations comando .

Gli errori temporanei che si verificano durante il processo di riempimento vengono ritentati. Se tutti i tentativi vengono esauriti, il comando avrà esito negativo e richiederà una nuova esecuzione manuale del comando create.

Non è consigliabile usare il riempimento quando il numero di record nella tabella di origine supera number-of-nodes X 200 million (a volte anche meno, a seconda della complessità della query). Un'alternativa è l'opzione backfill by move extents.An alternative is the backfill by move extents option.

L'uso dell'opzione backfill non è supportato per i dati in una cache a freddo. Aumentare il periodo della cache ad accesso frequente, se necessario, per la durata della creazione della visualizzazione. Ciò potrebbe richiedere un aumento del numero di istanze.

Se si verificano errori durante la creazione della visualizzazione, provare a modificare queste proprietà:

MaxSourceRecordsForSingleIngest: per impostazione predefinita, il numero di record di origine in ogni operazione di inserimento durante il backfill è di 2 milioni per nodo. È possibile modificare questa impostazione predefinita impostando questa proprietà sul numero di record desiderato. Il valore è il numero totale di record in ogni operazione di inserimento.

La riduzione di questo valore può essere utile quando la creazione ha esito negativo sui limiti di memoria o sui timeout delle query. L'aumento di questo valore può velocizzare la creazione della vista, presupponendo che il database possa eseguire la funzione di aggregazione su più record rispetto all'impostazione predefinita.
Concurrency: le operazioni di inserimento, in esecuzione come parte del processo di backfill, vengono eseguite simultaneamente. Per impostazione predefinita, la concorrenza è min(number_of_nodes * 2, 5). È possibile impostare questa proprietà per aumentare o ridurre la concorrenza. È consigliabile aumentare questo valore solo se la CPU del database è bassa, perché l'aumento può influire significativamente sull'utilizzo della CPU del database.

Ad esempio, il comando seguente riempie la vista materializzata da 2020-01-01. Il numero massimo di record in ogni operazione di inserimento è 3 milioni. Il comando eseguirà le operazioni di inserimento con concorrenza di 2.

.create async materialized-view with (
        backfill=true,
        effectiveDateTime=datetime(2020-01-01),
        MaxSourceRecordsForSingleIngest=3000000,
        Concurrency=2
    )
    CustomerUsage on table T
{
    T
    | summarize count(), dcount(User), max(Duration) by Customer, bin(Timestamp, 1d)
}

Se la vista materializzata include una chiave di raggruppamento datetime, il processo di backfill supporta l'override dell'ora di creazione dell'extent in base alla colonna datetime. Ciò può essere utile, ad esempio, se si desidera che i record meno recenti vengano eliminati prima di quelli recenti, perché i criteri di conservazione si basano sul tempo di creazione dell'extent. La updateExtentsCreationTime proprietà è supportata solo se la vista include una chiave datetime group-by che usa la bin() funzione . Ad esempio, il backfill seguente assegnerà il tempo di creazione in base alla Timestamp chiave group-by:

.create async materialized-view with (
        backfill=true,
        updateExtentsCreationTime=true
    )
    CustomerUsage on table T
{
    T
    | summarize count() by Customer, bin(Timestamp, 1d)
}

Backfill per extent di spostamento

L'opzione di backfilling spostando extent riempie la vista materializzata in base a una tabella esistente, che non è necessariamente la tabella di origine della vista materializzata. Per ottenere il riempimento , spostare gli extent dalla tabella specificata alla tabella di vista materializzata sottostante. Questo processo implica che:

I dati nella tabella specificata devono avere lo stesso schema dello schema della vista materializzata.
I record nella tabella specificata vengono spostati nella vista così com'è. Si presuppone che vengano deduplicati in base alla definizione della vista materializzata.

Ad esempio, se la vista materializzata ha l'aggregazione seguente:

T | summarize arg_max(Timestamp, *) by EventId

I record nella tabella di origine per l'operazione di spostamento extent devono essere già deduplicati da EventID.

Poiché l'operazione usa extent con estensione move, i record verranno rimossi dalla tabella specificata durante il riempimento (spostato, non copiato).

Il backfill per extent di spostamento non è supportato per tutte le funzioni di aggregazione supportate nelle viste materializzate. Avrà esito negativo per le aggregazioni, avg()ad esempio , dcount(), in cui i dati sottostanti archiviati nella vista sono diversi dall'aggregazione stessa.

La vista materializzata viene riempita solo in base alla tabella specificata. La materializzazione dei record nella tabella di origine della vista inizierà dall'ora di creazione della visualizzazione, per impostazione predefinita.

Se la tabella di origine della vista materializzata inserisce continuamente dati, la creazione della vista tramite extent di spostamento potrebbe comportare una perdita di dati. Ciò è dovuto al fatto che i record inseriti nella tabella di origine, nel breve periodo tra il tempo di preparazione della tabella da cui eseguire il backfill e il tempo di creazione della vista, non verranno inclusi nella vista materializzata. Per gestire questo scenario, è possibile impostare la source_ingestion_time_from proprietà sull'ora di inizio della vista materializzata sulla tabella di origine.

Casi d'uso

L'opzione di backfilling tramite extent di spostamento può essere utile in due scenari principali:

Quando si dispone già di una tabella che include i dati di origine deduplicati per la vista materializzata e non sono necessari questi record in questa tabella dopo la creazione della vista perché si usa solo la vista materializzata.
Quando la tabella di origine della vista materializzata è molto grande e il riempimento della vista in base alla tabella di origine non funziona correttamente a causa delle limitazioni indicate in precedenza. In questo caso, è possibile orchestrare manualmente il processo di backfill in una tabella temporanea usando l'inserimento da comandi di query. Quando la tabella temporanea include tutti i record per il riempimento nascosto, creare la vista materializzata in base a tale tabella.

È anche possibile usare uno degli strumenti di orchestrazione consigliati.

Esempi:

Nell'esempio seguente la tabella DeduplicatedTable include un singolo record per EventId istanza e verrà usata come linea di base per la vista materializzata. Nella vista materializzata verranno inclusi solo i record in T che vengono inseriti dopo l'ora di creazione della visualizzazione.
```
.create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
Se la effectiveDateTime proprietà viene specificata insieme alla move_extents_from proprietà , solo gli extent nel DeduplicatedTable cui MaxCreatedOn valore è maggiore di effectiveDateTime vengono inclusi nel riempimento nascosto (spostati nella vista materializzata):
```
.create async materialized-view with 
    (move_extents_from=DeduplicatedTable, effectiveDateTime=datetime(2019-01-01)) 
    MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
Nell'esempio seguente viene illustrato l'uso della source_ingestion_time_from proprietà nell'opzione di riempimento in base agli extent di spostamento. L'uso di entrambi source_ingestion_time_from e move_extents_from indica che la vista materializzata viene riempita da due origini:
- Tabellamove_extents_from: DeduplicatedTable nell'esempio seguente. Questa tabella deve includere tutti i dati cronologici da riempire. Facoltativamente, è possibile utilizzare la effectiveDateTime proprietà per includere solo extent nel DeduplicatedTable cui MaxCreatedOn valore è maggiore di effectiveDateTime.
- Tabella di origine della vista materializzata: T nell'esempio seguente. Il backfill da questa tabella include solo i record il cui valore ingestion_time() è maggiore di source_ingestion_time_from.
  
  La source_ingestion_time_from proprietà deve essere utilizzata solo per gestire la possibile perdita di dati nel breve tempo tra la preparazione della tabella da (DeduplicatedTable) e il tempo di creazione della vista. Non impostare questa proprietà troppo lontano in passato. Ciò avvierebbe la vista materializzata con un ritardo significativo, che potrebbe essere difficile da recuperare.
Nell'esempio seguente si supponga che l'ora corrente sia 2020-01-01 03:00. Table DeduplicatedTable è una tabella deduplicata di T. Include tutti i dati cronologici, deduplicati fino a 2020-01-01 00:00. Il create comando usa DeduplicatedTable per il riempimento della vista materializzata usando extent di spostamento. Il create comando include anche tutti i record in T che sono stati inseriti dopo 2020-01-01.
```
.create async materialized-view with (move_extents_from=DeduplicatedTable, source_ingestion_time_from=datetime(2020-01-01)) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```

Annullare la creazione della vista materializzata

È possibile annullare il processo di creazione della visualizzazione materializzata quando si usa l'opzione backfill. Questa azione è utile quando la creazione richiede troppo tempo e si vuole arrestarla durante l'esecuzione.

Avviso

La vista materializzata non può essere ripristinata dopo l'esecuzione di questo comando.

Il processo di creazione non può essere annullato immediatamente. Il comando cancel segnala la materializzazione da arrestare e la creazione controlla periodicamente se è stato richiesto un annullamento. Il comando di annullamento attende un periodo massimo di 10 minuti fino a quando il processo di creazione della visualizzazione materializzata non viene annullato e segnala se l'annullamento è riuscito.

Anche se l'annullamento non riesce entro 10 minuti e il comando di annullamento segnala un errore, la vista materializzata verrà probabilmente annullata in un secondo momento nel processo di creazione. Il .show operations comando indica se l'operazione è stata annullata.

Se l'operazione non è più in corso quando viene eseguito il .cancel operation comando, il comando segnala un errore.

Sintassi

.cancel operationoperationId

Altre informazioni sulle convenzioni di sintassi.

Parametri

Nome	Digita	Obbligatorio	Descrizione
`operationId`	`guid`	✔️	ID operazione restituito dal `.create async materialized-view` comando.

Output

Nome	Tipo	Descrizione
OperationId	`guid`	ID operazione del `.create materialized-view` comando.
Operazione	`string`	Tipo di operazione.
StartedOn	`datetime`	Ora di inizio dell'operazione di creazione.
CancellationState	`string`	Uno di: `Canceled successfully` (la creazione è stata annullata), `Cancellation failed` (attesa del timeout dell'annullamento), `Unknown` (la creazione della visualizzazione non è più in esecuzione ma non è stata annullata da questa operazione).
ReasonPhrase	`string`	Motivo per cui l'annullamento non è riuscito.

Esempi

.cancel operation c4b29441-4873-4e36-8310-c631c35c916e

OperationId	Operazione	StartedOn	CancellationState	ReasonPhrase
`c4b29441-4873-4e36-8310-c631c35c916e`	`MaterializedViewCreateOrAlter`	`2020-05-08 19:45:03.9184142`	`Canceled successfully`

Se l'annullamento non è stato completato entro 10 minuti, CancellationState indicherà un errore. La creazione può quindi essere annullata.

Condividi tramite

.create materialized-view

Autorizzazioni

Sintassi

Parametri

Proprietà supportate

Creare una vista materializzata sulla vista materializzata

Esempi

Osservazioni:

Query parameter (Parametro di query)

Funzioni di aggregazione supportate

Suggerimenti per incrementare le prestazioni

Riempimento di una vista materializzata

Backfill per extent di spostamento

Casi d'uso

Annullare la creazione della vista materializzata

Sintassi

Parametri

Output

Esempi

Commenti e suggerimenti

Risorse aggiuntive