Limity dotazů

Platí pro: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel

Kusto je ad hoc dotazovací stroj, který hostuje velké datové sady a snaží se uspokojovat dotazy tím, že obsahuje všechna relevantní data v paměti. Existuje vlastní riziko, že dotazy budou monopolizovat prostředky služeb bez hranic. Kusto poskytuje několik předdefinovaných ochrany ve formě výchozích limitů dotazů. Pokud zvažujete odebrání těchto limitů, nejprve určete, jestli tím skutečně získáte nějakou hodnotu.

Omezení souběžnosti požadavků

Souběžnost požadavků je limit, který je kladen na několik požadavků spuštěných současně.

• Výchozí hodnota limitu závisí na SKU, na které databáze běží, a vypočítá se takto: Cores-Per-Node x 10.
  • Například pro databázi, která je nastavená na SKU D14v2, kde každý počítač má 16 virtuálních jader, je 16 cores x10 = 160výchozí limit .
• Výchozí hodnotu je možné změnit konfigurací zásad default omezení četnosti požadavků skupiny úloh.
  • Skutečný počet požadavků, které se dají spustit souběžně v databázi, závisí na různých faktorech. Mezi nejdůležitější faktory patří skladová položka databáze, dostupné prostředky databáze a vzory využití. Zásady je možné nakonfigurovat na základě zátěžových testů provedených ve vzorech použití podobných produkčním prostředí.

Omezení velikosti sady výsledků (zkrácení výsledku)

Zkrácení výsledku je limit nastavený ve výchozím nastavení pro sadu výsledků vrácenou dotazem. Kusto omezuje počet záznamů vrácených klientovi na 500 000 a celkovou velikost dat těchto záznamů na 64 MB. Pokud dojde k překročení některého z těchto limitů, dotaz selže s "částečnou chybou dotazu". Překročení celkové velikosti dat vygeneruje výjimku se zprávou:

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).'

Překročení počtu záznamů selže s výjimkou, která říká:

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).'

Existuje několik strategií pro řešení této chyby.

• Zmenšete velikost sady výsledků úpravou dotazu tak, aby vracela jenom zajímavá data. Tato strategie je užitečná, když je počáteční neúspěšný dotaz příliš široký. Dotaz například neprojektuje datové sloupce, které nejsou potřeba.
• Zmenšete velikost sady výsledků tak, že posunete zpracování po dotazu, například agregace, do samotného dotazu. Strategie je užitečná ve scénářích, kdy se výstup dotazu odesílá do jiného systému zpracování a pak provádí další agregace.
• Pokud chcete exportovat velké sady dat ze služby, přepněte z dotazů na použití exportu dat.
• Dejte službě pokyn, aby potlačit tento limit dotazů pomocí set příkazů uvedených níže nebo příznaků ve vlastnostech požadavku klienta.

Metody pro zmenšení velikosti sady výsledků vytvořené dotazem zahrnují:

• Použijte skupinu operátoru sumarizace a agregujte u podobných záznamů ve výstupu dotazu. Potenciálně můžete vzorek některých sloupců pomocí take_any agregační funkce.
• Pomocí operátoru take můžete vzorek výstupu dotazu.
• Pomocí funkce podřetězce můžete oříznout široké volné textové sloupce.
• Pomocí operátoru projektu můžete ze sady výsledků odstranit libovolný nezajímavý sloupec.

Zkrácení výsledku notruncation můžete zakázat pomocí možnosti požadavku. Doporučujeme, aby byla stále zavedena určitá forma omezení.

Příklad:

set notruncation;
MyTable | take 1000000

Pomocí nastavení hodnoty truncationmaxsize (maximální velikost dat v bajtech, výchozí hodnota je 64 MB) a truncationmaxrecords (maximální počet záznamů, výchozí hodnota je 500 000). Například následující dotaz nastaví zkrácení výsledku na 1 105 záznamů nebo 1 MB podle toho, co je překročeno.

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

Odebrání limitu zkrácení výsledku znamená, že máte v úmyslu přesunout hromadná data z Kusto.

Limit zkrácení výsledku můžete odebrat buď pro účely exportu .export , pomocí příkazu nebo pro pozdější agregaci. Pokud zvolíte pozdější agregaci, zvažte agregaci pomocí Kusto.

