.create materialized-view

Article
10/15/2024

S’applique à : ✅Microsoft Fabric ✅Azure Data Explorer

Une vue matérialisée est une requête d’agrégation sur une table source. Il représente une seule déclaration summarize.

Il existe deux façons de créer une vue matérialisée, comme indiqué par l’option de remplissage de retour dans la commande :

Créez la vue matérialisée à partir de maintenant :

La vue matérialisée est créée vide. Il inclut uniquement les enregistrements ingérés après la création de l’affichage. La création de ce type retourne immédiatement et la vue est immédiatement disponible pour la requête.

Créez la vue matérialisée en fonction des enregistrements existants dans la table source :

Consultez le remplissage d’une vue matérialisée.
La création peut prendre un certain temps, en fonction du nombre d’enregistrements dans la table source. La vue ne sera pas disponible pour les requêtes tant que le remplissage n’est pas terminé.
Lorsque vous utilisez cette option, la commande create doit être async. Vous pouvez surveiller l’exécution à l’aide de la .show operations commande.
Vous pouvez annuler le processus de remplissage à l’aide de la .cancel operation commande.

Important

Sur les tables sources volumineuses, l’option de remplissage peut prendre beaucoup de temps. Si ce processus échoue temporairement lors de l’exécution, il ne sera pas retenté automatiquement. Vous devez ensuite réexécuter la commande create. Pour plus d’informations, consultez Le remplissage d’une vue matérialisée.

autorisations

Cette commande nécessite des autorisations d’administrateur de base de données. Le créateur de la vue matérialisée devient l’administrateur de celui-ci.

Syntaxe

.create[] [asyncifnotexists] materialized-view [ with(PropertyName = PropertyValue,...] )Requête MaterializedViewName SourceTableName on table { }

En savoir plus sur les conventions de syntaxe.

Paramètres

Nom	Type	Requise	Description
PropertyName, PropertyValue	`string`		Liste des propriétés sous la forme de paires nom et valeur, dans la liste des propriétés prises en charge.
MaterializedViewName	`string`	✔️	Nom de la vue matérialisée. Le nom de la vue ne peut pas entrer en conflit avec les noms de table ou de fonction dans la même base de données et doit respecter les règles d’affectation de noms d’identificateur.
SourceTableName	`string`	✔️	Nom de la table source sur laquelle la vue est définie.
Requête	`string`	✔️	Définition de requête de la vue matérialisée. Pour plus d’informations et de limitations, consultez la section Des paramètres de requête.

Remarque

Si la vue matérialisée existe déjà :

Si l’indicateur ifnotexists est spécifié, la commande est ignorée. Aucune modification n’est appliquée, même si la nouvelle définition ne correspond pas à la définition existante.
Si l’indicateur ifnotexists n’est pas spécifié, une erreur est retournée.
Pour modifier une vue matérialisée existante, utilisez la commande .alter materialized-view .

Propriétés prises en charge

Les propriétés suivantes sont prises en charge dans la with (clause PropertyName = PropertyValue.) Toutes les propriétés sont facultatives.

