Cluster- und datenbankübergreifende Abfragen

  • Artikel

Abfragen werden mit einer bestimmten Datenbank ausgeführt, die als Datenbank im Kontext festgelegt ist. Diese Datenbank fungiert als Standard für die Berechtigungsüberprüfung. Wenn in einer Abfrage ohne Angabe des Clusters oder der Datenbank auf eine Entität verwiesen wird, wird sie für diese Datenbank aufgelöst.

In diesem Artikel wird erläutert, wie Abfragen ausgeführt werden, die Entitäten betreffen, die sich außerhalb der aktuellen Kontextdatenbank befinden.

Voraussetzungen

Identifizieren des Clusters und der Datenbank im Kontext

In der folgenden Tabelle wird erläutert, wie Sie die Datenbank im Kontext nach Abfrageumgebung identifizieren.

Environment Datenbank im Kontext
Kusto-Explorer Die Standarddatenbank ist die im Bereich Verbindungen ausgewählte Datenbank, und der aktuelle Cluster ist der Cluster, der diese Datenbank enthält.
Webbenutzeroberfläche von Azure Data Explorer Die Standarddatenbank ist die im Verbindungsbereich ausgewählte Datenbank, und der aktuelle Cluster ist der Cluster, der diese Datenbank enthält.
Clientbibliotheken Die Standarddatenbank und der Cluster werden durch die Data Source Eigenschaften und Initial Catalog der Kusto-Verbindungszeichenfolgen angegeben.

Durchführen cluster- oder datenbankübergreifender Abfragen

Um im Kontext auf Entitäten außerhalb der Datenbank zuzugreifen, verwenden Sie die Funktionen cluster() und database(), um den Entitätsnamen zu qualifizieren.

Für eine Tabelle in einer anderen Datenbank innerhalb desselben Clusters:

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

Für eine Tabelle in einem Remotecluster:

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

Hinweis

Zum Ausführen einer Abfrage müssen Sie über die Viewerberechtigung für die Standarddatenbank und für jede andere Datenbank verfügen, auf die in der Abfrage verwiesen wird. Weitere Informationen finden Sie unter Rollenbasierte Zugriffssteuerung in Kusto.

Tipp

Die Anzahl der von einer Abfrage zurückgegebenen Datensätze ist standardmäßig begrenzt, auch wenn der take Operator nicht speziell verwendet wird. Um diese Begrenzung aufzuheben, verwenden Sie die Clientanforderungsoption notruncation . Weitere Informationen finden Sie unter Abfragegrenzwerte.

Qualifizierte Namen und der Union-Operator

Wenn ein qualifizierter Name als Operand des Union-Operator angezeigt wird, können Platzhalter verwendet werden, um mehrere Tabellen und mehrere Datenbanken anzugeben. In Clusternamen sind Dies ist nicht zulässig.

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

Hinweis

Der Name der Standarddatenbank ist auch eine potenzielle Übereinstimmung, sodass database("*") alle Tabellen aller Datenbanken einschließlich der Standarddatenbank angegeben werden.

Qualifizierte Namen und Einschränken von Zugriffsanweisungen

Qualifizierte Namen oder Muster können auch in die Einschränkung des Zugriffs eingeschlossen werden. Wildcards in Clusternamen sind nicht zulässig.

Die folgende Abfrage schränkt den Abfragezugriff auf die folgenden Entitäten ein:

  • Ein beliebiger Entitätsname, der mit my... in der Standarddatenbank beginnt.
  • Jede Tabelle in allen Datenbanken mit dem Namen MyOther... des aktuellen Clusters.
  • Jede Tabelle in allen Datenbanken mit dem Namen my2... im Cluster OtherCluster.kusto.windows.net.
restrict access to (my*, database("MyOther*").*, cluster("OtherCluster").database("my2*").*);

Behandeln von Schemaänderungen von Remoteentitäten

