1 / 32

Hekaton Christophe LAPORTE

Hekaton Christophe LAPORTE. Christophe LAPORTE. ~ depuis 1997 6.5 <= SQL Server <= 2014. @ c onseilit. christophe_laporte@hotmail.fr. http://conseilit.wordpress.com/. Merci à nos sponsors. Agenda. Pourquoi ? Comment ? Donc … Du changement ? Considérations Hardware Limitations

neka
Télécharger la présentation

Hekaton Christophe LAPORTE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hekaton Christophe LAPORTE

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

  3. Merci à nos sponsors

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

  5. 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

  6. 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

  7. 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

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

  9. 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 Interoppermet 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

  10. Durabilité des transactions 1/3

  11. Durabilité des transactions 2/3

  12. Durabilité des transactions 3/3

  13. Démonstration • Création d’une table • Création d’une base

  14. Un enregistrement dans Hekaton

  15. 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

  16. 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

  17. Démonstration • Native CompiledProcedure

  18. 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

  19. Hash Index

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

  21. Démo

  22. 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

  23. Hardware - disque • 2 à 3 fois espace d'une diskbasedtable • 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 ???

  24. 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

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

  26. 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 « diskbased » • Phase de UNDO • Seulement pour les tables « diskbased » • Tables Hekaton: seules les transactions avec commit sont loguées

  27. Migrer ?

  28. 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

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

  30. 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

More Related