Kusto poskytuje řadu klientských knihoven, které můžou zpracovávat "nekonečné velké" výsledky jejich streamováním do volajícího. Použijte jednu z těchto knihoven a nakonfigurujte ji do režimu streamování. Použijte například klienta rozhraní .NET Framework (Microsoft.Azure.Kusto.Data) a buď nastavte vlastnost streamování připojovací řetězec na true, nebo použijte volání ExecuteQueryV2Async(), které vždy streamuje výsledky. Příklad použití ExecuteQueryV2Async() najdete v aplikaci HelloKustoV2 .

Ukázkovou aplikaci pro příjem dat streamování v C# můžete najít také užitečnou.

Zkrácení výsledku se ve výchozím nastavení použije nejen u výsledného datového proudu vráceného klientovi.

Ve výchozím nastavení se také použije u každého poddotazu, který jeden eventhouse vydá do jiného eventhouse v dotazu mezi událostmi, s podobnými účinky.

Nastavení více vlastností zkrácení výsledků

Následující platí při použití set příkazů a/nebo při zadávání příznaků ve vlastnostech požadavku klienta.

• Je-li notruncation nastavena a některá z truncationmaxsize, truncationmaxrecordsnebo query_take_max_records jsou také nastavena - notruncation je ignorována.
• truncationmaxrecords Pokud truncationmaxsizea/nebo query_take_max_records jsou nastaveny vícekrát - nižší hodnota pro každou vlastnost platí.

Omezení paměti spotřebované operátory dotazů (E_RUNAWAY_QUERY)

Kusto omezuje paměť, kterou může každý operátor dotazu využívat k ochraně před "runaway" dotazy. K tomuto limitu může dojít u některých operátorů dotazů, jako join jsou například operátory summarizedotazů, které pracují tím, že uchovávají významná data v paměti. Ve výchozím nastavení je limit 5 GB (na uzel) a dá se zvýšit nastavením možnosti maxmemoryconsumptionperiteratorpožadavku:

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

Po dosažení tohoto limitu se částečná chyba dotazu vygeneruje se zprávou, která obsahuje text E_RUNAWAY_QUERY.

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).

Pokud maxmemoryconsumptionperiterator je nastavena vícekrát, například ve vlastnostech požadavku klienta a pomocí set příkazu, platí nižší hodnota.

Dalším limitem, který může aktivovat E_RUNAWAY_QUERY částečné selhání dotazu, je omezení maximální kumulované velikosti řetězců uchovávané jedním operátorem. Tento limit nelze přepsat výše uvedenou možností požadavku:

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

Při překročení tohoto limitu je nejpravděpodobnějším operátorem joindotazu operátor , summarizenebo make-series. Pokud chcete tento limit obejít, měli byste upravit dotaz tak, aby používal strategii dotazu náhodného prohazování. (To také pravděpodobně zlepší výkon dotazu.)

Ve všechpřípadechch E_RUNAWAY_QUERY Následující dva dotazy ukazují, jak provést vzorkování. Prvním dotazem je statistický vzorkování pomocí generátoru náhodných čísel. Druhý dotaz je deterministický vzorkování, které provádí hashováním některého sloupce z datové sady, obvykle určitého ID.

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

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

Omezení paměti na uzel

Maximální paměť na jeden dotaz na uzel je dalším limitem, který se používá k ochraně před "runaway" dotazy. Tento limit reprezentovaný možností max_memory_consumption_per_query_per_nodepožadavku nastaví horní mez množství paměti, kterou lze použít na jednom uzlu pro konkrétní dotaz.

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

Pokud max_memory_consumption_per_query_per_node je nastavena vícekrát, například ve vlastnostech požadavku klienta a pomocí set příkazu, platí nižší hodnota.

Pokud dotaz používá summarizeoperátory , joinnebo make-series operátory, můžete použít strategii pro náhodné dotazování ke snížení zatížení paměti na jednom počítači.

Omezení časového limitu provádění

Časový limit serveru je časový limit na straně služby, který se použije pro všechny požadavky. Časový limit pro spouštění požadavků (dotazy a příkazy pro správu) se vynucuje v několika bodech kusto:

• klientská knihovna (pokud se používá)
• koncový bod služby, který přijímá požadavek
• modul služeb, který zpracovává požadavek

