Sdílet prostřednictvím

Osvědčené postupy pro vyhrazené fondy SQL v Azure Synapse Analytics

Tento článek obsahuje kolekci osvědčených postupů, které vám pomůžou dosáhnout optimálního výkonu vyhrazených fondů SQL ve službě Azure Synapse Analytics. Pokud pracujete s bezserverovými fondy SQL, vizte osvědčené postupy pro bezserverové fondy SQL, kde najdete konkrétní pokyny. Níže najdete základní pokyny a důležité oblasti, na které se při vytváření řešení zaměříte. Každá část vás seznámí s konceptem a pak vás nasměří na podrobnější články, které tento koncept podrobněji popisují.

Načítání vyhrazených fondů SQL

Pokyny k načítání vyhrazených fondů SQL najdete v pokynech k načítání dat.

Snižte náklady pomocí pozastavení a škálování

Další informace o snížení nákladů prostřednictvím pozastavení a škálování najdete v tématu Správa výpočetních prostředků.

Udržujte statistiky

Vyhrazený fond SQL je možné nakonfigurovat tak, aby automaticky detekoval a vytvářel statistiky sloupců. Plány dotazů vytvořené optimalizátorem jsou stejně dobré jako dostupné statistiky.

Doporučujeme povolit AUTO_CREATE_STATISTICS pro vaše databáze a udržovat statistiky aktualizované denně nebo po každém načtení, abyste zajistili, že jsou statistiky sloupců používaných v dotazech vždy aktuální.

Pokud chcete zkrátit dobu údržby statistik, vyberte, které sloupce mají statistiky nebo potřebují nejčastější aktualizaci. Například můžete chtít denně aktualizovat sloupce s datem, do kterých se mohou přidávat nové hodnoty. Zaměřte se na statistiky pro sloupce zapojené do spojení, sloupce používané v klauzuli WHERE a sloupce nalezené v GROUP BY.

Další informace o statistikách najdete v článcích Spravovat statistiky tabulek, CREATE STATISTICS a UPDATE STATISTICS.

Ladění výkonu dotazů

Seskupujte příkazy INSERT do dávek

Jednorázové načtení do malé tabulky s příkazem INSERT, jako INSERT INTO MyLookup VALUES (1, 'Type 1')je například nejlepší přístup v závislosti na vašich potřebách. Pokud ale potřebujete v průběhu dne načíst tisíce nebo miliony řádků, je pravděpodobné, že jednotlivé INSERT příkazy nejsou optimální volbou.

Jedním ze způsobů, jak tento problém vyřešit, je vyvinout jeden proces, který zapisuje do souboru, a pak jiný proces, který bude tento soubor pravidelně načítat. Další informace najdete v článku INSERT .

Použijte PolyBase k rychlému načítání a exportu dat

Vyhrazený fond SQL podporuje načítání a export dat prostřednictvím několika nástrojů, mezi které patří Azure Data Factory, PolyBase a BCP. Pro malá množství dat, kde není výkon tak důležitý, by vám měl stačit libovolný nástroj.

Poznámka:

PolyBase je nejlepší volbou při načítání nebo exportu velkých objemů dat nebo potřebujete rychlejší výkon.

Úlohy funkce PolyBase můžete spustit pomocí příkazů CTAS nebo INSERT INTO. CTAS minimalizuje protokolování transakcí a je nejrychlejší způsob, jak načíst data. Azure Data Factory také podporuje načítání PolyBase a dokáže dosáhnout výkonu podobného CTAS. PolyBase podporuje různé formáty souborů, včetně souborů Gzip.

Pokud chcete maximalizovat propustnost při použití textových souborů Gzip, rozdělte soubory na 60 nebo více souborů, abyste maximalizovali paralelismus načítání. Pro rychlejší celkovou propustnost zvažte souběžné načítání dat. Další informace, které jsou relevantní pro tuto část, jsou uvedeny v následujících článcích:

Načtěte a následně dotazujte externí tabulky

