Limiti delle query

Si applica a: ✅Microsoft Fabric✅Azure Esplora dati✅ Azure Monitor✅Microsoft Sentinel

Kusto è un motore di query ad hoc che ospita set di dati di grandi dimensioni e tenta di soddisfare le query mantenendo tutti i dati pertinenti in memoria. Esiste un rischio intrinseco che le query monopolizzino le risorse del servizio senza limiti. Kusto offre diverse funzionalità di protezione predefinite, sotto forma di limiti di query predefiniti. Se si sta valutando la possibilità di rimuovere questi limiti, determinare innanzitutto se tale rimozione può portare effettivamente un vantaggio.

Limite alla concorrenza delle richieste

La concorrenza delle richieste è un limite imposto a più richieste in esecuzione contemporaneamente.

• Il valore predefinito del limite dipende dallo SKU su cui è in esecuzione il database e viene calcolato come : Cores-Per-Node x 10.
  • Ad esempio, per un database configurato nello SKU D14v2, in cui ogni computer ha 16 vCore, il limite predefinito è 16 cores x10 = 160.
• Il valore predefinito può essere modificato configurando i criteri di limite di frequenza delle richieste del default gruppo di carico di lavoro.
  • Il numero effettivo di richieste che possono essere eseguite simultaneamente in un database dipende da vari fattori. I fattori più dominanti sono lo SKU del database, le risorse disponibili del database e i modelli di utilizzo. I criteri possono essere configurati in base ai test di carico eseguiti su modelli di utilizzo simili alla produzione.

Limite sulle dimensioni del set di risultati (troncamento dei risultati)

Il troncamento dei risultati è un limite impostato per impostazione predefinita sul set di risultati restituito dalla query. Kusto limita il numero di record restituiti al client a 500.000 e le dimensioni complessive dei dati per tali record a 64 MB. Se uno di questi limiti viene superato la query non riesce, restituendo un errore di query parziale. Il superamento delle dimensioni complessive dei dati genera un'eccezione con il messaggio seguente:

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

Il superamento del numero di record genera un'eccezione con il messaggio seguente:

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

Questo errore può essere gestito tramite diverse strategie.

• Ridurre le dimensioni del set di risultati modificando la query in modo che restituisca solo i dati a cui si è interessati. Questa strategia è utile quando la query iniziale che ha generato un errore è troppo ampia. Ad esempio, la query non esclude le colonne di dati non necessarie.
• Ridurre le dimensioni del set di risultati spostando l'elaborazione post-query, come le aggregazioni, nella query stessa. Questa strategia è utile negli scenari in cui l'output della query viene immesso in un altro sistema di elaborazione, che quindi esegue altre aggregazioni.
• Passare dall'uso delle query all'uso dell'esportazione dati quando si vogliono esportare set di dati di grandi dimensioni dal servizio.
• Indicare al servizio di rimuovere questo limite delle query usando le istruzioni set elencate di seguito o i flag nelle proprietà di richiesta client.

I metodi per ridurre le dimensioni del set di risultati prodotto dalla query includono:

• Usare il gruppo di operatori summarize ed eseguire l'aggregazione su record simili nell'output della query. Potenzialmente esempi di alcune colonne usando la funzione di aggregazione take_any.
• Usare un operatore take per campionare l'output della query.
• Usare la funzione substring per tagliare le colonne di testo libero estese.
• Usare l'operatore project per eliminare qualsiasi colonna non di interesse dal set di risultati.

È possibile disabilitare il troncamento dei risultati usando l'opzione di richiesta notruncation. È comunque consigliabile mantenere una qualche forma di limitazione.

Ad esempio:

set notruncation;
MyTable | take 1000000

È anche possibile ottenere un controllo più preciso sul troncamento dei risultati impostando il valore di truncationmaxsize (dimensioni massime dei dati in byte, il valore predefinito è 64 MB) e truncationmaxrecords (numero massimo di record, il valore predefinito è 500.000). Ad esempio, la query seguente imposta il troncamento dei risultati in corrispondenza di 1.105 record o 1 MB, a seconda del limite che viene superato per primo.

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

La rimozione del limite di troncamento dei risultati indica l'intenzione di spostare i dati in blocco all'esterno di Kusto.

