Maximera radgruppskvaliteten för kolumnlagringsindex i en dedikerad SQL-pool

Artikel
06/01/2023

Radgruppskvaliteten bestäms av antalet rader i en radgrupp. Om du ökar det tillgängliga minnet kan du maximera antalet rader som ett kolumnlagringsindex komprimerar till varje radgrupp. Använd dessa metoder för att förbättra komprimeringshastigheten och frågeprestanda för kolumnlagringsindex.

Varför radgruppsstorleken är viktig

Eftersom ett kolumnlagringsindex genomsöker en tabell genom att skanna kolumnsegment för enskilda radgrupper, förbättrar maximerande av antalet rader i varje radgrupp frågeprestanda.

När radgrupper har ett stort antal rader förbättras datakomprimering, vilket innebär att det finns färre data att läsa från disken.

Mer information om radgrupper finns i Guiden columnstore-index.

Målstorlek för radgrupper

För bästa frågeprestanda är målet att maximera antalet rader per radgrupp i ett kolumnlagringsindex. En radgrupp kan innehålla högst 1 048 576 rader.

Det är okej att inte ha det maximala antalet rader per radgrupp. Kolumnlagringsindex ger bra prestanda när radgrupper har minst 100 000 rader.

Radgrupper kan trimmas under komprimering

Under en massinläsning eller återskapande av kolumnlagringsindex finns det ibland inte tillräckligt med minne tillgängligt för att komprimera alla rader som har angetts för varje radgrupp. När det finns minnestryck trimmar kolumnlagringsindex radgruppsstorlekarna så att komprimering till kolumnlagringen kan lyckas.

När det inte finns tillräckligt med minne för att komprimera minst 10 000 rader till varje radgrupp genereras ett fel.

Mer information om massinläsning finns i Massinläsning till ett grupperat columnstore-index.

Så här övervakar du radgruppskvalitet

DMV-sys.dm_pdw_nodes_db_column_store_row_group_physical_stats (sys.dm_db_column_store_row_group_physical_stats innehåller vydefinitionen som matchar SQL DB) som visar användbar information, till exempel antal rader i radgrupper och orsaken till trimningen, om det fanns trimning.

Du kan skapa följande vy som ett praktiskt sätt att fråga denna DMV för att få information om radgrupps trimning.

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;

Trim_reason_desc anger om radgruppen har trimmats(trim_reason_desc = NO_TRIM innebär att det inte fanns någon trimning och att radgruppen är av optimal kvalitet). Följande trimningsorsaker indikerar för tidig trimning av radgruppen:

BULKLOAD: Den här trimningsorsaken används när den inkommande batchen med rader för belastningen hade mindre än 1 miljon rader. Motorn skapar komprimerade radgrupper om det finns fler än 100 000 rader som infogas (i stället för att infogas i deltalagret) men anger trimorsaken till BULKLOAD. I det här scenariot bör du överväga att öka batchbelastningen så att fler rader inkluderas. Utvärdera också partitioneringsschemat igen för att säkerställa att det inte är för detaljerat eftersom radgrupper inte kan sträcka sig över partitionsgränser.
MEMORY_LIMITATION: Om du vill skapa radgrupper med 1 miljon rader krävs en viss mängd arbetsminne av motorn. När tillgängligt minne för inläsningssessionen är mindre än det nödvändiga arbetsminnet, trimmas radgrupper i förtid. I följande avsnitt beskrivs hur du beräknar nödvändigt minne och allokerar mer minne.
DICTIONARY_SIZE: Den här trimningsorsaken anger att radgrupps trimning inträffade eftersom det fanns minst en strängkolumn med breda och/eller hög kardinalitetssträngar. Ordlistestorleken är begränsad till 16 MB i minnet och när den här gränsen har nåtts komprimeras radgruppen. Om du stöter på den här situationen bör du överväga att isolera den problematiska kolumnen till en separat tabell.

Så här beräknar du minneskraven

Om du vill visa en uppskattning av minneskraven för att komprimera en radgrupp med maximal storlek till ett columnstore-index kan du skapa exempelvyn dbo.vCS_mon_mem_grant. Den här frågan visar storleken på det minnestillviljande som en radgrupp kräver för komprimering i kolumnlagringen.

