INDICI: ARCHITETTURA, UTILIZZO, MANUTENZIONE... ED EVOLUZIONE (II PARTE) INDICI COLUMNSTORE: CONCETTI ED EVOLUZIONE GILBERTO ZAMPATTI

Presentazione sul tema: "INDICI: ARCHITETTURA, UTILIZZO, MANUTENZIONE... ED EVOLUZIONE (II PARTE) INDICI COLUMNSTORE: CONCETTI ED EVOLUZIONE GILBERTO ZAMPATTI"— Transcript della presentazione:

1 INDICI: ARCHITETTURA, UTILIZZO, MANUTENZIONE... ED EVOLUZIONE (II PARTE) INDICI COLUMNSTORE: CONCETTI ED EVOLUZIONE GILBERTO ZAMPATTI GILBERTO.ZAMPATTI@NUOVISOCI.IT

2 SPEAKER INFO IT pro IT pro da …un bel mucchietto di anni ;) MCT MCT: un pò meno di metà del tempo in aule di varia misura e capienza Mentore/Consulente Mentore/Consulente: mi si contatta quando le cose vanno …ma si vuol che vadano meglio Speaker Speaker: tra i fondatori di UGISS, qualche conferenza ogni anno mi tiene in salute

3 AGENDA Scenari e requisiti Business Columnstore Indexes in SQL 2012 Columnstore Indexes in SQL 2014

4 PREMESSA (SQL 2012) Gli indici Columnstore offrono un metodo relativamente semplice per migliorare significativamente l’utilizzo dei datawarehouse in termini prestazionali (soprattutto su dataset VERAMENTE grandi) I miglioramenti oscillano tra 10x e 100x I migliori risultati si ottengono per queries effettuate su modelli star-schema che applicano filtri, aggregazioni e raggruppamenti

5 REQUISITI E SOLUZIONI A fronte del bisogno di queries molto efficienti in un DW su data set molto (MOLTO) voluminosi: In SQL Server 2008 e SQL Server 2008 R2 OLAP (SSAS) MDX ROLAP e T-SQL + tabelle di aggregazione intermedie, indexed views e tabelle di aggregati Flessibilità insufficiente In SQL Server 2012 Creazione di columnstore index su tabelle dei fatti molto grandi, che referenzino tutte le colonne (purché supportino data type coerenti) Utilizzo di T-SQL e delle funzionalità di base del Database Engine Refactoring e/o interventi minimi Creando il columnstore index, la tabella diventa “read only” – ma si può adottare il partitioning per effettuare switch bi-direzionale dei dati, OPPURE drop/rebuild periodico degli indici

6 COME SI OTTENGONO LE PRESTAZIONI RICHIESTE? Due tecnologie complementari: Storage I Dati sono memorizzati in un formato colonnare compresso (stored by column) invece che nel “tradizionale” formato per riga (stored by row). Meno dati acceduti quando solo un sottoinsieme di colonne costituisce l’indice Miglioramento nell’uso della buffer pool memory Esecuzione in “batch mode” I dati possono essere elaborati in batches (blocchi di 1,000 righe) invece che riga per riga In funzione dei filtri e di altri fattori, una query può giovarsi della “segment elimination” – bypassando porzioni di milioni di righe (segmenti) e riducendo ulteriormente l’ I/O

7 COLUMN VS. ROW STORE ROW STORE (HEAP / B-TREE) ProductIDOrderDateCost 310200107012171.29 311200107011912.15 312200107022171.29 31320010702413.14 COLUMN STORE (VALORI COMPRESSI) data page 1000 ProductIDOrderDateCost 31420010701333.42 315200107011295.00 316200107024233.14 31720010702641.22 data page 1001 ProductID 310 311 312 313 314 315 316 317 318 319 320 321 data page 2001 OrderDate 20010701 … 20010702 … … 20010703 … … … … 20010704 … data page 2000 data page 2002 Cost 2171.29 1912.15 2171.29 413.14 333.42 1295.00 4233.14 641.22 24.95 64.32 1111.25

