Best practices voor Kusto Query Language-query's

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

Hier volgen verschillende aanbevolen procedures om uw query sneller uit te voeren.

Kortom

Handeling	Gebruik	Niet gebruiken	Opmerkingen
De hoeveelheid gegevens die wordt opgevraagd verminderen	Gebruik mechanismen zoals de where operator om de hoeveelheid verwerkte gegevens te verminderen.		Zie De hoeveelheid verwerkte gegevens verminderen voor meer informatie over efficiënte manieren om de hoeveelheid verwerkte gegevens te verminderen.
Vermijd het gebruik van redundante gekwalificeerde verwijzingen	Wanneer u verwijst naar lokale entiteiten, gebruikt u de niet-gekwalificeerde naam.		Zie Vermijd het gebruik van redundante gekwalificeerde verwijzingen voor meer informatie.
datetime Kolommen	Gebruik het datetime gegevenstype.	Gebruik het gegevenstype niet long .	Gebruik in query's geen unix-tijdconversiefuncties, zoals unixtime_milliseconds_todatetime(). Gebruik in plaats daarvan updatebeleid om Unix-tijd tijdens opname te converteren naar het datetime gegevenstype.
tekenreeksoperators	Gebruik de has-operator.	Niet gebruiken contains	Wanneer u op zoek bent naar volledige tokens, werkt dit beter, has omdat deze niet zoekt naar subtekenreeksen.
Hoofdlettergevoelige operators	Gebruik ==.	Niet gebruiken =~.	Gebruik indien mogelijk hoofdlettergevoelige operators.
	Gebruik in.	Niet gebruiken in~.
	Gebruik contains_cs.	Niet gebruiken contains.	Het gebruik has/has_cs heeft de voorkeur contains/contains_cs.
Tekst zoeken	Zoek 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 bij opnametijd als de meeste query's velden uit dynamische objecten over miljoenen rijen extraheren met behulp van een updatebeleid.		Met deze methode betaalt u slechts één keer voor kolomextractie.
Opzoeken voor zeldzame sleutels/waarden in dynamische objecten	Gebruik MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value".	Niet gebruiken MyTable | where DynamicColumn.SomeKey == "Rare value".	Met deze methode filtert u de meeste records uit en voert u alleen JSON-parsering uit op de rest.
let instructie met een waarde die u meer dan één keer gebruikt	Gebruik de functie materialize().		Zie materialize()voor meer informatie over het gebruik. Zie Query's optimaliseren die gebruikmaken van benoemde expressies voor meer informatie.
Typeconversies toepassen op meer dan één miljard records	Hervorm uw query om de hoeveelheid gegevens die in de conversie worden ingevoerd, te verminderen.	Converteer geen grote hoeveelheden gegevens als deze kunnen worden vermeden.
Nieuwe query's	Gebruik limit [small number] of count aan het einde.		Het uitvoeren van niet-afhankelijke query's via onbekende gegevenssets kan leiden tot een retournering van gigabytes aan resultaten, wat resulteert in een traag antwoord en een drukke omgeving.
Hoofdlettergevoelige vergelijkingen	Gebruik Col =~ "lowercasestring".	Niet gebruiken tolower(Col) == "lowercasestring".
Gegevens vergelijken die al in kleine letters (of hoofdletters) staan	Col == "lowercasestring" (of Col == "UPPERCASESTRING").	Vermijd het gebruik van hoofdlettergevoelige vergelijkingen.
Filteren op kolommen	Filter op een tabelkolom.	Filter niet op een berekende kolom.
	Gebruik T | where predicate(*Expression*)	Niet gebruiken T | extend _value = *Expression* | where predicate(_value)
operator samenvatten	Gebruik hint.shufflekey=<key> wanneer de group by keyssummarize operator een hoge kardinaliteit heeft.		Hoge kardinaliteit is idealiter meer dan één miljoen.
join-operator	Selecteer de tabel met de minste rijen als de eerste (meest links in de query).
	Gebruik in in plaats van een linker semi join om te filteren op één kolom.
Samenvoegen tussen clusters	Voer de query aan de rechterkant van de join uit in externe omgevingen, zoals clusters of Eventhouses, waar de meeste gegevens zich bevinden.
Join wanneer de linkerkant klein is en de rechterkant groot is	Gebruik hint.strategy=broadcast.		Klein verwijst naar maximaal 100 mb aan gegevens.
Lid worden wanneer de rechterzijde klein is en de linkerkant groot is	Gebruik de opzoekoperator in plaats van de join operator		Als de rechterkant van de zoekactie groter is dan meerdere tientallen MB, mislukt de query.
Deelnemen wanneer beide zijden te groot zijn	Gebruik hint.shufflekey=<key>.		Gebruik deze functie wanneer de joinsleutel een hoge kardinaliteit heeft.
Waarden extraheren in kolom met tekenreeksen die dezelfde indeling of hetzelfde patroon delen	Gebruik de parseringsoperator.	Gebruik geen verschillende extract() instructies.	Bijvoorbeeld waarden zoals "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ....".
extract() functie	Gebruiken wanneer geparseerde tekenreeksen niet allemaal dezelfde indeling of hetzelfde patroon volgen.		Pak de vereiste waarden uit met behulp van een REGEX.
materialize() functie	Push alle mogelijke operators die de gerealiseerde gegevensset verminderen en behoud nog steeds de semantiek van de query.		Bijvoorbeeld filters of alleen vereiste kolommen project. Zie Query's optimaliseren die gebruikmaken van benoemde expressies voor meer informatie.
Gerealiseerde weergaven gebruiken	Gebruik gerealiseerde weergaven voor het opslaan van veelgebruikte aggregaties. Geef de voorkeur aan het gebruik van de materialized_view() functie om alleen een query uit te voeren op gerealiseerde onderdelen.		materialized_view('MV')