È possibile rimuovere il limite di troncamento dei risultati ai fini dell'esportazione usando il comando .export o per eseguire un'aggregazione successivamente. Nel caso dell'aggregazione, è consigliabile eseguirla con Kusto.

Kusto fornisce alcune librerie client in grado di gestire risultati "infinitamente grandi" trasmettendoli al chiamante. Usare una di queste librerie e configurarla in modalità di trasmissione. Ad esempio, usare il client .NET Framework (Microsoft.Azure.Kusto.Data) e impostare la proprietà di trasmissione della stringa di connessione su true oppure usare la chiamata a ExecuteQueryV2Async() che trasmette sempre i risultati. Per un esempio di come usare ExecuteQueryV2Async(), vedere l'applicazione HelloKustoV2 .

Anche l'applicazione di esempio di inserimento in streaming C# può risultare utile.

Il troncamento dei risultati viene applicato per impostazione predefinita, non solo al flusso di risultati restituito al client.

Viene applicato anche per impostazione predefinita a qualsiasi sottoquery che una Eventhouse emette a un'altra Eventhouse in una query cross-Eventhouse, con effetti simili.

Impostazione di più proprietà di troncamento dei risultati

Quando si usano istruzioni set e/o si specificano flag nelle proprietà delle richieste client si verifica quanto segue.

• Se la proprietà notruncation è impostata e anche truncationmaxsize, truncationmaxrecords o query_take_max_records è impostata, notruncation viene ignorata.
• Se la proprietà truncationmaxsize, truncationmaxrecords e/o query_take_max_records viene impostata più volte, viene applicato il valore minore per ogni proprietà.

Limite di memoria utilizzato dagli operatori di query (E_RUNAWAY_QUERY)

Kusto limita la memoria che ogni operatore di query può utilizzare per proteggersi dalle query "in esecuzione". Questo limite potrebbe essere raggiunto da alcuni operatori di query, ad esempio join e summarize, che operano mantenendo dati significativi in memoria. Per impostazione predefinita, il limite è 5 GB (per nodo) e può essere aumentato impostando l'opzione maxmemoryconsumptionperiteratordi richiesta :

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

Quando viene raggiunto questo limite, viene generato un errore di query parziale con un messaggio che include il testo E_RUNAWAY_QUERY.

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

Se l'opzione maxmemoryconsumptionperiterator viene impostata più volte, ad esempio in entrambe le proprietà della richiesta client, e si usa un'istruzione set, verrà applicato il valore minore.

Un limite aggiuntivo che potrebbe attivare un E_RUNAWAY_QUERY errore di query parziale è un limite per le dimensioni massime accumulate delle stringhe mantenute da un singolo operatore. Questo limite non può essere sostituito dall'opzione di richiesta precedente:

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

Quando questo limite viene superato, probabilmente l'operatore di query pertinente è , joinsummarizeo make-series. Per aggirare il limite, è necessario modificare la query per usare la strategia di query casuale. È anche probabile che ciò possa migliorare le prestazioni della query.

In tutti i casi di E_RUNAWAY_QUERY, un'opzione aggiuntiva (oltre ad aumentare il limite impostando l'opzione di richiesta e modificando la query in modo da usare una strategia casuale) consiste nel passare al campionamento. Le due query seguenti mostrano come eseguire il campionamento. La prima query è un campionamento statistico, usando un generatore di numeri casuali. La seconda query è il campionamento deterministico, eseguito eseguendo l'hashing di alcune colonne dal set di dati, in genere un ID.

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

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

Limite sulla memoria per nodo

La memoria massima per query per nodo è un altro limite usato come protezione dalle query con eccessivo tempo di esecuzione. Questo limite, rappresentato dall'opzione di richiesta max_memory_consumption_per_query_per_node, imposta un limite superiore sulla quantità di memoria che può essere usata in un singolo nodo per una query specifica.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Se l'opzione max_memory_consumption_per_query_per_node viene impostata più volte, ad esempio in entrambe le proprietà della richiesta client, e si usa un'istruzione set, verrà applicato il valore minore.

Se la query usa summarizeoperatori , joino make-series , è possibile usare la strategia di query casuale per ridurre la pressione della memoria in un singolo computer.

Limite al timeout esecuzione

Il timeout del server è un timeout sul lato servizio applicato a tutte le richieste. Il timeout sulle richieste in esecuzione (query e comandi di gestione) viene applicato in più punti in Kusto:

