Lekérdezési korlátok

  • Cikk

A Kusto egy alkalmi lekérdezési motor, amely nagy adatkészleteket üzemeltet, és az összes releváns adat memóriában tartásával megpróbálja kielégíteni a lekérdezéseket. Eredendően fennáll annak a kockázata, hogy a lekérdezések korlátok nélkül monopolizálják a szolgáltatás erőforrásait. A Kusto számos beépített védelmet biztosít alapértelmezett lekérdezési korlátok formájában. Ha el szeretné távolítani ezeket a korlátokat, először állapítsa meg, hogy ezzel valóban értéket szerez-e.

Kérelmek egyidejűségének korlátozása

A kérések egyidejűsége egy olyan korlát, amelyet egy fürt egyszerre futó több kérelemre is kivet.

  • A korlát alapértelmezett értéke attól a termékváltozattól függ, amelyen a fürt fut, és a következő módon lesz kiszámítva: Cores-Per-Node x 10.
    • Például egy olyan fürt esetében, amely a D14v2 termékváltozaton van beállítva, ahol minden gép 16 virtuális magot tartalmaz, az alapértelmezett korlát a 16 cores x10 = 160.
  • Az alapértelmezett érték a számítási feladatcsoport kérelemsebesség-korlátozási szabályzatánakdefault konfigurálásával módosítható.
    • A fürtön egyidejűleg futtatható kérések tényleges száma különböző tényezőktől függ. A legmeghatározóbb tényezők a fürt termékváltozata, a fürt rendelkezésre álló erőforrásai és a használati minták. A szabályzat az éles környezethez hasonló használati mintákon végzett terheléstesztek alapján konfigurálható.

További információkért lásd: Optimalizálás az Azure Data Explorer magas egyidejűségére.

Az eredményhalmaz méretének korlátozása (eredmény csonkolása)

Az eredmény csonkolása a lekérdezés által visszaadott eredményhalmazon alapértelmezés szerint beállított korlát. A Kusto az ügyfélnek visszaadott rekordok számát 500 000-re, a rekordok teljes adatméretét pedig 64 MB-ra korlátozza. Ha túllépi valamelyik korlátot, a lekérdezés "részleges lekérdezési hibával" meghiúsul. A teljes adatméret túllépése kivételt eredményez az üzenettel:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal data size limit 67108864 (E_QUERY_RESULT_SET_TOO_LARGE).'

A rekordok számának túllépése a következő kivétellel meghiúsul:

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal record count limit 500000 (E_QUERY_RESULT_SET_TOO_LARGE).'

Ennek a hibának a kezelésére több stratégia is létezik.

  • Csökkentse az eredményhalmaz méretét úgy, hogy úgy módosítja a lekérdezést, hogy csak érdekes adatokat adjon vissza. Ez a stratégia akkor hasznos, ha a kezdeti sikertelen lekérdezés túl "széles". A lekérdezés például nem vet ki olyan adatoszlopokat, amelyekre nincs szükség.
  • Csökkentse az eredményhalmaz méretét úgy, hogy a lekérdezés utáni feldolgozást, például az összesítéseket a lekérdezésbe alakítja át. A stratégia olyan helyzetekben hasznos, amikor a lekérdezés kimenete egy másik feldolgozási rendszerbe van etetve, és ez más összesítéseket is végez.
  • Ha nagy adatkészleteket szeretne exportálni a szolgáltatásból, váltson lekérdezésekről adatexportálás használatára.
  • Kérje meg a szolgáltatást, hogy tiltsa le ezt a lekérdezési korlátot az alább felsorolt utasítások vagy az ügyfélkérés tulajdonságaiban szereplő jelzők használatávalset.

A lekérdezés által előállított eredményhalmaz méretének csökkentésére szolgáló módszerek a következők:

Az eredmény csonkítását a notruncation kérelem lehetőséggel tilthatja le. Javasoljuk, hogy a korlátozás valamilyen formáját továbbra is érvényben legyen.

Például:

set notruncation;
MyTable | take 1000000

