Requêtes entre plusieurs clusters et bases de données

Les requêtes s’exécutent avec une base de données particulière désignée comme base de données dans le contexte. Cette base de données agit comme valeur par défaut pour la vérification des autorisations. Si une entité est référencée dans une requête sans spécifier le cluster ou la base de données, elle est résolue par rapport à cette base de données.

Les requêtes s’exécutent avec une base de données particulière désignée comme base de données dans le contexte. Cette base de données agit comme valeur par défaut pour la vérification des autorisations. Si une entité est référencée dans une requête sans spécifier le contexte, elle est résolue sur cette base de données.

• Si les clusters se trouvent dans différents locataires, suivez les instructions fournies dans Autoriser les requêtes et commandes interlocataires.

Identifier le cluster et la base de données dans le contexte

Identifier l’eventhouse et la base de données dans le contexte

Effectuer des requêtes entre clusters ou inter-bases de données

Effectuer des requêtes inter-événements ou inter-bases de données

Pour une table dans une autre base de données au sein du même cluster :

database("<DatabaseName>").<TableName>

Pour une table dans un cluster distant :

cluster("<ClusterName>").database("<DatabaseName>").<TableName>

Pour une table dans une autre base de données au sein du même eventhouse :

database("<DatabaseName>").<TableName>

Pour une table dans un cluster eventhouse ou un service distant (comme Azure Data Explorer) :

cluster("<EventhouseClusterURI>").database("<DatabaseName>").<TableName>

Lorsqu’un nom qualifié apparaît en tant qu’opérande de l’opérateur union, les caractères génériques peuvent être utilisés pour spécifier plusieurs tables et plusieurs bases de données. Les caractères génériques ne sont pas autorisés dans les noms de cluster.

union withsource=TableName *, database("OtherDb*").*Table, cluster("OtherCluster").database("*").*

Lorsqu’un nom qualifié apparaît en tant qu’opérande de l’opérateur union, les caractères génériques peuvent être utilisés pour spécifier plusieurs tables et plusieurs bases de données. Les caractères génériques ne sont pas autorisés dans les noms de la maison d’événements.

union withsource=TableName *, database("OtherDb*").*Table, cluster("OtherEventhouseClusterURI").database("*").*

Les noms qualifiés ou les modèles peuvent également être inclus dans l’instruction restreindre l’accès . Les caractères génériques dans les noms de cluster ne sont pas autorisés.

Les caractères génériques dans les noms d’eventhouse ne sont pas autorisés.

• Tout nom d’entité commençant par my... dans la base de données par défaut.
• Toute table de toutes les bases de données nommées MyOther... du cluster actuel.
• Toute table de toutes les bases de données nommées my2... dans le cluster OtherCluster.kusto.windows.net.

restrict access to (my*, database("MyOther*").*, cluster("OtherCluster").database("my2*").*);

• Tout nom d’entité commençant par l’événement... dans la base de données par défaut.
• Toute table de toutes les bases de données nommées EventOther... de l’eventhouse actuel.
• Toute table de toutes les bases de données nommées event2... dans le OtherEventhouse.kusto.data.microsoft.com de la maison d’événements.

restrict access to (event*, database("EventOther*").*, cluster("OtherEventhouseClusterURI").database("event2*").*);

Pour traiter une requête inter-cluster, le cluster qui effectue l’interprétation initiale de la requête doit avoir le schéma des entités référencées sur des clusters distants. Pour obtenir ces informations, une commande est envoyée pour récupérer les schémas, qui sont ensuite stockés dans un cache.

S’il existe une modification de schéma dans le cluster distant, un schéma mis en cache peut devenir obsolète. Cela peut entraîner des effets indésirables, notamment des scénarios où les colonnes nouvelles ou supprimées provoquent un Partial query failure. Pour résoudre ces problèmes, actualisez manuellement le schéma avec la commande de schéma distant du cache .clear.

Pour traiter une requête de cluster inter-eventhouse ou eventhouse-to-ADX, l’eventhouse qui effectue l’interprétation initiale de la requête doit avoir le schéma des entités référencées sur des eventhouses ou clusters distants. Pour obtenir ces informations, une commande est envoyée pour récupérer les schémas, qui sont ensuite stockés dans un cache.

S’il existe une modification de schéma distante, un schéma mis en cache peut devenir obsolète. Cela peut entraîner des effets indésirables, notamment des scénarios où les colonnes nouvelles ou supprimées provoquent un Partial query failure. Pour résoudre ces problèmes, actualisez manuellement le schéma avec la commande de schéma distant du cache .clear.

Les fonctions et vues (persistantes et créées inline) peuvent référencer des tables entre les limites de base de données et de cluster. Le code suivant est valide.

let MyView = Table1 join database("OtherDb").Table2 on Key | join cluster("OtherCluster").database("SomeDb").Table3 on Key;
MyView | where ...

Les fonctions et vues persistantes sont accessibles à partir d’une autre base de données du même cluster.

Par exemple, supposons que vous créez la fonction tabulaire suivante (vue) dans une base de données OtherDb:

.create function MyView(v:string) { Table1 | where Column1 has v ...  }  

Ensuite, vous créez la fonction scalaire suivante dans une base de données OtherDb:

.create function MyCalc(a:double, b:double, c:double) { (a + b) / c }  

Dans la base de données par défaut, ces entités peuvent être référencées comme suit :

database("OtherDb").MyView("exception") | extend CalCol=database("OtherDb").MyCalc(Col1, Col2, Col3) | take 10

Les fonctions et vues (persistantes et créées inline) peuvent référencer des tables entre les limites de base de données et d’entrepôt d’événements. Le code suivant est valide.

