Share via

.create materialized-view

  • Artikel

En materialiserad vy är en aggregeringsfråga över en källtabell. Den representerar en enda summarize instruktion.

Det finns två möjliga sätt att skapa en materialiserad vy, som anges av återfyllnadsalternativet i kommandot:

Skapa den materialiserade vyn från och med nu:

  • Den materialiserade vyn skapas tom. Den innehåller endast poster som matats in när vyn har skapats. Skapandet av den här typen returneras omedelbart och vyn är omedelbart tillgänglig för frågor.

Skapa den materialiserade vyn baserat på befintliga poster i källtabellen:

  • Se Återfyll en materialiserad vy.
  • Det kan ta lång tid att skapa, beroende på antalet poster i källtabellen. Vyn är inte tillgänglig för frågor förrän återfyllnad har slutförts.
  • När du använder det här alternativet måste kommandot create vara async. Du kan övervaka körningen .show operations med hjälp av kommandot .
  • Du kan avbryta återfyllnadsprocessen med hjälp .cancel operation av kommandot .

Viktigt

I stora källtabeller kan det ta lång tid att slutföra återfyllnadsalternativet. Om den här processen tillfälligt misslyckas när den körs, kommer den inte att försöka igen automatiskt. Du måste sedan köra kommandot create igen. Mer information finns i Återfyll en materialiserad vy.

Behörigheter

Det här kommandot kräver behörigheter för Databas Admin. Skaparen av den materialiserade vyn blir administratör för den.

Syntax

.create [async] [ifnotexists] materialized-view [ with(PropertyName=PropertyValue,...)] MaterializedViewNameon tableSourceTableName{Fråga}

Läs mer om syntaxkonventioner.

Parametrar

Namn Typ Obligatorisk Beskrivning
PropertyName, PropertyValue string Lista över egenskaper i form av namn- och värdepar från listan över egenskaper som stöds.
MaterializedViewName string ✔️ Namnet på den materialiserade vyn. Vynamnet får inte vara i konflikt med tabell- eller funktionsnamn i samma databas och måste följa namngivningsreglerna för identifierare.
SourceTableName string ✔️ Namnet på källtabellen som vyn har definierats för.
Query string ✔️ Frågedefinition för den materialiserade vyn. Mer information och begränsningar finns i avsnittet Frågeparameter .

Anteckning

Om den materialiserade vyn redan finns:

  • ifnotexists Om flaggan anges ignoreras kommandot. Ingen ändring tillämpas, även om den nya definitionen inte matchar den befintliga definitionen.
  • ifnotexists Om flaggan inte anges returneras ett fel.
  • Om du vill ändra en befintlig materialiserad vy använder du kommandot .alter materialized-view .

Egenskaper som stöds

Följande egenskaper stöds i with(PropertyName=PropertyValue-satsen) . Alla egenskaper är valfria.

Namn Typ Description
återfyllnad bool Om du vill skapa vyn baserat på alla poster som för närvarande finns i SourceTable (true) eller skapa den från och med nu (false). Standardvärdet är false. Mer information finns i Återfyll en materialiserad vy.
effectiveDateTime datetime Endast relevant när du använder backfill. Om den har angetts fylls återfyllnad endast med poster som matats in efter datetime. backfill måste också anges till true. Den här egenskapen förväntar sig en datetime-literal; till exempel effectiveDateTime=datetime(2019-05-01).
updateExtentsCreationTime bool Endast relevant när du använder backfill. Om den är inställd på tilldelas tid för trueatt skapa utrymme baserat på datetime-grupperingsnyckeln under återfyllnadsprocessen. Mer information finns i Återfyll en materialiserad vy.
tillbakablick timespan Endast giltigt för arg_max//arg_mintake_any materialiserade vyer. Den begränsar den tidsperiod då dubbletter förväntas. Om till exempel en återblick på 6 timmar har angetts i en arg_max vy, kommer dedupliceringen mellan nyligen inmatade poster och befintliga endast att ta hänsyn till poster som matades in för upp till 6 timmar sedan.

