Abfragegrenzwerte

Wechseln Von Diensten mithilfe der Dropdownliste "Version ". Weitere Informationen zur Navigation.
Gilt für: ✅ Microsoft Fabric ✅ Azure Data Explorer ✅ Azure Monitor ✅ Microsoft Sentinel

Kusto ist ein Ad-hoc-Abfragemodul, das große Datasets hostet und versucht, Abfragen zu erfüllen, indem alle relevanten Daten im Arbeitsspeicher gespeichert werden. Es besteht ein inhärentes Risiko, dass Abfragen die Dienstressourcen ohne Grenzen monopolisieren. Kusto bietet verschiedene integrierte Schutzmaßnahmen in Form von standardmäßigen Abfragegrenzwerten. Wenn Sie erwägen, diese Grenzwerte zu entfernen, ermitteln Sie zunächst, ob Sie dadurch tatsächlich einen Vorteil gewinnen.

Grenzwert für Anforderungsparallelität

Die Parallelität der Anforderung ist ein Grenzwert für mehrere Anforderungen, die gleichzeitig ausgeführt werden.

• Der Standardwert des Grenzwerts hängt von der SKU ab, auf der die Datenbank ausgeführt wird, und wird wie folgt berechnet: Cores-Per-Node x 10
  • Für eine Datenbank, die auf der D14v2-SKU eingerichtet ist, wobei jeder Computer 16 vCores hat, lautet 16 cores x10 = 160der Standardgrenzwert.
• Sie können den Standardwert ändern, indem Sie die Anforderungsratengrenzrichtlinie der default Workloadgruppe konfigurieren.
  • Verschiedene Faktoren wirken sich auf die tatsächliche Anzahl von Anforderungen aus, die gleichzeitig auf einer Datenbank ausgeführt werden können. Die wichtigsten Faktoren sind Datenbank-SKU, verfügbare Ressourcen und Verwendungsmuster der Datenbank. Konfigurieren Sie die Richtlinie basierend auf Auslastungstests, die auf produktionsähnlichen Verwendungsmustern ausgeführt werden.

Grenzwert für die Größe des Resultsets (Ergebniskürzung)

Ergebniskürzung ist ein Standardgrenzwert für das von der Abfrage zurückgegebene Resultset. Kusto begrenzt die Anzahl der an den Client zurückgegebenen Datensätze auf 500.000 und die Gesamtdatengröße für diese Datensätze auf 64 MB. Wenn einer dieser Grenzwerte überschritten wird, tritt bei der Abfrage ein „teilweiser Abfragefehler“ auf. Wenn Sie die Gesamtdatengröße überschreiten, wird eine Ausnahme mit der folgenden Meldung generiert:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal data size limit 67108864 (E_QUERY_RESULT_SET_TOO_LARGE).'

Das Überschreiten der Anzahl von Datensätzen schlägt mit einer Ausnahme fehl, die besagt:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal record count limit 500000 (E_QUERY_RESULT_SET_TOO_LARGE).'

Sie können mehrere Strategien verwenden, um diesen Fehler zu beheben.

• Verringern Sie die Resultsetgröße, indem Sie die Abfrage so ändern, dass nur interessante Daten zurückgegeben werden. Diese Strategie ist nützlich, wenn die anfängliche fehlerhafte Abfrage zu „breit“ gefasst ist. Beispielsweise projiziert die Abfrage Datenspalten nicht weg, die nicht benötigt werden.
• Verringern Sie die Größe des Resultsets, indem Sie die Nachverarbeitung der Abfrage, z. B. Aggregationen, in die Abfrage selbst verschieben. Diese Strategie ist in Szenarien hilfreich, in denen die Ausgabe der Abfrage in ein anderes Verarbeitungssystem gespeist wird und das System dann andere Aggregationen ausführt.
• Wechseln Sie von Abfragen zur Verwendung des Datenexports, wenn Sie große Datenmengen aus dem Dienst exportieren möchten.
• Weisen Sie den Dienst an, diesen Abfragegrenzwert mithilfe der anweisungen zu unterdrücken, die set im folgenden Abschnitt oder flags in Clientanforderungseigenschaften aufgeführt sind.

Zu den Methoden zum Verringern der von der Abfrage erzeugten Resultsetgröße gehören:

• Verwenden Sie den Zusammenfassungsoperator , um ähnliche Datensätze in der Abfrageausgabe zu gruppieren und zu aggregieren. Potenzielle Stichprobenentnahme einiger Spalten mithilfe der Aggregationsfunktion „take_any“.
• Verwenden eines take-Operators zur Entnahme von Stichproben aus der Abfrageausgabe.
• Verwenden der substring-Funktion zum Zuschneiden breiter Freitextspalten.
• Verwenden des project-Operators, um alle uninteressanten Spalten aus dem Resultset zu löschen.

