A sorcsoport minőségének maximalizálása a dedikált SQL-készlet oszlopcentrikus indexeihez

A sorcsoport minőségét egy sorcsoport sorainak száma határozza meg. A rendelkezésre álló memória növelése maximalizálhatja az oszlopcentrikus index által az egyes sorcsoportokba tömörített sorok számát. Ezekkel a módszerekkel javíthatja az oszlopcentrikus indexek tömörítési sebességét és lekérdezési teljesítményét.

Miért fontos a sorcsoport mérete?

Mivel egy oszlopcentrikus index az egyes sorcsoportok oszlopszegmenseinek vizsgálatával vizsgál be egy táblát, az egyes sorcsoportokban lévő sorok számának maximalizálása növeli a lekérdezési teljesítményt.

Ha a sorcsoportok nagy számú sorból állnak, az adattömörítés javul, ami azt jelenti, hogy kevesebb adatot kell beolvasni a lemezről.

További információ a sorcsoportokról: Oszlopcentrikus indexek útmutatója.

Célméret sorcsoportokhoz

A legjobb lekérdezési teljesítmény érdekében a cél az oszlopcentrikus indexben lévő sorcsoportonkénti sorok számának maximalizálása. Egy sorcsoport legfeljebb 1 048 576 sort tartalmazhat.

Nem baj, ha nem rendelkezik a sorcsoportonkénti sorok maximális számával. Az oszlopcentrikus indexek akkor érnek el jó teljesítményt, ha a sorcsoportok legalább 100 000 sort tartalmaznak.

A sorcsoportok tömörítés közben levághatók

A tömeges terhelés vagy az oszlopcentrikus index újraépítése során néha nincs elegendő memória az egyes sorcsoportokhoz kijelölt összes sor tömörítéséhez. Memóriaterhelés esetén az oszlopcentrikus indexek levágják a sorcsoport méretét, hogy az oszloptárba történő tömörítés sikeres legyen.

Ha nincs elegendő memória ahhoz, hogy legalább 10 000 sort tömörítsen az egyes sorcsoportokba, hibaüzenet jelenik meg.

A tömeges betöltésről további információt a Fürtözött oszlopcentrikus indexbe történő tömeges betöltés című témakörben talál.

A sorcsoport minőségének monitorozása

A DMV-sys.dm_pdw_nodes_db_column_store_row_group_physical_stats (sys.dm_db_column_store_row_group_physical_stats tartalmazza az SQL DB-nek megfelelő nézetdefiníciót), amely hasznos információkat tesz elérhetővé, például a sorcsoportok sorainak számát és a vágás okát, ha volt vágás.

A következő nézetet hasznos eszközként hozhatja létre a DMV lekérdezéséhez, hogy információt szerezzen a sorcsoportok vágásáról.

create view dbo.vCS_rg_physical_stats
as
with cte
as
(
select   tb.[name]                    AS [logical_table_name]
,        rg.[row_group_id]            AS [row_group_id]
,        rg.[state]                   AS [state]
,        rg.[state_desc]              AS [state_desc]
,        rg.[total_rows]              AS [total_rows]
,        rg.[trim_reason_desc]        AS trim_reason_desc
,        mp.[physical_name]           AS physical_name
FROM    sys.[schemas] sm
JOIN    sys.[tables] tb               ON  sm.[schema_id]          = tb.[schema_id]
JOIN    sys.[pdw_table_mappings] mp   ON  tb.[object_id]          = mp.[object_id]
JOIN    sys.[pdw_nodes_tables] nt     ON  nt.[name]               = mp.[physical_name]
JOIN    sys.[dm_pdw_nodes_db_column_store_row_group_physical_stats] rg      ON  rg.[object_id]     = nt.[object_id]
                                                                            AND rg.[pdw_node_id]   = nt.[pdw_node_id]
                                        AND rg.[distribution_id]    = nt.[distribution_id]
)
select *
from cte;

A trim_reason_desc azt jelzi, hogy a sorcsoportot levágták-e (trim_reason_desc = NO_TRIM azt jelzi, hogy nincs vágás, és a sorcsoport optimális minőségű). A következő metszési okok a sorcsoport korai metszését jelzik:

  • BULKLOAD: Ezt a vágási okot akkor használják, ha a feltöltéshez beérkezett sorok kötege kevesebb mint 1 millió sort tartalmazott. A motor tömörített sorcsoportokat hoz létre, ha több mint 100 000 sort szúrnak be (ahelyett, hogy a deltatárolóba szúrná be őket), de a vágás okának beállításához a BULKLOAD értéket használja. Ebben a forgatókönyvben fontolja meg a tételterhelés növelését, hogy több sor kerüljön bele. Emellett értékelje újra a particionálási sémát, hogy ne legyen túl részletes, mivel a sorcsoportok nem tudják átfogni a partíciók határait.
  • MEMORY_LIMITATION: Az 1 millió sorból álló sorcsoportok létrehozásához a motornak bizonyos mennyiségű munkamemóriára van szüksége. Ha a betöltési munkamenet rendelkezésre álló memóriája kisebb, mint a szükséges munkamemória, a sorcsoportok idő előtt le lesznek vágva. A következő szakaszok ismertetik, hogyan becsülhet meg szükséges memóriát, és hogyan foglalhat le több memóriát.
  • DICTIONARY_SIZE: Ez a vágási ok azt jelzi, hogy a sorcsoport vágása azért történt, mert volt legalább egy karakterlánc-oszlop széles és/vagy magas kardinalitású karakterláncokkal. A szótár mérete 16 MB-ra van korlátozva a memóriában, és a korlát elérése után a sorcsoport tömörítve lesz. Ha mégis belefut ebbe a helyzetbe, fontolja meg a problémás oszlop elkülönítését egy külön táblába.

