presenta – #wpc15it1 BI008 - SQL Server 2016: Evoluzione dei Columnstore Indexes e maturazione dell'In-Memory OLTP 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 Requisiti Premesse (2012)  Columnstore 2012  Limitazioni Premesse (2014)  Columnstore 2014  Limitazioni Terzo passo …(2016) Hekaton (2014) Memory-optimized tables  Indexes Transaction Log streams Checkpoint streams Natively compiled Objects What’s NEW? –

4 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

– 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

– 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

– 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

– Creazione di un indice columnstore T-SQL  SSMS

– 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

– 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

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

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

– 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…

– Esecuzione in batch di queries in single thread Supporto per Snapshot isolation e Read Committed Snapshot Isolation Definizione di columnstore index durante la creazione di una tabella Supporto ad indici columnstore UPDATABLE nelle repliche secondary di AlwaysOn Indici columnstore NON clustered AGGIORNABILI (tanto su heap quanto su b-tree) Indici b-tree su un indice columnstore clustered Indice columnstore NON clustered FILTRATO Terzo passo… SQL Server 2016

– Di conseguenza: “REAL TIME OPERATIONAL ANALYTICS”  La possibilità di creare indici columnstore updatable su una tabella OLTP  Diventa possibile (e ragionevole) accedere alla tabella tanto per attività transazionali (OLTP) quanto per analisi dati… in tempo reale Ma anche per i nostri datawarehouse…  La presenza contemporanea di indici non clustered “tradizionali” insieme al columnstore permette accessi efficienti anche in seek (accessi puntuali o su piccoli intervalli di righe) Terzo passo… SQL Server 2016

– Manutenzione:  REBUILD: rimuove eventuali frammentazioni e porta tutte le righe nel columnstore; per ora è un’operazione offline, quindi la tabella o la partizione in rebuild non è disponibile per la durata del processo.  REORGANIZE: deframmenta il columnstore portando le righe dei deltastores chiusi nel columnstore e elimina le righe DELETED. Terzo passo… SQL Server 2016

– Hekaton  Cosa è Hekaton  Hekaton = In-Memory Optimized OLTP  La risposta all’esigenza di prestazioni sempre maggiori e dati sempre accessibili/disponibili  In greco Hekaton significa 100  100x di miglioramento delle prestazioni  Hekaton è un nuovo engine  Nativo in SQL Server  Poche modifiche ai DB esistenti (con le dovute cautele....)  Miglioramenti nelle prestazioni senza modifiche Sw e Hw

– Hekaton  Cosa NON è Hekaton  Hekaton NON è l’ecquivalente dell’istruzione DBCC PINTABLE  Comunque DBCC PINTABLE era mantenuta per retrocompatibilità ma non funziona...  Hekaton NON è Buffer Pool Extension  Hekaton NON è la panacea di tutti i mali dei DB  Hekaton non è MongoDb...

SQL Server engine (con Hekaton)…oggi TDS handler and Session Management Sql Server.exe Parser, Catalog, Optimizer Interpreted T-SQL Query execution Tables… Indexes… Buffer Pool for tables & Indexes In-memory OLTP Compiler Natively compiled SPs and Schema Query Interop Tables… Indexes… Memory Optimized Tables & Indexes Client Application

Storage Sono interamente in memoria Non richiedono I/O sul disco per reperire i dati  Non è del tutto vero ma per ora va bene così Non usano Datapages ed Extent  Non usano nessuna delle strutture a cui siamo abituati Durability Schema & Data =>Dati non volatili => User Tables Schema Only => Dati Volatili => Staging Tables Memory-optimized Tables

Una In-Memory Table è composta da : Rows  Nuova struttura ottimizzata per la RAM  Multiversioning (no lock, no blocking, no latch) Index  NO B-TREE  L’indice punta la riga, non la duplica  2 tipi di indici  Hash  Range Index Memory-optimized Tables

Struttura della riga: Header = descrittore iniziale del record Payload = Record Memory-optimized Tables

Begin Ts = Timestamp Inizio validità riga (8 Bytes) End Ts = Fine validità riga (8 Bytes).  Se la riga è in corso di validità assume il nuovo valore «Infinity» StmtId (4 Bytes)  Id dello statement che ha modificato la riga IdxLinkCount (2 Bytes)  Numero di indici IdxPointer (8 bytes * n Indici)  Puntatore a ciascun indice che referenzia la riga Memory-optimized Tables

Limitazioni (2014) Non tutti i tipi di dato sono supportati  Xml  Clr  Type(MAX) i.e. Varchar(max)  Lunghezza massima di una riga 8060 Bytes No Foreign Key No Check No DML Trigger No Unique Index oltre alla Primary key No Identity No ALTER post creazione !!!! Memory-optimized Tables

