Querylimieten

Van toepassing op: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel-

Kusto is een ad-hocquery-engine die als host fungeert voor grote gegevenssets en probeert te voldoen aan query's door alle relevante gegevens in het geheugen te bewaren. Er is een inherent risico dat query's uitvoeren op de servicebronnen zonder grenzen. Kusto biedt verschillende ingebouwde beveiligingen in de vorm van standaardquerylimieten. Als u deze limieten overweegt te verwijderen, moet u eerst bepalen of u hiermee daadwerkelijk waarde krijgt.

Limiet voor gelijktijdigheid van aanvragen

Gelijktijdigheid van aanvragen is een limiet voor verschillende aanvragen die tegelijkertijd worden uitgevoerd.

• De standaardwaarde van de limiet is afhankelijk van de SKU waarop de database wordt uitgevoerd en wordt berekend als: Cores-Per-Node x 10.
  • Voor een database die is ingesteld op D14v2 SKU, waarbij elke machine 16 vCores heeft, is de standaardlimiet 16 cores x10 = 160.
• U kunt de standaardwaarde wijzigen door het beleid voor aanvraagsnelheidslimiet van de default workloadgroep te configureren.
  • Verschillende factoren zijn van invloed op het werkelijke aantal aanvragen dat gelijktijdig op een database kan worden uitgevoerd. De meest dominante factoren zijn database-SKU, beschikbare resources van de database en gebruikspatronen. Configureer het beleid op basis van belastingstests die worden uitgevoerd op productieachtige gebruikspatronen.

Limiet voor de grootte van de resultatenset (afkapping van resultaten)

Het afkappen van resultaten is een standaardlimiet voor de resultatenset die door de query wordt geretourneerd. Kusto beperkt het aantal records dat aan de client wordt geretourneerd tot 500.000en de totale gegevensgrootte voor deze records tot 64 MB. Wanneer een van deze limieten wordt overschreden, mislukt de query met een 'gedeeltelijke queryfout'. Als u de totale gegevensgrootte overschrijdt, wordt er een uitzondering gegenereerd met het volgende bericht:

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

Het overschrijden van het aantal records mislukt met een uitzondering met de volgende tekst:

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

U kunt verschillende strategieën gebruiken om deze fout op te lossen.

• Verklein de grootte van de resultatenset door de query te wijzigen zodat alleen interessante gegevens worden geretourneerd. Deze strategie is handig wanneer de eerste mislukte query te breed is. Met de query worden bijvoorbeeld gegevenskolommen die niet nodig zijn, niet geprojected.
• Verklein de grootte van de resultatenset door postqueryverwerking, zoals aggregaties, naar de query zelf te verplaatsen. Deze strategie is handig in scenario's waarin de uitvoer van de query wordt ingevoerd in een ander verwerkingssysteem en dat systeem vervolgens andere aggregaties uitvoert.
• Schakel over van query's naar het gebruik van gegevensexport wanneer u grote sets gegevens uit de service wilt exporteren.
• Instrueer de service om deze querylimiet te onderdrukken met behulp van de set instructies die worden vermeld in de volgende sectie of vlaggen in eigenschappen van clientaanvragen.

Methoden voor het verminderen van de grootte van de resultatenset die door de query wordt geproduceerd, zijn onder andere:

• Gebruik de operator Summarize om vergelijkbare records in de query-uitvoer te groeperen en samen te voegen. U kunt een aantal kolommen steekproefen met behulp van de take_any aggregatiefunctie.
• Gebruik een operator om de query-uitvoer te samplen.
• Gebruik de subtekenreeksfunctie om brede vrije-tekstkolommen te knippen.
• Gebruik de projectoperator om een onintervalerende kolom uit de resultatenset te verwijderen.

U kunt het afkappen van resultaten uitschakelen met behulp van de optie notruncation aanvraag. We raden u aan dat er nog een vorm van beperking is ingesteld.

Bijvoorbeeld:

set notruncation;
MyTable | take 1000000

U kunt ook meer verfijnde controle hebben over het afkappen van resultaten door de waarde in te stellen van truncationmaxsize (maximale gegevensgrootte in bytes, standaard ingesteld op 64 MB) en truncationmaxrecords (maximum aantal records, standaard ingesteld op 500.000). Met de volgende query wordt bijvoorbeeld het afkappen van resultaten ingesteld op 1105 records of 1 MB, afhankelijk van wat wordt overschreden.

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

Het verwijderen van de limiet voor het afkappen van resultaten betekent dat u bulkgegevens uit Kusto wilt verplaatsen.

U kunt de limiet voor het afkappen van resultaten verwijderen voor exportdoeleinden met behulp van de opdracht .export of voor latere aggregatie. Als u later aggregatie kiest, kunt u overwegen om te aggregeren met Behulp van Kusto.