• libreria client (se usata)
• endpoint di servizio che accetta la richiesta
• motore del servizio che elabora la richiesta

Per impostazione predefinita, il timeout è impostato su quattro minuti per le query e 10 minuti per i comandi di gestione. Questo valore può essere aumentato se necessario (fino al limite massimo di un'ora).

• Vari strumenti client supportano la modifica del timeout come parte delle impostazioni globali o per connessione. Ad esempio, in Kusto.Explorer usare Strumenti>Opzioni* >Connessioni>timeout del server di query.
• A livello di codice, gli SDK supportano l'impostazione del timeout tramite la servertimeout proprietà . Ad esempio, in .NET SDK questa operazione viene eseguita tramite una proprietà della richiesta client impostando un valore di tipo System.TimeSpan.

Note sui timeout

• Sul lato client, il timeout viene applicato dalla richiesta creata fino al momento in cui la risposta inizia ad arrivare al client. Il tempo impiegato per leggere il payload nel client non viene considerato come parte del timeout. Dipende dalla rapidità con cui il chiamante estrae i dati dal flusso.
• Sul lato client, inoltre, il valore di timeout effettivo usato è leggermente superiore rispetto al valore di timeout del server richiesto dall'utente. Questa differenza ha lo scopo di consentire le latenze di rete.
• Per usare automaticamente il valore massimo consentito per il timeout delle richieste, impostare la proprietà della richiesta client norequesttimeout su true.

Limite sull'utilizzo delle risorse CPU delle query

Kusto consente di eseguire query e di usare tutte le risorse della CPU disponibili nel database. Se sono in esecuzione più query, cerca di eseguire un round robin equo tra di esse. Questo metodo restituisce le prestazioni migliori per le funzioni definite da query. In alcune situazioni può essere opportuno limitare le risorse CPU usate per una determinata query. Se si esegue un "processo in background", ad esempio, il sistema potrebbe tollerare latenze più elevate per assegnare priorità elevata alle query inline simultanee.

Kusto supporta la specifica di due proprietà della richiesta durante l'esecuzione di una query. Le proprietà sono query_fanout_threads_percent e query_fanout_nodes_percent. Entrambe le proprietà sono numeri interi che per impostazione predefinita corrispondono al valore massimo (100), ma questo valore può essere ridotto per una query specifica.

La prima proprietà, query_fanout_threads_percent, controlla il fattore di fan-out per l'uso dei thread. Quando questa proprietà è impostata al 100%, tutte le CPU verranno assegnate in ogni nodo. Ad esempio, 16 CPU distribuite nei nodi di Azure D14. Se questa proprietà è impostata sul 50%, verrà usata la metà delle CPU e così via. I numeri vengono arrotondati per eccesso a un'intera CPU, quindi è possibile impostare il valore della proprietà su 0.

Il secondo, query_fanout_nodes_percent, controlla il numero di nodi di query da usare per ogni operazione di distribuzione della sottoquery. Funziona in modo simile.

Se l'opzione query_fanout_nodes_percent o query_fanout_threads_percent viene impostata più volte, ad esempio in entrambe le proprietà della richiesta client, e si usa un'istruzione set, verrà applicato il valore minore.

Limite sulla complessità delle query

Durante l'esecuzione della query, il testo viene trasformato in un albero di operatori relazionali che rappresenta la query. Se la profondità dell'albero supera una soglia interna, la query viene considerata troppo complessa per l'elaborazione e avrà esito negativo con un codice di errore. L'errore indica che l'albero degli operatori relazionali supera i limiti.

Gli esempi seguenti mostrano modelli di query comuni che possono causare il superamento di questo limite e l'esito negativo della query:

• elenco lungo di operatori binari concatenati. Ad esempio:

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

Per questo caso specifico, riscrivere la query usando l'operatore in().

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

• Una query con un operatore union che esegue un'analisi dello schema troppo ampia, in particolare che il sapore predefinito dell'unione consiste nel restituire lo schema di unione "esterno", ovvero l'output includerà tutte le colonne della tabella sottostante.

Il suggerimento in questo caso consiste nell'esaminare la query e ridurre le colonne usate dalla query.

Contenuto correlato

• Procedure consigliate per le query