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
Hekaton – Multiversion Concurrency Control
Hekaton – Multiversion Concurrency Control
From: In-Memory OLTP WhitePaper - http://bit.ly/1fndSuf
Hekaton – Multiversion Concurrency Control
From: In-Memory OLTP WhitePaper - 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
Hekaton – Multiversion Concurrency Control
From: In-Memory OLTP WhitePaper - http://bit.ly/1fndSuf
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
Ideali per chiavi di cui non è ipotizzabile a priori il bucket count o che verranno cercate per range di valori
From: In-Memory OLTP WhitePaper - http://bit.ly/1fndSuf
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
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 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
Hekaton – Multiversion Concurrency Control
TX1 (ID = 89)1) Begin timestamp = 240
2) DELETE Greg, Lisbon
3) UPDATE Jane, Helsinki
To -> Jane, Perth
4) Commit TX1End timestamp = 250
Hekaton – Multiversion Concurrency Control
From: In-Memory OLTP WhitePaper - http://bit.ly/1fndSuf
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 – Multiversion Concurrency Control
Hekaton - Natively Compiled Stored Procedures
What’s next
Grazie!Trovi altri video su:
www.ugiss.org/sql-server-2014-
pills