De hoeveelheid gegevens verminderen die wordt verwerkt

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 volgende discussie is het belangrijk om rekening te houden met het concept van filterselectiviteit. Selectiviteit is welk percentage van de records wordt gefilterd bij het filteren op een predicaat. Een zeer selectief predicaat betekent dat er slechts een handvol records blijven na het toepassen van het predicaat, waardoor de hoeveelheid gegevens die vervolgens effectief moeten worden verwerkt, wordt verminderd.

In volgorde van belang:

• Alleen referentietabellen waarvan de gegevens nodig zijn voor de query. Wanneer u bijvoorbeeld de union operator met jokertekentabelverwijzingen gebruikt, is het beter om vanuit een prestatiepunt alleen te verwijzen naar een handvol tabellen, in plaats van een jokerteken (*) te gebruiken om naar alle tabellen te verwijzen en gegevens vervolgens 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 onmiddellijk na tabelverwijzingen toe.

• Wanneer u de where queryoperator gebruikt, kan de volgorde waarin u de predicaten plaatst, ongeacht of u één where operator of meerdere opeenvolgende where operatoren gebruikt, een aanzienlijk effect hebben op de queryprestaties. In veel gevallen rangschikt de queryoptimalisatie automatisch de predicaten in een efficiënte volgorde. Dit is echter niet altijd gegarandeerd, dus als dat niet het geval is, moet u de predicaten handmatig orden volgens de richtlijnen in de volgende punten.

• Pas predicaten toe die eerst reageren op datetime tabelkolommen. Kusto bevat een efficiënte index voor dergelijke kolommen, waardoor hele gegevenshards vaak volledig worden geëlimineerd zonder toegang te hoeven krijgen tot deze shards.

• Pas vervolgens predicaten toe die handelen string op en dynamic kolommen, met name dergelijke predicaten die op termsniveau van toepassing zijn. Bestel de predicaten door de selectiviteit. Het zoeken naar een gebruikers-id wanneer er miljoenen gebruikers zijn, is bijvoorbeeld zeer selectief en omvat meestal een zoekterm waarvoor de index zeer efficiënt is.

• Pas vervolgens predicaten toe die selectief zijn en zijn gebaseerd op numerieke kolommen.

• Voor query's die de gegevens van een tabelkolom scannen (bijvoorbeeld voor predicaten zoals contains"@!@!", die geen termen hebben en geen voordeel hebben van indexering), moet u de predicaten zodanig rangschikken dat de kolommen met minder gegevens eerst worden gescand. Dit vermindert de noodzaak om grote kolommen te decomprimeren en scannen.

Vermijd het gebruik van redundante gekwalificeerde verwijzingen

Verwijzingsentiteiten zoals tabellen en gerealiseerde weergaven op naam.

De tabel kan bijvoorbeeld worden verwezen als simpelweg T (de T naam) of door een databasekwalificatie te gebruiken (bijvoorbeeld wanneer de tabel database("DB").T zich in een database bevindt met de naamDB), of met behulp van een volledig gekwalificeerde naam (bijvoorbeeldcluster("<serviceURL>").database("DB").T).

Het is een best practice om te voorkomen dat u naamkwalificaties gebruikt wanneer ze redundant zijn, om de volgende redenen:

1. Niet-gekwalificeerde namen zijn gemakkelijker te identificeren (voor een menselijke lezer) als behorend tot het databasebereik.

2. Het verwijzen naar entiteiten binnen het bereik van databases is altijd minstens zo snel en in sommige gevallen veel sneller, dan entiteiten die deel uitmaken van andere databases.

Dit geldt met name wanneer deze databases zich in een ander Eventhouse bevinden.

Als u gekwalificeerde namen vermijdt, kan de lezer het juiste doen.

Notitie

Dit betekent niet dat gekwalificeerde namen slecht zijn voor prestaties. Kusto kan in de meeste gevallen identificeren wanneer een volledig gekwalificeerde naam verwijst naar een entiteit die deel uitmaakt van het databasebereik. We raden u echter niet aan dit te vertrouwen wanneer dit niet nodig is.