Quando inseriamo una riga Una Funzione di Hash è applicata a tutte le colonne chiave (key column) della riga e determina a quale bucket la riga sarà associata Nel caso che più righe restituiscano il medesimo Hash, viene creata una catena di righe (Row Chain) (…tra poco) Ogni Hash Bucket ha una dimensione di 8 Bytes  Non sprecare Ram esagerando con il numero di bucket  Non essere troppo restrittivi: le Row Chain possono degradare molto le prestazioni Hash Index

CREATE TABLE Hash_MemoryTable ( id int not null PRIMARY KEY NONCLUSTERED HASH WITH(BUCKET_COUNT = 1024),Campo char(30) not null ) WITH( MEMORY_OPTIMIZED = ON,DURABILITY = SCHEMA_AND_DATA ); GO

Q & A DEMO – #wpc15it34

Range Index Bw-Tree (Buzz World) Simile ai B-Tree che conosciamo ma più performanti Utili se non conosciamo la cardinalità dei dati o faremo ricerche su range di valori

Range Index Data Pages a dimensione variabile, al max 8 Kb Ogni Datapage ha un PID Logical page number Page Mapping Table Traduzione da PID a physical Address

Range Index

CREATE Table Range_MemoryTable ( id int not null PRIMARY KEY NONCLUSTERED,Campo char(30) not null )WITH ( MEMORY_OPTIMIZED = ON,DURABILITY = SCHEMA_AND_DATA ); GO

La durabilità dei dati è garantita da  Log Streams  Sfrutta il T-Log del DB  Ogni transazione è registrata nel T-Log  Checkpoint Streams  Files di checkpoint gestiti tramite Filestream Il contenuto combinato di Log e Checkpoint Stream è sufficiente a ricostruire le tabelle point in time in caso di necessità Transaction Log Stream

La scrittura delle transazioni delle In-Memory Tables è ottimizzata al fine da ridurre il più possibile l’I/O Con un unico record di Log è possibile registrare multiple Insert, Update e Delete Le operazioni sugli indici non necessitano di Log, vengono ricostruiti in caso di bisogno Transaction Log Stream

Checkpoint Streams  Data Streams = Contiene tutte le righe inserite in un determinato intervallo di tempo  Delta Streams = Associato ad un Data Streams contiene la lista delle righe eliminate in un determinato intervallo di tempo Checkpoint Stream

Data e delta file sono popolati da un thread in background denominato offline checkpoint Checkpoint Stream Memory Optimized Data Filegroup Range Range Range Range Range 500- offline checkpoint Thread Una transazione con un timestamp di 600 aggiunge una riga e ne elimina n inserite da una transazione con commit timestamp di 150, 250 E 420

Con l’andare del tempo il numero di coppie Data e Delta aumenterà Per mantenere basso il numero di coppie e la quantità di spazio allocata su disco, periodicamente parte un processo di Merge. Periodicamente coppie di Data e Delta file, il cui contenuto è riconducibile a 128 MB, vengono unificati in un solo Data file. In casi particolari è possibile invocare il merge dei file con stored procedure sys.sp_xtp_merge_checkpoint_files Checkpoint Stream

Merge Memory Optimized Data Filegroup Range Range Range Range Range Range Range Range Merge Range Range

Il linguaggio T-SQL è lento per sua natura.... Cosa c’è di più veloce di un modulo C compilato e caricato in memoria ?!?! Possiamo creare SP in T-SQL ma renderle veloci come dei moduli C caricati in memoria !! Natively Compiled Objects

CREATE PROCEDURE int not null WITH NATIVE_COMPILATION,SCHEMABINDING,EXECUTE AS OWNER AS BEGIN ATOMIC WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = 'us_english' ) varchar(25) = A.campo FROM dbo.Memorytable A WHERE A.id UPDATE dbo.Memorytable SET campo = campo + 'AAAA' WHERE id DELETE FROM dbo.Memorytable WHERE id INSERT INTO END GO

L’accesso alle In-Memory Tables può essere effettuato tanto da codice interpretato (tramite Interop), quanto da natively compiled stored procedures Interop non supporta:  TRUNCATE TABLE  MERGE (se il target è una in-memory table)  Cursori dinamici e keyset (questi degradano automaticamente a statici)  Query cross-database  Transazioni cross-database  Linked Servers  Locking hints: TABLOCK, XLOCK, PAGLOCK, ecc.  Isolation level READ UNCOMMITTED, READ COMMITTED, READ COMMITTEDLOCK T-SQL (2014!)

MEMORIA Evoluzione SQL 2014SQL 2016 Si raccomanda un utilizzo massimo di 256 GB di memoria per le memory-optimized table. Non è un limite fisico ma un suggerimento basato sul numero di checkpoint files necessari Il numero di checkpoint files supportati è esteso, e Microsoft ha testato vari scenari portando il suggerimento a un utilizzo massimo di 2 TB