let EventView = Table1 join database("OtherDb").Table2 on Key | join cluster("OtherEventhouseClusterURI").database("SomeDb").Table3 on Key;
EventView | where ...

Les fonctions et vues persistantes sont accessibles à partir d’une autre base de données dans le même eventhouse.

Par exemple, supposons que vous créez la fonction tabulaire suivante (vue) dans une base de données OtherDb:

.create function EventView(v:string) { Table1 | where Column1 has v ...  }  

Ensuite, vous créez la fonction scalaire suivante dans une base de données OtherDb:

.create function EventCalc(a:double, b:double, c:double) { (a + b) / c }  

Par exemple, supposons que vous créez la fonction tabulaire suivante (vue) dans une base de données OtherDb:

.create function EventView(v:string) { Table1 | where Column1 has v ...  }  

Ensuite, vous créez la fonction scalaire suivante dans une base de données OtherDb:

.create function EventCalc(a:double, b:double, c:double) { (a + b) / c }  

Dans la base de données par défaut, ces entités peuvent être référencées comme suit :

database("OtherDb").EventView("exception") | extend CalCol=database("OtherDb").EventCalc(Col1, Col2, Col3) | take 10

Limitations des appels de fonction entre clusters

Les fonctions ou vues tabulaires peuvent être référencées entre les clusters. Les restrictions suivantes s’appliquent :

• Les fonctions distantes doivent retourner le schéma tabulaire. Les fonctions scalaires sont accessibles uniquement dans le même cluster.
• Les fonctions distantes peuvent accepter uniquement les arguments scalaires. Les fonctions qui obtiennent un ou plusieurs arguments de table sont accessibles uniquement dans le même cluster.
• Le schéma de résultat des fonctions distantes doit être résolu (connu à l’avance sans exécuter des parties de la requête). Ainsi, les constructions de requête telles que le pivot plug-in ne peuvent pas être utilisées. Certains plug-ins, tels que le bag_unpack plug-in, prennent en charge un moyen d’indiquer le schéma de résultat de manière statique, et sous cette forme, il peut être utilisé dans les appels de fonction inter-cluster.
• Pour des raisons de performances, le cluster appelant met en cache le schéma des entités distantes après l’appel initial. Par conséquent, les modifications apportées à l’entité distante peuvent entraîner une incompatibilité avec les informations de schéma mises en cache, ce qui peut entraîner des échecs de requête. Pour plus d’informations, consultez requêtes inter-clusters et modifications de schéma.

Limitations des appels de fonction inter-événements

Les fonctions ou vues tabulaires peuvent être référencées entre les entrepôts d’événements. Les restrictions suivantes s’appliquent :

• Les fonctions distantes doivent retourner le schéma tabulaire. Les fonctions scalaires sont accessibles uniquement dans le même eventhouse.
• Les fonctions distantes peuvent accepter uniquement les arguments scalaires. Les fonctions qui obtiennent un ou plusieurs arguments de table sont accessibles uniquement dans le même eventhouse.
• Le schéma de résultat des fonctions distantes doit être résolu (connu à l’avance sans exécuter des parties de la requête). Ainsi, les constructions de requête telles que le pivot plug-in ne peuvent pas être utilisées. Certains plug-ins, tels que le bag_unpack plug-in, prennent en charge un moyen d’indiquer le schéma de résultat de manière statique, et sous cette forme, il peut être utilisé dans les appels de fonction inter-événements.
• Pour des raisons de performances, l’eventhouse appelant met en cache le schéma des entités distantes après l’appel initial. Par conséquent, les modifications apportées à l’entité distante peuvent entraîner une incompatibilité avec les informations de schéma mises en cache, ce qui peut entraîner des échecs de requête. Pour plus d’informations, consultez requêtes inter-clusters et modifications de schéma.

L’appel inter-cluster suivant est valide.

cluster("OtherCluster").database("SomeDb").MyView("exception") | count

La requête suivante appelle une fonction MyCalcscalaire distante. Cet appel enfreint la règle n° 1. Il n’est donc pas valide.

MyTable | extend CalCol=cluster("OtherCluster").database("OtherDb").MyCalc(Col1, Col2, Col3) | take 10

La requête suivante appelle une fonction MyCalc distante et fournit un paramètre tabulaire. Cet appel enfreint la règle n° 2. Il n’est donc pas valide.

cluster("OtherCluster").database("OtherDb").MyCalc(datatable(x:string, y:string)["x","y"] )

L’appel inter-événements suivant est valide.

cluster("OtherEventhouseURI").database("SomeDb").EventView("exception") | count

La requête suivante appelle une fonction EventCalcscalaire distante. Cet appel enfreint la règle n° 1. Il n’est donc pas valide.

Eventtable | extend CalCol=cluster("OtherEventhouseClusterURI").database("OtherDb").MyCalc(Col1, Col2, Col3) | take 10

La requête suivante appelle une fonction EventCalc distante et fournit un paramètre tabulaire. Cet appel enfreint la règle n° 2. Il n’est donc pas valide.

cluster("EventhouseClusterURI").database("OtherDb").MyCalc(datatable(x:string, y:string)["x","y"] )

cluster("OtherCluster").database("OtherDb").SomeTable("MyTable")

cluster("OtherEventhouseClusterURI").database("OtherDb").SomeTable("EventTable")

cluster("OtherCluster").database("OtherDb").GetDataPivot()

cluster("OtherEventhouseClusterURI").database("OtherDb").GetDataPivot()

• Jointure entre clusters
• Autoriser les requêtes et les commandes interlocataires

• Jointure entre clusters