Abfragegrenzwerte

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. Dabei besteht das inhärente Risiko, dass Abfragen die Dienstressourcen grenzenlos 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

Anforderungskoncurrency ist ein Grenzwert, der mehreren Gleichzeitig ausgeführten Anforderungen auferlegt wird.

• 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.
• Der Standardwert kann geändert werden, indem Sie die Richtlinie für die Anforderungsratenbegrenzung der Arbeitsauslastungsgruppe default konfigurieren.
  • Die tatsächliche Anzahl der Anforderungen, die gleichzeitig auf einer Datenbank ausgeführt werden können, hängt von verschiedenen Faktoren ab. Die wichtigsten Faktoren sind Datenbank-SKU, verfügbare Ressourcen und Verwendungsmuster der Datenbank. Die Richtlinie kann auf Grundlage von Auslastungstests konfiguriert werden, die mit produktionsähnlichen Verwendungsmustern ausgeführt werden.

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

Ergebniskürzung ist ein Grenzwert, der standardmäßig für das von der Abfrage zurückgegebene Resultset festgelegt wird. 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. Das Überschreiten der Gesamtdatengröße generiert eine Ausnahme mit der folgenden Meldung:

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 folgender Ausnahme fehl:

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).'

Es gibt verschiedene Strategien für den Umgang mit diesem Fehler.

• 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. Die Strategie ist in Szenarien nützlich, in denen die Ausgabe der Abfrage an ein anderes Verarbeitungssystem weitergeleitet wird, das dann andere Aggregationen durchfü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 zu unterdrücken, indem Sie die unten aufgeführten set-Anweisungen oder Flags in Eigenschaften von Clientanforderungen verwenden.

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

• Verwenden des summarize-Operators zum Gruppieren und Aggregieren ähnlicher Datensätze in der Abfrageausgabe. 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

Es ist auch möglich, eine präzisere Kontrolle über die Ergebniskürzung auszuüben, indem Sie den Wert von truncationmaxsize (maximale Datengröße in Bytes, standardmäßig 64 MB) und von truncationmaxrecords (maximale Anzahl von Datensätzen, Standardwert 500.000) festlegen. Mit der folgenden Abfrage wird z. B. festgelegt, dass die Ergebniskürzung bei 1.105 Datensätzen oder 1 MB erfolgt, 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 eine Reihe von 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 .

Unter Umständen finden Sie auch die C#-Beispielanwendung für die Streamingerfassung hilfreich.

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

Es wird auch standardmäßig auf alle Unterabfragen angewendet, die ein Eventhouse in einer ereignisübergreifenden Abfrage mit ähnlichen Effekten auf ein anderes Eventhouse ausgibt.

Festlegen der Eigenschaften für das Abschneiden mehrerer Ergebnisse

Bei der Verwendung von set-Anweisungen und/oder bei der Angabe von Flags in Clientanforderungseigenschaften gilt Folgendes:

• Wenn truncationmaxsize, truncationmaxrecords oder query_take_max_records zusätzlich zu notruncation festgelegt ist, wird notruncation ignoriert.
• Wenn truncationmaxsize, truncationmaxrecords und/oder query_take_max_records mehrmals festgelegt sind, gilt jeweils der niedrigere Wert für jede Eigenschaft.

Grenzwert für den von Abfrageoperatoren verbrauchten Arbeitsspeicher (E_RUNAWAY_QUERY)

Kusto beschränkt den Speicher, den jeder Abfrageoperator zum Schutz vor "Runaway"-Abfragen nutzen kann. Dieser Grenzwert kann von einigen Abfrageoperatoren erreicht werden, z join . B. und summarize, die mit erheblichen Daten im Arbeitsspeicher arbeiten. Standardmäßig beträgt der Grenzwert 5 GB (pro Knoten) und kann durch Festlegen der Anforderungsoption maxmemoryconsumptionperiteratorerhöht werden:

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

Wenn dieser Grenzwert erreicht ist, wird ein Teilweiser Abfragefehler mit einer Nachricht ausgegeben, die den Text E_RUNAWAY_QUERYenthält.

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

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

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

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

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

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

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

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

