Ajánlott eljárások a Kusto lekérdezési nyelv lekérdezéseihez

Szolgáltatások váltása a Verzió legördülő listával. További információ a navigációról.
A következőkre vonatkozik: ✅ Microsoft Fabric ✅ Azure Data Explorer ✅ Azure Monitor ✅ Microsoft Sentinel

Az alábbiakban néhány ajánlott eljárást követve gyorsabban futtathatja a lekérdezést.

Röviden

Tevékenység	Használd	Ne használja	Jegyzetek
A lekérdezett adatok mennyiségének csökkentése	A feldolgozandó adatok mennyiségének csökkentéséhez használjon olyan mechanizmusokat, mint where az operátor.		A feldolgozott adatok mennyiségének csökkentésére szolgáló hatékony módszerekről további információt a feldolgozott adatok mennyiségének csökkentése című témakörben talál.
Kerülje a redundáns minősített hivatkozások használatát	Helyi entitásokra való hivatkozáskor használja a nem minősített nevet.		További információt a redundáns minősített hivatkozások használatának elkerülése című témakörben talál.
datetime Oszlopok	Használja az adattípust datetime .	Ne használja az adattípust long .	A lekérdezésekben ne használjon Unix időkonvertálási függvényeket, például unixtime_milliseconds_todatetime(). Ehelyett frissítési szabályzatokkal konvertálja a Unix-időt adattípusra a datetime betöltés során.
sztring operátorok	Használja az has operátort.	Ne használja contains	Ha teljes jogkivonatokat keres, has jobban működik, mivel nem keres részszűkítéseket.
Kis- és nagybetűket megkülönböztető operátorok	Használja a ==.	Ne használja =~.	Lehetőség szerint használjon kis- és nagybetűket megkülönböztető operátorokat.
	Használja a in.	Ne használja in~.
	Használja a contains_cs.	Ne használja contains.	A használat has/has_cs előnyben részesítendő.contains/contains_cs
Szöveg keresése	Keresse meg egy adott oszlopban.	Ne használja *.	* teljes szöveges keresést végez az összes oszlopban.
Mezők kinyerése dinamikus objektumokból több millió sorból	Ha a lekérdezések többsége dinamikus objektumokból több millió sorból nyer ki mezőket, akkor a betöltési időben hasznosítja az oszlopot egy Frissítési szabályzat használatával.		Ezzel a módszerrel csak egyszer kell fizetnie az oszlopkiemelésért.
Ritka kulcsok/értékek keresése dinamikus objektumokban	Használja a MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value".	Ne használja MyTable | where DynamicColumn.SomeKey == "Rare value".	Ezzel a módszerrel kiszűrheti a legtöbb rekordot, és csak a maradékon végez JSON-elemzést.
let egynél többször használt értékkel rendelkező utasítás	Használja a materialize() függvényt.		További információ a használat materialize()módjáról: materialize(). További információ: Elnevezett kifejezéseket használó lekérdezések optimalizálása.
Típuskonverziók alkalmazása több mint egymilliárd rekordon	Alakítsa át a lekérdezést, hogy csökkentse az átalakításba betáplált adatok mennyiségét.	Ne konvertáljon nagy mennyiségű adatot, ha elkerülhető.
Új lekérdezések	Használja limit [small number] vagy count a végén.		A kötetlen lekérdezések ismeretlen adathalmazokon való futtatása gigabájtnyi eredményt eredményezhet, ami lassú válaszhoz és forgalmas környezethez vezethet.
Kis- és nagybetűk érzéketlen összehasonlításai	Használja a Col =~ "lowercasestring".	Ne használja tolower(Col) == "lowercasestring".
A már kisbetűs (vagy nagybetűs) adatok összehasonlítása	Col == "lowercasestring" (vagy Col == "UPPERCASESTRING").	Kerülje a kis- és nagybetűk érzéketlen összehasonlítását.
Szűrés oszlopokon	Szűrés táblázatoszlopon.	Ne szűrjön számított oszlopra.
	Használja a T | where predicate(*Expression*)-t	Ne használja T | extend _value = *Expression* | where predicate(_value)
összesítő operátor	Használja a hint.shufflekey=<billentyűt> , ha az group by keyssummarize operátor nagy számossággal rendelkezik.		A magas számosság ideális esetben több mint egymillió.
illesztés operátor	Jelölje ki azt a táblát, amely elsőként a legkevesebb sort tartalmazza (a lekérdezés bal oldali része).
	Bal oldali fél in helyett egyetlen oszlop szerinti szűréshez használhatójoin.
Csatlakozás fürtök között	Futtassa a lekérdezést az illesztés "jobb" oldalán távoli környezetekben, például fürtökben vagy eventhouse-okban, ahol az adatok nagy része található.
Illesztés, ha a bal oldal kicsi, a jobb oldal pedig nagy	Használja a hint.strategy=broadcast parancsot.		A kicsi legfeljebb 100 megabájt (MB) adatra utal.
Csatlakozás, ha a jobb oldal kicsi, a bal oldal pedig nagy	A keresési operátor használata az join operátor helyett		Ha a keresés jobb oldala több tíz MB-nál nagyobb, a lekérdezés meghiúsul.
Csatlakozás, ha mindkét oldal túl nagy	Használja a hint.shufflekey=<key parancsot>.		Akkor használható, ha az illesztőkulcs nagy számossággal rendelkezik.
Értékek kinyerése az oszlopból ugyanazzal a formátummal vagy mintával rendelkező sztringekkel	Használja az elemzési operátort.	Ne használjon több extract() utasítást.	Például olyan értékeket, mint a "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ....".
extract() függvény	Akkor használható, ha az elemzési sztringek nem ugyanazt a formátumot vagy mintát követik.		A szükséges értékek kinyerése REGEX használatával.
materialize() függvény	Az összes lehetséges operátor leküldése, amely csökkenti a materializált adathalmazt, és továbbra is megőrzi a lekérdezés szemantikáját.		A szűrőkhöz vagy a projekthez például csak oszlopok szükségesek. További információ: Elnevezett kifejezéseket használó lekérdezések optimalizálása.
Materializált nézetek használata	Használjon materializált nézeteket a gyakran használt összesítések tárolásához. Inkább csak a materializált rész lekérdezéséhez használja a materialized_view() függvényt.		materialized_view('MV')

