Frågegränser

Gäller för: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel

Kusto är en ad hoc-frågemotor som är värd för stora datamängder och försöker uppfylla frågor genom att lagra alla relevanta data i minnet. Det finns en inneboende risk att frågor monopoliserar tjänstresurserna utan gränser. Kusto tillhandahåller flera inbyggda skydd i form av standardfrågegränser. Om du överväger att ta bort dessa gränser måste du först avgöra om du faktiskt får något värde genom att göra det.

Gräns för samtidighet för begäran

Begärandekonkurrens är en gräns som tillämpas på flera begäranden som körs samtidigt.

• Standardvärdet för gränsen beror på den SKU som databasen körs på och beräknas som: Cores-Per-Node x 10.
  • För en databas som har konfigurerats på D14v2 SKU, där varje dator har 16 virtuella kärnor, är standardgränsen 16 cores x10 = 160.
• Standardvärdet kan ändras genom att konfigurera princip för hastighetsbegränsning för default arbetsbelastningsgrupp.
  • Det faktiska antalet begäranden som kan köras samtidigt på en databas beror på olika faktorer. De mest dominerande faktorerna är databas-SKU, databasens tillgängliga resurser och användningsmönster. Principen kan konfigureras baserat på belastningstester som utförs på produktionsliknande användningsmönster.

Gräns för resultatuppsättningsstorlek (resultattrunkering)

Resultat trunkering är en gräns som anges som standard för den resultatuppsättning som returneras av frågan. Kusto begränsar antalet poster som returneras till klienten till 500 000och den totala datastorleken för dessa poster till 64 MB. När någon av dessa gränser överskrids misslyckas frågan med ett "partiellt frågefel". Om den totala datastorleken överskrids genereras ett undantag med meddelandet:

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

Det går inte att överskrida antalet poster med ett undantag som säger:

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

Det finns flera strategier för att hantera det här felet.

• Minska resultatuppsättningens storlek genom att ändra frågan så att den endast returnerar intressanta data. Den här strategin är användbar när den inledande misslyckade frågan är för "bred". Frågan projicerar till exempel inte bort datakolumner som inte behövs.
• Minska resultatuppsättningens storlek genom att flytta bearbetningen efter frågan, till exempel aggregeringar, till själva frågan. Strategin är användbar i scenarier där frågans utdata matas till ett annat bearbetningssystem och som sedan utför andra aggregeringar.
• Växla från frågor till att använda dataexport när du vill exportera stora uppsättningar data från tjänsten.
• Instruera tjänsten att utelämna den här frågegränsen med hjälp av set -instruktioner som anges nedan eller flaggor i egenskaper för klientbegäran.

Metoder för att minska den resultatuppsättningsstorlek som skapas av frågan är:

• Använd sammanfatta operatorn grupp och aggregera över liknande poster i frågeutdata. Prova eventuellt vissa kolumner med hjälp av aggregeringsfunktionen take_any.
• Använd en ta operatorn för att exempel på frågeutdata.
• Använd funktionen delsträng för att trimma breda fritextkolumner.
• Använd projektoperator för att släppa valfri kolumn som inte är intressant från resultatuppsättningen.

Du kan inaktivera resultattrunkering med hjälp av alternativet notruncation begäran. Vi rekommenderar att någon form av begränsning fortfarande införs.

Till exempel:

set notruncation;
MyTable | take 1000000

Det går också att ha mer förfinad kontroll över resultattrunkering genom att ange värdet för truncationmaxsize (maximal datastorlek i byte, standardvärdet är 64 MB) och truncationmaxrecords (maximalt antal poster, standardvärdet är 500 000). Följande fråga anger till exempel resultattrunkering till antingen 1 105 poster eller 1 MB, beroende på vilket som överskrids.

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

Om du tar bort resultatbegränsningen innebär det att du tänker flytta massdata från Kusto.

Du kan ta bort resultatbegränsningen antingen i exportsyfte med hjälp av kommandot .export eller för senare aggregering. Om du väljer senare aggregering bör du överväga att aggregera med kusto.