Nom	Type	Description
Remblai	`bool`	Indique s’il faut créer l’affichage en fonction de tous les enregistrements actuellement dans `SourceTable` (`true`) ou de le créer à partir de maintenant (`false`). La valeur par défaut est `false`. Pour plus d’informations, consultez Le remplissage d’une vue matérialisée.
effectiveDateTime	`datetime`	Pertinent uniquement lorsque vous utilisez `backfill`. Si elle est définie, la création revient uniquement avec les enregistrements ingérés après la datetime. `backfill` doit également être défini sur `true`. Cette propriété attend un littéral datetime ; par exemple, `effectiveDateTime=datetime(2019-05-01)`.
updateExtentsCreationTime	`bool`	Pertinent uniquement lorsque vous utilisez `backfill`. S’il est défini `true`sur , l’heure de création de l’étendue est affectée en fonction de la clé de groupe datetime par clé pendant le processus de remplissage. Pour plus d’informations, consultez Le remplissage d’une vue matérialisée.
lookback	`timespan`	Valide uniquement pour `arg_max`//`arg_mintake_any` les vues matérialisées. Elle limite la période pendant laquelle les doublons sont attendus. Par exemple, si une recherche de 6 heures est spécifiée sur une `arg_max` vue, la déduplication entre les enregistrements nouvellement ingérés et les enregistrements existants prend en compte uniquement les enregistrements qui ont été ingérés il y a jusqu’à 6 heures. Lookback est relatif à ingestion_time(). Si la requête d’affichage matérialisée ne conserve pas la `ingestion_time()` valeur, la recherche en arrière ne peut pas être définie sur la vue. Consultez les limitations de vues matérialisées et les problèmes connus. La définition incorrecte de la période de recherche peut entraîner des doublons dans la vue matérialisée. Par exemple, si un enregistrement pour une clé spécifique est ingéré 10 heures après l’ingestion d’un enregistrement pour la même clé et que la recherche est définie sur 6 heures, cette clé est un doublon dans la vue. La période de recherche est appliquée pendant le temps de matérialisation et l’heure de requête.
autoUpdateSchema	`bool`	Indique s’il faut mettre à jour automatiquement la vue sur les modifications apportées à la table source. La valeur par défaut est `false`. Cette option est valide uniquement pour les vues de type `arg_max(Timestamp, )`//`arg_min(Timestamp, )take_any()` (uniquement lorsque l’argument de la colonne est ).`` Si cette option est définie `true`sur , les modifications apportées à la table source sont automatiquement reflétées dans la vue matérialisée.
dimensionTables	tableau	Argument dynamique qui inclut un tableau de tables de dimension dans la vue. Consultez le paramètre De requête.
dossier	`string`	Dossier de la vue matérialisée.
docString	`string`	Chaîne qui documente la vue matérialisée.
allowMaterializedViewsWithoutRowLevelSecurity	`bool`	Permet de créer une vue matérialisée sur une table avec une stratégie de sécurité au niveau des lignes activée.

Avertissement

Le système désactive automatiquement une vue matérialisée si les modifications apportées à la table source de la vue matérialisée, ou les modifications apportées aux données, entraînent une incompatibilité entre la requête de vue matérialisée et le schéma de vue matérialisé attendu.
Pour éviter cette erreur, la requête de vue matérialisée doit être déterministe. Par exemple, le plug-in bag_unpack ou pivot entraîne un schéma non déterministe.
Lorsque vous utilisez une arg_max(Timestamp, *) agrégation et lorsque autoUpdateSchema la valeur est false, les modifications apportées à la table source peuvent également entraîner des incompatibilités de schéma. Évitez cet échec en définissant la requête d’affichage comme arg_max(Timestamp, Column1, Column2, ...), ou en utilisant l’option autoUpdateSchema .
L’utilisation autoUpdateSchema peut entraîner une perte de données irréversible lorsque les colonnes de la table source sont supprimées.
Surveillez la désactivation automatique des vues matérialisées à l’aide de la métrique MaterializedViewResult.
Une fois que vous avez résolu les problèmes d’incompatibilité, vous devez réactiver explicitement la vue à l’aide de la commande Activer la vue matérialisée.

Créer une vue matérialisée sur une vue matérialisée

Vous pouvez créer une vue matérialisée sur une autre vue matérialisée uniquement lorsque la vue matérialisée source est une take_any(*) agrégation (déduplication). Pour plus d’informations, consultez La vue matérialisée sur l’affichage matérialisé et les exemples.

Syntaxe :

.create[] [asyncifnotexists] materialized-view [ with(PropertyName = PropertyValue,...] )Requête MaterializedViewName SourceMaterializedViewName { on materialized-view }

Paramètres :

Nom	Type	Requise	Description
PropertyName, PropertyValue	`string`		Liste des propriétés sous la forme de paires nom et valeur, dans la liste des propriétés prises en charge.
MaterializedViewName	`string`	✔️	Nom de la vue matérialisée. Le nom de la vue ne peut pas entrer en conflit avec les noms de table ou de fonction dans la même base de données et doit respecter les règles d’affectation de noms d’identificateur.
SourceMaterializedViewName	`string`	✔️	Nom de la vue matérialisée source sur laquelle la vue est définie.
Requête	`string`	✔️	Définition de requête de la vue matérialisée.

