Les journées SQL Server 2013 ont présenté Hekaton, un nouveau moteur de base de données in-memory, offrant des performances améliorées grâce à une réduction des verrous et des latches. Les participants ont découvert des innovations sur la durabilité des transactions, la gestion des index et les limitations de SQL Server 2014, ainsi que des outils pour migrer vers Hekaton. L'événement a mis l'accent sur les bénéfices de performance et l'intégration de ce moteur dans SQL Server tout en attirant l'attention sur ses contraintes.

1. Les journées
SQL Server 2013
Un événement organisé par GUSS
#JSS2013

2. Les journées
SQL Server 2013
Hekaton
Christophe LAPORTE
Un événement organisé par GUSS
#JSS2013

3. Christophe LAPORTE
~ depuis 1997
6.5 <= SQL Server <= 2014
christophe_laporte@hotmail.fr
http://conseilit.wordpress.com/
@conseilit
#JSS2013

4. Merci à nos sponsors
#JSS2013

5. Agenda
•
•
•
•
•
•
•
Pourquoi ?
Comment ?
Donc …
Du changement ?
Considérations Hardware
Limitations
Migrer ?
#JSS2013

6. Pourquoi Hekaton ?
• Les disques flash sont plus rapides que les
disques rotatifs mais moins rapide que la RAM
• La quantité de mémoire augmente / le prix
diminue
• La puissance des CPU double tous les 2 ans,
mais la fréquence ne croit plus
• Tous les SGBD sont matures / optimisés
• Il faut trouver de nouvelles voies pour
augmenter les perfs
#JSS2013

7. Comment ?
• Supprimer des lignes de code
• Les latches
– Mécanismes de protection des ressources partagées comme le buffer pool
• Les locks
– Mécanismes de contrôle de concurrence d'accès
– Poser un verrou nécessite plusieurs latches …
• Les plans d'exécutions
–
–
–
–
Bien que compilés sont interprétés
Compilation = parsing / algébrisation / optimisation
Mais l'interpréteur va parcourir chaque élément de l'arbre du plan d'exécution
Cout d'interprétation
• Données sur disque -> négligeable
• Données en mémoire -> important
#JSS2013

8. Hekaton …
•
•
•
•
•
Nouveau moteur
Second moteur InMemory après Apollo
Tables & index en mémoire
Compilation native des procédures
Plus de locks ni de latches
#JSS2013

9. « Les » moteurs SQL Server
T-SQL
Parser
Metadata Management
Catalogs
Query Optimizer
Apollo
(Column
Store)
Relational
Hekaton
Query
Engines
Memory
DB & Log
#JSS2013

10. Du changement ?
• On ne change rien (ou presque) et ça change tout !
– Un requête peut être exécutée sur les 3 moteurs …
– Le mode Interop permet d'accéder à une table InMemory
• On change tout (ou presque) et ça ne change rien tout
– Réécrite d'une procédure en version compilation native
• Appel inchangé
• Le client ne sait pas ce qu‘il se passe en arrière-plan
• Pleinement Intégré à SQL Server !
–
–
–
–
Installation
Sauvegardes
HA (groupe de disponibilité, fci)
Perfmon, XEvent, DMVs
#JSS2013

11. Durabilité des transactions 1/3
SCHEMA_AND_DATA
SCHEMA_ONLY
•
•
•
•
•
Transactions durables, pas de perte de données
Commit de transactions « synchrone »
Ecrites dans TLog avant de rentre le contrôle à l’utilisateur
Persisté sur disque juste avant le succès du commit
Option par défaut
• Données volatiles
• Ne résiste pas à une restart
• Encore plus performant que SCHEMA_AND_DATA
#JSS2013

12. Durabilité des transactions 2/3
•
•
•
•
DELAYED_DURABILITY
Ecriture asynchrone du Tlog
Enregistré dans un buffer qui est ensuite flushé sur disque
Commit n’attends pas les IO du Tlog
Si transactions concurrentes, bufferise et ensuite écrit des gros
blocs
• Tolère des pertes de données
• Convient à des charge de travail élevée
• Peut se gérer niveau
• Database
• Bloc de code
• Commit
#JSS2013

13. Durabilité des transactions 3/3
COMMIT setting
/
Database setting
DELAYED_DURABILITY =
DISABLED (default)
DELAYED_DURABILITY =
ALLOWED
DELAYED_DURABILITY =
FORCED
DELAYED_DURABILITY = OFF
In-Memory OLTP only
transaction. (OFF)
Transaction is fully durable.
Transaction is fully durable.
Transaction is delayed
durable.
DELAYED_DURABILITY = ON
In-Memory OLTP only
transaction.
Transaction is fully durable.
Transaction is delayed
durable.
Transaction is delayed
durable.
DELAYED_DURABILITY = OFF
Cross database or
distributed transaction.
Transaction is fully durable.
Transaction is fully durable.
Transaction is fully durable.
DELAYED_DURABILITY = ON
Cross database or
distributed transaction.
Transaction is fully durable.
Transaction is fully durable.
Transaction is fully durable
#JSS2013

14. Démonstration
•
Création d’une base
•
Création d’une table
#JSS2013

15. Un enregistrement dans Hekaton
#JSS2013

