Best practices for dedicated SQL pools in Azure Synapse Analytics

  • Cikk

Ez a cikk ajánlott eljárásokat tartalmaz, amelyekkel optimális teljesítményt érhet el a dedikált SQL-készletekhez az Azure Synapse Analyticsben. Ha kiszolgáló nélküli SQL-készlettel dolgozik, további útmutatásért tekintse meg a kiszolgáló nélküli SQL-készletek ajánlott eljárásait. Az alábbiakban alapvető útmutatást és fontos területeket talál a megoldás létrehozásakor. Minden szakasz egy koncepciót mutat be, majd részletesebb cikkekre mutat, amelyek részletesebben ismertetik a fogalmat.

Dedikált SQL-készletek betöltése

A dedikált SQL-készletek betöltési útmutatóját az adatok betöltésére vonatkozó útmutatóban talál.

Költségek csökkentése felfüggesztés és méretezés által

További információ a költségek szüneteltetéssel és skálázással történő csökkentéséről: Számítás kezelése.

Statisztikák karbantartása

Dedikált SQL-készlet konfigurálható az oszlopok statisztikáinak automatikus észlelésére és létrehozására. Az optimalizáló által létrehozott lekérdezési tervek csak olyan jók, mint a rendelkezésre álló statisztikák.

Javasoljuk, hogy engedélyezze a AUTO_CREATE_STATISTICS az adatbázisokhoz, és a statisztikákat naponta vagy minden terhelés után frissítse, hogy a lekérdezésekben használt oszlopok statisztikái mindig naprakészek legyenek.

A statisztikák karbantartási idejének lerövidítéséhez válassza ki, hogy mely oszlopok rendelkeznek statisztikával, vagy a leggyakoribb frissítésre van szükség. Előfordulhat például, hogy frissíteni szeretné a dátumoszlopokat, ahol naponta új értékeket adhat hozzá. Az illesztésekben részt vevő oszlopokra, a WHERE záradékban használt oszlopokra és a GROUP BY-ban található oszlopokra vonatkozó statisztikákra összpontosíthat.

A statisztikákról további információt a Táblastatisztika kezelése, a CREATE STATISTICS és az UPDATE STATISTICS cikkekben talál.

Tune query performance

INSERT utasítások csoportosítása kötegekbe

Egy in Standard kiadás RT utasítással INSERT INTO MyLookup VALUES (1, 'Type 1')rendelkező kis táblába való egyszeri terhelés az igényeitől függően a legjobb módszer lehet. Ha azonban több ezer vagy több millió sort kell betöltenie a nap folyamán, valószínű, hogy az in Standard kiadás RTS egytonnás nem optimális.

A probléma megoldásának egyik módja egy fájlba írható folyamat fejlesztése, majd egy másik folyamat, amellyel rendszeres időközönként betölthető a fájl. További információért tekintse meg az IN Standard kiadás RT cikket.

Az adatok gyors betöltése és exportálása a PolyBase segítségével

A dedikált SQL-készlet számos eszközzel támogatja az adatok betöltését és exportálását, beleértve az Azure Data Factoryt, a PolyBaset és a BCP-t. Kis mennyiségű adat kezelése esetén, ahol a teljesítmény nem kulcsfontosságú tényező, bármelyik eszköz megfelelhet az igényeinek.

Megjegyzés:

A PolyBase a legjobb választás, ha nagy mennyiségű adatot tölt be vagy exportál, vagy gyorsabb teljesítményre van szüksége.

A PolyBase-betöltések a CTAS vagy az INSERT INTO paranccsal futtathatók. A CTAS minimalizálja a tranzakciónaplózást, és ez a leggyorsabb módja az adatok betöltésének. Az Azure Data Factory támogatja a PolyBase-terheléseket is, és a CTAS-hez hasonló teljesítményt érhet el. A PolyBase különböző fájlformátumokat támogat, beleértve a Gzip-fájlokat is.

A Gzip-szövegfájlok használatakor az átviteli sebesség maximalizálásához bontsa fel a fájlokat 60 vagy több fájlra a terhelés párhuzamosságának maximalizálása érdekében. A gyorsabb teljes átviteli teljesítmény érdekében érdemes lehet egy időben betölteni az adatokat. Az e szakaszra vonatkozó további információk a következő cikkekben találhatók:

Betöltés, majd külső táblák lekérdezése

A PolyBase nem optimális lekérdezésekhez. A dedikált SQL-készletekhez készült PolyBase-táblák jelenleg csak az Azure Blob-fájlokat és az Azure Data Lake Storage-t támogatják. Ezek a fájlok nem rendelkeznek olyan számítási erőforrásokkal, amelyek biztonsági másolatot készítenének róluk. Ennek eredményeképpen a dedikált SQL-készletek nem tudják kicsomagolni ezt a munkát, és be kell olvasniuk a teljes fájlt úgy, hogy tempdb betöltik, hogy beolvashassák az adatokat.

