Vous êtes sur la page 1sur 4

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.

31/10/2010

Optimisation de requête répartie

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.

Schéma général de l’optimisation

Dans un système distribué, l'optimisation peut se faire de trois manières principales :

Une optimisation centralisée: un site central détermine la stratégie d'exécution sur tous les autres sites.

l'optimisation est plus facile mais souvent peu efficace car il faudrait connaître exactement les indices de chaque site…

Une optimisation distribuée où chaque site a sa propre stratégie d'optimisation

les deux première méthodes pour en faire une hybride:

dans un premier temps, un site décide de l'optimisation globale et ensuite chaque site optimise à son tour, à son niveau.

Exemples

Exemples

31/10/2010

Requête sur des relations réparties Décomposition de requêtes réparties Schéma global Requête sous forme
Requête sur des relations réparties
Décomposition de requêtes réparties
Schéma global
Requête sous forme algébrique
Site initiateur
Localisation des données
Fragements
Fragments de requêtes
Optimisation globale
Statistiques sur les
fragments
Fragments de requête optimisées, y compris au niveau des
communications
Sites locaux
Schéma local
Optimisation locale
Requête locales optimisées
y compris au niveau des communications Sites locaux Schéma local Optimisation locale Requête locales optimisées 2
Choix de solution 31/10/2010 Coût de la solution • Supposons – taille (Cde1) = taille

Choix de solution

Choix de solution

31/10/2010

Choix de solution 31/10/2010 Coût de la solution • Supposons – taille (Cde1) = taille (Cde2)

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

Importance de la fragmentation horizontale 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

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.

31/10/2010

Recommandations de C.J Date (12)

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.