Aanbevolen procedures voor Kusto-querytaal query's
Hier volgen enkele aanbevolen procedures om uw query sneller te laten uitvoeren.
In het kort
Actie | Gebruik | Niet gebruiken | Notities |
---|---|---|---|
De hoeveelheid gegevens verminderen die wordt opgevraagd | Gebruik mechanismen zoals de where operator om de hoeveelheid gegevens te verminderen die wordt verwerkt. |
Hieronder vindt u efficiënte manieren om de hoeveelheid gegevens die wordt verwerkt te verminderen. | |
Vermijd het gebruik van redundante gekwalificeerde verwijzingen | Wanneer u verwijst naar lokale entiteiten, gebruikt u de niet-gekwalificeerde naam. | Zie hieronder voor meer informatie over dit onderwerp. | |
datetime Kolommen |
Gebruik het datetime gegevenstype. |
Gebruik long het gegevenstype niet. |
Gebruik in query's geen unix-tijdconversiefuncties, zoals unixtime_milliseconds_todatetime() . Gebruik in plaats daarvan updatebeleidsregels om unix-tijd te converteren naar het datetime gegevenstype tijdens opname. |
Tekenreeksoperators | has De operator gebruiken |
Niet gebruiken contains |
Wanneer u op zoek bent naar volledige tokens, has werkt dit beter, omdat er niet naar subtekenreeksen wordt gezocht. |
Hoofdlettergevoelige operators | == gebruiken |
Niet gebruiken =~ |
Gebruik indien mogelijk hoofdlettergevoelige operators. |
in gebruiken |
Niet gebruiken in~ |
||
contains_cs gebruiken |
Niet gebruiken contains |
Als u wel en niet kunt gebruiken has //has_cs contains contains_cs , is dat nog beter. |
|
Tekst zoeken | Zoeken in een specifieke kolom | Niet gebruiken * |
* voert een zoekopdracht in volledige tekst uit in alle kolommen. |
Velden extraheren uit dynamische objecten in miljoenen rijen | Materialiseer uw kolom tijdens opnametijd als de meeste query's velden extraheren uit dynamische objecten in miljoenen rijen. | Op deze manier betaalt u slechts één keer voor kolomextractie. | |
Zoeken naar zeldzame sleutels/waarden in dynamische objecten | MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value" gebruiken |
Niet gebruiken MyTable | where DynamicColumn.SomeKey == "Rare value" |
Op deze manier filtert u de meeste records uit en parseert u JSON alleen van de rest. |
let -instructie met een waarde die u meer dan één keer gebruikt |
De functie materialize() gebruiken | Zie materialize() voor meer informatie over het gebruikmaterialize() . Zie Query's optimaliseren die gebruikmaken van benoemde expressies voor meer informatie. |
|
Conversies toepassen op meer dan 1 miljard records | Geef uw query een nieuwe vorm om de hoeveelheid gegevens te verminderen die in de conversie worden ingevoerd. | Converteer geen grote hoeveelheden gegevens als dit kan worden vermeden. | |
Nieuwe query's | Gebruik limit [small number] of count aan het einde. |
Het uitvoeren van niet-afhankelijke query's op onbekende gegevenssets kan leiden tot GB aan resultaten die moeten worden geretourneerd aan de client, wat resulteert in een trage reactie en een bezet cluster. | |
Niet-hoofdlettergevoelige vergelijkingen | Col =~ "lowercasestring" gebruiken |
Niet gebruiken tolower(Col) == "lowercasestring" |
|
Gegevens vergelijken die al in kleine letters (of hoofdletters) staan | Col == "lowercasestring" (of Col == "UPPERCASESTRING" ) |
Vermijd het gebruik van niet-hoofdlettergevoelige vergelijkingen. | |
Filteren op kolommen | Filteren op een tabelkolom. | Filter niet op een berekende kolom. | |
T | where predicate(*Expression*) gebruiken |
Niet gebruiken T | extend _value = *Expression* | where predicate(_value) |
||
operator summarize | Gebruik de sleutel> hint.shufflekey=<als de group by keys van de samenvattende operator een hoge kardinaliteit heeft. |
Hoge kardinaliteit is idealiter boven 1 miljoen. | |
operator join | Selecteer de tabel met het aantal rijen als eerste (meest links in query). | ||
Gebruik in in plaats van linkerhalf om join te filteren op één kolom. |
|||
Koppelen tussen clusters | Voer in meerdere clusters de query uit aan de 'rechterkant' van de join, waar de meeste gegevens zich bevinden. | ||
Deelnemen wanneer de linkerkant klein is en de rechterkant groot is | Hint.strategy=broadcast gebruiken | Klein verwijst naar maximaal 100 MB aan gegevens. | |
Deelnemen wanneer de rechterkant klein is en de linkerkant groot is | Gebruik de opzoekoperator in plaats van de join operator |
Als de rechterkant van de zoekopdracht groter is dan enkele tientallen MB's, mislukt de query. | |
Deelnemen wanneer beide zijden te groot zijn | Hint.shufflekey=<key gebruiken> | Gebruik deze optie wanneer de joinsleutel een hoge kardinaliteit heeft. | |
Waarden extraheren in een kolom met tekenreeksen die dezelfde indeling of hetzelfde patroon hebben | De parseeroperator gebruiken | Gebruik niet meerdere extract() instructies. |
Bijvoorbeeld waarden als "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ...." |
extract(), functie | Gebruik deze optie wanneer geparseerde tekenreeksen niet allemaal dezelfde indeling of hetzelfde patroon hebben. | Pak de vereiste waarden uit met behulp van een REGEX. | |
materialize() , functie | Push alle mogelijke operators die de gerealiseerde gegevensset verminderen en toch de semantiek van de query behouden. | Bijvoorbeeld filters of project alleen vereiste kolommen. Zie Query's optimaliseren die gebruikmaken van benoemde expressies voor meer informatie. | |
Gerealiseerde weergaven gebruiken | Gebruik gerealiseerde weergaven voor het opslaan van veelgebruikte aggregaties. Gebruik liever de materialized_view() functie om alleen een query uit te voeren op gerealiseerde onderdelen |
materialized_view('MV') |
De hoeveelheid gegevens die wordt verwerkt verminderen
De prestaties van een query zijn rechtstreeks afhankelijk van de hoeveelheid gegevens die moet worden verwerkt. Hoe minder gegevens worden verwerkt, hoe sneller de query (en hoe minder resources deze verbruikt). Daarom is de belangrijkste best practice om de query zodanig te structuren dat de hoeveelheid gegevens die wordt verwerkt, wordt verminderd.
Notitie
In de onderstaande discussie is het belangrijk om rekening te houden met het concept van filterselectiviteit. Selectiviteit is welk percentage van de records wordt uitgefilterd bij het filteren op een bepaald predicaat. Een zeer selectief predicaat betekent dat er slechts een handvol records overblijft na het toepassen van het predicaat, waardoor de hoeveelheid gegevens wordt verminderd die vervolgens effectief moet worden verwerkt.
In volgorde van urgentie:
Alleen verwijzen naar tabellen waarvan de gegevens nodig zijn voor de query. Als u bijvoorbeeld de
union
operator gebruikt met jokertekentabelverwijzingen, is het vanuit het oogpunt van de prestaties beter om alleen naar een handvol tabellen te verwijzen, in plaats van een jokerteken (*
) te gebruiken om naar alle tabellen te verwijzen en vervolgens gegevens uit te filteren met behulp van een predicaat op de naam van de brontabel.Profiteer van het gegevensbereik van een tabel als de query alleen relevant is voor een specifiek bereik. De functie table() biedt een efficiënte manier om gegevens te elimineren door het bereik ervan te bepalen volgens het cachebeleid (de Parameter DataScope ).
Pas de
where
queryoperator direct na tabelverwijzingen toe.Wanneer u de
where
queryoperator gebruikt, kan een verstandig gebruik van de volgorde van predicaten (in één operator of met een aantal opeenvolgende operators, het maakt niet uit welke) een aanzienlijk effect hebben op de queryprestaties, zoals hieronder wordt uitgelegd.Pas eerst hele shardpredicaten toe. Dit betekent dat predicaten die de functie extent_id() gebruiken, eerst moeten worden toegepast, net als predicaten die gebruikmaken van de functie extent_tags() en predicaten die zeer selectief zijn ten opzichte van de gegevenspartities van de tabel (indien gedefinieerd).
Pas vervolgens predicaten toe die inwerken op
datetime
tabelkolommen. Kusto bevat een zeer efficiënte index voor dergelijke kolommen, waardoor shards van hele gegevens vaak volledig worden geëlimineerd zonder dat u toegang tot deze shards nodig hebt.Pas vervolgens predicaten toe die op en-kolommen
dynamic
inwerkenstring
, met name predicaten die van toepassing zijn op termenniveau. De predicaten moeten worden geordend op basis van de selectiviteit (bijvoorbeeld het zoeken naar een gebruikers-id wanneer er miljoenen gebruikers zijn, is zeer selectief en is meestal een zoekterm waarvoor de index zeer efficiënt is.)Pas vervolgens predicaten toe die selectief zijn en zijn gebaseerd op numerieke kolommen.
Ten slotte, voor query's die de gegevens van een tabelkolom scannen (bijvoorbeeld voor predicaten zoals 'bevat '@!@!' die geen termen hebben en geen baat hebben bij indexering), ordent u de predicaten zodanig dat de predicaten die kolommen met minder gegevens scannen, de eerste zijn. Dit vermindert de noodzaak om grote kolommen te decomprimeren en scannen.
Vermijd het gebruik van redundante gekwalificeerde verwijzingen
Naar entiteiten zoals tabellen en gerealiseerde weergaven wordt op naam verwezen.
Naar de tabel T
kan bijvoorbeeld worden verwezen als eenvoudig T
(de niet-gekwalificeerde naam), of door een databasekwalificatie te gebruiken (bijvoorbeeld database("DB").T
wanneer de tabel zich in een database bevindt met de naam DB
), of door een volledig gekwalificeerde naam (bijvoorbeeld cluster("X.Y.kusto.windows.net").database("DB").T
).
Het is een best practice om het gebruik van naamkwalificaties te vermijden wanneer deze overbodig zijn, om de volgende redenen:
Niet-gekwalificeerde namen zijn gemakkelijker te identificeren (voor een menselijke lezer) als behorend tot de database binnen het bereik.
Verwijzen naar entiteiten binnen het bereik van databases is altijd minstens net zo snel en in sommige gevallen veel sneller dan entiteiten die deel uitmaken van andere databases (met name wanneer deze databases zich in een ander cluster bevinden).) Het vermijden van gekwalificeerde namen helpt de lezer om het juiste te doen.
Notitie
Dit wil niet zeggen dat gekwalificeerde namen slecht zijn voor de prestaties. Kusto is in de meeste gevallen zelfs in staat om te bepalen wanneer een volledig gekwalificeerde naam verwijst naar een entiteit die behoort tot de database binnen het bereik en de query 'kortsluitend' zodat deze niet wordt beschouwd als een query voor meerdere clusters. We raden u echter aan om hier niet op te vertrouwen wanneer dit niet nodig is, om de hierboven opgegeven redenen.
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie:Feedback verzenden en weergeven voor