Megosztás a következőn keresztül:

Ajánlott eljárások dedikált SQL-készletekhez az Azure Synapse Analyticsben

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

A 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ése érdekében válogassa meg, hogy mely oszlopok rendelkeznek statisztikával, vagy melyek igénylik a leggyakoribb frissítést. Előfordulhat például, hogy csak a dátumoszlopokat szeretné frissíteni, amelyekbe napi rendszerességgel kerülnek új értékek. 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.

Lekérdezési teljesítmény finomhangolása

INSERT utasítások csoportosítása batch-ekbe

Egy kis táblázat egyszeri betöltése INSERT utasítással, például INSERT INTO MyLookup VALUES (1, 'Type 1')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, akkor valószínű, hogy a singleton INSERTS 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 INSERT 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.

Feljegyzé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 átruházni ezt a munkát, és be kell olvasniuk a teljes fájlt úgy, hogy tempdb betöltik, hogy olvassa az adatokat.

Ha több lekérdezést végez ehhez az adathoz, akkor érdemes egyszer betölteni 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 hash alapú elosztása

Alapértelmezés szerint a táblák Round Robin elosztással 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 Round Robin táblák bizonyos számítási feladatokhoz megfelelően működhetnek. A legtöbb esetben azonban a terjesztési oszlop jobb teljesítményt nyújt.

Az oszlopok szerint elosztott táblák leggyakoribb példája, amikor túlteljesítenek egy körkörösen kiosztott táblát, az az, amikor két nagy ténytáblát egyesítenek.

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 cikkhivatkozá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.

Egy megfontolandó lehetőség az, hogy olyan részletességet alkalmaz, amely alacsonyabb, mint amit korábban az SQL Server használatával valósított meg. É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 INSERT, 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ók méretét. A tranzakcióméretek minimalizálása az INSERT, UPDATE és DELETE utasítások részekre való felosztásával végezhető el. Ha például olyan INSERT-fájlja van, amely várhatóan 1 órát vesz igénybe, az INSERT-t négy részre bonthatja. Ezután minden futtatás 15 percre rövidül.

Tipp

A visszaállítási kockázat csökkentése érdekében használjon speciális minimális naplózási eseteket, például CTAS-t, TRUNCATE, DROP TABLE vagy INSERT üres táblákra.

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 kicserélheted a benne lévő adatokkal a partíciót egy üres partícióra egy másik táblából (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 adatokat csak azért tölt be, hogy az átalakítások futtatása előtt előzetesen tárolja, akkor a halmaztáblába történő betöltés gyorsabb lesz, mint az adatok pártolt oszloptá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ót az Ideiglenes táblák, a CREATE TABLE és a CREATE TABLE AS SELECT cikkekben talál.

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-pool táblái Clustered ColumnStore formában jönnek létre. Annak érdekében, hogy az oszlopcentrikus táblák a lehető legjobb teljesítményt nyújtsák, fontos a jó szegmensminőség. Amikor sorokat írunk oszlopalapú táblákba memóriaterhelés esetén, az oszlopalapú 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 jó minőségű oszlopcentrikus szegmensek fontosak, érdemes olyan felhasználói ID-ket 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 érjünk el egy másodlagos indexekkel rendelkező halomtábla használatával, ahelyett, hogy oszlopalapú táblát használnánk.

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ések - például a nagyobb egyesítések vagy a fürtözött oszlopcentrikus táblákba történő betöltések - esetén előnyt jelenthetnek a nagyobb memória-kiosztások. Egyes lekérdezések, például a tiszta vizsgálatok, nem hoznak előnyt. 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éről szóló erőforrásosztályokat ismertető 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ősegíti az egyidejűségi erőforrások fogyasztását, ami miatt más lekérdezések sorba kerülhetnek. 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:

Kapcsolódó tartalom

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