Vous êtes sur la page 1sur 27

Bases de Données Avancées 2 (BDA2)

– Cours 12 –
Chapitre 7 : Optimisation de la persistance de données

Dr. CHAOUCHE A.-C.


Faculté des nouvelles technologies
ahmed.chaouche@univ-constantine2.dz

Université Constantine 2 2018/2019. Semestre 1


Bases de Données Avancées 2 (BDA2)
– Cours 12 –
Chapitre 7 : Optimisation de la persistance de données

Dr. CHAOUCHE A.-C.


Faculté des nouvelles technologies
ahmed.chaouche@univ-constantine2.dz

Etudiants concernés
Faculté/Institut Département Niveau Spécialité

Nouvelles technologies IFA Master 2 STIC

Université Constantine 2 2018/2019. Semestre 1


Résumé

Prérequis
Oracle DB
Langage SQL
ORM

Objectifs du cours
Concevoir une BD performante

Université Constantine 2 © Dr. Chaouche A.-C. 3


Optimisation à plusieurs niveaux (1/2)

Couche ORM Pool de


DAO
• Hibernate
• Toplink connexion
JDBC BD

Optimisation des requêtes


Astuces
Spécificité d’Oracle DB
Cache
Extraction du schéma
Stratégies de chargement
Outils de diagnostic
Requêtes personnalisées Conception d’une BD

Université Constantine 2 © Dr. Chaouche A.-C. 4


Optimisation à plusieurs niveaux (2/2)

1. Optimisation du modèle de données

2. Optimisation des requêtes

3. Optimisation au niveau des ORM

4. Optimisation applicative et matérielle

5. Migration vers des BD NoSQL

Université Constantine 2 © Dr. Chaouche A.-C. 5


1. Optimisation du modèle de données
a. Conception d'une BD