Az eredmények csonkításának pontosabb szabályozása is lehetséges az érték truncationmaxsize (maximális adatméret bájtban, alapértelmezett érték: 64 MB) és truncationmaxrecords (rekordok maximális száma, alapértelmezés szerint 500 000). A következő lekérdezés például 1105 rekordnál vagy 1 MB-nál állítja be az eredmény csonkítását, attól függően, hogy melyiket lépi túl a rendszer.

set truncationmaxsize=1048576;
set truncationmaxrecords=1105;
MyTable | where User=="UserId1"

Az eredmény csonkítási korlátjának eltávolítása azt jelenti, hogy tömeges adatokat szeretne áthelyezni a Kusto-ból.

Az eredmény csonkítási korlátját az paranccsal vagy későbbi összesítéssel távolíthatja el exportálás céljából .export . Ha a későbbi összesítést választja, fontolja meg az összesítést a Kusto használatával.

A Kusto számos olyan ügyfélkódtárat biztosít, amelyek képesek kezelni a "végtelenül nagy" eredményeket a hívónak való streameléssel. Használja ezeket a kódtárakat, és konfigurálja streamelési módra. Használja például a .NET-keretrendszer-ügyfelet (Microsoft.Azure.Kusto.Data), és állítsa a kapcsolati karakterlánc streamelési tulajdonságát true (igaz) értékre, vagy használja az ExecuteQueryV2Async() hívást, amely mindig streameli az eredményeket. Az ExecuteQueryV2Async() használatát a HelloKustoV2 alkalmazás ismerteti.

A C#-streamelési mintaalkalmazás is hasznos lehet.

Az eredmény csonkolása alapértelmezés szerint nem csak az ügyfélnek visszaadott eredménystreamre vonatkozik. Alapértelmezés szerint minden olyan albekérdezésre is alkalmazva van, amelyet az egyik fürt egy fürtközi lekérdezésben egy másik fürtnek ad ki, hasonló hatásokkal.

Több találat csonkítási tulajdonságának beállítása

Az alábbiak az utasítások használatakor set és/vagy az ügyfélkérés tulajdonságaiban lévő jelölők megadásakor érvényesek.

  • Ha notruncation be van állítva, és a truncationmaxsize, truncationmaxrecordsvagy query_take_max_records bármelyike is be van állítva, notruncation akkor a rendszer figyelmen kívül hagyja.
  • Ha truncationmaxsizea , truncationmaxrecords és/vagy query_take_max_records többször van beállítva , akkor az egyes tulajdonságok alacsonyabb értéke lesz érvényes.

A lekérdezési operátorok által felhasznált memória korlátozása (E_RUNAWAY_QUERY)

A Kusto korlátozza azt a memóriát, amelyet az egyes lekérdezési operátorok felhasználhatnak az "elszabadult" lekérdezések elleni védelemhez. Ezt a korlátot egyes lekérdezési operátorok, például join a és summarizea elérhetik, amelyek jelentős mennyiségű adatot tartanak a memóriában. Alapértelmezés szerint a korlát 5 GB (fürtcsomópontonként), és a kérelem beállításával maxmemoryconsumptionperiteratornövelhető:

set maxmemoryconsumptionperiterator=68719476736;
MyTable | summarize count() by Use

Ha eléri ezt a korlátot, részleges lekérdezési hiba jelenik meg a következő szöveget E_RUNAWAY_QUERYtartalmazó üzenettel: .

The ClusterBy operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete E_RUNAWAY_QUERY.

The DemultiplexedResultSetCache operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The ExecuteAndCache operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The HashJoin operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The Sort operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The Summarize operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The TopNestedAggregator operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

The TopNested operator has exceeded the memory budget during evaluation. Results may be incorrect or incomplete (E_RUNAWAY_QUERY).

Ha maxmemoryconsumptionperiterator többször van beállítva, például az ügyfélkérés tulajdonságaiban és egy set utasítás használatával, az alacsonyabb érték lesz érvényes.

