Delen via

Query's voor meerdere clusters en databases

  • Artikel

Query's worden uitgevoerd met een bepaalde database die is aangewezen als de database in context. Deze database fungeert als de standaardinstelling voor het controleren van machtigingen. Als er in een query naar een entiteit wordt verwezen zonder het cluster of de database op te geven, wordt deze omgezet op basis van deze database.

In dit artikel wordt uitgelegd hoe u query's uitvoert die betrekking hebben op entiteiten die zich buiten de huidige contextdatabase bevinden.

Vereisten

Het cluster en de database in context identificeren

In de volgende tabel wordt uitgelegd hoe u de database kunt identificeren in de context per queryomgeving.

Omgeving Database in context
Kusto Explorer De standaarddatabase is de database die is geselecteerd in het deelvenster Verbindingen en het huidige cluster is het cluster met die database.
Azure Data Explorer-webinterface De standaarddatabase is de database die is geselecteerd in het verbindingsvenster en het huidige cluster is het cluster met die database.
Clientbibliotheken De standaarddatabase en het standaardcluster worden opgegeven door de Data Source eigenschappen en Initial Catalog van de Kusto-verbindingsreeksen.

Query's voor meerdere clusters of databases uitvoeren

Als u in context toegang wilt krijgen tot entiteiten buiten de database, gebruikt u de functies cluster() en database() om de entiteitsnaam te kwalificeren.

Voor een tabel in een andere database binnen hetzelfde cluster:

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

Voor een tabel in een extern cluster:

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

Notitie

Als u een query wilt uitvoeren, moet u beschikken over viewermachtigingen voor de standaarddatabase en voor elke andere database waarnaar in de query wordt verwezen. Zie Op rollen gebaseerd toegangsbeheer van Kusto voor meer informatie.

Tip

Het aantal records dat door een query wordt geretourneerd, is standaard beperkt, zelfs als er geen specifiek gebruik van de take operator is. Als u deze limiet wilt opheffen, gebruikt u de notruncation optie clientaanvraag. Zie Querylimieten voor meer informatie.

Gekwalificeerde namen en de samenvoegoperator

Wanneer een gekwalificeerde naam wordt weergegeven als een operand van de samenvoegoperator, kunnen jokertekens worden gebruikt om meerdere tabellen en meerdere databases op te geven. Jokertekens zijn niet toegestaan in clusternamen.

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

Notitie

De naam van de standaarddatabase is ook een mogelijke overeenkomst, dus database("*") hiermee worden alle tabellen van alle databases opgegeven, inclusief de standaarddatabase.

Gekwalificeerde namen en toegangsinstructies

Gekwalificeerde namen of patronen kunnen ook worden opgenomen in de instructie Toegang beperken . Jokertekens in clusternamen zijn niet toegestaan.

Met de volgende query wordt de querytoegang beperkt tot de volgende entiteiten:

  • Elke entiteitsnaam die begint met mijn... in de standaarddatabase.
  • Een tabel in alle databases met de naam MyOther... van het huidige cluster.
  • Elke tabel in alle databases met de naam my2... in het cluster OtherCluster.kusto.windows.net.
restrict access to (my*, database("MyOther*").*, cluster("OtherCluster").database("my2*").*);

Schemawijzigingen van externe entiteiten verwerken

Als u een clusteroverschrijdende query wilt verwerken, moet het cluster dat de eerste query-interpretatie uitvoert, beschikken over het schema van de entiteiten waarnaar wordt verwezen op externe clusters. Om deze informatie te verkrijgen, wordt een opdracht verzonden om de schema's op te halen, die vervolgens worden opgeslagen in een cache.

In het geval van een schemawijziging in het externe cluster, kan een schema in de cache verouderd raken. Dit kan leiden tot ongewenste effecten, waaronder scenario's waarin nieuwe of verwijderde kolommen een Partial query failureveroorzaken. U kunt dergelijke problemen oplossen door het schema handmatig te vernieuwen met de opdracht .clear cache remote-schema .

Functies en weergaven

Functies en weergaven (permanent en inline gemaakt) kunnen verwijzen naar tabellen over database- en clustergrenzen heen. De volgende code is geldig.

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

Permanente functies en weergaven kunnen worden geopend vanuit een andere database in hetzelfde cluster.

Stel dat u de volgende tabellaire functie (weergave) maakt in een database OtherDb:

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

Vervolgens maakt u de volgende scalaire functie in een database OtherDb:

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

In de standaarddatabase kan als volgt naar deze entiteiten worden verwezen:

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

Beperkingen van functie-aanroepen tussen clusters

Naar functies of weergaven in tabelvorm kan worden verwezen tussen clusters. De volgende beperkingen zijn van toepassing:

  • Externe functies moeten een tabellair schema retourneren. Scalaire functies kunnen alleen worden geopend in hetzelfde cluster.
  • Externe functies kunnen alleen scalaire argumenten accepteren. Functies die een of meer tabelargumenten ophalen, kunnen alleen worden geopend in hetzelfde cluster.
  • Het resultaatschema van externe functies moet worden opgelost (van tevoren bekend zonder delen van de query uit te voeren). Dit voorkomt het gebruik van queryconstructies zoals de pivot invoegtoepassing. (Houd er rekening mee dat sommige invoegtoepassingen, zoals de bag_unpack invoegtoepassing, een manier ondersteunen om het resultaatschema statisch aan te geven, en in deze vorm kan het worden gebruikt in functieoproepen tussen clusters.)
  • Om prestatieredenen wordt het schema van externe entiteiten na de eerste aanroep in de cache opgeslagen door het aanroepende cluster. Daarom kunnen wijzigingen in de externe entiteit ertoe leiden dat de schemagegevens in de cache niet overeenkomen, wat kan leiden tot queryfouten. Zie Query's voor meerdere clusters en schemawijzigingen voor meer informatie.

Voorbeelden

De volgende clusteroverschrijdende aanroep is geldig.

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

Met de volgende query wordt een externe scalaire functie aangeroepen MyCalc. Deze aanroep is in strijd met regel 1, dus deze is ongeldig.

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

Met de volgende query wordt de externe functie MyCalc aangeroepen en wordt een tabellaire parameter weergegeven. Deze aanroep is in strijd met regel 2, dus deze is ongeldig.

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

Met de volgende query wordt een externe functie SomeTable aangeroepen die een variabele schema-uitvoer heeft op basis van de parameter tablename. Deze aanroep is in strijd met regel 3, dus deze is niet geldig.

Tabellaire functie in OtherDb.

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

In de standaarddatabase.

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

Met de volgende query wordt een externe functie GetDataPivot aangeroepen die een variabele schema-uitvoer heeft op basis van de gegevens (invoegtoepassing pivot() heeft dynamische uitvoer). Deze aanroep is in strijd met regel 3, dus deze is niet geldig.

Tabellaire functie in OtherDb.

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

Tabellaire functie in de standaarddatabase.

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

Gerelateerde inhoud