Lookback är relativt till ingestion_time. Om du definierar återblicksperioden felaktigt kan det leda till dubbletter i den materialiserade vyn. Om till exempel en post för en specifik nyckel matas in 10 timmar efter att en post för samma nyckel matades in och återställningen är inställd på 6 timmar, blir nyckeln en dubblett i vyn. Återblicksperioden tillämpas både under materialiseringstiden och frågetiden.
autoUpdateSchema bool Om vyn för källtabelländringar ska uppdateras automatiskt. Standardvärdet är false. Det här alternativet är endast giltigt för vyer av typen arg_max(Timestamp, *)//arg_min(Timestamp, *)take_any(*) (endast när kolumnens argument är ).* Om det här alternativet är inställt truepå återspeglas ändringar i källtabellen automatiskt i den materialiserade vyn.
dimensionTables matris Ett dynamiskt argument som innehåller en matris med dimensionstabeller i vyn. Se Frågeparameter.
mapp string Mappen för den materialiserade vyn.
docString string En sträng som dokumenterar den materialiserade vyn.
allowMaterializedViewsWithoutRowLevelSecurity bool Gör att du kan skapa en materialiserad vy över en tabell med en säkerhetsprincip på radnivå aktiverad.

Varning

  • Systemet inaktiverar automatiskt en materialiserad vy om ändringar i källtabellen i den materialiserade vyn eller ändringar i data leder till inkompatibilitet mellan den materialiserade vyfrågan och det förväntade materialiserade vyschemat.
  • För att undvika det här felet måste den materialiserade vyfrågan vara deterministisk. Till exempel resulterar bag_unpack- eller pivot-plugin-programmet i ett icke-deterministiskt schema.
  • När du använder en arg_max(Timestamp, *) aggregering och när autoUpdateSchema är falskt kan ändringar i källtabellen också leda till schemamatchningar. Undvik det här felet genom att definiera visningsfrågan som arg_max(Timestamp, Column1, Column2, ...)eller med hjälp autoUpdateSchema av alternativet .
  • Användning autoUpdateSchema kan leda till oåterkallelig dataförlust när kolumner i källtabellen tas bort.
  • Övervaka automatisk inaktivering av materialiserade vyer med hjälp av måttet MaterializedViewResult.
  • När du har åtgärdat inkompatibilitetsproblem bör du uttryckligen återaktivera vyn med hjälp av kommandot aktivera materialiserad vy .

Skapa materialiserad vy över materialiserad vy

Du kan bara skapa en materialiserad vy över en annan materialiserad vy när den materialiserade källvyn är en take_any(*) aggregering (deduplicering). Mer information finns i Materialiserad vy över materialiserad vy och Exempel.

Syntax:

.create [async] [ifnotexists] materialized-view [ with(PropertyName=PropertyValue,...)] MaterializedViewNameon materialized-viewSourceMaterializedViewName{Fråga}

Parametrar:

Namn Typ Obligatorisk Beskrivning
PropertyName, PropertyValue string Lista över egenskaper i form av namn- och värdepar från listan över egenskaper som stöds.
MaterializedViewName string ✔️ Namnet på den materialiserade vyn. Vynamnet får inte vara i konflikt med tabell- eller funktionsnamn i samma databas och måste följa namngivningsreglerna för identifierare.
SourceMaterializedViewName string ✔️ Namnet på den materialiserade källvyn som vyn har definierats för.
Query string ✔️ Frågedefinition för den materialiserade vyn.

Exempel

  • Skapa en tom arg_max vy som endast materialiserar poster som matas in från och med nu:

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

  • Skapa en materialiserad vy för dagliga aggregat med alternativet återfyllnad med hjälp asyncav :

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

  • Skapa en materialiserad vy med backfill och effectiveDateTime. Vyn skapas endast baserat på poster från 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
}

  • Skapa en materialiserad vy som deduplicerar källtabellen EventId , baserat på kolumnen, med en återblick på 6 timmar. Poster dedupliceras endast mot poster som matas in 6 timmar före aktuella poster.

    .create materialized-view with(lookback=6h) DeduplicatedTable on table T
{
    T
    | summarize take_any(*) by EventId
}

  • Skapa en nedsampling av materialiserad vy som baseras på den tidigare DeduplicatedTable materialiserade vyn:

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

  • Definitionen kan innehålla ytterligare operatorer före -instruktionen summarize , så länge det summarize är den sista:

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

  • Här är materialiserade vyer som kopplas till en dimensionstabell:

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