Egy további korlát, amely részleges lekérdezési hibát válthat ki E_RUNAWAY_QUERY , az egyetlen operátor által tárolt sztringek maximális halmozott méretének korlátja. Ezt a korlátot a fenti kérési lehetőség nem bírálhatja felül:

Runaway query (E_RUNAWAY_QUERY). Aggregation over string column exceeded the memory budget of 8GB during evaluation.

Ha túllépi ezt a korlátot, a megfelelő lekérdezési operátor valószínűleg egy join, summarizevagy make-series. A korlát megkerüléséhez módosítsa a lekérdezést úgy, hogy az elosztási lekérdezési stratégiát használja. (Ez valószínűleg javítja a lekérdezés teljesítményét is.)

A minden esetben egy további lehetőség (a korlát növelésén túl a kérési beállítás beállításával és a lekérdezés elosztási E_RUNAWAY_QUERYstratégia használatára történő módosításával) a mintavételezésre való váltás. Az alábbi két lekérdezés bemutatja, hogyan kell elvégezni a mintavételezést. Az első lekérdezés egy statisztikai mintavételezés egy véletlenszerű számgenerátor használatával. A második lekérdezés a determinisztikus mintavételezés, amelyet az adathalmaz néhány oszlopának kivonatolásával végeznek, általában valamilyen azonosítóval.

T | where rand() < 0.1 | ...

T | where hash(UserId, 10) == 1 | ...

Memóriakorlát csomópontonként

A lekérdezésenkénti maximális memóriacsomópontonként egy másik korlát, amellyel védelmet lehet biztosítani az "elszabadult" lekérdezések ellen. Ez a kérelembeállítás max_memory_consumption_per_query_per_nodeáltal képviselt korlát felső határt állít be az adott lekérdezés egyetlen csomópontján használható memória mennyiségére vonatkozóan.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Ha max_memory_consumption_per_query_per_node többször van beállítva, például az ügyfélkérés tulajdonságaiban és egy set utasítás használatával, az alacsonyabb érték lesz érvényes.

Ha a lekérdezés , joinvagy make-series operátort használsummarize, az elosztási lekérdezési stratégiával csökkentheti a memóriaterhelést egyetlen gépen.

Végrehajtási időtúllépés korlátozása

A kiszolgálói időtúllépés szolgáltatásoldali időtúllépés, amely az összes kérelemre érvényes. A futó kérések (lekérdezések és felügyeleti parancsok) időtúllépése a Kusto több pontján van kényszerítve:

  • ügyfélkódtár (ha használják)
  • a kérést elfogadó szolgáltatásvégpont
  • a kérést feldolgozó szervizmotor

Alapértelmezés szerint az időtúllépés négy percre van állítva a lekérdezések esetében, és 10 percre a felügyeleti parancsok esetében. Ez az érték szükség esetén növelhető (egy órán belül leképezve).

  • A különböző ügyféleszközök támogatják az időtúllépés módosítását a globális vagy kapcsolatonkénti beállítások részeként. A Kusto.Explorerben például használja az Eszközök>beállításai* >Kapcsolatok>lekérdezési kiszolgáló időtúllépése lehetőséget.
  • Az SDK-k programozott módon támogatják az időtúllépés beállítását a servertimeout tulajdonságon keresztül. A .NET SDK-ban például ez egy ügyfélkérési tulajdonságon keresztül történik, egy típusú System.TimeSpanérték beállításával.

Megjegyzések az időtúllépésekről

  • Az ügyféloldalon a rendszer az időtúllépést alkalmazza a létrehozás alatt álló kérésből addig, amíg a válasz meg nem érkezik az ügyfélhez. Az ügyfél hasznos adatainak visszaolvasásához szükséges idő nem lesz az időtúllépés részeként kezelve. Ez attól függ, hogy a hívó milyen gyorsan húzza le az adatokat a streamből.
  • Az ügyféloldalon a ténylegesen használt időtúllépési érték valamivel magasabb, mint a felhasználó által kért kiszolgálói időtúllépési érték. Ez a különbség a hálózati késések engedélyezése.
  • Az engedélyezett maximális kérelem-időtúllépés automatikus használatához állítsa az ügyfélkérés tulajdonságát norequesttimeout értékre true.