PolyBase není optimální pro dotazy. Tabulky PolyBase pro dedikované fondy SQL aktuálně podporují pouze soubory Azure Blob a Azure Data Lake Storage. Tyto soubory nemají žádné výpočetní prostředky, které je zálohují. V důsledku toho vyhrazené fondy SQL nemohou tuto práci přesměrovat a musí načíst celý soubor do tempdb, aby mohly data přečíst.

Pokud máte několik dotazů na dotazování na tato data, je lepší tato data jednou načíst a použít místní tabulku. Další pokyny k PolyBase najdete v příručce k používání článku PolyBase .

Distribuujte velké tabulky hashováním

Ve výchozím nastavení jsou tabulky distribuovány metodou Round Robin. Tato výchozí možnost usnadňuje uživatelům vytváření tabulek, aniž by se museli rozhodnout, jak se mají jejich tabulky distribuovat. Tabulky typu Round Robin mohou být pro některé úlohy dostatečně výkonné. Ve většině případů ale distribuční sloupec poskytuje lepší výkon.

Nejčastějším příkladem, kdy tabulka distribuovaná podle sloupců překoná tabulku rozloženou kruhově, je situace, když jsou spojeny dvě velké tabulky faktů.

Pokud máte například tabulku objednávek distribuovanou order_id a tabulku transakcí distribuovanou také order_id, při spojení tabulky objednávek s tabulkou transakcí na order_id se tento dotaz stane předávacím dotazem. Operace přesunu dat se pak eliminují. Méně kroků znamená rychlejší dotaz. Méně přesunů dat také přispívá ke zrychlení dotazů.

Tip

Při načítání distribuované tabulky by se příchozí data neměla řadit podle distribučního klíče. Tím se zpomalí zatížení.

Níže uvedené odkazy na článek vám poskytnou další podrobnosti o zlepšení výkonu výběrem distribučního sloupce. V klauzuli WITH příkazu CREATE TABLE najdete také informace o tom, jak definovat distribuovanou tabulku:

Nepřehánějte dělení do oddílů

I když dělení dat může být efektivní pro údržbu vašich dat prostřednictvím přepínání partíc nebo optimalizace skenů odstraněním partíc, příliš mnoho partíc může zpomalit vaše dotazy. Strategie dělení s vysokou členitostí, která může dobře fungovat na SQL Serveru, nemusí dobře fungovat ve vyhrazeném fondu SQL.

Příliš mnoho oddílů může snížit efektivitu clusterovaných indexů columnstore, pokud má každý oddíl méně než 1 milion řádků. Vyhrazené fondy SQL automaticky rozdělují data do 60 databází. Pokud tedy vytvoříte tabulku s 100 oddíly, bude výsledkem 6 000 oddílů. Každá úloha se liší, takže nejlepší doporučení je experimentovat s dělením, abyste zjistili, co je pro vaši úlohu nejvhodnější.

Jednou z možností, jak zvážit, je použití členitosti, která je nižší než to, co jste implementovali pomocí SQL Serveru. Zvažte například použití týdenních nebo měsíčních particí místo denních particí.

Další informace o dělení najdete v článku o dělení tabulek.

Minimalizujte velikosti transakcí

Příkazy INSERT, UPDATE a DELETE se spouští v transakci. Když selžou, musí se vrátit zpět. Aby se snížila možnost dlouhého vrácení zpět, minimalizujte velikosti transakcí, kdykoli je to možné. Minimalizace velikostí transakcí je možné provést rozdělením příkazů INSERT, UPDATE a DELETE na části. Pokud máte například insert, který očekáváte, že bude trvat 1 hodinu, můžete rozdělit INSERT do čtyř částí. Každý běh bude následně zkrácen na 15 minut.

Tip

Pokud chcete snížit riziko vrácení zpět, použijte případy minimálního protokolování, jako CTAS, TRUNCATE, DROP TABLE nebo INSERT do prázdných tabulek.