Zum Verarbeiten einer clusterübergreifenden Abfrage muss für den Cluster, der die anfängliche Abfrageinterpretation ausführt, das Schema der Entitäten in Remoteclustern referenziert werden. Um diese Informationen abzurufen, wird ein Befehl gesendet, um die Schemas abzurufen, die dann in einem Cache gespeichert werden.

Im Fall einer Schemaänderung im Remotecluster kann ein zwischengespeichertes Schema veraltet sein. Dies kann zu unerwünschten Auswirkungen führen, einschließlich Szenarien, in denen neue oder gelöschte Spalten einen Partial query failureverursachen. Um solche Probleme zu beheben, aktualisieren Sie das Schema manuell mit dem Befehl ".clear cache remote-schema ".

Funktionen und Sichten

Funktionen und Ansichten (persistent und inline erstellt) können über Datenbank- und Clustergrenzen hinweg auf Tabellen verweisen. Der folgende Code ist gültig.

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

Auf persistente Funktionen und Ansichten kann von einer anderen Datenbank im selben Cluster zugegriffen werden.

Angenommen, Sie erstellen die folgende tabellarische Funktion (Ansicht) in einer Datenbank OtherDb:

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

Anschließend erstellen Sie die folgende skalare Funktion in einer Datenbank OtherDb:

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

In der Standarddatenbank kann wie folgt auf diese Entitäten verwiesen werden:

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

Einschränkungen clusterübergreifender Funktionsaufrufe

Tabellenfunktionen oder Ansichten können clusterübergreifend referenziert werden. Es gelten die folgenden Einschränkungen:

  • Remotefunktionen müssen ein tabellarisches Schema zurückgeben. Auf skalare Funktionen kann nur im gleichen Cluster zugegriffen werden.
  • Remotefunktionen können nur skalare Argumente akzeptieren. Auf Funktionen, die mindestens ein Tabellenargument erhalten, kann nur im selben Cluster zugegriffen werden.
  • Das Ergebnisschema von Remotefunktionen muss korrigiert werden (im Voraus bekannt, ohne Teile der Abfrage auszuführen). Dies schließt die Verwendung von Abfragekonstrukten wie dem pivot Plug-In aus. (Beachten Sie, dass einige Plug-Ins, z. B. das bag_unpack Plug-In, eine Möglichkeit unterstützen, das Ergebnisschema statisch anzugeben, und in dieser Form in clusterübergreifenden Funktionsaufrufen verwendet werden kann .)
  • Aus Leistungsgründen wird das Schema der Remoteentitäten nach dem ersten Aufruf vom aufrufenden Cluster zwischengespeichert. Daher können Änderungen an der Remoteentität zu einem Konflikt mit den zwischengespeicherten Schemainformationen führen, was zu Abfragefehlern führen kann. Weitere Informationen finden Sie unter Clusterübergreifende Abfragen und Schemaänderungen.

Beispiele

Der folgende clusterübergreifende Aufruf ist gültig.

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

Die folgende Abfrage ruft eine skalare Remotefunktion MyCalcauf. Dieser Aufruf verstößt gegen Regel #1, daher ist er ungültig.

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

Die folgende Abfrage ruft die Remotefunktion MyCalc auf und stellt einen tabellarischen Parameter bereit. Dieser Aufruf verstößt gegen Regel #2, daher ist er ungültig.

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

Die folgende Abfrage ruft eine Remotefunktion SomeTable auf, die eine Variablenschemaausgabe basierend auf dem Parameter tablenameaufweist. Dieser Aufruf verstößt gegen Regel 3, daher ist er ungültig.

Tabellarische Funktion in OtherDb.

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

In der Standarddatenbank.

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

Die folgende Abfrage ruft eine Remotefunktion GetDataPivot auf, die eine Variablenschemaausgabe basierend auf dem Daten (pivot()-Plug-In mit dynamischer Ausgabe aufweist. Dieser Aufruf verstößt gegen Regel 3, daher ist er ungültig.

Tabellarische Funktion in OtherDb.

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

Tabellarische Funktion in der Standarddatenbank.

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

Verwandte Inhalte