Exemples

Créez une vue vide arg_max qui matérialisera uniquement les enregistrements ingérés à partir de maintenant :
```
.create materialized-view ArgMax on table T
{
    T | summarize arg_max(Timestamp, *) by User
}
```

Créez une vue matérialisée pour les agrégats quotidiens avec l’option de remplissage en utilisant 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 
}

Créez une vue matérialisée avec backfill et effectiveDateTime. La vue est créée en fonction des enregistrements de datetime uniquement.

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

Créez une vue matérialisée qui déduplique la table source, en fonction de la colonne, à l’aide EventId d’une recherche de 6 heures. Les enregistrements sont dédupliqués uniquement par rapport aux enregistrements ingérés 6 heures avant les enregistrements actuels.
```
.create materialized-view with(lookback=6h) DeduplicatedTable on table T
{
    T
    | summarize take_any(*) by EventId
}
```

Créez une vue matérialisée rétro-échantillonnée basée sur la vue matérialisée précédente DeduplicatedTable :

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

La définition peut inclure des opérateurs supplémentaires avant l’instruction summarize , tant qu’elle summarize est la dernière :

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

Voici des vues matérialisées qui se joignent à une table de dimension :

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

Notes

Paramètre de requête.

Les règles suivantes limitent la requête utilisée dans le paramètre de requête de vue matérialisée :

La requête doit référencer une table de faits unique qui est la source de la vue matérialisée. Il doit inclure un opérateur unique summarize et une ou plusieurs fonctions d’agrégation agrégées par un ou plusieurs groupes par expressions. L’opérateur summarize doit toujours être le dernier opérateur de la requête.

Une vue matérialisée qui inclut une seule arg_max//arg_mintake_any agrégation peut fonctionner mieux qu’une vue matérialisée qui inclut ces agrégations ainsi que d’autres agrégations (paravgcount/dcount/ exemple). Cela est dû au fait que certaines optimisations sont pertinentes uniquement pour ces types de vues matérialisées. Ils ne s’appliquent pas lorsque la vue inclut des fonctions d’agrégation mixtes (où des moyens/take_any arg_maxarg_min/mixtes et d’autres agrégations dans la même vue).
La requête ne doit pas inclure d’opérateurs qui dépendent now(). Par exemple, la requête ne doit pas avoir where Timestamp > ago(5d). Utilisez la stratégie de rétention sur la vue matérialisée pour limiter la période de couverture de la vue.
Les opérateurs suivants ne sont pas pris en charge dans la requête de vue matérialisée : sort, , top-nestedtop, partition, . serialize
Les agrégations composites ne sont pas prises en charge dans la définition de la vue matérialisée. Par exemple, au lieu d’utiliser SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Id, définissez la vue matérialisée comme suit : SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id. Pendant l’affichage de l’heure de requête, exécutez MaterializedViewName | project Id, Result=a/b. La sortie requise de la vue, y compris la colonne calculée (a/b), peut être encapsulée dans une fonction stockée. Accédez à la fonction stockée au lieu d’accéder directement à la vue matérialisée.

Les requêtes entre clusters et bases de données croisées ne sont pas prises en charge.

Les requêtes inter-événements et inter-bases de données ne sont pas prises en charge.