Dalším způsobem, jak eliminovat rollbacky, je použít operace pouze s metadaty ke správě dat, například přepínání oddílů. Například místo provedení příkazu DELETE odstraňte všechny řádky v tabulce, ve které byl order_date v říjnu 2001, můžete data rozdělit měsíčně. Poté můžete oddíl s daty vyměnit za prázdný oddíl z jiné tabulky (viz příklady ALTER TABLE).

U tabulek, které nejsou rozdělené na oddíly, zvažte použití CTAS k zápisu dat, která chcete zachovat v tabulce, místo použití delete. Pokud CTAS trvá stejnou dobu, je mnohem bezpečnější spustit, protože má minimální protokolování transakcí a v případě potřeby ho můžete rychle zrušit.

Další informace o obsahu souvisejícím s touto částí najdete v následujících článcích:

Zmenšení velikostí výsledků dotazu

Omezení velikosti výsledků dotazů pomáhá vyhnout se problémům na straně klienta způsobeným velkými výsledky dotazů. Dotaz můžete upravit tak, aby se snížil počet vrácených řádků. Některé nástroje pro generování dotazů umožňují přidat do každého dotazu syntaxi "top N". Můžete také převést výsledek dotazu do dočasné tabulky pomocí CETAS a poté použít Export PolyBase pro další zpracování.

Použijte co nejmenší velikost sloupce

Při definování DDL použijte nejmenší datový typ, který bude podporovat vaše data. Tím se zlepší výkon dotazů. Toto doporučení je zvlášť důležité pro sloupce CHAR a VARCHAR. Pokud má nejdelší hodnota v sloupci 25 znaků, nadefinujte typ sloupce jako VARCHAR(25). Vyhněte se definování všech sloupců se znaky s velkou výchozí délkou. Kromě toho definujte sloupce jako VARCHAR, pokud je to vše potřebné místo použití NVARCHAR.

Pro podrobnější přehled základních konceptů relevantních pro výše uvedené informace si přečtěte články Přehled tabulek, Datové typy tabulek a CREATE TABLE.

Použijte dočasné tabulky hald pro přechodná data

Když dočasně ukládáte data do vyhrazených fondů SQL, haldy tabulek obecně zrychlují celkový proces. Pokud načítáte data pouze, aby byla připravena před spuštěním dalších transformací, načtení tabulky do bezhodnotové tabulky bude rychlejší než načtení dat do seskupené tabulky columnstore.

Načítání dat do dočasné tabulky se také načte mnohem rychleji než načtení tabulky do trvalého úložiště. Dočasné tabulky začínají znakem "#" a jsou přístupné pouze sezení, které je vytvořilo. V důsledku toho můžou fungovat pouze v omezených scénářích. Haldové tabulky se definují v klauzuli WITH příkazu CREATE TABLE. Pokud používáte dočasnou tabulku, nezapomeňte nad ní také vytvořit statistiky.

Další informace najdete v článcích Dočasné tabulky, CREATE TABLE a CREATE TABLE AS SELECT .

Optimalizujte clusterované columnstore tabulky

Clusterované indexy columnstore jsou jedním z nejúčinnějších způsobů, jak ukládat data ve vyhrazeném prostoru SQL. Ve výchozím nastavení se tabulky ve vyhrazeném fondu SQL vytvářejí jako Clustered ColumnStore. Pokud chcete dosáhnout co nejlepšího výkonu dotazů na tabulky columnstore, je důležité mít kvalitní segmenty. Když se při zatížení paměti řádky zapisují do tabulek columnstore, může tím utrpět kvalita segmentů columnstore.

Kvalitu segmentu lze měřit počtem řádků v komprimované skupině řádků. Podrobné pokyny k detekci a zlepšení kvality segmentů pro clusterované columnstore tabulky najdete v článku Tabulka indexů o Příčinách špatné kvality indexu columnstore.

Vzhledem k tomu, že segmenty columnstore s vysokou kvalitou jsou důležité, je vhodné použít ID uživatelů, kteří jsou ve střední nebo velké třídě prostředků pro načítání dat. Použití nižších jednotek datového skladu znamená, že chcete uživateli načítání přiřadit větší třídu prostředků.

