Frågebegränsningar

  • Artikel

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 för 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äranden

Samtidiga begäranden är en gräns som ett kluster tillämpar på flera begäranden som körs samtidigt.

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

Mer information finns i Optimera för hög samtidighet med Azure Data Explorer.

Gräns för resultatuppsättningens storlek (resultattrunkering)

Resultattrunkering ä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 000 och 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 endast intressanta data returneras. 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 mängder 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 resultatuppsättningens storlek som skapas av frågan är:

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

Exempel:

set notruncation;
MyTable | take 1000000

Det går också att få mer förfinad kontroll över resultattrunkering genom att ange värdet truncationmaxsize för (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 att resultattrunkeringen ska ske på 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 resultattrunkeringsgränsen har du för avsikt att flytta massdata från Kusto.

Du kan ta bort resultattrunkeringsgränsen antingen i exportsyfte med hjälp .export av kommandot 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 något av dessa bibliotek och konfigurera det till strömningsläge. Du kan till exempel använda .NET Framework-klienten (Microsoft.Azure.Kusto.Data) och antingen ange strömningsegenskapen för anslutningssträng till true eller använda ExecuteQueryV2Async() -anropet som alltid strömmar resultat. Ett exempel på hur du använder ExecuteQueryV2Async()finns i HelloKustoV2-programmet .

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

Resultattrunkering tillämpas som standard, inte bara på resultatströmmen som returneras till klienten. Den tillämpas också som standard på underfrågor som ett kluster utfärdar till ett annat kluster i en fråga mellan kluster, med liknande effekter.

Ange egenskaper för flera 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ågot av truncationmaxsize, truncationmaxrecordseller query_take_max_records också har angetts - notruncation ignoreras.
  • Om truncationmaxsize, truncationmaxrecords och/eller query_take_max_records anges flera gånger – gäller det lägre värdet för varje egenskap.

Gräns för minne som används 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 klusternod) och kan ökas genom att ange alternativet maxmemoryconsumptionperiteratorför begäran:

set maxmemoryconsumptionperiterator=68719476736;
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.

En ytterligare gräns som kan utlösa ett partiellt E_RUNAWAY_QUERY 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 , joinsummarize, eller make-series. Om du vill kringgå gränsen bör du ändra frågan så att den använder shuffle-frågestrategin . (Detta kommer sannolikt också att förbättra frågans prestanda.)

I samtliga fall är E_RUNAWAY_QUERYett ytterligare alternativ (utöver att öka gränsen genom att ange begärandealternativet och ändra frågan för att använda en shuffle-strategi) att växla till sampling. De två frågorna nedan visar hur du utfö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 summarizeoperatorerna , joineller make-series kan du använda shuffle-frågestrategin för att minska minnesbelastningen på en enskild dator.

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

Tidsgränsen för servern ä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 punkter i Kusto:

  • klientbibliotek (om det används)
  • tjänstslutpunkt som accepterar 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 Verktygsalternativ>* >Timeout för anslutningsfrågans>server.
  • Programmässigt har SDK:er stöd för att ställa in tidsgränsen servertimeout via egenskapen . I .NET SDK görs detta till exempel via en klientförfrågningsegenskap genom att ange ett värde av typen System.TimeSpan.

Information om tidsgränser

  • På klientsidan tillämpas tidsgränsen från den begäran som skapas tills svaret börjar komma in till klienten. Den tid det tar att läsa nyttolasten tillbaka på klienten behandlas inte som en del av tidsgränsen. Det beror på hur snabbt anroparen hämtar data från dataströmmen.
  • På klientsidan är det faktiska timeout-värdet som används något högre än det servertimeout-värde som användaren begär. 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 norequesttimeout för klientbegäran till true.

Anteckning

Se Ange tidsgränsgränser för en stegvis guide om hur du anger tidsgränser i webbgränssnittet för Azure Data Explorer, Kusto.Explorer, Kusto.Cli, Power BI och när du använder ett SDK.

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

Med Kusto kan du köra frågor och använda lika mycket PROCESSOR-resurser som klustret. Den försöker utföra en rättvis resursallokering mellan frågor om fler ä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 till exempel kör ett "bakgrundsjobb" kan systemet 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 standardvä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 anges till 100 %, tilldelar klustret alla processorer på varje nod. Till exempel 16 processorer i ett kluster 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 CPU, så det är säkert att ange egenskapsvärdet till 0.

Den andra , query_fanout_nodes_percent, styr hur många av frågenoderna i klustret 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.

Begränsa frågekomplexiteten

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 göra att frågan överskrider den här gränsen och misslyckas:

  • en lång lista över binära operatorer som är sammanlänkade. Exempel:
T 
| where Column == "value1" or 
        Column == "value2" or 
        .... or
        Column == "valueN"

Skriv om frågan med operatorn in() för det här specifika fallet.

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 standardsmaken för union är att returnera "yttre" unionschema (vilket innebär att utdata inkluderar 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