16. Verrouillage – Concurrence d’accès
• On assume que les conflits sont rares
• 3 techniques combinées
– Verrouillage optimiste
– Transaction se déroule sans verrouillage
– Conflits détectés lors de la phase de validation
• Multi version
– Update engendre un nouvel enregistrement
– Donc pas de locks !
• TimeStamps
– Utilisation du TimeStamp de début de transaction pour obtenir la
bonne version de l’enregistrement
• Démo
#JSS2013

17. Compilation native
• Procédures stockées
– Pas pour les requêtes Ad-Hoc
– Attention : plan d'exécution déterminé au moment de la compilation
• Les données présentes dans la table doivent être représentatives
• Les statistiques DOIVENT être à jour
– Compilation intervient
• Lors de la création de la SP
• Lorsque la base est mise Online
• Pourquoi ?
– Eviter l’interprétation du plan d’ exécution
– Réduction du nombre d’instructions / transaction
– Gagner en performance
• Comment ?
– Génération de code C
#JSS2013

18. Démonstration
• Native Compiled Procedure
#JSS2013

19. Gestion des index
•
•
•
•
Création concomitante à la table
Ne sont présents qu’en mémoire
1 minimum, 8 maximum
2 types d’index
– Hash
• Tableau de pointeurs
• Pointe vers les enregistrements
– Range
• Recherches sur des intervalles
• BUCKET_COUNT difficile à estimer
• BW-Tree
#JSS2013

20. Hash Index
#JSS2013

21. Range Index
The Bw-Tree: A B-tree for New Hardware Platforms
http://research.microsoft.com/pubs/178758/bw-tree-icde2013-final.pdf
#JSS2013

22. Démo
#JSS2013

23. Hardware – mémoire
• 2 fois la taille des données
• Limitations de mémoire embedded
– 80 % maximum
– Gestion via le resource governor
• Attention à le pas consommer trop au
détriment du buffer pool
• Possibilité de jouer avec le Buffer Pool Extension
– Clean pages sur disque rapide
#JSS2013

24. Hardware - disque
• 2 à 3 fois espace d'une disk based table
– Insert
• Écriture dans fichier Data (128MB / « Pages » de 256KB)
– Update
• Nouvelle version de l’enregistrement dans fichier Data
– Delete
• Ecriture de la suppression dans fichier Delta
– Checkpoint
• Force la fermeture de fichier Data => augmentation de l’espace
– Merge
• Fusionne des paires de fichiers Data/Delta
• SSD ou fusion IO car très peu de latence
• N'oubliez pas l'espace pour les index !
• Non ! Personne ne suit dans la salle ???
#JSS2013

25. Limitations (SQL 2014)
• Prévu pour du High Troughput OLTP
– Rows 8060 max :
• Pas de type off row ou LOB (varchar max), sqlvariant
– Pas de types CLR (XML ...)
– Pas de triggers
• Design / Exploitation
–
–
–
–
–
Pas de FK
Pas de check
Pas de identity
Pas de alter table => drop / create table
Pas de create index => drop / create table
#JSS2013

26. Limitations (SQL 2014) … encore (désolé)
TRUNCATE TABLE
MERGE (table cible de type InMemory)
Dynamic and keyset cursors (degrades en curseurs statiques)
Requêtes Cross-database
Transactions Cross-database / transactions distribuées
Serveurs liés
Locking hints: TABLOCK, XLOCK, PAGLOCK, , etc. (NOLOCK est
supporté mais ignoré)
• Isolation level hints READUNCOMMITTED, READCOMMITTED
et READCOMMITTEDLOCK
•
•
•
•
•
•
•
#JSS2013

27. RTO / Recovery
• Phase d’analyse
– Recherche du dernier checkpoint
• Chargement des données
– Depuis les fichiers data/delta
– Effectuée en // : 1 thread par fichier
– Performance et RTO dictés par performance disque
• Phase de REDO
– Rejouer les transactions depuis dernier checkpoint
– Performance et RTO dictés par redo concurrent sur
• Tables Hekaton
• Tables « disk based »
• Phase de UNDO
– Seulement pour les tables « disk based »
– Tables Hekaton : seules les transactions avec commit sont loguées
#JSS2013

28. Migrer ?
Oui
•
•
•
•
•
•
•
Faible latence
Concurrence d’accès
Lock
Latch
Table values parameters
Tables « Temporaire »
Lookups
Non
•
•
•
•
•
•
Très gros volumes
Types de données
Contraintes
Schéma peu stable
Table scan
Sharepoint
#JSS2013

29. Par où commencer ?
• AMR Tool (Analyze, Migration, Reporting)
–
–
–
–
Identifie tables et procédures candidat à migration
Identifie tables et procédures ne pouvant pas migrer
Aperçu des gains de performance possibles
Démo
#JSS2013

30. Conclusion
• Performant
• Facilité
– Installation
– Exploitation
– Intégration
• Nécessite quelques ajustements
• Mais ce n’est qu’une V1 !!!
#JSS2013

31. Questions / réponses
• Merci pour votre présence
• Des articles et des scripts sur
http://conseilit.wordpress.com/?s=hekaton
• Les speakers des JSS sont là pour répondre
à toutes vos questions
#JSS2013

32. #JSS2013
#JSS2013