Memóriakövetelmények becslése

A maximális méretű sorcsoport oszlopcentrikus indexbe való tömörítéséhez szükséges memóriakövetelmények becslésének megtekintéséhez érdemes lehet létrehozni a mintanézetet dbo.vCS_mon_mem_grant. Ez a lekérdezés azt mutatja, hogy mekkora memória-juttatás szükséges egy sorcsoport számára az oszloptárba történő tömörítéshez.

Az egy sorcsoport tömörítéséhez szükséges maximális memória körülbelül

  • 72 MB +
  • #rows * #columns * 8 bájt +
  • #rows * #rövid-karakteroszlopok * 32 bájt +
  • #long-string-columns * 16 MB a tömörítési szótárhoz

Megjegyzés:

A rövid sztringoszlopok 32 bájtos sztring adattípusokat < használnak, a hosszú sztringoszlopok pedig 32 bájtos sztring adattípusokat >.

A hosszú sztringeket szöveg tömörítésére tervezett módszerrel tömörítik. Ez a tömörítési módszer egy szótári-et használ a szövegminták tárolására. A szótár maximális mérete 16 MB. A sorcsoport minden hosszú sztringoszlopához csak egy szótár tartozik.

A memóriakövetelmények csökkentésének módjai

Az alábbi technikákkal csökkentheti a sorcsoportok oszlopcentrikus indexekbe való tömörítésének memóriakövetelményeit.

Kevesebb oszlop használata

Ha lehetséges, tervezzen kevesebb oszlopot tartalmazó táblát. Ha egy sorcsoportot tömörít az oszloptárba, az oszloptár index külön tömöríti minden oszlopszegmenst.

Így a sorcsoportok tömörítésének memóriakövetelményei az oszlopok számának növekedésével nőnek.

Kevesebb sztringoszlop használata

A sztring adattípusok oszlopai több memóriát igényelnek, mint a numerikus és a dátum típusú adattípusok. A memóriaigény csökkentése érdekében fontolja meg a sztringoszlopok eltávolítását a ténytáblákból, és helyezze őket kisebb dimenziótáblákba.

További memóriakövetelmények a sztringtömörítéshez:

  • A legfeljebb 32 karakter hosszúságú sztring adattípusok értékenként 32 bájtot igényelhetnek.
  • A 32 karakternél több karaktert tartalmazó sztring adattípusok szótári módszerekkel vannak tömörítve. A sorcsoport minden oszlopához további 16 MB szükséges a szótár létrehozásához.

Kerülje a túlparticionálást

Az oszlopcentrikus indexek partíciónként egy vagy több sorcsoportot hoznak létre. Az Azure Synapse Analytics dedikált SQL-készlete esetén a partíciók száma gyorsan nő, mivel az adatok elosztva és particionálásra kerülnek.

Ha a tábla túl sok partícióval rendelkezik, előfordulhat, hogy nincs elegendő sor a sorcsoportok kitöltéséhez. A sorok hiánya nem okoz memóriaterhelést a tömörítés során. Ez azonban olyan sorcsoportokhoz vezet, amelyek nem érik el a legjobb oszlopcentrikus lekérdezési teljesítményt.

A túlparticionálás elkerülésének másik oka, hogy a sorok egy particionált tábla oszlopcentrikus indexébe való betöltése memóriaterheléssel jár.

A terhelés során számos partíció fogadhatja a bejövő sorokat, amelyek a memóriában maradnak, amíg minden partícióhoz elegendő sor nem lesz tömörítve. A túl sok partíció további memóriaterhelést eredményez.

A terheléses lekérdezés egyszerűsítése

Az adatbázis megosztja a lekérdezés memória-megadását a lekérdezés összes operátora között. Ha egy terheléses lekérdezés összetett rendezésekkel és illesztésekkel rendelkezik, a tömörítéshez rendelkezésre álló memória csökken.

Úgy tervezheti meg a betöltési lekérdezést, hogy csak a lekérdezés betöltésére összpontosítson. Ha átalakításokat kell futtatnia az adatokon, futtassa őket a terhelési lekérdezéstől elkülönítve. Az adatokat például egy halomtáblában előkészítheti, futtathatja az átalakításokat, majd betölti az előkészítési táblát az oszlopalapú indexbe.

Jótanács

Azt is megteheti, hogy először betölti az adatokat, majd az MPP-rendszerrel átalakítja az adatokat.

A MAXDOP beállítása

Minden disztribúció párhuzamosan tömöríti a sorcsoportokat az oszloptárba, ha eloszlásonként egynél több processzormag érhető el.

A párhuzamosság további memóriaerőforrásokat igényel, ami memóriaterheléshez és sorcsoport-vágáshoz vezethet.

A memóriaterhelés csökkentése érdekében a MAXDOP lekérdezési tipp használatával kényszerítheti a terhelési műveletet soros módban való futtatásra az egyes disztribúciókon belül.

CREATE TABLE MyFactSalesQuota
WITH (DISTRIBUTION = ROUND_ROBIN)
AS SELECT * FROM FactSalesQuota
OPTION (MAXDOP 1);

További memória lefoglalásának módjai

A DWU mérete és a felhasználói erőforrásosztály együttesen határozzák meg, hogy mennyi memória áll rendelkezésre egy felhasználói lekérdezéshez.

A terheléses lekérdezés memóriahasználatának növeléséhez növelheti a DWU-k számát, vagy növelheti az erőforrásosztályt.

Következő lépések

A dedikált SQL-készlet teljesítményének javításához további módszereket a Teljesítmény áttekintésében talál.

  • Last updated on