Sie können die Ergebniskürzung deaktivieren, indem Sie die Anforderungsoption notruncation verwenden. Wir empfehlen, dass irgendeine Art von Grenzwert aktiviert bleibt.

Zum Beispiel:

set notruncation;
MyTable | take 1000000

Sie können auch eine bessere Kontrolle über die Ergebniskürzung haben, indem Sie den Wert ( truncationmaxsize maximale Datengröße in Bytes, Standardwerte auf 64 MB) und truncationmaxrecords (maximale Anzahl von Datensätzen, Standardwerte auf 500.000) festlegen. Die folgenden Abfragesets führen beispielsweise zum Abschneiden von Ergebnissen bei 1.105 Datensätzen oder 1 MB, je nachdem, welcher Wert überschritten wird.

set truncationmaxsize=1048576;
set truncationmaxrecords=1105;
MyTable | where User=="UserId1"

Wenn Sie den Grenzwert für die Ergebniskürzung entfernen, bedeutet dies, dass Sie beabsichtigen, Massendaten aus Kusto zu verschieben.

Sie können den Grenzwert für die Ergebniskürzung entweder für Exportzwecke mithilfe des .export-Befehls oder für die spätere Aggregation entfernen. Wenn Sie sich zur späteren Aggregation entschließen, sollten Sie erwägen mittels Kusto zu aggregieren.

Kusto bietet viele Clientbibliotheken, die "unendlich große" Ergebnisse verarbeiten können, indem sie an den Aufrufer gestreamt werden. Verwenden Sie eine dieser Bibliotheken, und konfigurieren Sie sie für den Streamingmodus. Verwenden Sie beispielsweise den .NET Framework-Client (Microsoft.Azure.Kusto.Data), und legen Sie entweder die Streaming-Eigenschaft der Verbindungszeichenfolge auf true fest, oder verwenden Sie den ExecuteQueryV2Async()-Aufruf, der Ergebnisse immer streamt. Ein Beispiel für die Verwendung von ExecuteQueryV2Async()finden Sie in der HelloKustoV2-Anwendung .

Möglicherweise finden Sie auch die C#-Streaming-Beispielanwendung hilfreich.

Ergebniskürzung wird standardmäßig angewendet, nicht nur auf den Ergebnisstream, der an den Client zurückgegeben wird.

Festlegen der Eigenschaften für das Abschneiden mehrerer Ergebnisse

Die folgenden Regeln gelten, wenn Sie Anweisungen verwenden set oder Flags in Clientanforderungseigenschaften angeben.

• Wenn Sie festlegen notruncation , aber auch truncationmaxsize, truncationmaxrecords, oder query_take_max_records, der Dienst ignoriert notruncation.
• Wenn Sie für truncationmaxsizejede Eigenschaft den truncationmaxrecords Wert verwendenquery_take_max_records, oder mehrmals, verwendet der Dienst den niedrigeren Wert.

Grenzwert für den von Abfrageoperatoren verbrauchten Arbeitsspeicher

Sie können die maximale Speicherauslastung pro Iteratorgrenze konfigurieren, um die Menge des Arbeitsspeichers zu steuern, den jeder Abfrageoperator pro Knoten verbraucht. Einige Abfrageoperatoren, z join . B. und summarize, enthalten wichtige Daten im Arbeitsspeicher. Indem Sie den Standardwert der Anforderungsoption maxmemoryconsumptionperiteratorerhöhen, können Sie Abfragen ausführen, die mehr Arbeitsspeicher pro Operator erfordern.

Der maximal unterstützte Wert für diese Anforderungsoption beträgt 32.212.254.720 (30 GB). Wenn Sie mehrere Male festlegen maxmemoryconsumptionperiterator , z. B. in Clientanforderungseigenschaften und mithilfe einer set Anweisung, wird der niedrigere Wert angewendet.

Wenn die Abfrage den konfigurierten Arbeitsspeicher pro Operatorgrenzwert erreicht, wird eine Teilweise-Abfragefehlermeldung angezeigt und enthält den Text E_RUNAWAY_QUERY.

Zum Beispiel:

The ClusterBy operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The HashJoin operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The Sort operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

In dieser Abfrage wird beispielsweise die maximale Speicherauslastung pro Iterator auf 15 GB festgelegt:

set maxmemoryconsumptionperiterator=16106127360;
MyTable | summarize count() by Use

Ein weiterer Grenzwert, der einen E_RUNAWAY_QUERY Teilabfragefehler auslösen kann, ist die maximale angesammelte Größe von Zeichenfolgen, die von einem einzelnen Operator gehalten werden. Die zuvor beschriebene Anforderungsoption kann diesen Grenzwert nicht außer Kraft setzen.

