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

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

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

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

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

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

COLUMN VS. ROW STORE ROW STORE (HEAP / B-TREE) ProductIDOrderDateCost COLUMN STORE (VALORI COMPRESSI) data page 1000 ProductIDOrderDateCost data page 1001 ProductID data page 2001 OrderDate … … … … … … … … data page 2000 data page 2002 Cost

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

CREAZIONE DI UN INDICE COLUMNSTORE T-SQL SSMS

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

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

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

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

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)

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

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

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

Demo 1

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

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.

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;

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

OrderDateKeyProductKeyStoreKeyRegionKeyQuantitySalesAmount Un esempio

OrderDateKeyProductKeyStoreKeyRegionKeyQuantitySalesAmount OrderDateKeyProductKeyStoreKeyRegionKeyQuantitySalesAmount Partizionamento orizzontale(Row Groups) ~1M rows

OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount Partizionamento verticale(Segments)

OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount Compressione di ogni Segmento

OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount Lettura dei dati Column Elimination Segment Elimination

DIETRO LE QUINTE:

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

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

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).

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.

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

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

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

COMPRESSIONE…

Demo 2

Q&A Questions?