8 BATCH MODE Consente l’elaborazione di blocchi di 1,000 righe in alternativa alle operazioni su singola riga Consente l’uso di algoritmi aggiuntivi che possono ridurre significativamente l’overhead di CPU Il “segmento” Batch mode è una partizione frammentata in porzioni di milioni di righe cui sono associate statistiche utilizzate per il filtering Il Batch mode permette di migliorare ulteriormente le prestazioni delle query su un indice columnstore, ma non è sempre consentito: Alcune operazioni non sono abilitate outer joins sulla tabella con indice columnstore / join su stringhe / NOT IN / IN / EXISTS / aggregati scalari Il Row mode è l’alternativa a fronte di SQL Server memory pressure o indisponibilità di parallelismo

9 CREAZIONE DI UN INDICE COLUMNSTORE T-SQL SSMS

10 CANDIDATI IDEALI PER INDICIZZAZIONE COLUMNSTORE Tabelle: Tabelle dei fatti MOLTO grandi (centinaia di milioni/miliardi di righe) Tabelle dimensionali (milioni di righe) con elevate densità Nel dubbio è semplice creare un indice columnstore e verificarne l’impatto sulle prestazioni

11 CANDIDATI IDEALI PER INDICIZZAZIONE COLUMNSTORE Query (su tabelle con indice columnstore): Scan (gli indici columnstore non supportano operazioni seek) Risultati di Aggregazione molto più piccoli della tabella Joins su tabelle dimensionali più piccole Filtering su tabelle dei fatti e/o dimensioni –su un modello star schema Sub-set di colonne Joins su singola Colonna tra la tabella con indice columnstore e altre tabelle

12 DEFINIZIONI Tipo di Indice Gli Indici Columnstore sono sempre non-clustered e non-unique NON possono essere creati su viste, viste indicizzate, sparse columns NON possono agire come vincoli di primary o foreign key Selezione delle colonne Non esistono “key columns” Si scelgono le colonne che saranno usate nelle query Fino a 1,024 colonne – non ha importanza l’ordine in cui sono indicate Concetto di “INCLUDE” non esiste Limite dei 900 byte sulla “chiave” abolito Ordinamento Non sono consentite le opzioni ASC or DESC – l’ordinamento è definito dagli algoritmi di compressione

13 DATA TYPES Supportati Char / nchar / varchar / nvarchar (max), legacy LOB types e FILESTREAM non supportati Decimal/numeric Precisione superiore ai 18 digits NON è supportata Tinyint, smallint, int, bigint Float/real Bit Money, smallmoney Date and time Datetimeoffset con scale > 2 NON supportata

14 MANUTENZIONE Creato l’indice, la tabella diventa “read-only” e INSERT/UPDATE/DELETE/MERGE non sono più ammissibili ALTER INDEX REBUILD / REORGANIZE non sono consentiti Opzioni supportate: Partition switches (IN and OUT) Drop dell’indice columnstore / modifiche alla tabella / ri-creazione dell’indice columnstore UNION ALL (verificare le prestazioni)

15 LIMITAZIONI Gli Indici Columnstore non sono ammessi in: Change Data Capture e Change Tracking Colonne Filestream (altre colonne sulla tabella sono ammesse) Compressioni Page, row e vardecimal Replication Sparse columns

16 LIMITAZIONI Limitazioni sui Data type Binary / varbinary / ntext / text / image varchar (max) / nvarchar (max) uniqueidentifier / rowversion / sql_variant decimal or numeric with precesion > 18 digits CLR types / hierarchyid / xml datetimeoffset with scale > 2

17 LIMITAZIONI Si può inibire in una query l’uso dell’indice columnstore facendo uso del query hint IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX memory management non eccellente ( no resource governor, index build/re-build, run-time) Consente solo un subset degli operatori di join (scan, filter, project, hash (inner) join and (local) hash aggregation) No batch hash join spilling