Ha több lekérdezése is van az adatok lekérdezéséhez, jobb, ha egyszer betölti ezeket az adatokat, és a lekérdezések a helyi táblát használják. További PolyBase-útmutatást tartalmaz az útmutató a PolyBase használatához.

Nagy táblák kivonatos elosztása

Alapértelmezés szerint a táblák ciklikus időszeleteléssel vannak elosztva. Ez az alapértelmezett beállítás megkönnyíti a felhasználók számára a táblák létrehozását anélkül, hogy el kellene dönteniük a táblák elosztásának módját. A kerekített időszeleteléses táblák bizonyos számítási feladatokhoz elegendő teljesítményt nyújthatnak. A legtöbb esetben azonban a terjesztési oszlop jobb teljesítményt nyújt.

A ciklikus időszeleteléses táblázatot túlteljesítő oszlop által elosztott táblák leggyakoribb példája két nagy ténytábla összekapcsolása.

Ha például egy rendeléstáblát order_id oszt el, és egy tranzakciós táblát is eloszt order_id, amikor a rendelési táblát a order_id tranzakciós táblájához csatlakoztatja, ez a lekérdezés egy átmenő lekérdezés lesz. Ezután megszűnnek az adatáthelyezési műveletek. Ha kevesebb lépést kell végrehajtani, felgyorsul a lekérdezési folyamat. A kisebb mértékű adatmozgás is gyorsabb lekérdezéseket eredményez.

Tipp.

Elosztott tábla betöltésekor a bejövő adatokat nem szabad a terjesztési kulcson rendezni. Ez lelassítja a terhelést.

Az alábbi hivatkozások további részleteket nyújtanak a teljesítmény javításáról egy terjesztési oszlop kiválasztásával. Az elosztott táblák definiálásáról a CREATE TABLE utasítás WITH záradékában talál információt:

Túl sok partíció használatának kerülése

Bár az adatok particionálása hatékony lehet az adatok partícióváltással történő karbantartásához, vagy a vizsgálatok partícióeltörléssel történő optimalizálásához, a túl sok partíció lelassíthatja a lekérdezéseket. Gyakran előfordulhat, hogy az SQL Serveren jól működő, részletes particionálási stratégia nem működik megfelelően a dedikált SQL-készleten.

Ha túl sok partíció van, az csökkentheti a fürtözött oszlopcentrikus indexek hatékonyságát, ha mindegyik partíció kevesebb mint 1 millió sorból áll. A dedikált SQL-készletek automatikusan particionálják az adatokat 60 adatbázisba. Ha tehát 100 partíciót tartalmazó táblát hoz létre, az eredmény 6000 partíció lesz. Minden számítási feladat eltérő, ezért a legjobb tanács a particionálással való kísérletezés, hogy lássa, mi működik a legjobban a számítási feladathoz.

Az egyik lehetőség, hogy olyan részletességet használ, amely alacsonyabb, mint amit az SQL Server használatával implementált. Érdemes lehet például heti vagy havi partíciókat használni a napi partíciók helyett.

A particionálásról további információt a Table particionálási cikkben talál.

Tranzakcióméretek minimalizálása

AZ IN Standard kiadás RT, UPDATE és DELETE utasítások egy tranzakcióban futnak. Ha nem sikerül, vissza kell őket állítani. A hosszú visszaállítás lehetőségének csökkentése érdekében lehetőség szerint minimalizálja a tranzakcióméreteket. A tranzakcióméretek minimalizálása az IN Standard kiadás RT, UPDATE és DELETE utasítások részekre való felosztásával végezhető el. Ha például olyan IN Standard kiadás RT-fájlja van, amely várhatóan 1 órát vesz igénybe, az IN Standard kiadás RT négy részre bontható. Ezután minden futtatás 15 percre rövidül.

Tipp.

Használja ki a minimális naplózást igénylő speciális eseteket, például a CTAS, TRUNCATE, DROP TABLE vagy INSERT utasításokat a táblák kiürítéséhez, hogy csökkentse a visszaállítással kapcsolatos kockázatokat.

A visszaállítások kiküszöbölésének másik módja a csak metaadatokat használó műveletek alkalmazása, például az adatkezelés partícióváltása. Például ahelyett, hogy egy DELETE utasítást hajtanak végre egy olyan tábla összes sorának törléséhez, amelyben a order_date 2001 októberében volt, havonta particionálhatja az adatokat. Ezután egy üres partíció adataival másik táblából is ki lehet kapcsolni a partíciót (lásd az ALTER TABLE-példákat).

