Query tra cluster e cross-database

  • Articolo

Le query vengono eseguite con un database specifico designato come database nel contesto. Questo database funge da impostazione predefinita per il controllo delle autorizzazioni. Se un'entità viene fatto riferimento in una query senza specificare il cluster o il database, viene risolto in questo database.

Questo articolo illustra come eseguire query che coinvolgono entità che si trovano all'esterno del database di contesto corrente.

Prerequisiti

Identificare il cluster e il database nel contesto

La tabella seguente illustra come identificare il database nel contesto in base all'ambiente di query.

Ambiente Database nel contesto
Kusto Explorer Il database predefinito è quello selezionato nel pannello connessioni e il cluster corrente è il cluster contenente tale database.
Interfaccia utente Web di Azure Esplora dati Il database predefinito è quello selezionato nel riquadro di connessione e il cluster corrente è il cluster contenente tale database.
Librerie client Il database e il Data Source cluster predefiniti vengono specificati dalle proprietà e Initial Catalog delle stringhe di connessione Kusto.

Eseguire query tra cluster o tra database

Per accedere alle entità esterne al database nel contesto, usare le funzioni cluster() e database() per qualificare il nome dell'entità.

Per una tabella in un database diverso all'interno dello stesso cluster:

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

Per una tabella in un cluster remoto:

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

Nota

Per eseguire una query, è necessario disporre dell'autorizzazione visualizzatore per il database predefinito e per ogni altro database a cui si fa riferimento nella query. Per altre informazioni, vedere Controllo degli accessi in base al ruolo kusto.

Suggerimento

Il numero di record restituiti da una query è limitato per impostazione predefinita, anche se non è presente alcun uso specifico dell'operatore take . Per aumentare questo limite, usare l'opzione di richiesta client notruncation . Per altre informazioni, vedere Limiti di query.

Nomi qualificati e operatore di unione

Quando un nome qualificato viene visualizzato come operando dell'operatore union, i caratteri jolly possono essere usati per specificare più tabelle e più database. I caratteri jolly non sono consentiti nei nomi del cluster.

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

Nota

Il nome del database predefinito è anche una corrispondenza potenziale, quindi database("*") specifica tutte le tabelle di tutti i database, tra cui l'impostazione predefinita.

Nomi qualificati e limitare le istruzioni di accesso

I nomi o i modelli qualificati possono essere inclusi anche nell'istruzione limita l'accesso . I caratteri jolly nei nomi del cluster non sono consentiti.

La query seguente limita l'accesso alle query alle entità seguenti:

  • Qualsiasi nome di entità a partire da my... nel database predefinito.
  • Qualsiasi tabella in tutti i database denominati MyOther... del cluster corrente.
  • Qualsiasi tabella in tutti i database denominati my2... nel cluster OtherCluster.kusto.windows.net.
restrict access to (my*, database("MyOther*").*, cluster("OtherCluster").database("my2*").*);

Gestire le modifiche dello schema delle entità remote

Per elaborare una query tra cluster, il cluster che esegue l'interpretazione iniziale della query deve avere lo schema delle entità a cui fa riferimento nei cluster remoti. Per ottenere queste informazioni, viene inviato un comando per recuperare gli schemi, che vengono quindi archiviati in una cache.

In caso di modifica dello schema nel cluster remoto, uno schema memorizzato nella cache potrebbe diventare obsoleto. Ciò può causare effetti indesiderati, inclusi gli scenari in cui le colonne nuove o eliminate causano un Partial query failureoggetto . Per risolvere tali problemi, aggiornare manualmente lo schema con il comando . clear cache remote-schema .

Funzioni e viste

Funzioni e viste (persistenti e create inline) possono fare riferimento a tabelle tra limiti di database e cluster. Il codice seguente è valido.

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

Le funzioni e le viste persistenti possono essere accessibili da un altro database nello stesso cluster.

Ad esempio, si supponga di creare la funzione tabulare seguente (visualizzazione) in un database OtherDb:

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

Creare quindi la funzione scalare seguente in un database OtherDb:

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

Nel database predefinito è possibile fare riferimento a queste entità come indicato di seguito:

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

Limitazioni delle chiamate di funzione tra cluster

Le funzioni o le visualizzazioni tabulari possono essere a cui si fa riferimento tra cluster. Si applicano le limitazioni seguenti:

  • Le funzioni remote devono restituire lo schema tabulare. Le funzioni scalari possono essere accessibili solo nello stesso cluster.
  • Le funzioni remote possono accettare solo argomenti scalari. Le funzioni che ottengono uno o più argomenti di tabella possono essere accessibili solo nello stesso cluster.
  • Lo schema dei risultati delle funzioni remote deve essere fisso (noto in anticipo senza eseguire parti della query). Ciò impedisce l'uso di costrutti di query, ad esempio il pivot plug-in. Si noti che alcuni plug-in, ad esempio il bag_unpack plug-in, supportano un modo per indicare lo schema dei risultati in modo statico e in questo formato può essere usato nelle chiamate di funzione tra cluster.
  • Per motivi di prestazioni, lo schema delle entità remote viene memorizzato nella cache dal cluster chiamante dopo la chiamata iniziale. Pertanto, le modifiche apportate all'entità remota possono causare una mancata corrispondenza con le informazioni sullo schema memorizzate nella cache, causando potenzialmente errori di query. Per altre informazioni, vedere Query tra cluster e modifiche dello schema.

Esempio

La chiamata cross-cluster seguente è valida.

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

La query seguente chiama una funzione MyCalcscalare remota. Questa chiamata viola la regola #1, quindi non è valida.

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

La query seguente chiama la funzione MyCalc remota e fornisce un parametro tabulare. Questa chiamata viola la regola #2, quindi non è valida.

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

La query seguente chiama la funzione SomeTable remota con un output dello schema variabile basato sul parametro tablename. Questa chiamata viola la regola #3, quindi non è valida.

Funzione tabulare in OtherDb.

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

Nel database predefinito.

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

La query seguente chiama la funzione GetDataPivot remota con output dello schema variabile in base ai dati (pivot() plug-in ha output dinamico. Questa chiamata viola la regola #3, quindi non è valida.

Funzione tabulare in OtherDb.

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

Funzione tabulare nel database predefinito.

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

Contenuti correlati