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

JSS2013 : Hekaton

Embed Size (px)

Citation preview

Page 1: JSS2013 : Hekaton

#JSS2013

Les journées

SQL Server 2013

Un événement organisé par GUSS

Page 2: JSS2013 : Hekaton

#JSS2013

Les journées

SQL Server 2013

Un événement organisé par GUSS

HekatonChristophe LAPORTE

Page 3: JSS2013 : Hekaton

#JSS2013

Christophe LAPORTE

~ depuis 1997

6.5 <= SQL Server <= 2014

@conseilit

[email protected]

http://conseilit.wordpress.com/

Page 4: JSS2013 : Hekaton

#JSS2013

Merci à nos sponsors

Page 5: JSS2013 : Hekaton

#JSS2013

• Pourquoi ?

• Comment ?

• Donc …

• Du changement ?

• Considérations Hardware

• Limitations

• Migrer ?

Agenda

Page 6: JSS2013 : Hekaton

#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 ?

Page 7: JSS2013 : 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 ?

Page 8: JSS2013 : Hekaton

#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 …

Page 9: JSS2013 : Hekaton

#JSS2013

« Les » moteurs SQL ServerT-SQL

Parser

Metadata Management

Query Optimizer

RelationalQuery

Engines

Memory

Catalogs

DB & Log

Apollo(Column

Store)

Hekaton

Page 10: JSS2013 : 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 ?

Page 11: JSS2013 : Hekaton

#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

Page 12: JSS2013 : Hekaton

#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

Page 13: JSS2013 : Hekaton

#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

Page 14: JSS2013 : Hekaton

#JSS2013

• Création d’une base • Création d’une table

Démonstration

Page 15: JSS2013 : Hekaton

#JSS2013

Un enregistrement dans Hekaton

Page 16: JSS2013 : 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

Page 17: JSS2013 : Hekaton

#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

Page 18: JSS2013 : Hekaton

#JSS2013

• Native Compiled Procedure

Démonstration

Page 19: JSS2013 : Hekaton

#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

Page 20: JSS2013 : Hekaton

#JSS2013

Hash Index

Page 22: JSS2013 : Hekaton

#JSS2013

Démo

Page 23: JSS2013 : Hekaton

#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

Page 24: JSS2013 : Hekaton

#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

Page 25: JSS2013 : Hekaton

#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)

Page 26: JSS2013 : Hekaton

#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 estsupporté mais ignoré)

• Isolation level hints READUNCOMMITTED, READCOMMITTED et READCOMMITTEDLOCK

Limitations (SQL 2014) … encore (désolé)

Page 27: JSS2013 : Hekaton

#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

Page 28: JSS2013 : Hekaton

#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 ?

Page 29: JSS2013 : Hekaton

#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 ?

Page 30: JSS2013 : Hekaton

#JSS2013

• Performant

• Facilité– Installation

– Exploitation

– Intégration

• Nécessite quelques ajustements

• Mais ce n’est qu’une V1 !!!

Conclusion

Page 31: JSS2013 : Hekaton

#JSS2013

• Merci pour votre présence

• Des articles et des scripts surhttp://conseilit.wordpress.com/?s=hekaton

• Les speakers des JSS sont là pour répondre

à toutes vos questions

Questions / réponses

Page 32: JSS2013 : Hekaton

#JSS2013#JSS2013