Les références à external_table() et externaldata ne sont pas prises en charge.
La requête de vue matérialisée ne peut pas inclure de légendes qui nécessitent l’emprunt d’identité. Plus précisément, tous les plug-ins de connectivité de requête qui utilisent l’emprunt d’identité ne sont pas autorisés.
Outre la table source de la vue, la requête est autorisée à référencer une ou plusieurs tables de dimension. Les tables de dimension doivent être explicitement appelées dans les propriétés d’affichage. Il est important de comprendre le comportement suivant lorsque vous joignez des tables de dimension :
- Les enregistrements de la table source de la vue (la table de faits) ne sont matérialisés qu’une seule fois. Les mises à jour des tables de dimension n’ont aucun impact sur les enregistrements qui ont déjà été traités à partir de la table de faits.
- Une latence d’ingestion différente entre la table de faits et la table de dimension peut affecter les résultats de la vue.
  
  Exemple : une définition de vue inclut une jointure interne avec une table de dimension. Au moment de la matérialisation, l’enregistrement de dimension n’était pas entièrement ingéré, mais il était déjà ingéré dans la table de faits. Cet enregistrement sera supprimé de la vue et ne sera jamais traité à nouveau.
  
  De même, si la jointure est une jointure externe, l’enregistrement de la table de faits est traité et ajouté à la vue avec une valeur Null pour les colonnes de la table de dimension. Les enregistrements qui ont déjà été ajoutés (avec des valeurs Null) à la vue ne seront plus traités. Leurs valeurs, dans les colonnes de la table de dimension, restent null.

Fonctions d’agrégation prises en charge

Les fonctions d’agrégation suivantes sont prises en charge :

Astuces pour les performances

Utilisez une clé group-by datetime : les vues matérialisées qui ont une colonne datetime comme l’une de leurs clés group-by sont plus efficaces que celles qui ne le font pas. La raison est que certaines optimisations peuvent être appliquées uniquement lorsqu’il existe une clé de groupe datetime. Si l’ajout d’une clé de groupe datetime ne modifie pas la sémantique de votre agrégation, nous vous recommandons de l’ajouter. Vous ne pouvez le faire que si la colonne datetime est immuable pour chaque entité unique.

Par exemple, dans l’agrégation suivante :
```
    SourceTable | summarize take_any(*) by EventId
```
Si EventId toujours a la même Timestamp valeur et, par conséquent, l’ajout Timestamp ne modifie pas la sémantique de l’agrégation, il est préférable de définir la vue comme suit :
```
    SourceTable | summarize take_any(*) by EventId, Timestamp
```
Conseil

Les données arrivant en retard dans un groupe datetime par clé peuvent avoir un impact négatif sur les performances de la vue matérialisée. Par exemple, supposons qu’une vue matérialisée utilise bin(Timestamp, 1d) l’une de ses clés group-by et que les enregistrements nouvellement ingérés dans la table source ont d’anciennes Timestamp valeurs. Ces enregistrements peuvent affecter négativement la vue matérialisée.

Si vous prévoyez que les enregistrements arrivés en retard sont ingérés dans la table source, ajustez la stratégie de mise en cache de la vue matérialisée en conséquence. Par exemple, si les enregistrements avec Timestamp il y a six mois sont censés être ingérés dans la table source, le processus de matérialisation devra analyser la vue matérialisée pour les six mois précédents. Si cette période est en cache à froid, la matérialisation connaîtra des absences de cache qui auront un impact négatif sur les performances de la vue.

Si ces enregistrements arrivant en retard ne sont pas attendus, nous vous recommandons de filtrer ces enregistrements ou de normaliser leurs valeurs d’horodatage à l’heure actuelle dans la requête d’affichage matérialisée.
Définir une période de recherche : si elle s’applique à votre scénario, l’ajout d’une lookback propriété peut améliorer considérablement les performances des requêtes. Pour plus d’informations, consultez Les propriétés prises en charge.
Ajoutez des colonnes fréquemment utilisées pour le filtrage en tant que clés group-by : les requêtes de vue matérialisée sont optimisées lorsqu’elles sont filtrées par l’une des clés de groupe de la vue matérialisée. Si vous savez que votre modèle de requête filtre souvent par une colonne immuable en fonction d’une entité unique dans la vue matérialisée, incluez-la dans les clés group-by de la vue matérialisée.

Par exemple, une vue matérialisée s’expose arg_max par une ResourceId valeur qui sera souvent filtrée par SubscriptionId. En supposant qu’une ResourceId valeur appartient toujours à la même SubscriptionId valeur, définissez la requête de vue matérialisée comme suit :
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
}
```
La définition précédente est préférable à ce qui suit :
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by ResourceId 
}
```

