Maximera radgruppskvaliteten för prestanda för columnstore-index

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 komprimeringshastigheter och frågeprestanda för columnstore-index.

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 mindre data att läsa från disken.

Mer information om radgrupper finns i Columnstore Indexes Guide.

Målstorlek för radgrupper

För bästa frågeprestanda är målet att maximera antalet rader per radgrupp i ett columnstore-index. En radgrupp kan ha 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 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 kolumnarkivet 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 i ett grupperat columnstore-index.

Övervaka radgruppskvalitet

Den dynamiska hanteringsvyn (DMV) (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 trimning om det fanns trimning. Du kan skapa följande vy som ett praktiskt sätt att fråga den här DMV:en 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;

Kolumnen trim_reason_desc anger om radgruppen trimmades (trim_reason_desc = NO_TRIM innebär att det inte fanns någon trimning och att radgruppen är av optimal kvalitet). Följande trimningsorsaker anger 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 deltaarkivet) men anger trimorsaken till BULKLOAD. I det här scenariot bör du överväga att öka batchbelastningen för att inkludera fler rader. 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: För att 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 minne som krävs och allokerar mer minne.
DICTIONARY_SIZE: Den här trimningsorsaken anger att radgruppstrimning 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 i en separat tabell.

Så här beräknar du minneskraven

Det maximala minne som krävs för att komprimera en radgrupp är ungefär så här:

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

Anteckning

Där korta strängkolumner använder strängdatatyper av <= 32 byte och långa strängkolumner använder du 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ända färre kolumner

Om möjligt utformar du tabellen med färre kolumner. När en radgrupp komprimeras till kolumnarkivet komprimerar kolumnlagringsindexet varje kolumnsegment separat. Därför ökar minneskraven för att komprimera en radgrupp när antalet kolumner ökar.

Använd färre strängkolumner

Kolumner med strängdatatyper kräver mer minne än numeriska 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 på 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 datalagerhantering 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 minnestryck under komprimering, men det leder till radgrupper som inte uppnår bästa frågeprestanda för columnstore.

En annan anledning till att undvika överpartitionering är att det finns ett minnesomkostnader för att läsa in rader i ett kolumnlagringsindex i en partitionerad tabell. Under en inläsning kan många partitioner ta emot inkommande rader, som lagras i minnet tills varje partition har tillräckligt med rader för att komprimeras. Att ha för många partitioner skapar ytterligare minnestryck.

Förenkla inläsningsfrågan

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

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

Justera MAXDOP

Varje distribution komprimerar radgrupper till kolumnarkivet parallellt när det finns mer än en processorkärna tillgänglig per distribution. Parallelliteten kräver ytterligare minnesresurser, vilket kan leda till minnestryck och radgrupps trimning.

För att 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 belastningsfrå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å användarresursklass.

Nästa steg

Mer information om hur du kan förbättra prestanda i Synapse SQL finns i prestandaöversikten.

Dela via