1. Analyse des besoins (l'identification du contenu de la BD)


Rassembler toutes les données existantes qui seront intégrées à la BD (des entités,
des personnes, objets, lieux et événements, …)
Faire une liste des types de données
2. Modélisation des données
Un modèle décrit de façon abstraite comment sont représentées les données dans
une organisation métier, un SI ou une BD
Pour les BDR, le modèle entité-relation est utilisée pour établir un modèle de
données spécifique au domaine. Pour la POO, le langage UML (DC) est utilisé pour la
création du modèle
3. Organisation des données en tables
Commencer par un diagramme de classes UML et/ou un diagramme entité-association
Assigner le bon type de donnée à chaque colonne pour une cohérence des données
Décider quel(s) attribut(s) seront utilisés comme clé primaire pour chaque table
4. Analyse et création des relations entre les tables
Identifier les cardinalités des relations permet d’assurer une répartition efficace des
données (1-1, 1-N, ou N-N)
Eviter les relations circulaires et les relations redondantes

Université Constantine 2 © Dr. Chaouche A.-C. 6


1. Optimisation du modèle de données
b. Spécificité d’Oracle DB (1/2)

Les paramètres d'initialisation définissent les valeurs qui peuvent avoir


une incidence sur les performances du SGBD
les fonctions de l'optimiseur sont stockés dans un fichier de paramètres
Possibilité de les modifier en utilisant ALTER SYSTEM (avec le privilège SYSDBA)
Configuration :
1. Définir le paramètre CURSOR_SHARING sur SIMILAR ou FORCE afin que les valeurs
littérales soient converties en variables de liaison
2. Si le jeu de caractères de la BD est codé sur 2 octets ou Unicode, définir le
paramètre NLS_LENGTH_SEMANTICS sur CAR
3. Définir le paramètre WORKAREA_SIZE_POLICY sur AUTO pour dimensionner
automatiquement les zones de travail
4. Vérifier que le paramètre OPTIMIZER_FEATURES_ENABLE correspond à la version
actuelle de Oracle DB
5. Définir le paramètre PROCESSES sur le nombre max. d'utilisateurs et de
processus d'arrière-plan qui peuvent accéder à la BD simultanément
Ex : Si vous prévoyez 50 utilisateurs simultanés, définissez la valeur sur 70 pour inclure
les processus d'arrière-plan

Université Constantine 2 © Dr. Chaouche A.-C. 7


1. Optimisation du modèle de données
b. Spécificité d’Oracle DB (2/2)

6. Définir le paramètre OPEN_CURSORS sur le nombre max. de curseurs ouverts


qu'une session peut avoir simultanément
Les curseurs ouverts gèrent les zones SQL privées. Le nombre de curseurs ouverts
nécessaires dépend de votre déploiement.
7. Définir le paramètre SESSIONS pour spécifier le nombre max. de sessions pouvant
être créées, en se basant sur le nombre max. d'utilisateurs et de processus
d'arrière-plan auquel s'ajoute une allocation de 10% pour les processus récursifs
Ex : Si vous prévoyez 50 utilisateurs simultanés, définissez la valeur sur 77, qui peut
contenir 20 processus d'arrière-plan avec sept sessions de processus récursifs
8. Définir les paramètres de gestion SGA et PGA sur une taille de mémoire basée
sur la taille de la BD, le nombre d'utilisateurs simultanés et la charge de travail.
Les paramètres à définir pour Oracle DB 11g sont : SGA_TARGET, SGA_MAX_SIZE,
MEMORY_TARGET et MEMORY_MAX_TARGET

9. Définir le paramètre TRANSACTIONS pour spécifier le nombre max. de


transactions simultanées. Une valeur plus élevée pour ce paramètre signifie
que la taille de la mémoire SGA est également plus grande
Pour appliquer les changements, il faut redémarrer Oracle DB
Université Constantine 2 © Dr. Chaouche A.-C. 8
1. Optimisation du modèle de données
c. Extraction du schéma relationnel à partir du DC

Une BD bien structurée…


libère de l'espace disque en éliminant les données redondantes
préserve l'exactitude et l'intégrité des données
permet d'accéder efficacement aux données

Règle de transformation :
Choix des types : gagner de l’espace disque (ex: short/int/long)
Choix de la stratégie d’héritage : améliorer la complexité temporelle ou spatiale
Gestion des contraintes d’intégrité référentielle : éviter les insertions et les
mises à jour interdite
Contrôle des données (Check et triggers) : gagner de l’espace disque
Création de tables en cache
Création de vues matérialisées : considérées comme des caches de requêtes
Rajout d’indexes et de clusters : optimiser le temps d’exécution des requêtes,
mais ralentir les mises à jour

Université Constantine 2 © Dr. Chaouche A.-C. 9


1. Optimisation du modèle de données
d. Normalisation et dénormalisation de la BD (1/3)

2 types de BD :
BD OLTP (traitement transactionnel en ligne) doivent être normalisées, sachant
que les commandes exécutées sont souvent des commandes LMD
BD OLAP (traitement analytique en ligne) qui favorisent l'analyse et les
rapports, peuvent être plus efficaces avec un certain degré de dénormalisation
La normalisation de la BD consiste à éliminer la redondance et les
dépendances incohérentes entre les tables ce qui permet d'optimiser la BD
Considérée comme le but de la modélisation des BD
Ce processus conduit à la fragmentation des données dans plusieurs tables
Formes normales :
1FN : toutes les données sont atomiques
2FN : 1FN + un attribut non clé ne dépend pas d'une partie de la clé
3FN : 2FN + un attribut non clé ne dépend pas d'un ou plusieurs attributs ne
participant pas à la clé
FNBC, 4FN, 5FN, FNDC, 6FN, …

Université Constantine 2 © Dr. Chaouche A.-C. 10


1. Optimisation du modèle de données
d. Normalisation et dénormalisation de la BD (2/3)

La dénormalisation de la BD consiste à dupliquer délibérément de certaines


données afin d'accélérer l'extraction des données
il peut être intéressant de dénormaliser un modèle relationnel
des moyens doivent être mis en œuvre pour contrôler la redondance créée
l'objectif est d'améliorer les performances de la BD en termes de requêtes sur
les tables considérées, en implémentant les jointures plutôt qu'en les calculant
4 façons de dénormalisation :
Partitionnement horizontal : divise une table en plusieurs tables
contenant les mêmes colonnes, mais moins de lignes
Partitionnement vertical : divise une table en plusieurs tables
contenant le même nombre de lignes, mais moins de colonnes
Fusion de tables : fusionne des tables afin d'éliminer la jointure entre elles
Dénormalisation de colonne : répète une colonne dans plusieurs tables
afin d'éviter d'avoir à créer des jointures entre les tables

Université Constantine 2 © Dr. Chaouche A.-C. 11


1. Optimisation du modèle de données
d. Normalisation et dénormalisation de la BD (3/3)

Les partitionnement horizontal et vertical impliquent des compromis en


termes de performances et de complexité
Ils requièrent des jointures et unions supplémentaires afin d'extraire des
données de plusieurs tables
Des requêtes plus complexes pour décrire la table partitionnée,
La dénormalisation de colonne requiert plus de maintenance et d'espace
disque dans la mesure où certaines données sont dupliquées
Il faut analyser les besoins dans le domaine de l'accès aux données par les
applications
Certaines colonnes sont interrogées très fréquemment
Les problèmes de performances peuvent être résolus par une politique
d'indexation judicieuse

Université Constantine 2 © Dr. Chaouche A.-C. 12


2. Optimisation des requêtes
a. Requêtes SQL optimisées

Le moteur de données MyISAM est à privilégié à InnoDB pour les requêtes


Filtrer les données directement via WHERE et/ou LIMIT, en évitant que cela
ne soit fait par l’application
Eviter d’utiliser des fonctions dans les clauses de recherche, telle que WHERE
Eviter les lectures via "SELECT * from..." en privilégiant plutôt de lister
uniquement les colonnes qui seront exploitées
Eviter d’utiliser % au début d’une recherche LIKE
Ex : SELECT * FROM [table] WHERE [col] LIKE ‘%abc’ est consommatrice en performance
Utiliser des requêtes préparées ou procédures stockées pour mettre en
cache certaines requêtes
Purger les vieilles données non utile permet d’alléger le poids d’une BD
Une requête OPTIMIZE permet de réorganiser le stockage physique des
données et améliore l’efficacité lors de l’accès aux données
En utilisant l’outil AWR, consulter les informations recueillies pour
détecter les requêtes gourmandes pouvant être améliorées

Université Constantine 2 © Dr. Chaouche A.-C. 13


2. Optimisation des requêtes
b. Outils de diagnostic (1/2)

L'optimisation des BD est souvent perçue comme une tâche du DBA, mais le DBA
ne peut pas connaître la logique métier de la BD ni l’écriture des requêtes
Il est fréquent qu'une requête mal écrite coûte 10 fois plus de temps et de
ressources qu'elle ne le devrait
Pour écrire des requêtes efficaces il est nécessaire de connaître les mécanismes
de mis en œuvre de la BD
Plusieurs outils pour superviser Oracle DB et mesurer les performances :
Statspack : un ensemble d’utilitaires gratuits (scripts, packages, procédures et
fonctions stockées) de mesures des performances pour Oracle DB (introduit dans
la version 8i). Lorsque des problèmes interviennent, il est possible d’effectuer un
snapshot toutes les 15 minutes (Tutoriel)
AWR : un dépôt qui stocke un historique des informations utiles pour l’optimisation.
A intervalle régulier, des snapshots de la BD (statistiques, charge, …) sont stockés
dans l’AWR via le processus MMON (Tutoriel)
...

Université Constantine 2 © Dr. Chaouche A.-C. 14


2. Optimisation des requêtes
b. Outils de diagnostic (2/2)

Tkprof : une application permettant de tracer une session ou une instance et


interpréter le résultat. Elle est liée a l’Explain plan et aux statistiques générées sous
SQL*plus. Oracle DB génère un fichier contenant toutes les statistiques concernant
les commandes SQL exécutées pendant une session et un fichier pour chaque
processus (Tutoriel)
Autotrace : un outil intégré dans SQL*plus qui permet d’obtenir automatique-
ment un rapport sur le chemin d'exécution d’une commande LMD ainsi que les
statistiques d'exécution, dans le but de surveiller et d’ajuster sa performance
(Tutoriel)
Vues et tables dynamiques V$... : issues du dictionnaire de la BD (c-à-d. appartiennent
à SYS), servent comme source aux outils de diagnostic. Elles sont utiles pour la
surveillance en temps réel du système ou pour faire du tuning (Liste).

En pratique, lors d’une requête sur une table, les outils de diagnostic
permettent d’analyser et d’améliorer les performances

Université Constantine 2 © Dr. Chaouche A.-C. 15


2. Optimisation des requêtes
c. Hints de l’optimiseur (1/4)

Lors d'une requête SQL, Oracle construit dans un premier temps son plan
d'exécution, ce qui lui permet de savoir comment accéder aux données
Pour construire ce plan, Oracle s'appuie sur des règles qui sont paramétrables :
en mode RULE, si la colonne possède un index, il faut utiliser cet index
le mode CHOOSE utilise, en plus, les statistiques relatives à ses tables et index ;
dans ce cas, si la colonne est indexée mais que le nombre de lignes à parcourir est
très faible, il choisira de ne pas utiliser l'index et de faire un FULL SCAN sur la table
Des astuces (Hints) d'optimisation peuvent être utilisées avec des
commandes SQL pour modifier les plans d'exécution
Ils permettent de prendre les décisions généralement prises par l'optimiseur
Le concepteur d'applications connaît des informations sur les données qui sont
inconnues pour l'optimiseur du SGBD

Université Constantine 2 © Dr. Chaouche A.-C. 16


2. Optimisation des requêtes
c. Hints de l’optimiseur (2/4)

Principe :
1. Un certain index est plus sélectif pour certaines requêtes
2. Sur la base de ces informations, il est possible de choisir un plan d'exécution
plus efficace que l'optimiseur
3. Il faut utiliser des astuces pour indiquer à l'optimiseur d'utiliser le plan
d'exécution optimal
Syntaxe :
{DELETE|INSERT|SELECT|UPDATE} /* + hint [text] [hint[text]] ... */
* FROM [table] WHERE ...

Cas d’usage :
L'approche d'optimisation pour une commande SQL
L'objectif de l'optimiseur basé sur les coûts pour la commande
Le chemin d'accès à une table accessible par la commande
L'ordre de jointure pour une commande de jointure
Une opération de jointure dans une commande de jointure

Université Constantine 2 © Dr. Chaouche A.-C. 17


2. Optimisation des requêtes
c. Hints de l’optimiseur (3/4)

Catégories d’astuces : (Documentation)


Astuces pour les approches et objectifs d'optimisation : Les astuces
permettent de choisir entre les approches d'optimisation et les objectifs :
ALL_ROWS, FIRST_ROWS(n), CHOOSE, RULE
Astuces pour les chemins d'accès : Ce type d’astuces indique à l'optimiseur
d'utiliser un chemin d'accès spécifique pour une table : FULL, CLUSTER, HASH,
INDEX, NO_INDEX, INDEX_ASC, INDEX_JOIN, …
Astuces pour les transformations de requête : Chacune des astuces indique à
l'optimiseur d'utiliser une transformation spécifique de requête SQL : USE_CONCAT,
MERGE, NO_EXPAND, REWRITE, UNNEST, NO_UNNEST, STAR_TRANSFORMATION, FACT, …
Astuces pour les commandes de jointure : qui peuvent être LEADING ou
ORDERED
Astuces pour les opérations de jointures : indiquent à l'optimiseur d'utiliser
une opération de jointure spécifique pour une table : USE_NL, NO_USE_NL,
USE_NL_WITH_INDEX, USE_MERGE, USE_HASH, …
...

Université Constantine 2 © Dr. Chaouche A.-C. 18


2. Optimisation des requêtes
c. Hints de l’optimiseur (4/4)

Catégories d’astuces :
...
Astuces pour l'exécution parallèle : Ce type d’astuces détermine comment les
commandes sont parallélisées ou non lors d’une exécution parallèle : PARALLEL,
NOPARALLEL, PQ_DISTRIBUTE, PARALLEL_INDEX, NOPARALLEL_INDEX
Exemple : L’astuce PARALLEL permet de spécifier le nombre souhaité de serveurs
simultanés pouvant être utilisés pour une opération parallèle. L’astuce indice
s'applique aux commandes LMD, ainsi qu'à la partie d'analyse de la table

Université Constantine 2 © Dr. Chaouche A.-C. 19


3. Optimisation au niveau des ORM
a. Performances de Hibernate (1/2)

1. Stratégies de chargement
Par défaut, Hibernate utilise le chargement différé par select pour les collections
et le chargement différé par proxy pour les associations vers un seul objet
Optimiser les modes de chargement (Quand et Comment)
2. Cache de second niveau
Une session Hibernate est un cache de niveau transactionnel
Il est possible de choisir une implémentation de cache en spécifiant le nom de
la classe en utilisant la propriété hibernate.cache.provider_class
Plusieurs stratégies sont supportées : read-only, read-write, …
la méthode session.evict() permet de supprimer un objet et ses collections
dépendantes du cache de premier niveau de la session, et session.clear()
permet de vider le cache
3. Cache de requêtes
Les résultats d’une requête peuvent être mis en cache (utile pour les requêtes
fréquemment exécutées avec les mêmes paramètres)
Il faut activer le cache de requêtes : hibernate.cache.use_query_cache true
...

Université Constantine 2 © Dr. Chaouche A.-C. 20


3. Optimisation au niveau des ORM
a. Performances de Hibernate (2/2)

4. Performances des collections


Structure des clés primaires utilisée par Hibernate pour mettre à jour ou
supprimer les lignes des collections : collections indexées (maps, lists, arrays),
ensembles (sets), sacs (bags)
lists, maps, bags et sets sont les collections les plus efficaces pour la mise à jour
Les bags et les lists sont les plus efficaces pour les collections inverses
5. Moniteur de performance
Hibernate fournit plusieurs rapport et statistiques sur ses opérations internes via
sessionFactory.getStatistics()
Il est possible de (dés)activer le suivi pour une SessionFactory et les statistiques
peuvent être remises à zéro de manière programmatique
3 catégories de statistiques :
1. Les métriques relatives à l'usage général de la session comme le nombre de
sessions ouvertes, le nombre de connexions JDBC récupérées, ...
2. Les métriques relatives aux entités, collections, requêtes et caches
3. Les métriques détaillées relatives à une entité, une collection, une requête ou
une région de cache particulière

Université Constantine 2 © Dr. Chaouche A.-C. 21


3. Optimisation au niveau des ORM
b. Requêtes personnalisées peu gourmandes

Problèmes du N+1 :
Lors du chargement de plusieurs objets, les associations sont chargées en
différé, ce qui génère N+1 de SELECT
SELECT * FROM a;
// Pour tout A, obtenir les B
SELECT * FROM b WHERE b.a_id = ?;

Solution : requêtes personnalisées


Les stratégies de fetching peuvent être surchargées par des requêtes
personnalisées de type HQL ou Criteria
SQL> SELECT * FROM A a LEFT OUTER JOIN B b ON a.id = b.a_id;
HQL> FROM A a JOIN FETCH a.rb B
Criteria> Criteria cr = session.createCriteria(A.class);
cr.setFetchMode("rb", FetchMode.EAGER);

Université Constantine 2 © Dr. Chaouche A.-C. 22


4. Optimisation applicative et matérielle
a. Optimisation de l’installation et de la configuration

Allouer suffisamment de RAM pour le serveur du SGBD


Analyser et monitorer les performances du serveur afin de surveiller son
usage actuel et préconiser des adaptations
Ex : augmenter la RAM, allouer plus d’espace disque, …
Installer le SGBD sur le même serveur que l’application.
Lorsque le SGBD est sur le même équipement informatique, bien utiliser les sockets
Utiliser des connexions persistantes pour éviter trop d’ouvertures et
fermetures de connexion ce qui est très coûteux en performance
Toujours bien s’assurer que les connexions se ferment correctement
Activer le log des “slow queries” sur le serveur puis vérifier ce log
régulièrement.
Une analyse peut être effectuée pour chacune des lignes ajoutées dans ce log, par
exemple avec l’outil EXPLAIN
Utiliser le système de mise en cache disponible par le SGBD. Sinon, utiliser
un système de mise en cache externe (Ex : memcached)

Université Constantine 2 © Dr. Chaouche A.-C. 23


4. Optimisation applicative et matérielle
b. Usage des requêtes SQL dans l’application

Analyser le nombre de requêtes SQL utilisé au sein d’une vue pour


détecter si elle contient trop d’appels de requêtes SQL :
Une requête SQL similaire qui est appelée à plusieurs reprises
La requête “SELECT email FROM user WHERE id = 456”, puis la requête “SELECT
register_date FROM user WHERE id = 456” peuvent être extraites en une seule fois.

Eviter d’appeler des requêtes SQL dans une boucle


Une requête “SELECT * FROM comment WHERE article_id = 123” appelée plusieurs fois
dans une boucle serait plutôt à remplacer par une requête “SELECT * FROM comment WHERE
article_id IN (123, 124, 125 ...)”

Eviter de faire 2 requêtes pour le système de pagination, une requête


contenant les résultats et l’autre pour compter le nombre de résultats total
Dans une requête, remplacer WHERE IN par WHERE EXISTS si cela est possible
Eviter les sous-requêtes si une jointure est possible
Eviter de compter une colonne (SELECT COUNT(col) FROM table) lorsqu’il
faut compter le nombre d’enregistrement (SELECT COUNT(*) FROM table)

Université Constantine 2 © Dr. Chaouche A.-C. 24


5. Migration vers des BD NoSQL

Avec le développement de grandes entreprises internet (Google, Amazon,


eBay…) manipulant de grandes quantités de données (BigData)
Les BD NoSQL sont conçues pour remédier aux problématiques
auxquelles les BD relationnelles ne répondent pas suffisamment, telles
que la connectivité des données, la performance à l'échelle et la
flexibilité du schéma
Plusieurs familles :
NoSQL orienté-agrégats
NoSQL orienté-graphes
NoSQL sans-schéma

Université Constantine 2 © Dr. Chaouche A.-C. 25


Quelques liens utiles

Optimisation SQL
https://sql.sh/optimisation

Optimizer Hints
https://docs.oracle.com/cd/B10500_01/server.920/a96533/hintsref.htm

Améliorer les performances de Hibernate


http://docs.jboss.org/hibernate/core/3.5/reference/fr-FR/html/performance.html

Université Constantine 2 © Dr. Chaouche A.-C. 26


Références

IBM Knowledge Center, « Optimisation des performances dans Oracle


Database », 2018. Lien :
https://www.ibm.com/support/knowledgecenter/fr/SSLKT6_7.6.0/com.ib
m.mbs.doc/gp_sysperf/t_set_oracle_parameters.html
SQL.sh, « Optimisation SQL », 2018. Lien : https://sql.sh/optimisation
Oracle, « Database Performance Tuning Guide: Using Optimizer Hints »,
2018. Lien : docs.oracle.com/cd/B19306_01/server.102/b14211/
hintsref.htm #i8327
Aide-oracle.net, « Hint oracle et choix du plan d'exécution », 2018. Lien :
http://www.aide-oracle.net/2009/04/hint-oracle-et-choix-du-plan-d.html
Red Hat, « Hibernate Community Documentation : Chapitre 20. Améliorer
les performances », 2004. Lien : http://docs.jboss.org/hibernate/core/
3.5/reference/fr-FR/html/performance.html#performance-cache
S. Subramanian, « How to Identify and Resolve Hibernate N+1 SELECT's
Problems », 2018. Lien : https://dzone.com/articles/how-identify-and-
resilve-n1

Université Constantine 2 © Dr. Chaouche A.-C. 27

Vous aimerez peut-être aussi