Kusto tillhandahåller ett antal klientbibliotek som kan hantera "oändligt stora" resultat genom att strömma dem till anroparen. Använd ett av dessa bibliotek och konfigurera det till strömningsläge. Använd till exempel .NET Framework-klienten (Microsoft.Azure.Kusto.Data) och ange antingen anslutningssträngens strömmande egenskap till true, eller använd ExecuteQueryV2Async()-anrop som alltid strömmar resultat. Ett exempel på hur du använder ExecuteQueryV2Async()finns i programmet HelloKustoV2.

Du kanske också tycker att exempelprogrammet för C#-strömmande inmatning är användbart.

Resultattrunkering tillämpas som standard, inte bara på den resultatström som returneras till klienten.

Den tillämpas också som standard på alla underfrågor som en Händelsehus utfärdar till en annan Eventhouse i en fråga mellan Eventhouse, med liknande effekter.

Ange flera egenskaper för resultattrunkering

Följande gäller när du använder set-instruktioner och/eller när du anger flaggor i egenskaper för klientbegäran.

• Om notruncation har angetts och någon av truncationmaxsize, truncationmaxrecordseller query_take_max_records också har angetts , ignoreras notruncation.
• Om truncationmaxsizeanges truncationmaxrecords och/eller query_take_max_records flera gånger – det lägre värdet för varje egenskap gäller.

Gräns för minne som förbrukas av frågeoperatorer (E_RUNAWAY_QUERY)

Kusto begränsar det minne som varje frågeoperator kan använda för att skydda mot "skenande" frågor. Den här gränsen kan nås av vissa frågeoperatorer, till exempel join och summarize, som fungerar genom att lagra betydande data i minnet. Som standard är gränsen 5 GB (per nod) och kan ökas genom att ange alternativet för begäran maxmemoryconsumptionperiterator:

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

När den här gränsen nås genereras ett partiellt frågefel med ett meddelande som innehåller texten 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).

Om maxmemoryconsumptionperiterator anges flera gånger, till exempel i båda egenskaperna för klientbegäran och med hjälp av en set-instruktion, gäller det lägre värdet.

Det högsta värdet som stöds för det här alternativet för begäran är 32212254720 (30 GB).

En ytterligare gräns som kan utlösa ett E_RUNAWAY_QUERY partiella frågefel är en gräns för den maximala ackumulerade storleken på strängar som innehas av en enskild operator. Den här gränsen kan inte åsidosättas av begärandealternativet ovan:

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

När den här gränsen överskrids är förmodligen den relevanta frågeoperatorn en join, summarizeeller make-series. Om du vill kringgå gränsen bör du ändra frågan så att den använder shuffle-fråga strategi. (Detta kommer sannolikt också att förbättra frågans prestanda.)

I alla fall av E_RUNAWAY_QUERYär ett ytterligare alternativ (utöver att öka gränsen genom att ange begärandealternativet och ändra frågan så att den använder en shuffle-strategi) att växla till sampling. De två frågorna nedan visar hur du gör samplingen. Den första frågan är ett statistiskt urval med hjälp av en slumptalsgenerator. Den andra frågan är deterministisk sampling, som görs genom att hasha någon kolumn från datauppsättningen, vanligtvis ett visst ID.

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

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

Gräns för minne per nod

Maximalt minne per fråga per nod är en annan gräns som används för att skydda mot "skenande" frågor. Den här gränsen, som representeras av begärandealternativet max_memory_consumption_per_query_per_node, anger en övre gräns för mängden minne som kan användas på en enskild nod för en specifik fråga.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Om max_memory_consumption_per_query_per_node anges flera gånger, till exempel i båda egenskaperna för klientbegäran och med hjälp av en set-instruktion, gäller det lägre värdet.

Om frågan använder operatorerna summarize, joineller make-series kan du använda shuffle-frågan strategi för att minska minnesbelastningen på en enda dator.

Begränsa tidsgränsen för körning

Tidsgräns för server är en tidsgräns på tjänstsidan som tillämpas på alla begäranden. Tidsgränsen för att köra begäranden (frågor och hanteringskommandon) tillämpas på flera platser i Kusto:

• klientbibliotek (om det används)
• tjänstslutpunkt som godkänner begäran
• tjänstmotor som bearbetar begäran

Som standard är tidsgränsen inställd på fyra minuter för frågor och 10 minuter för hanteringskommandon. Det här värdet kan ökas om det behövs (begränsas till en timme).

• Olika klientverktyg stöder ändring av tidsgränsen som en del av deras globala inställningar eller inställningar per anslutning. I Kusto.Explorer kan du till exempel använda Tools>Options* >Connections>Query Server Timeout.
• Programmatiskt har SDK:er stöd för att ställa in tidsgränsen via egenskapen servertimeout. I .NET SDK görs detta till exempel via en egenskap för klientbegärangenom att ange ett värde av typen System.TimeSpan.

Anteckningar om tidsgränser

• På klientsidan tillämpas tidsgränsen från den begäran som skapas tills svaret börjar komma till klienten. Den tid det tar att läsa nyttolasten på klienten behandlas inte som en del av tidsgränsen. Det beror på hur snabbt anroparen hämtar data från strömmen.
• Även på klientsidan är det faktiska timeout-värdet som används något högre än det servertimeout-värde som användaren begärde. Den här skillnaden är att tillåta nätverksfördröjningar.
• Om du vill använda den högsta tillåtna tidsgränsen för begäranden automatiskt anger du egenskapen för klientbegäran norequesttimeout till true.

Gräns för cpu-resursanvändning för frågor

Med Kusto kan du köra frågor och använda alla tillgängliga CPU-resurser som databasen har. Den försöker utföra en rättvis resursallokering mellan frågor om mer än en körs. Den här metoden ger bästa möjliga prestanda för frågedefinierade funktioner. Vid andra tillfällen kanske du vill begränsa de CPU-resurser som används för en viss fråga. Om du kör ett "bakgrundsjobb" kan systemet till exempel tolerera högre svarstider för att ge samtidiga infogade frågor hög prioritet.

Kusto har stöd för att ange två begärandeegenskaper när du kör en fråga. Egenskaperna är query_fanout_threads_percent och query_fanout_nodes_percent. Båda egenskaperna är heltal som standard till det maximala värdet (100), men kan minskas för en specifik fråga till något annat värde.

Den första, query_fanout_threads_percent, styr fanout-faktorn för trådanvändning. När den här egenskapen har angetts till 100%tilldelas alla processorer på varje nod. Till exempel 16 processorer som distribuerats på Azure D14-noder. När den här egenskapen är inställd på 50%används hälften av processorerna och så vidare. Talen avrundas upp till en hel PROCESSOR, så det är säkert att ange egenskapsvärdet till 0.

Den andra, query_fanout_nodes_percent, styr hur många av frågenoderna som ska användas per distributionsåtgärd för underfrågor. Den fungerar på ett liknande sätt.

Om query_fanout_nodes_percent eller query_fanout_threads_percent anges flera gånger, till exempel i båda egenskaperna för klientbegäran och med hjälp av en set-instruktion, gäller det lägre värdet för varje egenskap.

Gräns för frågekomplexitet

Under frågekörningen omvandlas frågetexten till ett träd med relationsoperatorer som representerar frågan. Om träddjupet överskrider ett internt tröskelvärde anses frågan vara för komplex för bearbetning och misslyckas med en felkod. Felet indikerar att relationsoperatorträdet överskrider sina gränser.

I följande exempel visas vanliga frågemönster som kan leda till att frågan överskrider den här gränsen och misslyckas:

• en lång lista över binära operatorer som är sammanlänkade. Till exempel:

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

I det här specifika fallet skriver du om frågan med operatorn in().

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

• en fråga som har en union-operator som kör för bred schemaanalys, särskilt att standardversionen av union är att returnera "yttre" union schema (vilket innebär – att utdata kommer att innehålla alla kolumner i den underliggande tabellen).

Förslaget i det här fallet är att granska frågan och minska de kolumner som används av frågan.

Relaterat innehåll

• Bästa praxis för frågor