Utilisez les stratégies de mise à jour le cas échéant : la vue matérialisée peut inclure des transformations, des normalisations et des recherches dans les tables de dimension. Toutefois, nous vous recommandons de déplacer ces opérations vers une stratégie de mise à jour. Laissez uniquement l’agrégation pour la vue matérialisée.

Par exemple, il est préférable de définir la stratégie de mise à jour suivante :

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

Définissez la vue matérialisée suivante :

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

L’alternative, d’inclure la stratégie de mise à jour dans le cadre de la requête de vue matérialisée, peut s’avérer pire et, par conséquent, non recommandée :

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

Conseil

Si vous avez besoin des meilleures performances de temps de requête, mais que vous pouvez tolérer une latence de données, utilisez la fonction materialized_view().

Remplissage d’une vue matérialisée

Lorsque vous créez une vue matérialisée à l’aide de la backfill propriété, la vue matérialisée est créée en fonction des enregistrements disponibles dans la table source. Ou il sera créé en fonction d’un sous-ensemble de ces enregistrements, si vous utilisez effectiveDateTime.

En arrière-plan, le processus de remplissage fractionne les données pour effectuer le remplissage en plusieurs lots et exécute plusieurs opérations d’ingestion pour renvoyer la vue. Le processus peut prendre un certain temps quand le nombre d’enregistrements de la table source est volumineux. La durée du processus dépend de la taille de la base de données. Suivez la progression du remplissage à l’aide de la .show operations commande.

Les échecs temporaires qui se produisent dans le cadre du processus de remplissage sont retentés. Si toutes les nouvelles tentatives sont épuisées, la commande échoue et nécessite une réexécution manuelle de la commande create.

Nous vous déconseillons number-of-nodes X 200 million d’utiliser le remplissage lorsque le nombre d’enregistrements de la table source dépasse (parfois même moins, selon la complexité de la requête). Une alternative est l’option de remplissage par déplacement d’étendues .

L’utilisation de l’option de remplissage n’est pas prise en charge pour les données dans un cache à froid. Augmentez la période de cache à chaud, si nécessaire, pendant la durée de la création de la vue. Cela peut nécessiter un scale-out.

Si vous rencontrez des échecs dans la création d’affichage, essayez de modifier ces propriétés :

MaxSourceRecordsForSingleIngest: par défaut, le nombre d’enregistrements sources dans chaque opération d’ingestion pendant le remplissage est de 2 millions par nœud. Vous pouvez modifier cette valeur par défaut en définissant cette propriété sur le nombre d’enregistrements souhaité. (La valeur est le nombre total d’enregistrements dans chaque opération d’ingestion.)

La diminution de cette valeur peut être utile lorsque la création échoue sur les limites de mémoire ou les délais d’expiration des requêtes. L’augmentation de cette valeur peut accélérer la création d’affichage, en supposant que la base de données peut exécuter la fonction d’agrégation sur plus d’enregistrements que la valeur par défaut.
Concurrency: les opérations d’ingestion, exécutées dans le cadre du processus de remplissage, s’exécutent simultanément. Par défaut, la concurrence est min(number_of_nodes * 2, 5). Vous pouvez définir cette propriété pour augmenter ou diminuer la concurrence. Nous vous recommandons d’augmenter cette valeur uniquement si l’UC de databse est faible, car l’augmentation peut affecter considérablement la consommation du processeur de la base de données.

Par exemple, la commande suivante renflouera la vue matérialisée à partir de 2020-01-01. Le nombre maximal d’enregistrements dans chaque opération d’ingestion est de 3 millions. La commande exécute les opérations d’ingestion avec concurrence de 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)
}

Si la vue matérialisée inclut une clé de groupe datetime, le processus de remplissage prend en charge la substitution de l’heure de création de l’extension en fonction de la colonne datetime. Cela peut être utile, par exemple, si vous souhaitez que les enregistrements plus anciens soient supprimés avant les enregistrements récents, car la stratégie de rétention est basée sur l’heure de création de l’étendue. La updateExtentsCreationTime propriété est prise en charge uniquement si la vue inclut une clé de groupe datetime par clé qui utilise la bin() fonction. Par exemple, le remplissage suivant affecte le temps de création en fonction de la Timestamp clé group-by :

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

