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

  • Article

Les requêtes s’exécutent avec une base de données particulière désignée comme base de données en contexte. Cette base de données agit comme la 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.

Cet article explique comment exécuter des requêtes qui impliquent des entités situées en dehors de la base de données de contexte actuelle.

Prérequis

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

Le tableau suivant explique comment identifier la base de données en contexte par environnement de requête.

Environnement Base de données en contexte
Kusto Explorer La base de données par défaut est celle sélectionnée dans le panneau connexions, et le cluster actuel est le cluster contenant cette base de données.
Interface utilisateur web Azure Data Explorer La base de données par défaut est celle sélectionnée dans le volet de connexion, et le cluster actuel est le cluster contenant cette base de données.
Fournisseurs de données pour la connexion à Azure Analysis Services La base de données et le cluster par défaut sont spécifiés par les Data Source propriétés et Initial Catalog des chaînes de connexion Kusto.

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

Pour accéder aux entités en dehors de la base de données en contexte, utilisez les fonctions cluster() et database() pour qualifier le nom d’entité.

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>

Notes

Pour exécuter une requête, vous devez disposer de l’autorisation de visionneuse sur la base de données par défaut et sur toutes les autres bases de données référencées dans la requête. Pour plus d’informations, consultez Contrôle d’accès en fonction du rôle Kusto.

Conseil

Le nombre d’enregistrements retournés à partir d’une requête est limité par défaut, même si l’opérateur take n’est pas utilisé de manière spécifique. Pour relever cette limite, utilisez l’option de requête client notruncation . Pour plus d'informations, consultez Limites de requête.

Noms qualifiés et opérateur d’union

Lorsqu’un nom qualifié apparaît en tant qu’opérande de l’opérateur d’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("*").*

Notes

Le nom de la base de données par défaut étant une correspondance potentielle, spécifie toutes les tables de toutes les bases de données, database("*") y compris la valeur par défaut.

Noms qualifiés et instructions de restriction d’accès

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.

La requête suivante restreint l’accès aux requêtes aux entités suivantes :

  • Tout nom d’entité commençant par my... dans la base de données par défaut.
  • Toute table dans toutes les bases de données nommées MyOther... du cluster actuel.
  • Toute table dans 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*").*);

Gérer les modifications de schéma des entités distantes

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

En cas de 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, y compris des scénarios où des 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 .clear cache .

Fonctions et affichages

Les fonctions et les vues (persistantes et créées inline) peuvent référencer des tables au-delà des limites de la base de données et du 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 les vues persistantes sont accessibles à partir d’une autre base de données dans le 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

Limitations des appels de fonction inter-cluster

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

  • Les fonctions distantes doivent retourner un schéma tabulaire. Les fonctions scalaires sont uniquement accessibles dans le même cluster.
  • Les fonctions distantes peuvent accepter uniquement les arguments scalaires. Les fonctions qui obtiennent un ou plusieurs arguments de table ne sont accessibles que dans le même cluster.
  • Le schéma des résultats des fonctions distantes doit être corrigé (connu à l’avance sans exécuter certaines parties de la requête). Cela empêche l’utilisation de constructions de requête telles que le pivot plug-in. (Notez que 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, ils peuvent être utilisés dans les appels de fonction entre clusters.)
  • Pour des raisons de performances, le schéma des entités distantes est mis en cache par le cluster appelant 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 mis 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.

Exemples

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 ne respecte pas la règle 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 ne respecte pas la règle 2. Il n’est donc pas valide.

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

La requête suivante appelle une fonction SomeTable distante qui a une sortie de schéma variable basée sur le paramètre tablename. Cet appel ne respecte pas la règle 3. Il n’est donc pas valide.

Fonction tabulaire dans OtherDb.

.create function SomeTable(tablename:string) { table(tablename)  }

Dans la base de données par défaut.

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

La requête suivante appelle une fonction GetDataPivot distante qui a une sortie de schéma variable basée sur les données (le plug-in pivot() a une sortie dynamique). Cet appel ne respecte pas la règle 3. Il n’est donc pas valide.

Fonction tabulaire dans OtherDb.

.create function GetDataPivot() { T | evaluate pivot(PivotColumn) }

Fonction tabulaire dans la base de données par défaut.

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

Contenu connexe