Runaway query (E_RUNAWAY_QUERY). Aggregation over string column exceeded the memory budget of 8GB during evaluation.

Wenn dieser Grenzwert überschritten wird, ist der relevante Abfrageoperator wahrscheinlich ein join, oder summarizemake-series.

Um den Grenzwert zu umgehen, ändern Sie die Abfrage so, dass sie die Shuffle-Abfragestrategie verwendet. Diese Änderung wird wahrscheinlich auch die Leistung der Abfrage verbessern.

In allen Fällen E_RUNAWAY_QUERYist eine weitere Option (über die Erhöhung des Grenzwerts hinaus durch Festlegen der Anforderungsoption und Ändern der Abfrage zur Verwendung einer Shuffle-Strategie) zum Sampling zu wechseln. Das Sampling reduziert die Von der Abfrage verarbeitete Datenmenge und verringert daher den Speicherdruck auf Abfrageoperatoren.

Diese beiden Abfragen zeigen, wie das Sampling ausgeführt wird. Die erste Abfrage ist eine statistische Stichprobenentnahme, bei der ein Zufallszahlengenerator verwendet wird. Die zweite Abfrage ist ein deterministisches Sampling, das durch Hashing einiger Spalten aus dem Dataset erfolgt, in der Regel einige ID.

T | where rand() < 0.1 | ...

T | where hash(UserId, 10) == 1 | ...

Weitere Informationen zur Verwendung von Mechanismen, z hint.shufflekey . B. für beide summarize Und join, finden Sie unter Bewährte Methoden für Kusto Query Language-Abfragen.

Grenzwert für Arbeitsspeicher pro Knoten

Der maximale Arbeitsspeicher pro Abfrage pro Knoten ist ein weiterer Grenzwert, der vor Runaway-Abfragen schützt. Die Anforderungsoption max_memory_consumption_per_query_per_node legt eine obere Grenze für die Speichermenge fest, die ein einzelner Knoten für eine bestimmte Abfrage verwenden kann.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Wenn Sie mehrere Male festlegen max_memory_consumption_per_query_per_node , z. B. in Clientanforderungseigenschaften und einer set Anweisung, wird der niedrigere Wert angewendet.

Verwendet die Abfrage den Operator summarize, join oder make-series, können Sie die Strategie Shuffleabfrage nutzen, um die Arbeitsspeicherauslastung auf einem einzelnen Computer zu reduzieren.

Grenzwert für Ausführungstimeout

Servertimeout ist ein dienstseitiges Timeout, das der Dienst für alle Anforderungen anwendet. Kusto erzwingt timeout für ausgeführte Anforderungen (Abfragen und Verwaltungsbefehle) an mehreren Punkten:

• Clientbibliothek (falls verwendet)
• Dienstendpunkt, der die Anforderung akzeptiert
• Dienst-Engine, die die Anforderung verarbeitet

Standardmäßig ist das Timeout für Abfragen auf vier Minuten und 10 Minuten für Verwaltungsbefehle festgelegt. Sie können diesen Wert bei Bedarf bis zu einer Stunde erhöhen.

• Verschiedene Clienttools unterstützen das Ändern des Timeouts als Teil ihrer globalen oder verbindungsspezifischen Einstellungen. Verwenden Sie z. B. in Kusto.Explorer tools>Options>Connections>Query Server Timeout.
• Programmgesteuert unterstützen SDKs das Festlegen des Timeouts über die servertimeout Eigenschaft. Legen Sie diese Eigenschaft beispielsweise im .NET SDK über eine Clientanforderungseigenschaft fest, indem Sie einen Wert vom Typ System.TimeSpanfestlegen.

Hinweise zu Timeouts

• Clientseitig wird das Timeout vom Zeitpunkt der Erstellung der Anforderung bis zum Zeitpunkt, an dem die Antwort beim Client einzugehen beginnt, angewendet. Die Zeit, die das Lesen der Nutzlast auf dem Client erfordert, wird nicht als Teil des Timeouts behandelt. Sie hängt davon ab, wie schnell der Aufrufer die Daten aus dem Stream abruft.
• Ebenfalls clientseitig ist der tatsächlich verwendete Timeoutwert geringfügig höher als der vom Benutzer angeforderte Servertimeoutwert. Diese Differenz dient zum Abfangen von Netzwerkwartezeiten.
• Um automatisch das maximal zulässige Anforderungstimeout zu verwenden, legen Sie die Clientanforderungseigenschaft norequesttimeout auf true fest.

Grenzwert für die Abfrage-CPU-Ressourcennutzung

