Metodtips för Kusto-frågespråk frågor

Här följer flera metodtips för att få frågan att köras snabbare.

Kort och kort

Åtgärd	Användning	Använd inte	Kommentarer
Minska mängden data som efterfrågas	Använd mekanismer som operatorn where för att minska mängden data som bearbetas.		Se nedan för effektiva sätt att minska mängden data som bearbetas.
Undvik att använda redundanta kvalificerade referenser	Använd det okvalificerade namnet när du refererar till lokala entiteter.		Se nedan för mer information om ämnet.
datetime Kolumner	datetime Använd datatypen.	Använd long inte datatypen.	I frågor ska du inte använda unix-tidskonverteringsfunktioner, till exempel unixtime_milliseconds_todatetime(). Använd i stället uppdateringsprinciper för att konvertera unix-tid till datetime datatypen under inmatningen.
Strängoperatorer	Använda operatorn has	Använd inte contains	När du letar efter fullständiga token has fungerar det bättre, eftersom det inte letar efter delsträngar.
Skiftlägeskänsliga operatorer	Använda ==	Använd inte =~	Använd skiftlägeskänsliga operatorer när det är möjligt.
	Använda in	Använd inte in~
	Använda contains_cs	Använd inte contains	Om du kan använda has/has_cs och inte använda contains/contains_csär det ännu bättre.
Söka i text	Titta i en specifik kolumn	Använd inte *	* utför en fulltextsökning i alla kolumner.
Extrahera fält från dynamiska objekt över miljontals rader	Materialisera kolumnen vid inmatningstillfället om de flesta av dina frågor extraherar fält från dynamiska objekt över flera miljoner rader.		På så sätt betalar du bara en gång för extrahering av kolumner.
Sökning efter sällsynta nycklar/värden i dynamiska objekt	Använda MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value"	Använd inte MyTable | where DynamicColumn.SomeKey == "Rare value"	På så sätt filtrerar du bort de flesta poster och utför endast JSON-parsning av resten.
let instruktion med ett värde som du använder mer än en gång	Använda funktionen materialize()		Mer information om hur du använder materialize()finns i materialize(). Mer information finns i Optimera frågor som använder namngivna uttryck.
Tillämpa konverteringar på mer än 1 miljard poster	Omforma frågan för att minska mängden data som matas in i konverteringen.	Konvertera inte stora mängder data om det kan undvikas.
Nya frågor	Använd limit [small number] eller count i slutet.		Om du kör obundna frågor över okända datauppsättningar kan det ge gb resultat som ska returneras till klienten, vilket resulterar i ett långsamt svar och ett upptaget kluster.
Skiftlägesokänsliga jämförelser	Använda Col =~ "lowercasestring"	Använd inte tolower(Col) == "lowercasestring"
Jämför data som redan finns i gemener (eller versaler)	Col == "lowercasestring" (eller Col == "UPPERCASESTRING")	Undvik att använda skiftlägesokänsliga jämförelser.
Filtrera efter kolumner	Filtrera på en tabellkolumn.	Filtrera inte på en beräknad kolumn.
	Använda T | where predicate(*Expression*)	Använd inte T | extend _value = *Expression* | where predicate(_value)
summarize-operatorn	Använd hint.shufflekey=<key> när group by keys sammanfattningsoperatorn har hög kardinalitet.		Hög kardinalitet är idealiskt över 1 miljon.
join-operatorn	Markera tabellen med färre rader som den första (längst till vänster i frågan).
	Använd in i stället för vänster semi join för filtrering efter en enda kolumn.
Koppla mellan kluster	I kluster kör du frågan på "höger" sida av kopplingen, där de flesta data finns.
Anslut när vänster sida är liten och höger sida är stor	Använd hint.strategy=broadcast		Små refererar till upp till 100 MB data.
Anslut när höger sida är liten och vänster sida är stor	Använd uppslagsoperatorn i stället för operatorn join		Om den högra sidan av sökningen är större än flera tiotals MB misslyckas frågan.
Anslut när båda sidor är för stora	Använd hint.shufflekey=<key>		Använd när kopplingsnyckeln har hög kardinalitet.
Extrahera värden i kolumnen med strängar som delar samma format eller mönster	Använda parsningsoperatorn	Använd inte flera extract() instruktioner.	Till exempel värden som "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ...."
funktionen extract()	Använd när parsade strängar inte alla följer samma format eller mönster.		Extrahera de värden som krävs med hjälp av en REGEX.
funktionen materialize()	Push-överför alla möjliga operatorer som minskar den materialiserade datamängden och fortfarande behåller frågans semantik.		Till exempel filter eller projekt endast obligatoriska kolumner. Mer information finns i Optimera frågor som använder namngivna uttryck.
Använda materialiserade vyer	Använd materialiserade vyer för att lagra vanliga aggregeringar. Använd funktionen för materialized_view() att endast fråga materialiserad del		materialized_view('MV')

