Dela via

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

Radgruppskvaliteten bestäms av antalet rader i en radgrupp. Genom att öka det tillgängliga minnet kan antalet rader som ett kolumnlagringsindex komprimerar i varje radgrupp maximeras. Använd dessa metoder för att förbättra komprimeringsfrekvensen och frågeprestanda för columnstore-index.

Varför storleken på radgruppen spelar roll

Eftersom ett columnstore-index söker igenom 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 kolumnlagringsindex. 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 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 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.

For more information on bulk loading, see Bulk load into a clustered columnstore index.

Hur du kan övervaka radgruppskvalitet

Vyn dynamisk hantering (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. You can create the following view as a handy way to query this DMV to get information on rowgroup trimming.

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). The following trim reasons indicate premature trimming of the rowgroup:

  • BULKLOAD: This trim reason is used when the incoming batch of rows for the load had less than 1 million rows. The engine will create compressed row groups if there are greater than 100,000 rows being inserted (as opposed to inserting into the delta store) but sets the trim reason to BULKLOAD. I det här scenariot bör du överväga att öka batchbelastningen så att den innehåller fler rader. Utvärdera även 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 det tillgängliga minnet 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öga 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

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

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

Anmärkning

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

Utforma om möjligt 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 den bästa frågeprestandan 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 laddningsfrågan

Databasen delar minnestilldelningen för en fråga mellan 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 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 belastningsfrågan. Du kan till exempel mellanlagra data i en heaptabell, köra transformeringarna och sedan läsa in mellanlagringstabellen i kolumnlagringsindexet.

Adjust 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 minnestillviljan för en belastningsfråga kan du antingen öka antalet DWU:er eller öka resursklassen.

Nästa steg

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