Det maximala minne som krävs för att komprimera en radgrupp är ungefär

72 MB +
#rows * #columns * 8 byte +
#rows * #short-string-columns * 32 byte +
#long-string-columns * 16 MB för komprimeringsordlista

Anteckning

Korta strängkolumner använder strängdatatyper av <= 32 byte och långa strängkolumner använder strängdatatyper på > 32 byte.

Långa strängar komprimeras med en komprimeringsmetod som är utformad för att komprimera text. Den här komprimeringsmetoden använder en ordlista för att lagra textmönster. Den maximala storleken för en ordlista är 16 MB. Det finns bara en ordlista för varje lång strängkolumn i radgruppen.

Sätt att minska minneskraven

Använd följande tekniker för att minska minneskraven för att komprimera radgrupper till kolumnlagringsindex.

Använd färre kolumner

Utforma om möjligt tabellen med färre kolumner. När en radgrupp komprimeras till kolumnlagringen komprimerar kolumnlagringsindexet varje kolumnsegment separat.

Därför ökar minneskraven för att komprimera en radgrupp allt eftersom antalet kolumner ökar.

Använd färre strängkolumner

Kolumner med strängdatatyper kräver mer minne än numeriska datatyper och datumdatatyper. Du kan minska minneskraven genom att ta bort strängkolumner från faktatabeller och placera dem i mindre dimensionstabeller.

Ytterligare minneskrav för strängkomprimering:

Strängdatatyper upp till 32 tecken kan kräva ytterligare 32 byte per värde.
Strängdatatyper med fler än 32 tecken komprimeras med hjälp av ordlistemetoder. Varje kolumn i radgruppen kan kräva upp till ytterligare 16 MB för att skapa ordlistan.

Undvik överpartitionering

Kolumnlagringsindex skapar en eller flera radgrupper per partition. För dedikerad SQL-pool i Azure Synapse Analytics växer antalet partitioner snabbt eftersom data distribueras och varje distribution partitioneras.

Om tabellen har för många partitioner kanske det inte finns tillräckligt med rader för att fylla radgrupperna. Bristen på rader skapar inte minnesbelastning under komprimering. Men det leder till radgrupper som inte uppnår bästa prestanda för columnstore-frågor.

En annan anledning till att undvika överpartitionering är att det finns en minneskostnad för att läsa in rader i ett kolumnlagringsindex i en partitionerad tabell.

Under en inläsning kan många partitioner ta emot de inkommande raderna, som lagras i minnet tills varje partition har tillräckligt med rader för att komprimeras. Om du har för många partitioner ökar minnesbelastningen.

Förenkla inläsningsfrågan

Databasen delar minnestilldelningen för en fråga bland alla operatorer i frågan. När en inläsningsfråga har komplexa sorteringar och kopplingar minskas det tillgängliga minnet för komprimering.

Utforma inläsningsfrågan så att den endast fokuserar på att läsa in frågan. Om du behöver köra transformeringar på data kör du dem separat från inläsningsfrågan. Du kan till exempel mellanlagra data i en heap-tabell, köra omvandlingarna och sedan läsa in mellanlagringstabellen i kolumnlagringsindexet.

Tips

Du kan också läsa in data först och sedan använda MPP-systemet för att transformera data.

Justera MAXDOP

Varje distribution komprimerar radgrupper till kolumnlagringen parallellt när det finns mer än en processorkärna tillgänglig per distribution.

Parallelliteten kräver ytterligare minnesresurser, vilket kan leda till minnesbelastning och radgrupps trimning.

Om du vill minska minnesbelastningen kan du använda MAXDOP-frågetipset för att tvinga belastningsåtgärden att köras i serieläge inom varje distribution.

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

Sätt att allokera mer minne

DWU-storleken och användarresursklassen avgör tillsammans hur mycket minne som är tillgängligt för en användarfråga.

Om du vill öka minnestillslaget för en inläsningsfråga kan du antingen öka antalet DWU:er eller öka resursklassen.

Information om hur du ökar DWU:erna finns i Hur gör jag för att skalningsprestanda?
Information om hur du ändrar resursklassen för en fråga finns i Ändra ett exempel på en användarresursklass.

Nästa steg

Fler sätt att förbättra prestanda för dedikerad SQL-pool finns i Prestandaöversikt.

Share via