Remplissage en fonction des étendues de déplacement

L’option de remplissage en déplaçant les étendues reremplit la vue matérialisée en fonction d’une table existante, ce qui n’est pas nécessairement la table source de la vue matérialisée. Vous obtenez le remplissage en déplaçant les étendues de la table spécifiée dans la table de vue matérialisée sous-jacente. Ce processus implique que :

Les données de la table spécifiée doivent avoir le même schéma que le schéma de vue matérialisé.
Les enregistrements de la table spécifiée sont déplacés vers l’affichage tel qu’il se trouve. Elles sont supposées être dédupliquées en fonction de la définition de la vue matérialisée.

Par exemple, si la vue matérialisée a l’agrégation suivante :

T | summarize arg_max(Timestamp, *) by EventId

Ensuite, les enregistrements de la table source pour l’opération d’étendues de déplacement doivent déjà être dédupliqués par EventID.

Étant donné que l’opération utilise des étendues .move, les enregistrements sont supprimés de la table spécifiée pendant le remplissage (déplacé, non copié).

Le remplissage par extension de déplacement n’est pas pris en charge pour toutes les fonctions d’agrégation prises en charge dans les vues matérialisées. Elle échoue pour les agrégations telles que avg(), dcount()dans lesquelles les données sous-jacentes stockées dans la vue sont différentes de l’agrégation elle-même.

La vue matérialisée est remblayée uniquement en fonction de la table spécifiée. La matérialisation des enregistrements dans la table source de la vue commence par l’heure de création de l’affichage, par défaut.

Si la table source de la vue matérialisée est en permanence en train d’ingérer des données, la création de la vue à l’aide d’étendues de déplacement peut entraîner une perte de données. Cela est dû au fait que les enregistrements ingérés dans la table source, dans le court délai entre le temps de préparation de la table à remplir et l’heure de création de la vue, ne seront pas inclus dans la vue matérialisée. Pour gérer ce scénario, vous pouvez définir la source_ingestion_time_from propriété sur l’heure de début de la vue matérialisée sur la table source.

Cas d’utilisation

L’option de remplissage en déplaçant des étendues peut être utile dans deux scénarios principaux :

Lorsque vous disposez déjà d’une table qui inclut les données sources dédupliquées pour la vue matérialisée et que vous n’avez pas besoin de ces enregistrements dans cette table après la création de la vue, car vous utilisez uniquement la vue matérialisée.
Lorsque la table source de la vue matérialisée est très volumineuse et que le remplissage de la vue en fonction de la table source ne fonctionne pas correctement en raison des limitations mentionnées précédemment. Dans ce cas, vous pouvez orchestrer le processus de remplissage vous-même dans une table temporaire à l’aide de l’ingestion à partir des commandes de requête. Lorsque la table temporaire inclut tous les enregistrements du remplissage, créez la vue matérialisée en fonction de cette table.

Vous pouvez également utiliser l’un des outils d’orchestration recommandés.

Exemples :