18 Demo 1

19 PREMESSA (SQL 2014) Gli indici Columnstore offrono un metodo relativamente semplice per migliorare significativamente l’utilizzo dei datawarehouse MA NON SOLO in termini prestazionali (soprattutto su dataset VERAMENTE grandi) I miglioramenti oscillano tra 10x e 100x I migliori risultati si ottengono per queries effettuate su modelli star-schema che applicano filtri, aggregazioni e raggruppamenti

20 EVOLUZIONE Obiettivi del nuovo columnstore : Prestazioni “competitive” in caricamento e creazione dell’indice più efficiente. Massimizzazione dei fattori di compressione e prestazioni “competitive” delle query. Parità funzionale con il modello row-based.

21 CREAZIONE DI UN INDICE COLUMNSTORE T-SQL SSMS -- Create a columnstore index on the copied table CREATE NONCLUSTERED COLUMNSTORE INDEX csidx_FactOrderCS ON FactOrderCS(DateKey, CustomerKey, ProductKey, Quantity, SalesAmount); CREATE CLUSTERED COLUMNSTORE INDEX csidx_FactOrderCS ON FactOrderCS;

22 CLUSTERED COLUMNSTORE INDEX Righe da caricare Row Groups Segmenti di colonne Columnstore Segmenti di colonne compresse aggiunti al columnstore Deltastore Righe extra aggiunte al Deltastore

23 OrderDateKeyProductKeyStoreKeyRegionKeyQuantitySalesAmount 20101107106011630.00 20101107103042117.00 20101107109042220.00 20101107103032117.00 20101107106053420.00 20101108106021525.00 20101108102021114.00 20101108106032525.00 20101108109011110.00 20101109106042420.00 20101109106042525.00 20101109103011117.00 Un esempio

24 OrderDateKeyProductKeyStoreKeyRegionKeyQuantitySalesAmount 20101107106011630.00 20101107103042117.00 20101107109042220.00 20101107103032117.00 20101107106053420.00 20101108106021525.00 OrderDateKeyProductKeyStoreKeyRegionKeyQuantitySalesAmount 20101108102021114.00 20101108106032525.00 20101108109011110.00 20101109106042420.00 20101109106042525.00 20101109103011117.00 1. Partizionamento orizzontale(Row Groups) ~1M rows

25 OrderDateKey 20101107 20101108 ProductKey 106 103 109 103 106 StoreKey 01 04 03 05 02 RegionKey 1 2 2 2 3 1 Quantity 6 1 2 1 4 5 SalesAmount 30.00 17.00 20.00 17.00 20.00 25.00 OrderDateKey 20101108 20101109 ProductKey 102 106 109 106 103 StoreKey 02 03 01 04 01 RegionKey 1 2 1 2 2 1 Quantity 1 5 1 4 5 1 SalesAmount 14.00 25.00 10.00 20.00 25.00 17.00 2. Partizionamento verticale(Segments)

26 OrderDateKey 20101107 20101108 ProductKey 106 103 109 103 106 StoreKey 01 04 03 05 02 RegionKey 1 2 2 2 3 1 Quantity 6 1 2 1 4 5 SalesAmount 30.00 17.00 20.00 17.00 20.00 25.00 OrderDateKey 20101108 20101109 ProductKey 102 106 109 106 103 StoreKey 02 03 01 04 01 RegionKey 1 2 1 2 2 1 Quantity 1 5 1 4 5 1 SalesAmount 14.00 25.00 10.00 20.00 25.00 17.00 3. Compressione di ogni Segmento