Kusto biedt veel clientbibliotheken die oneindig grote resultaten kunnen verwerken door ze naar de beller te streamen. Gebruik een van deze bibliotheken en configureer deze naar de streamingmodus. Gebruik bijvoorbeeld de .NET Framework-client (Microsoft.Azure.Kusto.Data) en stel de streaming-eigenschap van de verbindingsreeks in op trueof gebruik de ExecuteQueryV2Async() aanroep die altijd resultaten streamt. Zie de toepassing HelloKustoV2 voor een voorbeeld van het gebruik van ExecuteQueryV2Async().

Mogelijk vindt u ook de voorbeeldtoepassing voor C#-streamingopname nuttig.

Afkapping van resultaten wordt standaard toegepast, niet alleen op de resultaatstroom die wordt geretourneerd naar de client.

Eigenschappen voor het afkappen van meerdere resultaten instellen

De volgende regels zijn van toepassing wanneer u instructies gebruikt set of vlaggen opgeeft in eigenschappen van clientaanvragen.

• Als u deze optie instelt notruncation maar ook truncationmaxsizeinstelt, truncationmaxrecordsof query_take_max_records, wordt de service genegeerd notruncation.
• Als u meerdere keren of truncationmaxrecordsquery_take_max_records meer dan één keer instelttruncationmaxsize, gebruikt de service de lagere waarde voor elke eigenschap.

Limiet voor geheugen dat wordt gebruikt door queryoperators

Het maximale geheugenverbruik per iteratorlimiet kan worden geconfigureerd om de hoeveelheid geheugen te bepalen die elke queryoperator per knooppunt verbruikt. Sommige queryoperators, zoals join en summarize, bevatten belangrijke gegevens in het geheugen. Door de standaardinstelling van de aanvraagoptie maxmemoryconsumptionperiteratorte verhogen, kunt u query's uitvoeren waarvoor meer geheugen per operator is vereist.

De maximaal ondersteunde waarde voor deze aanvraagoptie is 32212254720 (30 GB). Als u maxmemoryconsumptionperiterator meerdere keren instelt, bijvoorbeeld in eigenschappen van clientaanvragen en het gebruik van een set instructie, is de lagere waarde van toepassing.

Wanneer de query de geconfigureerde geheugenlimiet per operator bereikt, wordt er een gedeeltelijk foutbericht over queryfouten weergegeven en wordt de tekst E_RUNAWAY_QUERYopgenomen.

Bijvoorbeeld:

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

Met deze query wordt bijvoorbeeld het maximale geheugenverbruik per iterator ingesteld op 15 GB:

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

Een andere limiet die een E_RUNAWAY_QUERY gedeeltelijke queryfout kan veroorzaken, is de maximale samengevoegde grootte van tekenreeksen die door één operator worden bewaard. De bovenstaande aanvraagoptie kan deze limiet niet overschrijven.

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

Wanneer deze limiet wordt overschreden, is de relevante queryoperator waarschijnlijk een join, summarizeof make-series.

Als u de limiet wilt omzeilen, wijzigt u de query om de willekeurige querystrategie te gebruiken. Deze wijziging verbetert waarschijnlijk ook de prestaties van de query.

In alle gevallen van E_RUNAWAY_QUERYis een extra optie (behalve het verhogen van de limiet door de aanvraagoptie in te stellen en de query te wijzigen in een willekeurige strategie) over te schakelen naar steekproeven. Sampling vermindert de hoeveelheid gegevens die door de query worden verwerkt, en vermindert daarom de geheugendruk op queryoperators.

Deze twee query's laten zien hoe u de steekproeven kunt uitvoeren. De eerste query is een statistische steekproef met behulp van een generator voor willekeurige getallen. De tweede query is deterministische steekproeven, uitgevoerd door een hash van een kolom uit de gegevensset, meestal een bepaalde id.

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

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

Zie Best practices voor Kusto Query Language-query's voor meer informatie over het gebruik van mechanismen zoals hint.shufflekey voor beide summarize enjoin.

Limiet voor geheugen per knooppunt

Maximaal geheugen per query per knooppunt is een andere limiet die wordt gebruikt om te beschermen tegen runaway-query's. Deze limiet, vertegenwoordigd door de aanvraagoptie max_memory_consumption_per_query_per_node, stelt een bovengrens in voor de hoeveelheid geheugen die op één knooppunt voor een specifieke query kan worden gebruikt.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Als max_memory_consumption_per_query_per_node meerdere keren is ingesteld, bijvoorbeeld in eigenschappen van clientaanvragen en het gebruik van een set-instructie, is de lagere waarde van toepassing.

Als de query gebruikmaakt van summarize, joinof make-series operators, kunt u de query strategie gebruiken om de geheugenbelasting op één machine te verminderen.

Time-out voor uitvoering beperken