Dans l’exemple suivant, le tableau DeduplicatedTable inclut un enregistrement unique par EventId instance et sera utilisé comme base de référence pour la vue matérialisée. Seuls les enregistrements qui T sont ingérés après l’heure de création de l’affichage seront inclus dans la vue matérialisée.
```
.create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
Si la effectiveDateTime propriété est spécifiée avec la move_extents_from propriété, seules les étendues dans DeduplicatedTable lesquelles MaxCreatedOn la valeur est supérieure effectiveDateTime sont incluses dans le remplissage (déplacé vers la vue matérialisée) :
```
.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
} 
```
L’exemple suivant illustre l’utilisation de la source_ingestion_time_from propriété dans l’option de remplissage en fonction des étendues de déplacement. L’utilisation des deux source_ingestion_time_from et move_extents_from indique que la vue matérialisée est remblayée à partir de deux sources :
- Tableau move_extents_from : DeduplicatedTable dans l’exemple suivant. Cette table doit inclure toutes les données d’historique à remplir. Vous pouvez éventuellement utiliser la effectiveDateTime propriété pour inclure uniquement des étendues dans DeduplicatedTable lesquelles MaxCreatedOn la valeur est supérieure effectiveDateTimeà .
- Table source de la vue matérialisée : T dans l’exemple suivant. Le remplissage de cette table inclut uniquement les enregistrements dont la valeur ingestion_time() est supérieure source_ingestion_time_fromà .
  
  La source_ingestion_time_from propriété doit être utilisée uniquement pour gérer la perte de données possible dans le court délai entre la préparation de la table à partir de (DeduplicatedTable) et l’heure à laquelle la vue est créée. Ne définissez pas cette propriété trop loin dans le passé. Cela permettrait de commencer la vue matérialisée avec un décalage significatif, ce qui pourrait être difficile à rattraper.
Dans l’exemple suivant, supposons que l’heure actuelle est 2020-01-01 03:00. La table DeduplicatedTable est une table dédupliquée de T. Elle inclut toutes les données historiques, dédupliquées jusqu’à 2020-01-01 00:00. La create commande utilise DeduplicatedTable pour remplir la vue matérialisée à l’aide des étendues de déplacement. La create commande inclut également tous les enregistrements dans T ingérés depuis 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
} 
```

Annuler la création d’une vue matérialisée

Vous pouvez annuler le processus de création de vue matérialisée lorsque vous utilisez l’option de remplissage. Cette action est utile lorsque la création prend trop de temps et que vous souhaitez l’arrêter pendant son exécution.

Avertissement

La vue matérialisée ne peut pas être restaurée après l’exécution de cette commande.

Le processus de création ne peut pas être annulé immédiatement. La commande d’annulation signale la matérialisation à arrêter et la création vérifie régulièrement si une annulation a été demandée. La commande d’annulation attend une période maximale de 10 minutes jusqu’à ce que le processus de création d’affichage matérialisé soit annulé, et indique si l’annulation a réussi.

Même si l’annulation ne réussit pas dans les 10 minutes et que la commande d’annulation signale l’échec, la vue matérialisée s’annule probablement plus tard dans le processus de création. La .show operations commande indique si l’opération a été annulée.

Si l’opération n’est plus en cours lorsque la .cancel operation commande est émise, la commande signale une erreur indiquant ainsi.

Syntaxe

.cancel operationoperationId

En savoir plus sur les conventions de syntaxe.

Paramètres

Nom	Type	Requise	Description
`operationId`	`guid`	✔️	ID d’opération retourné par la `.create async materialized-view` commande.

Sortie

Nom	Type	Description
OperationId	`guid`	ID d’opération de la `.create materialized-view` commande.
Opération	`string`	Type d’opération.
StartedOn	`datetime`	Heure de début de l’opération de création.
CancellationState	`string`	Un des éléments suivants : `Canceled successfully` (la création a été annulée), `Cancellation failed` (attendre l’expiration du délai d’annulation) `Unknown` (la création de l’affichage n’est plus en cours d’exécution, mais n’a pas été annulée par cette opération).
ReasonPhrase	`string`	La raison pour laquelle l’annulation n’a pas réussi.

Exemples

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

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

Si l’annulation n’a pas terminé dans les 10 minutes, CancellationState indique l’échec. La création peut ensuite être annulée.

Partage via

.create materialized-view

autorisations

Syntaxe

Paramètres

Propriétés prises en charge

Créer une vue matérialisée sur une vue matérialisée

Exemples

Notes

Paramètre de requête.

Fonctions d’agrégation prises en charge

Astuces pour les performances

Remplissage d’une vue matérialisée

Remplissage en fonction des étendues de déplacement

Cas d’utilisation

Annuler la création d’une vue matérialisée

Syntaxe

Paramètres

Sortie

Exemples

Commentaires

Ressources supplémentaires