A nem particionált táblák esetében fontolja meg, hogy a DELETE helyett cTAS használatával írja meg a táblában tárolni kívánt adatokat. Ha egy CTAS ugyanannyi időt vesz igénybe, sokkal biztonságosabb a futtatás, mivel minimális tranzakciónaplózással rendelkezik, és szükség esetén gyorsan megszakítható.

A jelen szakaszhoz kapcsolódó tartalommal kapcsolatos további információk az alábbi cikkekben találhatók:

Lekérdezési eredmények méretének csökkentése

A lekérdezési eredmények méretének csökkentése segít elkerülni a nagy lekérdezési eredmények által okozott ügyféloldali problémákat. A lekérdezés szerkesztésével csökkentheti a visszaadott sorok számát. Egyes lekérdezésgenerálási eszközök lehetővé teszik az "első N" szintaxis hozzáadását minden lekérdezéshez. A lekérdezés eredményét egy ideiglenes táblára is átadhatja, majd a PolyBase-exportálást is használhatja az alacsonyabb szintű feldolgozáshoz.

A lehető legkisebb oszlopméret használata

A DDL meghatározásakor használja a legkisebb adattípust, amely támogatja az adatokat, mivel ez javítja a lekérdezési teljesítményt. Ez a javaslat különösen fontos a CHAR és VARCHAR oszlopok esetében. Ha egy oszlop leghosszabb értéke 25 karakterből áll, akkor VARCHAR(25) típusként határozza meg az oszlopot. Ne határozza meg az összes karakteroszlopot nagy alapértelmezett hosszúságértékkel. Emellett az oszlopokat VARCHAR-ként is definiálhatja, ha csak erre van szükség az NVARCHAR használata helyett.

A fenti információkhoz kapcsolódó alapvető fogalmak részletesebb áttekintéséhez tekintse meg a Táblázat áttekintését, a Tábla adattípusokat és a CREATE TABLE-cikkeket .

Ideiglenes halomtáblák használata átmeneti adatokhoz

Ha ideiglenesen a dedikált SQL-készletekre ad le adatokat, a halomtáblák általában felgyorsítják az általános folyamatot. Ha csak úgy tölt be adatokat, hogy további átalakítások futtatása előtt szakaszos legyen, a táblázat halomtáblába való betöltése gyorsabb lesz, mint az adatok fürtözött oszlopcentrikus táblába való betöltése.

Az adatok ideiglenes táblába való betöltése sokkal gyorsabban töltődik be, mint egy tábla állandó tárolóba való betöltése. Az ideiglenes táblák "#" betűvel kezdődnek, és csak az azt létrehozó munkamenet érheti el. Következésképpen előfordulhat, hogy csak korlátozott forgatókönyvekben működnek. A halomtáblákat a CREATE TABLE utasítás WITH záradékával lehet meghatározni. Ha ideiglenes táblát használ, ne felejtsen el rajta is statisztikákat létrehozni.

További információ: Ideiglenes táblák, CREATE TABLE és CREATE TABLE AS Standard kiadás LECT cikkek.

Fürtözött oszlopcentrikus táblák optimalizálása

A fürtözött oszlopcentrikus indexek az adatok dedikált SQL-készletben való tárolásának egyik leghatékonyabb módja. Alapértelmezés szerint a dedikált SQL-készlet táblái fürtözött oszloptárként jönnek létre. Annak érdekében, hogy az oszlopcentrikus táblák a lehető legjobb teljesítménnyel fussanak, fontos a jó szegmensminőség. Amikor a sorokat nagy memóriaterhelés mellett írja oszlopcentrikus táblákba, az oszlopcentrikus szegmens minősége gyengülhet.

A szegmens minősége a tömörített sorcsoportok sorainak számával mérhető. A fürtözött oszlopcentrikus táblák szegmensminőségének észlelésére és javítására vonatkozó részletes útmutatásért tekintse meg az oszlopcentrikus indexek gyenge minőségének okait a Table indexes cikkben.

Mivel a kiváló minőségű oszlopcentrikus szegmensek fontosak, érdemes olyan felhasználói azonosítókat használni, amelyek közepes vagy nagy erőforrásosztályba tartoznak az adatok betöltéséhez. Az alacsonyabb adatraktár-egységek használata azt jelenti, hogy nagyobb erőforrásosztályt szeretne hozzárendelni a betöltési felhasználóhoz.

