Ajánlott eljárások Kusto lekérdezésnyelv lekérdezésekhez

Íme néhány ajánlott eljárás a lekérdezés gyorsabb futtatásához.

Röviden

Művelet	Használat	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.		Az alábbiakban a feldolgozott adatok mennyiségének csökkentésére szolgáló hatékony módszereket talál.
Kerülje a redundáns minősített hivatkozások használatát	Ha helyi entitásokra hivatkozik, használja a nem minősített nevet.		A témáról alább talál további információt.
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 a frissítési szabályzatok használatával alakítsa át a unix-időt adattípusra a datetime betöltés során.
Sztringoperátorok	has Az operátor használata	Ne használja contains	Ha teljes jogkivonatokat keres, has jobban működik, mivel nem keres részsztringeket.
Kis- és nagybetűket megkülönböztető operátorok	A == használata	Ne használja =~	Ha lehetséges, használjon kis- és nagybetűket megkülönböztető operátorokat.
	A in használata	Ne használja in~
	A contains_cs használata	Ne használja contains	Ha használhatja has/has_cs és nem használhatja contains/contains_cs, az még jobb.
Szöveg keresése	Keresés 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 legtöbb lekérdezés dinamikus objektumokból nyer ki mezőket több millió sorból, akkor a betöltési időben materializálja az oszlopot.		Így csak egyszer kell fizetnie az oszlopkinyerésért.
Ritka kulcsok/értékek keresése dinamikus objektumokban	A MyTable | where DynamicColumn has "Rare value" | where DynamicColumn.SomeKey == "Rare value" használata	Ne használja MyTable | where DynamicColumn.SomeKey == "Rare value"	Így kiszűrheti a legtöbb rekordot, és csak a többit elemezheti JSON-ként.
let utasítás egy olyan értékkel, amelyet többször is használ	A materialize() függvény használata		A használatával materialize()kapcsolatos további információkért lásd: materialize(). További információ: Elnevezett kifejezéseket használó lekérdezések optimalizálása.
Konverziók alkalmazása több mint 1 milliárd rekordra	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 esetén a GB-k visszaadhatják az eredményeket az ügyfélnek, ami lassú választ és egy forgalmas fürtöt eredményez.
Kis- és nagybetűk megkülönböztetése	A Col =~ "lowercasestring" használata	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 megkülönböztetését.
Szűrés oszlopokra	Szűrjön egy táblázatoszlopra.	Számított oszlopra ne szűrjön.
	A T | where predicate(*Expression*) használata	Ne használja T | extend _value = *Expression* | where predicate(_value)
summarize operátor	Használja a hint.shufflekey=<billentyűt> , ha az group by keys összegző operátor nagy számossággal rendelkezik.		A magas számosság ideális esetben 1 millió felett van.
join operátor	Jelölje ki azt a táblát, amelynek kevesebb sora lesz az első (bal szélső a lekérdezésben).
	A bal oldali fél join helyett használjon in egyetlen oszlop szerinti szűrést.
Csatlakozás fürtök között	A fürtök között futtassa a lekérdezést az illesztés "jobb" oldalán, ahol az adatok nagy része található.
Csatlakozás, ha a bal oldal kicsi, a jobb oldal pedig nagy	A hint.strategy=broadcast használata		A kicsi legfeljebb 100 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 sikertelen lesz.
Csatlakozás, ha mindkét oldal túl nagy	A hint.shufflekey=<key> használata		Akkor használja, ha az illesztőkulcs nagy számossággal rendelkezik.
Értékek kinyerése az oszlopból azonos formátumú vagy mintázatú sztringekkel	Az elemzési operátor használata	Ne használjon több extract() utasítást.	Például az olyan értékeket, mint a "Time = <time>, ResourceId = <resourceId>, Duration = <duration>, ...."
extract() függvény	Akkor használja, ha az elemzett 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	Küldje le az összes lehetséges operátort, amely csökkenti a materializált adathalmazt, és továbbra is megőrzi a lekérdezés szemantikáját.		Például a szűrők vagy a projekt csak kötelező oszlopokat igényelnek. További információ: Elnevezett kifejezéseket használó lekérdezések optimalizálása.
Materializált nézetek használata	Materializált nézetek használata 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 feldolgozott adatok mennyiségének csökkentése

A lekérdezés teljesítménye közvetlenül a feldolgozandó adatok mennyiségétől függ. Minél kevesebb adatot dolgoz fel a rendszer, 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

Az alábbi vita során fontos szem előtt tartani a szűrési szelektivitá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, ami csökkenti a hatékonyan feldolgozandó adatok mennyiségét.

Fontossági sorrendben:

• Csak olyan táblákra hivatkozzon, amelyekre a lekérdezésnek szüksége van. Ha például az union operátort helyettesítő táblahivatkozásokkal használja, 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 egy 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 biztosít az adatok eltávolítására a gyorsítótárazási szabályzat ( DataScope paraméter) alapján történő hatókörkezeléssel.

• 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 sorrendjének megfelelő használata (egyetlen operátorban vagy több egymást követő operátor esetén nem számít, hogy melyik) jelentős hatással lehet a lekérdezési teljesítményre az alábbiakban leírtak szerint.

• Először alkalmazza a teljes szegmens-predikátumokat. Ez azt jelenti, hogy először a extent_id() függvényt használó predikátumokat kell alkalmazni, csakúgy, mint a extent_tags() függvényt használó predikátumok, valamint a tábla adatpartícióira (ha vannak definiálva) nagyon szelektív predikátumok.

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

• Ezután alkalmazzon olyan predikátumokat, amelyek a string és dynamic oszlopokat, különösen azokat az predikátumokat alkalmazzák, amelyek a kifejezés szintjén érvényesek. A predikátumokat a szelektivitásnak kell rendeznie (például egy felhasználói azonosító keresése, ha több millió felhasználó van, nagyon szelektív, és általában olyan kifejezéskeresés, amelynek az indexe nagyon hatékony.)

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

• Végül a táblaoszlopok adatait beolvasó lekérdezések esetében (például olyan predikátumok esetén, mint például a "@!@!" kifejezés, amely nem rendelkezik kifejezésekkel, és nem élvezi az indexelés előnyeit), rendezze a predikátumokat úgy, hogy a kevesebb adatot tartalmazó oszlopokat beolvasó predikátumok legyenek az elsők. Ez csökkenti a nagy oszlopok kibontására és vizsgálatára vonatkozó igényt.

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

Az entitásokra, például táblákra és materializált nézetekre név alapján hivatkozik a rendszer. A táblára T hivatkozhat például egyszerűen T (nem minősített név), vagy egy adatbázis-minősítő használatával (például database("DB").T ha a tábla egy nevű DBadatbázisban található), vagy egy teljes névvel (pl. cluster("X.Y.kusto.windows.net").database("DB").T).

Az alábbi okokból ajánlott elkerülni a névminősítések használatát, ha azok redundánsak:

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 (különösen akkor, ha ezek az adatbázisok egy másik fürtben találhatók).) A minősített nevek elkerülése segít az olvasónak abban, hogy helyesen járjon el.

Megjegyzés

Ez nem azt mondja, 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 egy, a hatókörben lévő adatbázishoz tartozó entitásra, és "rövidzárlat" a lekérdezésre, hogy az ne minősüljön fürtök közötti lekérdezésnek. Azonban azt javasoljuk, hogy ne támaszkodjon erre, ha nem szükséges, a fent megadott okokból.