A feldolgozandó adatok mennyiségének csökkentése

A lekérdezések teljesítménye közvetlenül a feldolgozandó adatok mennyiségétől függ. Minél kevesebb adatot dolgoz fel, annál gyorsabb a lekérdezés (és annál kevesebb erőforrást használ fel). Ezért a legfontosabb ajánlott eljárás a lekérdezés olyan strukturálása, amely csökkenti a feldolgozott adatok mennyiségét.

Megjegyzés:

A következő vita során fontos szem előtt tartani a szűrőválasztás fogalmát. A szelektivitás azt határozza meg, hogy a rekordok hány százaléka szűrhető ki bizonyos predikátumok alapján történő szűréskor. A szigorúan szelektív predikátum azt jelenti, hogy a predikátum alkalmazása után csak néhány rekord marad meg, csökkentve a hatékonyan feldolgozandó adatok mennyiségét.

Fontossági sorrendben:

• Csak olyan táblákra hivatkozik, amelyek adataira a lekérdezésnek szüksége van. Ha például helyettesítő táblahivatkozásokkal használja az union operátort, a teljesítmény szempontjából jobb, ha csak néhány táblára hivatkozik, ahelyett, hogy helyettesítő karaktert (*) használ az összes táblára való hivatkozáshoz, majd a forrástábla nevének predikátumával szűri ki az adatokat.

• Használja ki a tábla adathatókörét, ha a lekérdezés csak egy adott hatókörre vonatkozik. A table() függvény hatékony módszert kínál az adatok eltávolítására a gyorsítótárazási szabályzat (a DataScope paraméter) alapján történő hatókör meghatározásával.

• Alkalmazza a lekérdezési operátort közvetlenül a where táblahivatkozások után.

• A lekérdezési operátor használatakor a where predikátumok elhelyezésének sorrendje , akár egyetlen where operátort, akár több egymást követő where operátort használ, jelentős hatással lehet a lekérdezési teljesítményre, a lekérdezésoptimalizáló sok esetben automatikusan hatékony sorrendbe rendezi a predikátumokat. Ez azonban nem mindig garantált – ezért ha nem, akkor a predikátumokat manuálisan kell megrendelnie a következő pontokban szereplő irányelveknek megfelelően.

• Először a táblaoszlopokra ható datetime predikátumokat alkalmazza. A Kusto hatékony indexet tartalmaz az ilyen oszlopokon, és gyakran teljes adatszilánkokat szüntet meg anélkül, hogy hozzá kellene férnie ezekhez a szegmensekhez.

• Ezután alkalmazza azokat a predikátumokat, amelyek a string kifejezés szintjén érvényesek, és dynamic oszlopokat, különösen azokat a predikátumokat, amelyek a kifejezés szintjén érvényesek. Rendezze a predikátumokat a szelektivitás szerint. Ha például több millió felhasználó keres felhasználói azonosítót, az nagyon szelektív, és általában kifejezéskeresést is magában foglal, amely esetében az index nagyon hatékony.

• Ezután alkalmazza a szelektív és numerikus oszlopokon alapuló predikátumokat.

• Végül a táblaoszlop adatait beolvasó lekérdezések (például olyan predikátumok contains"@!@!"esetében, amelyek nem rendelkeznek kifejezésekkel, és nem élvezik az indexelés előnyeit), rendezze a predikátumokat úgy, hogy azok legyenek az elsők, amelyek kevesebb adatot tartalmazó oszlopokat vizsgálnak. Ez csökkenti a nagy oszlopok felbontásának és vizsgálatának szükségességét.

Kerülje a redundáns minősített hivatkozások használatát

Hivatkozási entitások, például táblák és materializált nézetek név szerint.

A tábla T például egyszerűen T (nem minősített név) vagy adatbázis-minősítő használatával (például database("DB").T ha a tábla egy úgynevezett DBadatbázisban található), vagy egy teljes névvel (például cluster("<serviceURL>").database("DB").T) hivatkozhat rá.

Érdemes elkerülni a névminősítések használatát redundáns esetekben, az alábbi okokból:

1. A nem minősített nevek könnyebben azonosíthatók (az emberi olvasó számára) a hatókörben lévő adatbázishoz tartozóként.

2. A hatókörön belüli adatbázis-entitásokra való hivatkozás mindig legalább olyan gyors, és bizonyos esetekben sokkal gyorsabb, mint a más adatbázisokhoz tartozó entitások.

Ez különösen akkor igaz, ha ezek az adatbázisok egy másik Eventhouse-ban találhatók.

A minősített nevek elkerülése segít az olvasónak, hogy helyesen cselekedjen.

Megjegyzés:

Ez nem jelenti azt, hogy a minősített nevek rosszak a teljesítmény szempontjából. A Kusto a legtöbb esetben képes azonosítani, hogy egy teljes név mikor hivatkozik a hatókörben lévő adatbázishoz tartozó entitásra. Ezt azonban nem javasoljuk, ha nem szükséges.