COLLATION Evoluzione SQL 2014SQL 2016 Tutte le colonne alfanumeriche (char, varchar, nchar e nvarchar) utilizzate in indici devono usare una collation BIN2; in una Natively compiled sp i confronti tra valori alfanumerici devono usare una collation BIN2 Le colonne alfanumeriche degli indici ed i confronti tra valori alfanumerici nelle NCSP possono far uso di qualsiasi collation. Vi sono tuttavia differenze prestazionali ancora a favore di BIN2

MODIFICHE A SCHEMA E DATI Evoluzione SQL 2014SQL 2016 Non è possibile modificare una memory-optimized table dopo la creazione. In sintesi, non è consentito l’uso dello statement ALTER TABLE ALTER TABLE può essere utilizzato per aggiungere, modificare o eliminare colonne e per aggiungere, eliminare o ricostruire (REBUILD) indici

PARALLELISMO Evoluzione SQL 2014SQL 2016 Per operazioni di accesso a memory-optimized tables non viene MAI generato un piano parallelo Viene considerato un piano parallelo per alcune operazioni che utililizzano hash indexes (purché non siano in una NCSP)

TDE (Transparent Data Encryption) Evoluzione SQL 2014SQL 2016 Un database seppur abilitato all’encryption non sottopone ad encryption dati memorizzati nel filegroup MEMORY_OPTIMIZED_DATA Supporto completo per Transparent Data Encryption: Le memory-optimized tables persistite su disco sono assoggettabili ad encryption

Native Compilation Evoluzione SQL 2014SQL 2016 L’Articolo Transact-SQL Constructs Not Supported by In-Memory OLTP della SQL Server Documentation elenca un nutrito schieramento di limitazioni e costrutti non supportati dale Native Compiled Stored Procedures Supporto introdotto per: LEFT and RIGHT OUTER JOIN SELECT DISTINCT OR and NOT operators Subqueries in tutte le clausole del SELECT statement Nested stored procedure calls UNION and UNION ALL All built-in math functions

FILESTREAM Evoluzione …nascosta SQL 2014SQL 2016 Il File System del Sistema Operativo supporta la scrittura sui files poggiando sulla tecnologia FILESTREAM; tuttavia questo richiede una tabella (xtp_storage) che contiene una Colonna filestream che il filegroup MEMORY_OPTIMIZED_DATA usa per backup FILESTREAM è utilizzato solo per offrire visibilità al filegroup MEMORY_OPTIMIZED_DATA; la gestione dei files di checkpoint è affidata all’engine che chiama direppamente API dell’NTFS; ciò traspare in interfaccia per una diversa struttura del folder del filegroup rispetto a 2014

LOG READER Evoluzione …nascosta SQL 2014SQL 2016 Per la lettura di transazioni dal log che impattano su memory-optimized tables, viene attivato un singolo thread per database. Ciò avviene tanto durante il recovery quanto in presenza di AlwaysOn. Sono manifesti alcuni problemi di scalabilità Per le attività di recovery e di checkpoint, per lettura ed utilizzo delle transazioni logged sono disponibili più thread, in relazione al numero di cores disponibili

AlwaysOn Evoluzione …nascosta SQL 2014SQL 2016 La visibilità dei dati di in-memory OLTP sulle repliche secondarie subisce una dilazione di alcune transazioni La latenza tende ad essere annullata: dopo una commit sulla replica primaria un accesso alla secondaria raramente omette le ultime modifiche apportate

Garbage Collecxtion Evoluzione …nascosta SQL 2014SQL 2016 I thread interni di garbage collection utilizzati possono subire – a fronte di carichi di lavoro particolarmente onerosi – una latenza percepibile nel rilascio della memoria impegnata da oggetti cancellati Miglioramenti agli algoritmi di garbage collection fanno si che – con sufficiente disponibilità di risorse – il garbage delle operazioni DML avvenga in tempo quasi-reale

– Connubio tra Columnstore technology e In Memory OLTP: Possibilità di creare NONCLUSTERED COLUMNSTORE INDEX su una memory-optimized table  Attualmente SOLO durante la CREATE… Possibilità di creare contestualmente indici B-Tree e Columnstore Per non dimenticarci cose importanti…

Q & A DEMO – #wpc15it59

Q & A Domande e Risposte – #wpc15it60

Corsi consigliati Fondamentalmente: -TechNet (In-Memory OLTP (In-Memory Optimization – us/library/dn133186(v=sql.130).aspx ) us/library/dn133186(v=sql.130).aspx -SQL Server Documentation (SQL 2014 e SQL 2016) us/library/gg492088(v=sql.130).aspxhttps://msdn.microsoft.com/en- us/library/gg492088(v=sql.130).aspx -MSDN (In-Memory OLTP (In-Memory Optimization - us/library/dn133186(v=sql.130).aspx ) us/library/dn133186(v=sql.130).aspx -WHITE Papers: -SQL_Server_2014_In-Memory_OLTP_TDM_White_Paper.pdf -SQL_Server_2016_In-Memory_OLTP_White_Paper.pdf – #wpc15it61

Contatti OverNet Education OverNet Education Tel – #wpc15it62