Abfragegrenzwerte

Gilt für: ✅Microsoft Fabric✅

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. 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 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 truncationmaxrecordsjede Eigenschaft den niedrigeren Wert verwendentruncationmaxsize, oder query_take_max_records mehrmals, verwendet der Dienst den niedrigeren Wert.

Grenzwert für den von Abfrageoperatoren verbrauchten Arbeitsspeicher

Die maximale Speicherauslastung pro Iteratorlimit kann so konfiguriert werden, dass die Menge des Arbeitsspeichers gesteuert wird, den jeder Abfrageoperator pro Knoten verbraucht. Einige Abfrageoperatoren, z join . B. und summarize, enthalten wichtige Daten im Arbeitsspeicher. Indem Sie die Standardeinstellung 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 ist 32212254720 (30 GB). Wenn Sie mehrere Male festlegen maxmemoryconsumptionperiterator , z. B. in Clientanforderungseigenschaften und bei Verwendung 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).

Diese Abfrage legt beispielsweise die maximale Speicherauslastung pro Iterator auf 15 GB fest:

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 oben genannte 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 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. 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 wie "hint.shufflekey" für beide summarize und joinzu bewährten Methoden für Kusto Query Language-Abfragen.

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 >* >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. Manchmal möchten Sie die CPU-Ressourcen einschränken, die für eine bestimmte Abfrage verwendet werden. 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 ist, werden 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 überschreitet, wird die Abfrage zur Verarbeitung als zu komplex betrachtet und schlägt mit einem Fehlercode fehl. 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 breite Schemaanalyse ausführt, insbesondere, dass der Standardgeschmack der Union das "äußere" Union-Schema zurückgibt (d. h., diese Ausgabe enthält alle Spalten der zugrunde liegenden Tabelle).

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)