31/10/2010
Optimisation de requête répartie
Optimisation de requête répartie
• Décomposition de la requête
– Normalisation: écrire la partie critère (contenu dans
la clause WHERE) sous forme d'une conjonction de
coordination ou disjonction de conjonction de
prédicats WHERE (a et b) ou (c et d).
– Analyse: détecter et éliminer les erreurs
la présence de champs ou relations inexistants, l'incohérence
des valeurs données avec les types réels des champs, etc.
– Elimination des redondances
• NON (NON A) == A
• A ET A == A
• A OU A ==A
– Réécriture: réécrire la requête en une forme qui
améliore ou optimise le temps de traitement global.
• Optimiser: choisir parmi de nombreuses
possibilités, une stratégie d'exécution de requête
efficace.
• Si l'utilisateur soumet une requête au SGBD, le
composant Query Processor (Oracle) récrit la
requête sous une forme plus simple, et optimale.
• L'optimisation d'une requête intervient à deux
principaux niveaux :
– Décomposition de la requête
– Répartition de la requête
• Répartition de la requête
– décomposer la requête globale en requêtes sur les
fragments
– Des reconstructions sont encore faites afin d'annuler
les formules dont les conditions ne respectent pas les
restrictions des fragments aux quelles elles font
référence.
– on peut remplacer certaines opérations par d'autres,
comme la jointure par la sémi - jointure car moins
coûteuse.
– Selon la localisation de chaque fragment et l'existence
ou non de relations répliquées, une stratégie
d'exécution est mise en place afin de minimiser au
maximum les trafics réseaux et bénéficier de rapides
accès aux données et traitements du CPU.
1
 31/10/2010

Schéma général de l’optimisation Requête sur des relations réparties

• Dans un système distribué, l'optimisation peut se Décomposition de requêtes réparties Schéma global

faire de trois manières principales :

Requête sous forme algébrique
– Une optimisation centralisée: un site central Site initiateur

détermine la stratégie d'exécution sur tous les autres Localisation des données
sites. Fragements

• l'optimisation est plus facile mais souvent peu efficace car il

Fragments de requêtes
faudrait connaître exactement les indices de chaque site…
– Une optimisation distribuée où chaque site a sa Optimisation globale
Statistiques sur les
propre stratégie d'optimisation fragments

– les deux première méthodes pour en faire une Fragments de requête optimisées, y compris au niveau des
hybride: communications

• dans un premier temps, un site décide de l'optimisation Sites locaux

globale et ensuite chaque site optimise à son tour, à son Optimisation locale Schéma local

niveau.
Requête locales optimisées

Exemples

2
 31/10/2010

Choix de solution Coût de la solution

• Supposons
– taille (Cde1) = taille (Cde2) = 10 000
– taille (Client1) = taille (Client2) = 2 000
– coût de transfert de 1n-uplet = 1
– Qt>10 ~1%
• Stratégie 1
– transfert de Cde1 + Cde2 = 20 000
– transfert de Client1 + Client2 = 4000
• Stratégie 2
– transfert de C1 + C2 = 200
– transfert de C3 + C4 = 200

3
 31/10/2010

• Importance de la fragmentation horizontale Recommandations de C.J Date (12)

pour augmenter le parallélisme inter- et
intra-requête
• Utiliser la fragmentation verticale si forte
affinité d'attributs et beaucoup d'attributs
• L'optimisation reposant sur un modèle de
coût, est critique s'il y a beaucoup de sites
• L'AUTONOMIE LOCALE
– Chaque site doit fonctionner indépendamment des autres même s’il y a des
pannes. Donc chaque site est responsable de l'intégrité, la sécurité et la
gestion de sa base de données.
• NE PAS SE REPOSER SUR UN SITE UNIQUE
– Viser à éviter des arrêts de production lorsqu'un site tombe en panne. On
peut soit penser à ce que Oracle appelle la réplication avancée ou les données
sont entièrement répliquées d'un site à l'autre.
• OPERATION EN CONTINU
– Assurer le fonctionnement continu du système réparti par des mises à jour et
maintenances effectuées.
• TRANSPARENCE VIS A VIS DE LA LOCALISATION
– Rendre l'accès aux données transparentes sur tout le réseau (les liens de base
de données et les synonymes)
• INDEPENDANCE VIS A VIS DE LA FRAGMENTATION
– La fragmentation doit être réelle et respectée sur chaque site,
indépendamment.
• INDEPENDANCE VIS A VIS DE LA REPLICATION
– Chaque site doit bien gérer ses réplications.

• TRAITEMENT DES REQUETES DISTRIBUEES

– Chaque site doit avoir des outils et stratégies d'optimisation.
• GESTION REPARTIE DES TRANSACTIONS
– Généralement les SGBD utilisent des protocoles de validation à 2
phases.
• UNE INDEPENDANCE VIS A VIS DU MATERIEL
– Le SGBD ne doit dépendre du matériel
• UNE INDEPENDANCE VIS A VIS DU SYSTEME D'EXPLOITATION
– Il est important que les SGBD utilisés soient utilisables sur plusieurs
systèmes d'Exploitation.
• UNE INDEPENDANCE VIS A VIS DU RES EAU
– L'idéal serait que chaque SGBD réparti ait son propre protocole réseau
comme Oracle, pour faire communiquer les différentes instances.
• UNE INDEPENDANCE VIS A VIS DU TYPE DE LA BASE DE DONNEES
RELATIONNELLE
– De plus en plus, il est possible d'interconnecter des SGBD de types
différents, au moyen des standards tels que ODBC, JDBC et des
middlewares fournis par les constructeurs eux-mêmes.