servertime-out is een time-out aan de servicezijde die wordt toegepast op alle aanvragen. Time-out bij actieve aanvragen (query's en beheeropdrachten) wordt afgedwongen op meerdere punten in de Kusto:

• clientbibliotheek (indien gebruikt)
• service-eindpunt dat de aanvraag accepteert
• service-engine die de aanvraag verwerkt

Time-out is standaard ingesteld op vier minuten voor query's en 10 minuten voor beheeropdrachten. Deze waarde kan indien nodig worden verhoogd (beperkt tot één uur).

• Verschillende clienthulpprogramma's ondersteunen het wijzigen van de time-out als onderdeel van hun globale of per-verbindingsinstellingen. Gebruik bijvoorbeeld in Kusto.Explorer Tools>Options* >Connections>Query Server Timeout.
• Programmatisch bieden SDK's ondersteuning voor het instellen van de time-out via de eigenschap servertimeout. In .NET SDK wordt dit bijvoorbeeld gedaan via een clientaanvraageigenschap, door een waarde van het type System.TimeSpanin te stellen.

Notities over time-outs

• Aan de clientzijde wordt de time-out toegepast op basis van de aanvraag die wordt gemaakt totdat het antwoord bij de client binnenkomt. De tijd die nodig is om de nettolading terug te lezen op de client, wordt niet behandeld als onderdeel van de time-out. Dit hangt af van hoe snel de beller de gegevens uit de stream haalt.
• Ook aan de clientzijde is de werkelijke time-outwaarde die wordt gebruikt iets hoger dan de time-outwaarde van de server die door de gebruiker is aangevraagd. Dit verschil is om netwerklatenties mogelijk te maken.
• Als u automatisch de maximaal toegestane aanvraagtime-out wilt gebruiken, stelt u de eigenschap van de clientaanvraag in norequesttimeout op true.

Limiet voor het cpu-resourcegebruik van query's

Met Kusto kunt u query's uitvoeren en alle beschikbare CPU-resources gebruiken die de database heeft. Er wordt geprobeerd een eerlijke round robin uit te voeren tussen query's als er meer dan één wordt uitgevoerd. Deze methode levert de beste prestaties op voor querygedefinieerde functies. Op andere momenten wilt u mogelijk de CPU-resources beperken die voor een bepaalde query worden gebruikt. Als u bijvoorbeeld een 'achtergrondtaak' uitvoert, kan het systeem hogere latenties tolereren om gelijktijdige inlinequery's hoge prioriteit te geven.

Kusto ondersteunt het opgeven van twee aanvraageigenschappen bij het uitvoeren van een query. De eigenschappen zijn query_fanout_threads_percent en query_fanout_nodes_percent. Beide eigenschappen zijn gehele getallen die standaard de maximumwaarde (100) hebben, maar kunnen worden verkleind voor een specifieke query naar een andere waarde.

De eerste, query_fanout_threads_percent, bepaalt de fanoutfactor voor threadgebruik. Wanneer deze eigenschap 100%is ingesteld, worden alle CPU's op elk knooppunt toegewezen. Bijvoorbeeld 16 CPU's die zijn geïmplementeerd op Azure D14-knooppunten. Wanneer deze eigenschap is ingesteld op 50%, worden de helft van de CPU's gebruikt, enzovoort. De getallen worden afgerond op een hele CPU, dus het is veilig om de eigenschapswaarde in te stellen op 0.

De tweede, query_fanout_nodes_percent, bepaalt hoeveel van de queryknooppunten per subquerydistributiebewerking moeten worden gebruikt. Het werkt op een vergelijkbare manier.

Als query_fanout_nodes_percent of query_fanout_threads_percent meerdere keren zijn ingesteld, bijvoorbeeld in eigenschappen van clientaanvragen en het gebruik van een set-instructie, is de lagere waarde voor elke eigenschap van toepassing.

Limiet voor querycomplexiteit

Tijdens het uitvoeren van de query wordt de querytekst omgezet in een structuur van relationele operators die de query vertegenwoordigen. Als de structuurdiepte een interne drempelwaarde overschrijdt, wordt de query als te complex beschouwd voor verwerking en mislukt de query met een foutcode. De fout geeft aan dat de structuur van relationele operators de limieten overschrijdt.

In de volgende voorbeelden ziet u veelvoorkomende querypatronen die ervoor kunnen zorgen dat de query deze limiet overschrijdt en mislukt:

• een lange lijst met binaire operators die aan elkaar zijn gekoppeld. Bijvoorbeeld:

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

Voor dit specifieke geval herschrijft u de query met behulp van de operator in().

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

• een query met een samenvoegoperator die een te brede schemaanalyse uitvoert, met name dat de standaardsmaak van samenvoeging het 'outer' samenvoegschema retourneert (wat betekent dat uitvoer alle kolommen van de onderliggende tabel bevat).

De suggestie in dit geval is het controleren van de query en het verminderen van de kolommen die door de query worden gebruikt.

Verwante inhoud

• best practices voor query's