Dela via

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

Gäller för: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel

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

Kort och kort

Åtgärd Använd Använd inte Noteringar
Minska mängden data som efterfrågas Använd mekanismer som operatorn where för att minska mängden data som bearbetas. Mer information om effektiva sätt att minska mängden data som bearbetas finns i Minska mängden data som bearbetas.
Undvik att använda redundanta kvalificerade referenser När du refererar till lokala entiteter använder du det okvalificerade namnet. Mer information finns i Undvik att använda redundanta kvalificerade referenser.
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änd 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änd ==. Använd inte =~. Använd skiftlägeskänsliga operatorer när det är möjligt.
Använd in. Använd inte in~.
Använd contains_cs. Använd inte contains. Du föredrar atthas/has_cs använda .contains/contains_cs
Söka i text Titta i en specifik kolumn. Använd inte *. * gör en fulltextsökning i alla kolumner.
Extrahera fält från dynamiska objekt över miljontals rader Materialisera kolumnen vid inmatningen om de flesta av dina frågor extraherar fält från dynamiska objekt över miljontals rader med hjälp av en uppdateringsprincip. Med den här metoden betalar du bara en gång för kolumnextrahering.
Sökning efter sällsynta nycklar/värden i dynamiska objekt Använd MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value". Använd inte MyTable | where DynamicColumn.SomeKey == "Rare value". Med den här metoden filtrerar du bort de flesta poster och utför bara JSON-parsning på resten.
let -instruktion med ett värde som du använder mer än en gång Använd 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 typkonverteringar på mer än en 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. Att köra obundna frågor över okända datauppsättningar kan ge en avkastning på gigabyte med resultat, vilket resulterar i ett långsamt svar och en upptagen miljö.
Skiftlägesokänsliga jämförelser Använd 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änd T | where predicate(*Expression*) Använd inte T | extend _value = *Expression* | where predicate(_value)
summarize-operator Använd hint.shufflekey=<key> när group by keys operatorn summarize har hög kardinalitet. Hög kardinalitet är helst mer än en miljon.
kopplingsoperator Välj tabellen med minst antal 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 av en enda kolumn.
Koppla mellan kluster Kör frågan på höger sida av kopplingen mellan fjärrmiljöer, till exempel kluster eller Eventhouses, 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änd parsningsoperatorn. Använd inte flera extract() instruktioner. Till exempel värden som "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ....".
funktionen extract() Använd när tolkade strängar inte alla följer samma format eller mönster. Extrahera nödvändiga värden med hjälp av en REGEX.
materialize() funktion 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 som endast krävs 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 sammansättningar. materialized_view() Använd funktionen för 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ådant sätt att mängden data som bearbetas minskar.

Anmärkning

I följande diskussion är det viktigt att ha i åtanke begreppet filterväljare. Selektivitet är vilken procentandel av posterna som filtreras bort vid filtrering av vissa predikat. Ett mycket selektivt predikat innebär att endast en handfull poster återstår efter att predikatet har tillämpats, vilket minskar mängden data som sedan måste bearbetas effektivt.

I prioritetsordning:

  • Endast referenstabeller vars data behövs av frågan. När du till exempel använder operatorn union med jokerteckentabellreferenser är det bättre från en prestandapunkt att bara referera till en handfull 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älltabellnamnet.

  • Dra nytta av en tabells dataomfång om frågan endast ä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 omedelbart efter tabellreferenser.

  • När du använder where frågeoperatorn kan den ordning i vilken du placerar predikaten, oavsett om du använder en enskild where operator eller flera på varandra följande where operatorer, ha en betydande effekt på frågeprestandan. I många fall ordnar frågeoptimeraren automatiskt predikaten i en effektiv ordning. Detta är dock inte alltid garanterat , så när det inte gör det bör du manuellt beställa predikaten enligt riktlinjerna i nästa punkter.

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

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

  • Använd sedan predikat som är selektiva och baseras på numeriska kolumner.

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

Undvik att använda redundanta kvalificerade referenser

Referera till entiteter som tabeller och materialiserade vyer efter namn.

Tabellen T kan till exempel refereras som helt enkelt T (det okvalificerade namnet) eller med hjälp av en databaskvalificerare (till exempel database("DB").T när tabellen finns i en databas med namnet DB), eller med hjälp av ett fullständigt kvalificerat namn (till exempel cluster("<serviceURL>").database("DB").T).

Tabellen T kan till exempel refereras som helt enkelt T (det okvalificerade namnet) eller med hjälp av en databaskvalificerare (till exempel database("DB").T när tabellen finns i en databas med namnet DB), eller med hjälp av ett fullständigt kvalificerat namn (till exempel cluster("X.Y.kusto.windows.net").database("DB").T).

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

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

  2. Att referera till entiteter med databas-in-scope är alltid minst lika snabbt, och i vissa fall mycket snabbare, sedan entiteter som tillhör andra databaser.

Detta gäller särskilt när dessa databaser finns i ett annat kluster.

Detta gäller särskilt när dessa databaser finns i ett annat Eventhouse.

Att undvika kvalificerade namn hjälper läsaren att göra det rätta.

Anmärkning

Det innebär 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 inte att du förlitar dig på detta när det inte behövs.

Anmärkning

Det innebär 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. Vi rekommenderar dock inte att du förlitar dig på detta när det inte behövs.