Minska mängden data som bearbetas

En frågas prestanda beror direkt på mängden data som den behöver bearbeta. Ju mindre data som bearbetas, desto snabbare blir frågan (och ju färre resurser den förbrukar). Därför är det viktigaste bästa sättet att strukturera frågan på ett sätt som minskar mängden data som bearbetas.

Anteckning

I diskussionen nedan är det viktigt att ha i åtanke begreppet filterväljare. Selektivitet är vilken procentandel av posterna som filtreras bort vid filtrering efter något predikat. Ett mycket selektivt predikat innebär att endast en handfull poster finns kvar efter att predikatet har tillämpats, vilket minskar mängden data som sedan behöver bearbetas effektivt.

I prioritetsordning:

• Endast referenstabeller vars data behövs av frågan. När du till exempel använder operatorn union med tabellreferenser med jokertecken är det bättre från en prestandapunkt att bara referera till ett fåtal tabeller, i stället för att använda ett jokertecken (*) för att referera till alla tabeller och sedan filtrera bort data med hjälp av ett predikat i källtabellens namn.

• Dra nytta av en tabells dataomfång om frågan bara är relevant för ett specifikt omfång. Funktionen table() är ett effektivt sätt att eliminera data genom att omfångsanpassa dem enligt cachelagringsprincipen (parametern DataScope).

• where Använd frågeoperatorn direkt efter tabellreferenser.

• När du använder where frågeoperatorn spelar en omdömesgill användning av predikatordningen (i en enda operator eller med ett antal på varandra följande operatorer ingen roll vilken) som kan ha en betydande effekt på frågeprestandan, enligt beskrivningen nedan.

• Använd predikat för hela shard först. Det innebär att predikat som använder funktionen extent_id() ska tillämpas först, liksom predikat som använder funktionen extent_tags() och predikat som är mycket selektiva över tabellens datapartitioner (om de definieras).

• Tillämpa sedan predikat som fungerar på datetime tabellkolumner. Kusto innehåller ett mycket effektivt index för sådana kolumner, vilket ofta eliminerar hela datashards helt utan att behöva komma åt dessa shards.

• Tillämpa sedan predikat som agerar på string kolumner och dynamic , särskilt sådana predikat som gäller på termnivå. Predikaten bör sorteras efter selektivitet (till exempel att söka efter ett användar-ID när det finns miljontals användare är mycket selektivt och vanligtvis är en termsökning som indexet är mycket effektivt för.)

• Tillämpa sedan predikat som är selektiva och baseras på numeriska kolumner.

• Slutligen, för frågor som söker igenom data i en tabellkolumn (till exempel för predikat som "innehåller "@!@!" som inte har några termer och inte drar nytta av indexering), beställer du predikaten så att de som söker igenom kolumner med färre data är först. Detta minskar behovet av att dekomprimera och skanna stora kolumner.

Undvik att använda redundanta kvalificerade referenser

Entiteter som tabeller och materialiserade vyer refereras till med namn. Tabellen T kan till exempel refereras som helt enkelt T (det okvalificerade namnet) eller genom att använda en databaskvalificerare (t.ex. database("DB").T när tabellen finns i en databas med namnet DB), eller genom att använda ett fullständigt kvalificerat namn (t.ex. cluster("X.Y.kusto.windows.net").database("DB").T).

Det är bästa praxis att undvika att använda namnkvalifikationer när de är överflödiga av följande skäl:

1. Okvalificerade namn är enklare att identifiera (för en mänsklig läsare) som tillhör databasen i omfånget.

2. Att referera till entiteter med databasomfång är alltid minst lika snabbt, och i vissa fall mycket snabbare, sedan entiteter som tillhör andra databaser (särskilt när dessa databaser finns i ett annat kluster.) Genom att undvika kvalificerade namn kan läsaren göra det rätta.

Anteckning

Det betyder inte att kvalificerade namn är dåliga för prestanda. Kusto kan i de flesta fall identifiera när ett fullständigt kvalificerat namn refererar till en entitet som tillhör databasen i omfånget och "kortslutning" för frågan så att den inte betraktas som en fråga mellan kluster. Vi rekommenderar dock att du inte förlitar dig på detta när det inte är nödvändigt, av de skäl som anges ovan.