Hekaton: Multiversion Concurrency Control ed indici

SQL Server 2014Hekaton – Multiversion Concurrency Control

Francesco Milano

[email protected]

PILLS SPONSORS

SQL Server5+ anni di esperienzaSQL Server 2005, 2008, 2008R2, 2012Progettazione, sviluppo, integrazione, ottimizzazioneData Platform Specialist @ SolidQ

.NET10+ anni di esperienzaFocus primario su soluzioni Web e Back-End

Membro UGISSSpeaker, blogger

Francesco Milano

Hekaton – In Memory Tables (Davide Mauri)

http://vimeo.com/83218500

What’s before




SQL Server 2014 introduce importanti novità per ottimizzare accesso e modifica di dati completamente in memoryNuova struttura di indici e tabelle

Nuovo meccanismo di concorrenza lock-free e latch-free

Sono gli indici a legare tra loro le righe

Almeno un indice deve esistere per ogni tabella

Hekaton – Multiversion Concurrency Control

Le tabelle in memory supportano due tipologie di indiciHash indexesRange indexes (CTP2)

Gli indici sono definiti e creati contestualmente alla tabella

Non vengono mai persistiti su disco

Massimo 8 indici per tabella



From: In-Memory OLTP WhitePaper - http://bit.ly/1fndSuf

http://bit.ly/1fndSuf



Hash indexesArray di puntatori

Ogni elemento è chiamato hash bucket

Per ogni riga viene calcolato un hash sulle sue colonne chiave

Chiavi che producono le stesso hash sono accedute dallo stesso hash bucket e sono legate tra loro in una catena

Ideali per chiavi con cardinalità ragionevolmente nota a priori e per richerche puntuali



Range indexes (BW-Tree)Ogni pagina ha un proprio PID. Il collegamento con l’indirizzo di memoria della pagina avviene tramite una tabella di mapping

Le pagine hanno dimensione variabile (massimo 8k) e non vengono mai modificate; INSERT o DELETE di una chiave generano Delta pages che integrano la variazione

Le pagine foglia contengono un puntatore alle righe in memoria; come per gli indici hash, righe con chiavi uguali sono legate in una catena

Ideali per chiavi di cui non è ipotizzabile a priori il bucket count o che verranno cercate per range di valori



Le operazioni sui dati di tabelle in memory usano sempre un Optimistic Multiversion Concurrency Control (MVCC)

Le righe non vengono modificate direttamente, ma vengono create nuove versioni della stessa riga con finestre temporali di validità piùrecenti

Lavorando in concorrenza ottimistica, se due transazioni attivecercano di modificare la stessa riga, la seconda transazione vieneabortita

E’importante gestire il retry dell’operazione


Un contatore monotonico crescente, identificato come timestamp, viene incrementato ad ogni commit di una transazione

Ogni versione di un record possiede due timestamps:Begin-Ts – commit time della transazione che l’ha generataEnd-Ts – commit time della transazione che l’ha “eliminata”

Il periodo di validità (valid time) della versione di un record denota ilrange di timestamps in cui tale versione risulta visibile alle altretransazioni


TX1 (ID = 89)1) Begin timestamp = 240

2) DELETE Greg, Lisbon

3) UPDATE Jane, Helsinki

To -> Jane, Perth

4) Commit TX1End timestamp = 250



89

89

89


Sistema concettualmente simile allo SNAPSHOT Isolation, ma:Nessun carico sul TempDBNessun blocco in UPDATE o DELETE

Pienamente transazionale (ACID properties)

Scritture nel Transaction Log drasticamente ridotteFootprint minimoDati sporchi non vengono mai persistiti


Hekaton - Natively Compiled Stored Procedures

What’s next

Grazie!Trovi altri video su:

www.ugiss.org/sql-server-2014-

pills

Hekaton: Multiversion Concurrency Control ed indici

Technology

Transcript of Hekaton: Multiversion Concurrency Control ed indici