Ve výchozím nastavení je časový limit pro dotazy nastavený na čtyři minuty a 10 minut pro příkazy pro správu. Tuto hodnotu je možné v případě potřeby zvýšit (omezena na jednu hodinu).

• Různé klientské nástroje podporují změnu časového limitu v rámci globálního nastavení nebo nastavení připojení. Například v Kusto.Exploreru použijte možnosti nástrojů>* >>Vypršení časového limitu dotazovacího serveru.
• Sady SDK prostřednictvím kódu programu podporují nastavení časového limitu servertimeout prostřednictvím vlastnosti. Například v sadě .NET SDK se to provádí prostřednictvím vlastnosti požadavku klienta nastavením hodnoty typu System.TimeSpan.

Poznámky k vypršení časových limitů

• Na straně klienta se časový limit použije z požadavku, který se vytvoří, dokud se odpověď nespustí do klienta. Čas potřebný ke čtení datové části zpět v klientovi není považován za součást časového limitu. Záleží na tom, jak rychle volající načte data z datového proudu.
• Na straně klienta je použitá skutečná hodnota časového limitu mírně vyšší než hodnota časového limitu serveru požadovaná uživatelem. Tento rozdíl spočívá v povolení latencí sítě.
• Pokud chcete automaticky použít maximální povolený časový limit požadavku, nastavte vlastnost norequesttimeout požadavku klienta na truehodnotu .

Omezení využití prostředků procesoru dotazů

Kusto umožňuje spouštět dotazy a používat všechny dostupné prostředky procesoru, které databáze obsahuje. Pokusí se provést spravedlivé kruhové dotazování mezi dotazy, pokud je spuštěno více než jedno. Tato metoda poskytuje nejlepší výkon pro funkce definované dotazem. Jindy můžete chtít omezit prostředky procesoru používané pro konkrétní dotaz. Pokud například spustíte úlohu na pozadí, systém může tolerovat vyšší latenci, aby souběžné vložené dotazy byly vysoce prioritní.

Kusto podporuje zadání dvou vlastností požadavku při spuštění dotazu. Vlastnosti jsou query_fanout_threads_percent a query_fanout_nodes_percent. Obě vlastnosti jsou celá čísla, která ve výchozím nastavení mají maximální hodnotu (100), ale u konkrétního dotazu se můžou snížit na jinou hodnotu.

První query_fanout_threads_percent řídí faktor fanout pro použití vlákna. Pokud je tato vlastnost nastavena 100 %, všechny procesory budou přiřazeny na každém uzlu. Například 16 procesorů nasazených na uzlech Azure D14. Pokud je tato vlastnost nastavena na 50 %, bude použita polovina procesorů atd. Čísla se zaokrouhlují nahoru na celý procesor, takže je bezpečné nastavit hodnotu vlastnosti na 0.

Druhý query_fanout_nodes_percent určuje, kolik uzlů dotazu se má použít pro každou operaci distribuce poddotazů. Funguje podobným způsobem.

Pokud query_fanout_nodes_percent nebo query_fanout_threads_percent jsou nastaveny vícekrát, například ve vlastnostech požadavku klienta a pomocí set příkazu – nižší hodnota pro každou vlastnost platí.

Omezení složitosti dotazů

Během provádění dotazu se text dotazu transformuje na strom relačních operátorů představujících dotaz. Pokud hloubka stromu překročí vnitřní prahovou hodnotu, dotaz se považuje za příliš složitý pro zpracování a selže s kódem chyby. Selhání značí, že strom relačních operátorů překračuje jeho limity.

Následující příklady ukazují běžné vzory dotazů, které můžou způsobit překročení tohoto limitu a selhání dotazu:

• dlouhý seznam binárních operátorů, které jsou zřetězené dohromady. Příklad:

T
| where Column == "value1" or
        Column == "value2" or
        .... or
        Column == "valueN"

V tomto konkrétním případě přepište dotaz pomocí operátoru in() .

T
| where Column in ("value1", "value2".... "valueN")

• dotaz, který má sjednocovací operátor, který spouští příliš širokou analýzu schématu, zejména proto, že výchozí variantou sjednocení je vrácení "vnějšího" sjednocovacího schématu (což znamená, že výstup bude obsahovat všechny sloupce podkladové tabulky).

Návrhem v tomto případě je zkontrolovat dotaz a snížit počet sloupců používaných dotazem.

Související obsah

• Osvědčené postupy pro dotazy