27 OrderDateKey 20101107 20101108 ProductKey 106 103 109 103 106 StoreKey 01 04 03 05 02 RegionKey 1 2 2 2 3 1 Quantity 6 1 2 1 4 5 SalesAmount 30.00 17.00 20.00 17.00 20.00 25.00 OrderDateKey 20101108 20101109 ProductKey 102 106 109 106 103 StoreKey 02 03 01 04 01 RegionKey 1 2 1 2 2 1 Quantity 1 5 1 4 5 1 SalesAmount 14.00 25.00 10.00 20.00 25.00 17.00 4. Lettura dei dati Column Elimination Segment Elimination

28 DIETRO LE QUINTE:

29 GLOSSARIO RowGroup: Gruppo di righe compresse contemporaneamente; ogni colonna è compressa e memorizzata separatamente nel media. Segmento: Unità di memorizzazione di base; ogni colonna può essere in più segmenti; ogni rowgroup contiene un segmento per ciascuna colonna Deltastore: Tabella « provvisoria» che ospita righe fino a che il loro numero raggiunge il limite previsto per il rowgroup

30 MULTI-ROW BATCH – BATCH PROCESSING Motivi: Column store riduce significativamente il fabbisogno di i/o; Una volta che l’ i/o è ridotto, l’uso di CPU diventa il principale collo di bottiglia Il Batch processing riduce l’utilizzo di CPU Funzionalità: Tra gli iteratori (operatori del piano di esecuzione) si muovono NON le righe bensì insiemi di righe chiamati BATCH; indicativamente circa 1000 righe alla volta. I Batches sono organizzati in formato colonnare (a vettori) con un vettore aggiuntivo che indica le righe qualificanti. Ogni batch passa da un iteratore al successivo. Il numero di function calls per riga elaborate cala di alcuni ordini di grandezza. Molte operazioni non necessitano della copia dei dati, ma determinano solo lievi variazioni del batch. bitmap of qualifying rows C1 Column vectors Batch object C2C3

31 GESTIONE DELLA MEMORIA Utilities (build, rebuild, load): I segmenti Columnstore sono costruiti in memoria. Il consumo di memoria si regola quando ci si trova in condizioni di memory pressure (e.g. data load, index build/rebuild). Il medesimo processo di memory grant e reservation è utilizzato dai diversi processi (build/rebuild/load). Run-time : È stato implementato il Batch mode spilling (non è più necessario tornare in “row mode” in caso di spilling).

32 GESTIONE DELLA MEMORIA Cautele: Dimensione ideale del segmento = 1M of rows. Il numero di segmenti (colonne nella tabella) determina i requisiti di memoria. SQL tenta sempre di creare segmenti ideali riservando “abbastanza” memoria. In condizioni di memory pressure: dapprima si riduce il DOP, poi si riduce la dimensione del segmento. In PDW, la memoria disponibile rispetta le impostazioni del resource governor sui nodi.

33 PIANI DI ESECUZIONE L’ottimizzatore opera ora sull’intero set di operatori di join: inner, outer, semi- and anti-semi joins batch-mode hash join con nuova funzionalità di data spilling: Uso temporaneo del disco qualora la tabella non possa essere interamente “contenuta” in memoria

34 OPERAZIONI DML Possono avvenire solo su un indice CLUSTERED INSERT: le righe sono inserite nel deltastore. DELETE: se la riga è nel columnstore, viene «marchiata» ma non fisicamente eliminata dal media, fino alla rebuild dell’indice; se invece è nel deltastore, viene fisicamente eliminata. UPDATE: se la riga è nel columnstore, viene marchiata come cancellata e la «nuova» versione è inserita nel deltastore; se invece è nel deltastore viene aggiornata direttamente

35 MANUTENZIONE REBUILD Tramite ALTER INDEX … REBUILD Tramite CREATE …COLUMNSTORE INDEX …WITH (DROP EXISTING) Rebuild di singola partizione (!!!) REORGANIZE Tramite ALTER INDEX …REORGANIZE Consente di spostare i rowgroups chiusi (CLOSED) dal DeltaStore nel columnstore

36 COMPRESSIONE…

37 Demo 2

38 Q&A Questions?