Wird maxmemoryconsumptionperiterator mehrmals festgelegt (beispielsweise in Clientanforderungseigenschaften und mithilfe einer set-Anweisung), gilt der niedrigere Wert.

Ein zusätzlicher Grenzwert, der einen E_RUNAWAY_QUERY Teilabfragefehler auslösen kann, ist ein Grenzwert für die maximale angesammelte Größe von Zeichenfolgen, die von einem einzelnen Operator gehalten werden. Dieser Grenzwert kann von der oben genannten Anforderungsoption nicht außer Kraft gesetzt werden:

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, sollte die Abfrage so geändert werden, dass sie die Shuffle-Abfragestrategie verwendet. (Dies wird wahrscheinlich auch die Leistung der Abfrage verbessern.)

In allen Fällen E_RUNAWAY_QUERYist eine zusätzliche 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. Die folgenden zwei Abfragen zeigen, wie die Stichprobenentnahme erfolgt. 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 | ...

Grenzwert für Arbeitsspeicher pro Knoten

Maximaler Arbeitsspeicher pro Abfrage und Knoten ist ein weiterer verwendeter Grenzwert zum Schutz vor „Endlosabfragen“. Dieser Grenzwert, der von der Anforderungsoption max_memory_consumption_per_query_per_node dargestellt wird, legt eine obere Grenze für die Menge an Arbeitsspeicher fest, die auf einem einzelnen Knoten für eine bestimmte Abfrage verwendet werden kann.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Wird max_memory_consumption_per_query_per_node mehrmals festgelegt (beispielsweise in Clientanforderungseigenschaften und mithilfe einer set-Anweisung), gilt der niedrigere Wert.

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 auf alle Anforderungen angewendet wird. Timeout für ausgeführte Anforderungen (Abfragen und Verwaltungsbefehle) wird an mehreren Punkten im Kusto erzwungen:

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

Das Timeout ist standardmäßig auf vier Minuten für Abfragen und 10 Minuten für Verwaltungsbefehle festgelegt. Dieser Wert kann bei Bedarf erhöht werden (maximal auf eine Stunde).

• 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. In .NET SDK erfolgt dies z. B. über eine Clientanforderungseigenschaft, 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

Mit Kusto können Sie Abfragen ausführen und alle verfügbaren CPU-Ressourcen verwenden, über die die Datenbank verfügt. Es versucht, ein faires Roundrobin zwischen Abfragen durchzuführen, wenn mehr als eine ausgeführt wird. Diese Methode liefert die beste Leistung für abfragedefinierte Funktionen. Zu anderen Zeitpunkten können Sie die CPU-Ressourcen, die für eine bestimmte Abfrage verwendet werden, begrenzen. Wenn Sie beispielsweise einen "Hintergrundauftrag" ausführen, tolerieren das System möglicherweise höhere Latenzen, 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 maximalen Wert (100) annehmen, jedoch für eine bestimmte Abfrage auf einen anderen Wert verringert werden können.

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

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

Wird query_fanout_nodes_percent oder query_fanout_threads_percent mehrmals festgelegt (beispielsweise in Clientanforderungseigenschaften und mithilfe einer set-Anweisung), 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 übersteigt, wird die Abfrage als zu komplex für die Verarbeitung betrachtet, und es tritt ein Fehler mit einem Fehlercode auf. Der Fehler zeigt an, dass die Struktur der relationalen Operatoren ihre Grenzwerte überschreitet.

Die folgenden Beispiele zeigen gängige Abfragemuster, die dazu führen können, dass die Abfrage diesen Grenzwert überschreitet und nicht erfolgreich ist:

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

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

Schreiben Sie in diesem Spezialfall die Abfrage mit dem in()-Operator neu.

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

• eine Abfrage mit einem Union-Operator, der zu breit ausgeführt wird, insbesondere, dass der Standardgeschmack der Union das "äußere" Union-Schema zurückgibt (d. h., dass die Ausgabe alle Spalten der zugrunde liegenden Tabelle enthält).

In diesem Fall empfiehlt es sich, die Abfrage zu überprüfen und die von der Abfrage verwendeten Spalten zu verringern.

Zugehöriger Inhalt

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