Limity dotazů

  • Článek

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

Omezení souběžnosti požadavků

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

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

Další informace najdete v tématu Optimalizace vysoké souběžnosti s Azure Data Explorer.

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 pro tyto záznamy na 64 MB. Při překročení některého z těchto limitů dotaz selže s částečným selháním 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).'

Pro řešení této chyby existuje několik strategií.

  • Zmenšete velikost sady výsledků úpravou dotazu tak, aby vracel jenom zajímavá data. Tato strategie je užitečná, pokud je počáteční neúspěšný dotaz příliš "široký". Dotaz například nepromítá sloupce dat, které nejsou potřeba.
  • Zmenšete velikost sady výsledků tím, že přesunete 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 předá jinému systému zpracování a ten pak provádí další agregace.
  • Pokud chcete exportovat velké sady dat ze služby, přepněte z dotazů na použití exportu dat.
  • Požádejte službu, aby potlačila tento limit dotazu pomocí set příkazů uvedených níže nebo příznaků ve vlastnostech požadavků klienta.

Mezi metody pro zmenšení velikosti sady výsledků vytvořené dotazem patří:

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

Příklad:

set notruncation;
MyTable | take 1000000

Je také možné mít přesnější kontrolu nad zkrácením výsledků nastavením hodnot 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). Následující dotaz například 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 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 .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 .

Může se vám také hodit ukázková aplikace pro příjem dat streamování v jazyce C#.

Zkrácení výsledku se ve výchozím nastavení používá nejen u výsledného datového proudu vráceného klientovi. Ve výchozím nastavení se také použije pro všechny poddotazy, které jeden cluster vydá na jiný cluster v dotazu mezi clustery, 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žadavků klienta.

  • Pokud notruncation je nastavená hodnota a některé z truncationmaxsizehodnot , truncationmaxrecordsnebo query_take_max_records jsou také nastaveny, notruncation se ignorují.
  • Pokud jsou a/nebo query_take_max_records nastaveny vícekrát, platí pro každou vlastnost nižší hodnota.truncationmaxsizetruncationmaxrecords

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

Kusto omezuje paměť, kterou může každý operátor dotazu využívat, aby chránil před "runaway" dotazy. Tohoto limitu můžou dosáhnout některé operátory dotazů, například join a summarize, které fungují tak, že v paměti uchovávají významná data. Ve výchozím nastavení je limit 5 GB (na uzel clusteru) a můžete ho zvýšit nastavením možnosti maxmemoryconsumptionperiteratorpožadavku:

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

Při dosažení tohoto limitu se vygeneruje částečná chyba dotazu 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 E_RUNAWAY_QUERY , který může způsobit částečné selhání dotazu, je omezení maximální kumulované velikosti řetězců uchovávaných jedním operátorem. Výše uvedená možnost požadavku nemůže tento limit přepsat:

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 s největší pravděpodobností relevantním operátorem joindotazu , summarizenebo make-series. Pokud chcete tento limit obejít, měli byste upravit dotaz tak, aby používal strategii prohazování dotazů . (Tím se také pravděpodobně zlepší výkon dotazu.)

Ve všech případech E_RUNAWAY_QUERYje další možností (kromě zvýšení limitu nastavením možnosti požadavku a změnou dotazu tak, aby používal strategii prohazování) přechod na vzorkování. Následující dva dotazy ukazují, jak vzorkování provést. První dotaz je statistický vzorkování pomocí generátoru náhodných čísel. Druhý dotaz je deterministické vzorkování, které se provádí hashováním některého sloupce z datové sady, obvykle nějaké ID.

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

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

Omezení paměti na uzel

Maximální paměť na 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 velikosti 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 , můžete pomocí strategie prohazování dotazů snížit zatížení paměti na jednom počítači.

Limit časového limitu spuštění

Časový limit serveru je časový limit na straně služby, který se vztahuje na všechny požadavky. Časový limit spuštěných požadavků (dotazů a příkazů pro správu) se vynucuje ve více 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 nastavený na čtyři minuty pro dotazy 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í pro jednotlivá připojení. Například v Kusto.Exploreru použijte Možnosti nástrojů>*>Vypršení>časového limitu dotazovacího serveru připojení.
  • 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 od vytvářeného požadavku až do okamžiku, kdy do klienta začne docházet odpověď. Doba potřebná ke zpětnému načtení datové části v klientovi není považována za součást časového limitu. Záleží na tom, jak rychle volající načítá data ze streamu.
  • Také na straně klienta je skutečná použitá hodnota časového limitu o něco vyšší než hodnota časového limitu serveru požadovaná uživatelem. Tento rozdíl spočívá v tom, že umožňuje latenci sítě.
  • Pokud chcete automaticky použít maximální povolený časový limit požadavku, nastavte vlastnost norequesttimeout žádosti klienta na true.

Poznámka

Podrobného průvodce nastavením časových limitů ve webovém uživatelském rozhraní Azure Data Explorer, Kusto.Exploreru, Kusto.Cli, Power BI a při použití sady SDK najdete v tématu Nastavení časových limitů.

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

Kusto umožňuje spouštět dotazy a používat tolik prostředků procesoru, kolik má cluster. Pokusí se provést spravedlivé kruhové dotazování mezi dotazy, pokud je spuštěno více než jeden. 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í", může systém tolerovat vyšší latenci, aby souběžným vloženým dotazům přidělil vysokou prioritu.

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á mají výchozí 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 nastavená na 100 %, cluster přiřadí všechny procesory na každém uzlu. Například 16 procesorů v clusteru nasazených v uzlech Azure D14. Pokud je tato vlastnost nastavená na 50 %, použije se 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, řídí, kolik uzlů dotazu v clusteru 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, platí nižší hodnota pro každou vlastnost.

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čí interní 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 své limity.

Následující příklady ukazují běžné vzory dotazů, které můžou způsobit, že dotaz překročí tento limit a selže:

  • dlouhý seznam binárních operátorů, které jsou zřetězené. 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á operátor sjednocení, který provádí příliš širokou analýzu schématu, zejména že výchozí příchuť sjednocení je vrátit "vnější" sjednocovací schéma (to znamená , že výstup bude zahrnovat všechny sloupce podkladové tabulky).

V tomto případě se doporučuje zkontrolovat dotaz a omezit počet sloupců, které dotaz používá.

Související obsah