3. Francesco Milano
SQL Server
5+ anni di esperienza
SQL Server 2005, 2008, 2008R2, 2012
Progettazione, sviluppo, integrazione, ottimizzazione
Data Platform Specialist @ SolidQ
.NET
10+ anni di esperienza
Focus primario su soluzioni Web e Back-End
Membro UGISS
Speaker, blogger
5. Hekaton – Multiversion Concurrency
Control
SQL Server 2014 introduce importanti novità per
ottimizzare accesso e modifica di dati completamente in
memory
Nuova 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
6. Hekaton – Multiversion Concurrency
Control
Le tabelle in memory supportano due tipologie di indici
Hash indexes
Range indexes (CTP2)
Gli indici sono definiti e creati contestualmente alla tabella
Non vengono mai persistiti su disco
Massimo 8 indici per tabella
8. Hekaton – Multiversion Concurrency
Control
Hash indexes
Array 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
From: In-Memory OLTP WhitePaper - http://bit.ly/1fndSuf
10. Hekaton – Multiversion Concurrency
Control
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
From: In-Memory OLTP WhitePaper - http://bit.ly/1fndSuf
Ideali per chiavi di cui non è ipotizzabile a
priori il bucket count o che verranno cercate
per range di valori
11. Hekaton – Multiversion Concurrency
Control
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 attive
cercano di modificare la stessa riga, la seconda transazione viene
abortita
E’importante gestire il retry dell’operazione
12. Hekaton – Multiversion Concurrency
Control
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 generata
End-Ts – commit time della transazione che l’ha “eliminata”
Il periodo di validità (valid time) della versione di un record denota il
range di timestamps in cui tale versione risulta visibile alle altre
transazioni
13. Hekaton – Multiversion Concurrency
Control
TX1 (ID = 89)
1) Begin timestamp =
240
89
2) DELETE Greg, Lisbon
3) UPDATE
Jane, Helsinki
To -> Jane, Perth
89
89
4) Commit TX1
End timestamp = 250
From: In-Memory OLTP WhitePaper - http://bit.ly/1fndSuf
14. Hekaton – Multiversion Concurrency
Control
Sistema concettualmente simile allo SNAPSHOT Isolation, ma:
Nessun carico sul TempDB
Nessun blocco in UPDATE o DELETE
Pienamente transazionale (ACID properties)
Scritture nel Transaction Log drasticamente ridotte
Footprint minimo
Dati sporchi non vengono mai persistiti