Kusto führt Abfragen aus und verwendet alle verfügbaren CPU-Ressourcen, über die die Datenbank verfügt. Es versucht, ein faires Roundrobin zwischen Abfragen durchzuführen, wenn mehr als eine Abfrage ausgeführt wird. Diese Methode liefert die beste Leistung für abfragedefinierte Funktionen. Manchmal möchten Sie die CPU-Ressourcen einschränken, die für eine bestimmte Abfrage verwendet werden. Wenn Sie beispielsweise einen Hintergrundauftrag ausführen, kann das System höhere Latenzen tolerieren, um gleichzeitige Inlineabfragen mit hoher Priorität zu versehen.

Kusto unterstützt das Angeben von zwei Anforderungseigenschaften beim Ausführen einer Abfrage. Die Eigenschaften sind query_fanout_threads_percent und query_fanout_nodes_percent. Beide Eigenschaften sind ganze Zahlen, die standardmäßig den Maximalwert (100) aufweisen, aber Sie können sie für eine bestimmte Abfrage reduzieren.

Die erste Eigenschaft , query_fanout_threads_percent, steuert den Fanoutfaktor für die Threadverwendung. Wenn Sie diese Eigenschaft auf 100%festlegen, verwendet die Abfrage alle CPUs auf jedem Knoten. Beispielsweise werden 16 CPUs auf Azure D14-Knoten bereitgestellt. Wenn Sie diese Eigenschaft auf 50%festlegen, verwendet die Abfrage die Hälfte der CPUs usw. Die Zahlen werden auf eine ganze CPU aufgerundet, sodass der Eigenschaftswert problemlos auf 0 festgelegt werden kann.

Die zweite Eigenschaft , query_fanout_nodes_percent, steuert, wie viele der Abfrageknoten pro Teilabfrageverteilungsvorgang verwendet werden sollen. Sie funktioniert auf ähnliche Weise.

Wenn Sie z. B. sowohl clientanforderungseigenschaften als auch mithilfe einer set Anweisung festlegen oder query_fanout_threads_percent mehrmals festlegenquery_fanout_nodes_percent, gilt der niedrigere Wert für jede Eigenschaft.

Grenzwert für Abfragekomplexität

Während der Abfrageausführung wird der Abfragetext in eine Struktur relationaler Operatoren transformiert, die die Abfrage darstellen. Wenn die Strukturtiefe einen internen Schwellenwert überschreitet, ist die Abfrage zur Verarbeitung zu komplex und schlägt mit einem Fehlercode fehl. Der Fehler zeigt an, dass die Struktur der relationalen Operatoren ihre Grenzwerte überschreitet.

Die Komplexität der Abfrage wurde überschritten.

Die Abfrage ist zu komplex, damit das Modul kompiliert werden kann. Diese Komplexität tritt in der Regel auf, wenn die Erstellung von Abfrageplänen zu viele Ressourcen verbraucht. Häufige Ursachen sind:

• Große Gewerkschaften über viele Tabellen hinweg, z. B. die Verwendung union * in einer großen Datenbank.
• Tief geschachtelte Unterabfragen.
• Viele Ebenen von let Anweisungen, die aufeinander verweisen.

Die Größe oder Komplexität des Abfrageplans überschreitet festgelegte Grenzwerte.

Die Abfrage generiert einen Abfrageplan, der zu groß zum Verarbeiten ist. Häufige Ursachen sind:

• Die linke Seite einer Broadcast-Verknüpfung erzeugt zu viele Daten.
• Die zurückgegebenen toscalar() Ergebnisse sind zu groß.
• Die Ergebnisse innerhalb eines in() Ausdrucks sind zu groß. Beispielsweise gibt eine in (subquery) Unterabfrage zu viele Werte zurück.

Die folgenden Beispiele zeigen allgemeine Abfragemuster, die dazu führen können, dass die Abfrage diese Grenzwerte überschreitet und fehlschlägt:

• Eine lange Liste von binären Operatoren, die miteinander verkettet sind. Zum Beispiel:

T
| where Column == "value1" or
        Column == "value2" or
        .... or
        Column == "valueN"

Für diesen spezifischen Fall schreiben Sie die Abfrage mithilfe des in() Operators neu.

T
| where Column in ("value1", "value2".... "valueN")

• Eine Abfrage, die einen Union-Operator verwendet und zu breite Schemaanalyse ausführt. Dieses Problem tritt auf, da der Standardgeschmack der Union ein "äußeres" Union-Schema zurückgibt. Dieses Schema bedeutet, dass die Ausgabe alle Spalten der zugrunde liegenden Tabelle enthält.

Überprüfen Sie die Abfrage, und verringern Sie die Anzahl der Spalten, die die Abfrage verwendet.

Zugehöriger Inhalt

• Query best practices (Bewährte Methoden für Abfragen)