Kommentarer

Frågeparameter

Följande regler begränsar frågan som används i frågeparametern för materialiserad vy:

  • Frågan ska referera till en enda faktatabell som är källan till den materialiserade vyn. Den bör innehålla en enda summarize operator och en eller flera aggregeringsfunktioner som aggregeras av en eller flera grupper efter uttryck. Operatorn summarize måste alltid vara den sista operatorn i frågan.

    En materialiserad vy som endast innehåller en enda arg_maxarg_mintake_any//aggregering kan fungera bättre än en materialiserad vy som innehåller dessa aggregeringar tillsammans med andra aggregeringar (till exempel ).count/dcount/avg Det beror på att vissa optimeringar endast är relevanta för den här typen av materialiserade vyer. De gäller inte när vyn innehåller blandade aggregeringsfunktioner (där blandat innebär både arg_max//arg_mintake_any och andra aggregeringar i samma vy).

  • Frågan får inte innehålla några operatorer som är beroende av now(). Frågan bör till exempel inte ha where Timestamp > ago(5d). Använd kvarhållningsprincipen i den materialiserade vyn för att begränsa den tidsperiod som vyn omfattar.

  • Följande operatorer stöds inte i den materialiserade vyfrågan: sort, top-nested, top, partition, serialize.

  • Sammansatta sammansättningar stöds inte i definitionen av den materialiserade vyn. I stället för att använda SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Iddefinierar du till exempel den materialiserade vyn som: SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id. Under visning av frågetid kör du MaterializedViewName | project Id, Result=a/b. Nödvändiga utdata från vyn, inklusive den beräknade kolumnen (a/b), kan kapslas in i en lagrad funktion. Få åtkomst till den lagrade funktionen i stället för att komma åt den materialiserade vyn direkt.

  • Frågor mellan kluster och mellan databaser stöds inte.

  • Referenser till external_table() och externaldata stöds inte.

  • Den materialiserade vyfrågan kan inte innehålla pratbubblar som kräver personifiering. Mer specifikt tillåts inte alla plugin-program för frågeanslutningar som använder personifiering.

  • Förutom källtabellen i vyn kan frågan referera till en eller flera dimensionstabeller. Dimensionstabeller måste uttryckligen framhävas i vyegenskaperna. Det är viktigt att förstå följande beteende när du ansluter till dimensionstabeller:

    • Poster i vyns källtabell (faktatabellen) materialiseras bara en gång. Uppdateringar till dimensionstabellerna påverkar inte poster som redan har bearbetats från faktatabellen.

    • En annan inmatningssvarstid mellan faktatabellen och dimensionstabellen kan påverka visningsresultatet.

      Exempel: En vydefinition innehåller en inre koppling med en dimensionstabell. Vid tidpunkten för materialiseringen matades inte dimensionsposten in helt, men den matades redan in i faktatabellen. Den här posten tas bort från vyn och bearbetas aldrig igen.

      Om kopplingen är en yttre koppling bearbetas posten från faktatabellen och läggs till för att visa med ett null-värde för dimensionstabellkolumnerna. Poster som redan har lagts till (med null-värden) i vyn bearbetas inte igen. Deras värden, i kolumner från dimensionstabellen, förblir null.

Sammansättningsfunktioner som stöds

Följande sammansättningsfunktioner stöds:

Prestandatips

  • Använd en datetime-grupperingsnyckel: Materialiserade vyer som har en datetime-kolumn som en av sina gruppera efter-nycklar är mer effektiva än de som inte har det. Anledningen är att vissa optimeringar endast kan tillämpas när det finns en datetime-grupperingsnyckel. Om du inte ändrar semantiken för din aggregering genom att lägga till en datetime-grupperingsnyckel rekommenderar vi att du lägger till den. Du kan bara göra detta om kolumnen datetime inte kan ändras för varje unik entitet.

    Till exempel i följande aggregering:

        SourceTable | summarize take_any(*) by EventId

    Om EventId alltid har samma Timestamp värde, och därför Timestamp inte ändrar semantiken för aggregeringen, är det bättre att definiera vyn som:

        SourceTable | summarize take_any(*) by EventId, Timestamp

    Tips

    Inkomna data i en datetime-grupperingsnyckel kan ha en negativ inverkan på den materialiserade vyns prestanda. Anta till exempel att en materialiserad vy använder bin(Timestamp, 1d) som en av dess grupperingsnycklar och att flera extremvärden i data har mycket gamla Timestamp värden. Dessa extremvärden kan påverka den materialiserade vyn negativt.

    Vi rekommenderar att du i den materialiserade vyfrågan antingen filtrerar bort avvikande poster eller normaliserar dessa poster till den aktuella tiden.

  • Definiera en återblicksperiod: Om det är tillämpligt för ditt scenario kan du avsevärt förbättra frågeprestanda genom att lägga till en lookback egenskap. Mer information finns i Egenskaper som stöds.

  • Lägg till kolumner som ofta används för filtrering som gruppera efter nycklar: Materialiserade vyfrågor optimeras när de filtreras efter någon av den materialiserade vyns grupperingsnycklar. Om du vet att ditt frågemönster ofta filtreras efter en kolumn som inte kan ändras enligt en unik entitet i den materialiserade vyn, tar du med den i den materialiserade vyns grupperingsnycklar.

    En materialiserad vy exponeras arg_max till exempel av ett ResourceId värde som ofta filtreras efter SubscriptionId. Förutsatt att ett ResourceId värde alltid tillhör samma SubscriptionId värde definierar du den materialiserade vyfrågan som:

    .create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
}

    Föregående definition är att föredra framför följande:

    .create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by ResourceId 
}

  • Använd uppdateringsprinciper där det är lämpligt: Den materialiserade vyn kan innehålla transformeringar, normaliseringar och sökningar i dimensionstabeller. Vi rekommenderar dock att du flyttar dessa åtgärder till en uppdateringsprincip. Lämna endast aggregeringen för den materialiserade vyn.

    Det är till exempel bättre att definiera följande uppdateringsprincip:

    .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}]'

    Och definiera följande materialiserade vy:

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

    Alternativet att inkludera uppdateringsprincipen som en del av den materialiserade vyfrågan kan prestera sämre och rekommenderas därför inte:

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

Tips

Om du behöver bästa frågetidsprestanda, men du kan tolerera viss datafördröjning, använder du funktionen materialized_view().

Återfyll en materialiserad vy

När du skapar en materialiserad vy med hjälp backfill av egenskapen skapas den materialiserade vyn baserat på de poster som är tillgängliga i källtabellen. Eller så skapas den baserat på en delmängd av dessa poster, om du använder effectiveDateTime.

I bakgrunden delar återfyllningsprocessen data för att återfylla till flera batchar och kör flera inmatningsåtgärder för att fylla i vyn igen. Processen kan ta lång tid att slutföra när antalet poster i källtabellen är stort. Processens varaktighet beror på klusterstorleken. Spåra förloppet för återfyllningen med hjälp .show operations av kommandot .

Tillfälliga fel som inträffar som en del av återfyllningsprocessen görs på nytt. Om alla återförsök är slut misslyckas kommandot och kräver en manuell omkörning av kommandot create.

Vi rekommenderar inte att du använder återfyllnad när antalet poster i källtabellen överskrider number-of-nodes X 200 million (ibland ännu mindre beroende på frågans komplexitet). Ett alternativ är alternativet för återfyllnad genom att flytta omfattningar .

Det går inte att använda alternativet för återfyllnad för data i en kall cache. Öka frekvent cacheperiod, om det behövs, under hela visningsgenereringen. Detta kan kräva utskalning.

Om det uppstår fel när vyn skapas kan du prova att ändra följande egenskaper:

  • MaxSourceRecordsForSingleIngest: Som standard är antalet källposter i varje inmatningsåtgärd under återfyllning 2 miljoner per nod. Du kan ändra den här standardinställningen genom att ange den här egenskapen till önskat antal poster. (Värdet är det totala antalet poster i varje inmatningsåtgärd.)

    Att minska det här värdet kan vara användbart när det inte går att skapa minnesgränser eller tidsgränser för frågor. Om du ökar det här värdet kan det påskynda skapandet av vyn, förutsatt att klustret kan köra aggregeringsfunktionen på fler poster än standardvärdet.

  • Concurrency: Inmatningsåtgärderna, som körs som en del av återfyllningsprocessen, körs samtidigt. Som standard är min(number_of_nodes * 2, 5)samtidighet . Du kan ange att den här egenskapen ska öka eller minska samtidigheten. Vi rekommenderar att du bara ökar det här värdet om klustrets PROCESSOR är låg, eftersom ökningen kan påverka klustrets CPU-förbrukning avsevärt.