Az oszlopcentrikus táblák általában csak akkor küldik le az adatokat egy tömörített oszloptár-szegmensbe, ha táblánként több mint 1 millió sor van. Minden dedikált SQL-készlettábla 60 különböző disztribúcióban van elosztva. Ezért az oszlopcentrikus táblák csak akkor lesznek hasznosak a lekérdezések számára, ha a tábla több mint 60 millió sort tartalmaz.

Tipp.

A 60 millió sornál kisebb sorokkal rendelkező táblák esetében előfordulhat, hogy az oszlopcentrikus index nem az optimális megoldás.

Ha particionálja az adatokat, minden partíciónak 1 millió sorból kell rendelkeznie ahhoz, hogy kihasználhassa a fürtözött oszlopcentrikus index előnyeit. A 100 partíciót tartalmazó tábláknak legalább 6 milliárd sorra van szükségük ahhoz, hogy kihasználják a fürtözött oszlopok tárolását (60 eloszlás 100 partíció 1 millió sor).

Ha a táblázat nem rendelkezik 6 milliárd sortal, két fő lehetőség közül választhat. Csökkentse a partíciók számát, vagy inkább használjon halomtáblát. Érdemes lehet kísérletezni, hogy jobb teljesítményt nyerjen egy halomtábla másodlagos indexekkel való használatával, nem pedig oszlopcentrikus táblával.

Oszlopcentrikus tábla lekérdezésekor a lekérdezések gyorsabban futnak, ha csak a szükséges oszlopokat választja ki. A táblázat- és oszlopcentrikus indexekkel kapcsolatos további információk az alábbi cikkekben találhatók:

Nagyobb erőforrásosztály használata a lekérdezés teljesítményének javítása érdekében

Az SQL-készletek erőforráscsoportokat használnak a lekérdezések memóriáinak lefoglalására. Kezdetben minden felhasználó a kis erőforrásosztályhoz van rendelve, amely eloszlásonként 100 MB memóriát biztosít. Mindig 60 eloszlás van. Minden eloszlás legalább 100 MB-ot kap. A teljes rendszerszintű memóriafoglalás 6000 MB, vagy alig 6 GB.

Bizonyos lekérdezéseknél, például a nagyobb egyesítéseknél vagy a fürtözött oszlopcentrikus táblákba végzett betöltésnél előnyt jelent a nagyobb memórialefoglalások használata. Egyes lekérdezések, például a tiszta vizsgálatok, nem fognak előnyt látni. A nagyobb erőforrásosztályok használata hatással van az egyidejűségre. Ezért érdemes szem előtt tartani ezeket a tényeket, mielőtt az összes felhasználót egy nagy erőforrásosztályba helyeznénk át.

Az erőforrásosztályokkal kapcsolatos további információkért tekintse meg a számítási feladatok kezelésének erőforrásosztályai című cikket.

Kisebb erőforrásosztály használata az egyidejűség növeléséhez

Ha hosszú késést tapasztal a felhasználói lekérdezésekben, előfordulhat, hogy a felhasználók nagyobb erőforrásosztályokban futnak. Ez a forgatókönyv előlépteti az egyidejűségi pontok használatát, ami más lekérdezések várólistára helyezését okozhatja. Annak megállapításához, hogy a felhasználók lekérdezései várólistára vannak-e állítva, futtassa SELECT * FROM sys.dm_pdw_waits , és ellenőrizze, hogy vannak-e visszaadott sorok.

A számítási feladatok kezeléséhez és sys.dm_pdw_waits cikkekhez tartozó erőforrásosztályok további információt nyújtanak.

A lekérdezések megfigyelése és optimalizálása DMV-kkel

A dedikált SQL-készletek több DMV-vel rendelkeznek, amelyek a lekérdezések végrehajtásának monitorozására használhatók. Az alábbi monitorozási cikk lépésről lépésre ismerteti, hogyan tekintheti meg a végrehajtó lekérdezések részleteit. Ha gyorsan szeretne lekérdezéseket kikeresni a DMV-kben, segíthet, ha a lekérdezéseknél használja a LABEL beállítást. További részletes információkért tekintse meg az alábbi listában szereplő cikkeket:

További lépések

A gyakori problémákat és megoldásokat a hibaelhárítási cikk is tartalmazza.

Ha a cikkben nem szereplő információkra van szüksége, az Azure Synapse Microsoft Q&A kérdésoldalán kereshet, ahol kérdéseket tehet fel más felhasználóknak és az Azure Synapse Analytics termékcsoportnak.

Aktívan figyeljük ezt a fórumot, és gondoskodunk róla, hogy tőlünk vagy egy másik felhasználótól választ kapjon a kérdéseire. Ha inkább a Stack Overflow-ról szeretne kérdéseket feltenni, az Azure Synapse Analytics Stack Overflow fóruma is megtalálható.