Tabulky sloupcového úložiště obvykle nepřenášejí data do komprimovaného segmentu, dokud tabulka neobsahuje více než 1 milion řádků. Každá vyhrazená tabulka fondu SQL se distribuuje do 60 různých distribucí. Tabulky columnstore proto nebudou těžit z dotazu, pokud tabulka neobsahuje více než 60 milionů řádků.

Tip

Index columnstore nemusí být pro tabulky s méně než 60 miliony řádků optimálním řešením.

Pokud rozdělíte data, každý oddíl bude muset mít 1 milion řádků, aby mohl využívat clusterovaný index columnstore. V případě tabulky s 100 oddíly musí mít alespoň 6 miliard řádků, aby bylo možné využít clusterovaného úložiště sloupců (60 distribucí 100 oddílů 1 milion řádků).

Pokud tabulka neobsahuje 6 miliard řádků, máte dvě hlavní možnosti. Snižte počet oddílů, nebo zvažte použití tabulky typu halda. Také může být vhodné experimentovat, abyste zjistili, jestli je možné dosáhnout lepšího výkonu pomocí tabulky haldy se sekundárními indexy spíše než pomocí tabulky columnstore.

Při dotazování tabulky columnstore budou příkazy pracovat rychleji, pokud vyberete pouze sloupce, které potřebujete. Další informace o indexech tabulek a columnstore naleznete v následujících článcích:

Použijte větší třídu prostředků k vylepšení výkonu dotazu

Fondy SQL používají skupiny prostředků jako způsob přidělení paměti dotazům. Zpočátku jsou všichni uživatelé přiřazeni k malé třídě prostředků, která uděluje 100 MB paměti na distribuci. Vždy existuje 60 distribucí. Každé distribuci je přiděleno minimálně 100 MB. Celkové přidělení paměti pro celý systém je 6 000 MB nebo jen pod 6 GB.

Pro určité dotazy, například velká spojení nebo nahrávání do clusterovaných tabulek columnstore, bude větší přidělení paměti přínosem. Některé dotazy, jako jsou čisté skeny, nebudou mít žádný prospěch. Využití větších tříd prostředků má vliv na souběžnost. Před přesunem všech uživatelů do velké třídy prostředků byste měli mít na paměti tato fakta.

Další informace o třídách prostředků najdete v článku Třídy prostředků pro správu úloh.

Použití menší zdrojové třídy ke zvýšení paralelního zpracování

Pokud si všimnete dlouhého zpoždění v dotazech uživatelů, můžou být vaši uživatelé spuštěni ve větších třídách prostředků. Tento scénář podporuje využívání slotů souběžnosti, což může způsobit zařazení ostatních dotazů do fronty. Pokud chcete zjistit, jestli jsou dotazy uživatelů zařazené do fronty, spusťte SELECT * FROM sys.dm_pdw_waits a zjistěte, jestli se vrátí nějaké řádky.

Třídy prostředků pro správu úloh a články o sys.dm_pdw_waits vám poskytnou další informace.

Použijte zobrazení dynamických zpráv k monitorování a optimalizaci dotazů

Vyhrazené bazény SQL mají několik DMV, které lze použít k monitorování spouštění dotazů. Následující článek monitorování vás provede podrobnými pokyny k zobrazení podrobností o prováděcím dotazu. Pro rychlé nalezení dotazů v těchto dynamických pohledech může pomoci použití možnosti LABEL v dotazech. Další podrobné informace najdete v následujících článcích:

Související obsah

Podívejte se také na článek Řešení běžných problémů pro obecné problémy a jejich řešení.

Pokud potřebujete informace, které nejsou uvedené v tomto článku, vyhledejte na stránce pro otázky Microsoft Q&A azure Synapse místo, kde můžete klást otázky jiným uživatelům a produktové skupině Azure Synapse Analytics.

Toto fórum aktivně sledujeme, abychom zajistili, že vaši otázku zodpoví další uživatel nebo někdo z nás. Pokud dáváte přednost kladení otázek na Stack Overflow, máme také fórum Azure Synapse Analytics na Stack Overflow.

  • Last updated on