Följande kommando fyller till exempel i den materialiserade vyn från 2020-01-01. Det maximala antalet poster i varje inmatningsåtgärd är 3 miljoner. Kommandot kör inmatningsåtgärderna med samtidighet av 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)
}

Om den materialiserade vyn innehåller en datetime-grupp-by-nyckel stöder återfyllningsprocessen åsidosätter tiden för att skapa omfattning baserat på kolumnen datetime. Detta kan till exempel vara användbart om du vill att äldre poster ska tas bort före de senaste, eftersom kvarhållningsprincipen baseras på tiden för att skapa omfattning. Egenskapen updateExtentsCreationTime stöds endast om vyn innehåller en datetime-grupp-by-nyckel som använder bin() funktionen. Följande återfyllning tilldelar till exempel skapandetid baserat på Timestamp grupp-by-nyckeln:

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

Återfyllnad efter flyttmängder

Alternativet att återfylla genom att flytta omfattningar fyller i den materialiserade vyn baserat på en befintlig tabell, vilket inte nödvändigtvis är källtabellen i den materialiserade vyn. Du uppnår återfyllningen genom att flytta omfattningar från den angivna tabellen till den underliggande materialiserade vytabellen. Den här processen innebär att:

  • Data i den angivna tabellen bör ha samma schema som det materialiserade vyschemat.
  • Poster i den angivna tabellen flyttas till vyn som den är. De antas vara deduplicerade baserat på definitionen av den materialiserade vyn.

Om den materialiserade vyn till exempel har följande aggregering:

T | summarize arg_max(Timestamp, *) by EventId

Sedan bör posterna i källtabellen för åtgärden flytta omfattningar redan dedupliceras av EventID.

Eftersom åtgärden använder .move-omfattningar tas posternabort från den angivna tabellen under återfyllningen (flyttas, kopieras inte).

Återfyllnad efter flyttutbredning stöds inte för alla aggregeringsfunktioner som stöds i materialiserade vyer. Det misslyckas för sammansättningar som avg(), dcount(), där underliggande data som lagras i vyn skiljer sig från själva aggregeringen.

Den materialiserade vyn fylls endast i baserat på den angivna tabellen. Materialisering av poster i källtabellen i vyn börjar som standard från vyns skapandetid.

Om källtabellen i den materialiserade vyn kontinuerligt matar in data kan det leda till viss dataförlust om du skapar vyn med hjälp av flyttutbredningar. Det beror på att poster som matas in i källtabellen, under den korta tiden mellan det att tabellen förbereds att fyllas i från och den tid då vyn skapas, inte tas med i den materialiserade vyn. Om du vill hantera det här scenariot kan du ange source_ingestion_time_from egenskapen till starttiden för den materialiserade vyn över källtabellen.

Användningsfall

Alternativet att återfylla efter flyttgrader kan vara användbart i två huvudscenarier:

  • När du redan har en tabell som innehåller deduplicerade källdata för den materialiserade vyn och du inte behöver dessa poster i den här tabellen när vyn har skapats eftersom du bara använder den materialiserade vyn.

  • När källtabellen i den materialiserade vyn är mycket stor och det inte fungerar bra att fylla i vyn baserat på källtabellen på grund av de begränsningar som nämndes tidigare. I det här fallet kan du orkestrera återfyllningsprocessen själv till en tillfällig tabell med hjälp av inmatning från frågekommandon och något av de rekommenderade orkestreringsverktygen. När den tillfälliga tabellen innehåller alla poster för återfyllningen skapar du den materialiserade vyn baserat på den tabellen.