Megjegyzés

Tekintse meg az időtúllépési korlátok beállításáról szóló részletes útmutatót, amely bemutatja, hogyan állíthat be időtúllépéseket az Azure Data Explorer webes felhasználói felületén, a Kusto.Explorerben, a Kusto.Cli-ben, a Power BI-ban és az SDK használatakor.

A lekérdezési CPU-erőforrás használatának korlátozása

A Kusto lehetővé teszi, hogy lekérdezéseket futtasson, és annyi CPU-erőforrást használjon, amennyit a fürt használ. A lekérdezések között ciklikus időszeletelést kísérel meg végrehajtani, ha egynél több fut. Ez a metódus a legjobb teljesítményt nyújtja a lekérdezés által definiált függvényekhez. Máskor érdemes lehet korlátozni az adott lekérdezéshez használt CPU-erőforrásokat. Ha például "háttérfeladatot" futtat, a rendszer nagyobb késéseket tűrhet, hogy az egyidejű beágyazott lekérdezések elsőbbséget élvezhessenek.

A Kusto két kérelemtulajdonság megadását támogatja lekérdezés futtatásakor. A tulajdonságok query_fanout_threads_percent és query_fanout_nodes_percent. Mindkét tulajdonság olyan egész szám, amely alapértelmezés szerint a maximális értékre (100) vonatkozik, de egy adott lekérdezés esetében más értékre csökkenthető.

Az első, query_fanout_threads_percent vezérli a szálhasználat fanout tényezőt. Ha ezt a tulajdonságot 100%-ban állítja be, a fürt minden csomóponthoz hozzárendeli az összes CPU-t. Például egy Azure D14-csomópontokon üzembe helyezett fürtön 16 CPU. Ha ez a tulajdonság 50%-ra van állítva, akkor a processzorok fele lesz használatban, és így tovább. A számok egy teljes CPU-ra vannak kerekítettek, így biztonságosan 0-ra lehet állítani a tulajdonságértéket.

A második, query_fanout_nodes_percent szabályozza, hogy a fürtben hány lekérdezési csomópontot használjon a lekérdezési elosztási műveletenként. Hasonló módon működik.

Ha query_fanout_nodes_percent vagy query_fanout_threads_percent többször van beállítva, például az ügyfélkérés tulajdonságaiban és egy set utasításban is, az egyes tulajdonságoknál az alacsonyabb érték érvényes.

A lekérdezések összetettségének korlátozása

A lekérdezés végrehajtása során a lekérdezés szövege a lekérdezést jelképező relációs operátorok fájává alakul át. Ha a famélység meghaladja a belső küszöbértéket, a lekérdezés túl összetettnek minősül a feldolgozáshoz, és hibakóddal meghiúsul. A hiba azt jelzi, hogy a relációs operátorok fája meghaladja a korlátait.

Az alábbi példák olyan gyakori lekérdezési mintákat mutatnak be, amelyek miatt a lekérdezés túllépheti ezt a korlátot, és meghiúsulhat:

  • az összeláncolt bináris operátorok hosszú listája. Például:
T 
| where Column == "value1" or 
        Column == "value2" or 
        .... or
        Column == "valueN"

Ebben az esetben írja át a lekérdezést az in() operátorral.

T 
| where Column in ("value1", "value2".... "valueN")
  • egy olyan lekérdezés, amely túl széles sémaelemzést futtató union operátorral rendelkezik, különösen azért, mert az unió alapértelmezett íze a "külső" uniós séma visszaadása (ami azt jelenti, hogy a kimenet tartalmazza az alapul szolgáló tábla összes oszlopát).

Ebben az esetben az a javaslat, hogy tekintse át a lekérdezést, és csökkentse a lekérdezés által használt oszlopokat.

Kapcsolódó tartalom