Les journées

SQL Server 2013

Un événement organisé par GUSS

#JSS2013
Les journées

SQL Server 2013

Hekaton

Christophe LAPORTE

Un événement organisé par GUSS

#JSS2013
Christophe LAPORTE
~ depuis 1997

6.5 <= SQL Server <= 2014

christophe_laporte@hotmail.fr
http://conseilit.wordpress.com/...
Merci à nos sponsors

#JSS2013
Agenda
•
•
•
•
•
•
•

Pourquoi ?
Comment ?
Donc …
Du changement ?
Considérations Hardware
Limitations
Migrer ?
#JSS2013
Pourquoi Hekaton ?
• Les disques flash sont plus rapides que les
disques rotatifs mais moins rapide que la RAM
• La quanti...
Comment ?
• Supprimer des lignes de code
• Les latches

– Mécanismes de protection des ressources partagées comme le buffe...
Hekaton …
•
•
•
•
•

Nouveau moteur
Second moteur InMemory après Apollo
Tables & index en mémoire
Compilation native des p...
« Les » moteurs SQL Server
T-SQL
Parser
Metadata Management

Catalogs

Query Optimizer

Apollo
(Column
Store)

Relational
...
Du changement ?
• On ne change rien (ou presque) et ça change tout !
– Un requête peut être exécutée sur les 3 moteurs …
–...
Durabilité des transactions 1/3

SCHEMA_AND_DATA

SCHEMA_ONLY

•
•
•
•
•

Transactions durables, pas de perte de données
C...
Durabilité des transactions 2/3
•
•
•
•
DELAYED_DURABILITY

Ecriture asynchrone du Tlog
Enregistré dans un buffer qui est ...
Durabilité des transactions 3/3
COMMIT setting
/
Database setting

DELAYED_DURABILITY =
DISABLED (default)

DELAYED_DURABI...
Démonstration
•

Création d’une base

•

Création d’une table

#JSS2013
Un enregistrement dans Hekaton

#JSS2013
Verrouillage – Concurrence d’accès
• On assume que les conflits sont rares
• 3 techniques combinées

– Verrouillage optimi...
Compilation native
• Procédures stockées

– Pas pour les requêtes Ad-Hoc

– Attention : plan d'exécution déterminé au mome...
Démonstration
• Native Compiled Procedure

#JSS2013
Gestion des index
•
•
•
•

Création concomitante à la table
Ne sont présents qu’en mémoire
1 minimum, 8 maximum
2 types d’...
Hash Index

#JSS2013
Range Index

The Bw-Tree: A B-tree for New Hardware Platforms

http://research.microsoft.com/pubs/178758/bw-tree-icde2013-...
Démo

#JSS2013
Hardware – mémoire
• 2 fois la taille des données
• Limitations de mémoire embedded
– 80 % maximum
– Gestion via le resour...
Hardware - disque
• 2 à 3 fois espace d'une disk based table

– Insert
• Écriture dans fichier Data (128MB / « Pages » de ...
Limitations (SQL 2014)
• Prévu pour du High Troughput OLTP

– Rows 8060 max :
• Pas de type off row ou LOB (varchar max), ...
Limitations (SQL 2014) … encore (désolé)
TRUNCATE TABLE
MERGE (table cible de type InMemory)
Dynamic and keyset cursors (d...
RTO / Recovery
• Phase d’analyse

– Recherche du dernier checkpoint

• Chargement des données

– Depuis les fichiers data/...
Migrer ?
Oui

•
•
•
•
•
•
•

Faible latence
Concurrence d’accès
Lock
Latch
Table values parameters
Tables « Temporaire »
L...
Par où commencer ?
• AMR Tool (Analyze, Migration, Reporting)
–
–
–
–

Identifie tables et procédures candidat à migration...
Conclusion
• Performant
• Facilité
– Installation
– Exploitation
– Intégration

• Nécessite quelques ajustements
• Mais ce...
Questions / réponses
• Merci pour votre présence
• Des articles et des scripts sur
http://conseilit.wordpress.com/?s=hekat...
#JSS2013
#JSS2013
Prochain SlideShare
Chargement dans…5
×

JSS2013 : Hekaton

329 vues

Publié le

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
329
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
10
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

JSS2013 : Hekaton

  1. 1. Les journées SQL Server 2013 Un événement organisé par GUSS #JSS2013
  2. 2. Les journées SQL Server 2013 Hekaton Christophe LAPORTE Un événement organisé par GUSS #JSS2013
  3. 3. Christophe LAPORTE ~ depuis 1997 6.5 <= SQL Server <= 2014 christophe_laporte@hotmail.fr http://conseilit.wordpress.com/ @conseilit #JSS2013
  4. 4. Merci à nos sponsors #JSS2013
  5. 5. Agenda • • • • • • • Pourquoi ? Comment ? Donc … Du changement ? Considérations Hardware Limitations Migrer ? #JSS2013
  6. 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. 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. 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. 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. 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. 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. 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. 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. 14. Démonstration • Création d’une base • Création d’une table #JSS2013
  15. 15. Un enregistrement dans Hekaton #JSS2013
  16. 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. 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. 18. Démonstration • Native Compiled Procedure #JSS2013
  19. 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. 20. Hash Index #JSS2013
  21. 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. 22. Démo #JSS2013
  23. 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. 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. 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. 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. 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. 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. 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. 30. Conclusion • Performant • Facilité – Installation – Exploitation – Intégration • Nécessite quelques ajustements • Mais ce n’est qu’une V1 !!! #JSS2013
  31. 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. 32. #JSS2013 #JSS2013

×