Exempel:

  • I följande exempel innehåller tabellen DeduplicatedTable en enda post per EventId instans och används som baslinje för den materialiserade vyn. Endast poster i T som matas in efter visningsgenereringstiden tas med i den materialiserade vyn.

    .create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
}

  • Om egenskapen effectiveDateTime anges tillsammans med move_extents_from egenskapen är det bara de delar i DeduplicatedTable vars värde är större än effectiveDateTime vad som MaxCreatedOn ingår i återfyllningen (flyttas till den materialiserade vyn):

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

  • I följande exempel visas användningen av source_ingestion_time_from egenskapen i alternativet att återfylla efter flyttmängder. Om du använder båda source_ingestion_time_from och move_extents_from anger att den materialiserade vyn är ifylld från två källor:

    • Tabellenmove_extents_from: DeduplicatedTable i följande exempel. Den här tabellen bör innehålla alla historiska data som ska fyllas i. Du kan också använda effectiveDateTime egenskapen för att endast inkludera omfattningar i DeduplicatedTable vars MaxCreatedOn värde är större än effectiveDateTime.

    • Källtabellen för den materialiserade vyn: T i följande exempel. Ifyllning från den här tabellen innehåller endast poster vars ingestion_time() värde är större än source_ingestion_time_from.

      Egenskapen source_ingestion_time_from ska endast användas för att hantera den möjliga dataförlusten under den korta tiden mellan att förbereda tabellen för återfyllning från (DeduplicatedTable) och den tid då vyn skapas. Ange inte den här egenskapen för långt tidigare. Det skulle starta den materialiserade vyn med en betydande fördröjning, vilket kan vara svårt att komma ikapp med.

    I följande exempel antar du att den aktuella tiden är 2020-01-01 03:00. Tabellen DeduplicatedTable är en deduplicerad tabell med T. Den innehåller alla historiska data, deduplicerade till .2020-01-01 00:00 Kommandot create använder DeduplicatedTable för att återfylla den materialiserade vyn med hjälp av flyttmängder. Kommandot create innehåller även alla poster som T har matats in sedan 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
}

Avbryt skapande av materialiserad vy

Du kan avbryta processen med att skapa materialiserad vy när du använder återfyllningsalternativet. Den här åtgärden är användbar när det tar för lång tid att skapa och du vill stoppa den när den körs.

Varning

Det går inte att återställa den materialiserade vyn när du har kört det här kommandot.

Det går inte att avbryta skapandeprocessen omedelbart. Kommandot Cancel signalerar materialisering att stoppa, och skapandet kontrollerar regelbundet om en avbokning begärdes. Kommandot Avbryt väntar i högst 10 minuter tills processen för att skapa den materialiserade vyn avbryts och rapporterar tillbaka om annulleringen lyckades.

Även om annulleringen inte lyckas inom 10 minuter och kommandot avbryts rapporterar fel, kommer den materialiserade vyn förmodligen att avbryta sig själv senare i skapandeprocessen. Kommandot .show operations anger om åtgärden avbröts.

Om åtgärden inte längre pågår när .cancel operation kommandot utfärdas rapporterar kommandot ett felmeddelande om detta.

Syntax

.cancel operationoperationId

Läs mer om syntaxkonventioner.

Parametrar

Namn Typ Obligatorisk Beskrivning
operationId guid ✔️ Åtgärds-ID:t som returnerades från .create async materialized-view kommandot.

Utdata

Namn Typ Description
OperationId guid Kommandots .create materialized-view åtgärds-ID.
Åtgärd string Typ av åtgärd.
StartedOn datetime Starttiden för skapandeåtgärden.
CancellationState string En av: Canceled successfully (skapandet avbröts) Cancellation failed (tidsgränsen för att avbrytas har överskridits) Unknown (vyn körs inte längre men avbröts inte av den här åtgärden).
ReasonPhrase string Anledningen till att annulleringen inte lyckades.

Exempel

.cancel operation c4b29441-4873-4e36-8310-c631c35c916e
OperationId Åtgärd StartedOn CancellationState ReasonPhrase
c4b29441-4873-4e36-8310-c631c35c916e MaterializedViewCreateOrAlter 2020-05-08 19:45:03.9184142 Canceled successfully

Om annulleringen inte har slutförts inom 10 minuter CancellationState indikerar det ett fel. Skapandet kan sedan avbrytas.