Hekaton Christophe LAPORTE
description
Transcript of Hekaton Christophe LAPORTE
#JSS2013
Les journéesSQL Server 2013
Un événement organisé par GUSS
#JSS2013
Les journéesSQL Server 2013
Un événement organisé par GUSS
HekatonChristophe LAPORTE
#JSS2013
Christophe LAPORTE~ depuis 19976.5 <= SQL Server <= 2014
@conseilit
http://conseilit.wordpress.com/
#JSS2013
Merci à nos sponsors
#JSS2013
• Pourquoi ?• Comment ?• Donc …• Du changement ?• Considérations Hardware• Limitations• Migrer ?
Agenda
#JSS2013
• 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
Pourquoi Hekaton ?
#JSS2013
• 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
Comment ?
#JSS2013
• Nouveau moteur• Second moteur InMemory après
Apollo• Tables & index en mémoire• Compilation native des procédures• Plus de locks ni de latches
Hekaton …
#JSS2013
« Les » moteurs SQL ServerT-SQL
ParserMetadata Management
Query Optimizer
Relational Query Engines
Memory
Catalogs
DB & Log
Apollo(Column Store)
Hekaton
#JSS2013
• 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
Du changement ?
#JSS2013
SCHEMA_AND_DATA
• 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
SCHEMA_ONLY• Données volatiles• Ne résiste pas à une restart• Encore plus performant que SCHEMA_AND_DATA
Durabilité des transactions 1/3
#JSS2013
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
Durabilité des transactions 2/3
#JSS2013
Durabilité des transactions 3/3COMMIT 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
• Création d’une base • Création d’une table
Démonstration
#JSS2013
Un enregistrement dans Hekaton
#JSS2013
• 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
Verrouillage – Concurrence d’accès
#JSS2013
• 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
Compilation native
#JSS2013
• Native Compiled ProcedureDémonstration
#JSS2013
• 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
Gestion des index
#JSS2013
Hash Index
#JSS2013
Range IndexThe Bw-Tree: A B-tree for New Hardware Platforms
http://research.microsoft.com/pubs/178758/bw-tree-icde2013-final.pdf
#JSS2013
Démo
#JSS2013
• 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
Hardware – mémoire
#JSS2013
• 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 ???
Hardware - disque
#JSS2013
• 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
Limitations (SQL 2014)
#JSS2013
• 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
Limitations (SQL 2014) … encore (désolé)
#JSS2013
• 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
RTO / Recovery
#JSS2013
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
Migrer ?
#JSS2013
• 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
Par où commencer ?
#JSS2013
• Performant• Facilité
– Installation– Exploitation– Intégration
• Nécessite quelques ajustements• Mais ce n’est qu’une V1 !!!
Conclusion
#JSS2013
• 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
Questions / réponses
#JSS2013#JSS2013