Vous êtes sur la page 1sur 13

13/11/2015

Transaction
• Une transaction:
– séquence d'instructions (LMD) qui soit réussit, soit
échoue.
• Les transactions doivent posséder les
Les requêtes propriétés ACID :
• Atomicité : les opérations sont exécutées dans leur
totalité ou pas du tout (begin, commit, abort): une
transaction est complète ou abandonnée
complètement .
• Consistance : transformation correcte de l ’état du
système (ne violant aucune contrainte d ’intégrité):
une transaction doit transformer le système d'un
état consistant à un autre état consistant.
2

• Isolation : les changements sur les données ne


sont visibles par les autres transactions
qu ’une fois la transaction achevée: chaque
transaction est vue indépendamment des
autres
• Durabilité : les modifications qui suivent une
validation doivent survivre à une panne du
système: les transactions validées ont des
effets permanents

3 4

1
13/11/2015

Traitement de requêtes séquentielles Analyse de requête


• L’exécution d’une requête séquentielle passe • Vérifier la validité de la requête en consultant
par plusieurs phases: le dictionnaire de données pour voir l’existence
– une analyse lexicale, syntaxique et sémantique est des relations et des attributs .
effectuée, • Examiner la validité grammaticale.
– la requête est transformée en un arbre d’exécution
• Pour générer un plan d’exécution optimal, des
logique,
simplifications sémantiques sont effectuées tel
– Cet arbre est optimisé par l’application des
transformations de l’algèbre relationnelle
que la détection de contradiction (ex :age=12 et
age>15)
– un plan d’exécution physique est produit en
choisissant le meilleur chemin d’accès aux données.

Traduction algébrique
• Le résultat est un Plan d’Exécution
• Traduire la requête en une expression
Logique(PEL) qui sera transformé en un Plan
algébrique sous forme d’arbre.
d’Exécution Physique(PEP)
• L’arbre est composé des nœuds, des arcs, et
• L’exécution débute des feuilles qui manipulent
des feuilles.
les tables, les résultats sont ensuite envoyés
– les feuilles représentent les tables (relations),
aux nœuds pères et ainsi de suite jusqu’à
– les nœuds représentent les operateurs
l’obtention de résultat final à la racine.
algébriques,
– les arcs représentent, les flux de données allant
d’un nœud fils vers son nœud père.

2
13/11/2015

Optimisation
• 1-1 Règles de transformation de l’algèbre
• L’optimisation se déroule en deux phases :
relationnelle :
l’optimisation logique et l’optimisation physique.
– 1. Commutativité des jointures :
• 1 L’optimisation logique(Rewriting) :
• Le principal but est de réduire le volume de – 2. Associativité des jointures:
données manipulé en appliquant les règles de
transformation de l’algèbre relationnelle ainsi – 3. Regroupement des sélections:
que des heuristiques pour produire de bonnes
stratégies d’exécutions.
• Ces trois dernières règles sont utilisées pour descendre
les sélections, le plus bas possible dans l’arbre.

• 2 L’optimisation physique :
• Ordonner (un ordre quasi optimal) les
opérations algébriques élémentaires
(atomiques) pour que les algorithmes de
recherche, de tri, et de jointure s’exécutent
plus efficacement. Cette optimisation dépend
du schéma interne de la base de données
(index, contraintes d’intégrite) et de la taille
des tables.

3
13/11/2015

• Un plan d’exécution physique (PEP) est le


Plan d’exécution
résultat final de la phase d’optimisation, ce
plan d’exécution est sous la forme d’un arbre
dont :
• Les nœuds : des opérateurs physiques (atomiques).
• Les feuilles : ce sont des liens (chemins) physiques
aux tables (relations) et index.
• Les arcs : ils représentent le flux de données, ces flot
peuvent être séquentiels ou pipelines.
• Le résultat final est au niveau de la racine.

14

Requête répartie Optimisation de requête répartie


• Optimiser: choisir parmi de nombreuses possibilités,
• Les opérations précédentes (par exemple) une stratégie d'exécution de requête efficace.
accèdent à des données situées sur différents • Établissement d’un plan d’évaluation optimal
sites. • Optimisation d’une fonction de coût ou de temps de
réponse:
• Le SGBD gère les accès distants en répartissant
• coût global :
la requête – coût(E/S)
– Exécution distante de la sous requête – coût(Processeur)
– Récupération de données résultat – coût(Communication) (messages) …
– Assemblage local (requête en lecture) • Ex: 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.

15

4
13/11/2015

• L'optimisation d'une requête intervient à deux principaux


niveaux : • Répartition de la requête
– Décomposition de la requête – décomposer la requête globale en requêtes sur les
– Répartition de la requête fragments
• Décomposition de la requête – des reconstructions sont encore faites afin d'annuler
– Normalisation: écrire la partie critère (contenu dans la clause les formules dont les conditions ne respectent pas les
WHERE) sous forme d'une conjonction de coordination ou restrictions des fragments auxquelles elles font
disjonction de conjonction de prédicats WHERE (a et b) ou (c référence.
et d). – on peut remplacer certaines opérations par d'autres,
– Analyse: détecter et éliminer les erreurs comme la jointure par la semi-jointure car moins
la présence de champs ou relations inexistants, l'incohérence des coûteuse.
valeurs données avec les types réels des champs, etc.
– selon la localisation de chaque fragment et l'existence
– Elimination des redondances ou non de relations répliquées, une stratégie
• NON (NON A) == A
• A ET A == A
d'exécution est mise en place afin de minimiser les
• A OU A ==A
trafics réseaux et bénéficier de rapides accès aux
données et traitements du CPU.
– Réécriture: réécrire la requête en une forme qui améliore ou
optimise le temps de traitement global.

Utilisateur Les composants d'un


Schéma général de l’optimisation réponse du système demande de l'utilisateur DBMS distribué et le
déroulement de
requêtes
• Dans un système distribué, l'optimisation peut se
faire de trois manières principales :
– Une optimisation centralisée: un site central gestionnaire de l'interface utilisateur schéma externe
détermine la stratégie d'exécution sur tous les autres
sites.
• l'optimisation est plus facile mais souvent peu efficace car il Processor de l'utilisateur
faudrait connaître exactement les indices de chaque site… contrôleur sémantique des données
– Une optimisation distribuée où chaque site a sa
schéma conceptuel
propre stratégie d'optimisation global
– les deux première méthodes pour en faire une
hybride: optimiseur global de requêtes
• dans un premier temps, un site décide de l'optimisation
globale et ensuite chaque site optimise à son tour, à son
niveau.
moniteur de l'exécution globale

5
13/11/2015

• 1) Le gestionnaire de l'interface utilisateur interprète les commandes de l'utilisateur


à leur arrivée et formate les résultats pour être émis à l'utilisateur. schéma conceptuel local

• 2) Le contrôleur sémantique des données utilise les contraintes d'intégrité des processeur de requête local

données et les autorisations qui ont été définies dans le schéma conceptuel global Processor des données

des données. Le contrôleur se base sur eux pour vérifier si la requête de


gestionnaire local de recouvrement
l'utilisateur peut être traitée.
l og système
• 3) L'optimiseur global des requêtes est aussi leur décomposeur, il détermine une
stratégie d'exécution pour minimiser la fonction coût d'exécution. Il traduit aussi la
requête globale en un ensemble de requêtes locales en utilisant le schéma schéma interne local
processeur d'exécution
conceptuel global ainsi que les schémas conceptuels locaux et le dictionnaire
global.

• 4) Le moniteur de l'exécution globale coordonne les exécutions distribuées des


requêtes de l'utilisateur. Ce moniteur est aussi appelé le gestionnaire des
transactions distribuées.

• 1) Le processeur de requêtes locale ou l'optimiseur des


requêtes locales, qui détermine le schéma d'exécution optimal
Exemples
• 2) Le gestionnaire local de recouvrement assure la
consistance des bases de données locales même si une
requête échoue.

• 3) Le processeur d'exécution accède réellement à la base de


données en exécutant des requêtes et ce conformément aux
étapes spécifiées par l'optimiseur de requêtes. Ce composant
correspond à l'interface avec le système d'exploitation, et
contient le buffeur de la base ou encore le gestionnaire du
cache qui facilite les accès.

6
13/11/2015

Choix de solution

7
13/11/2015

Coût de la solution • Importance de la fragmentation horizontale


pour augmenter le parallélisme inter- et
• Supposons intra-requête
– taille (Cde1) = taille (Cde2) = 10 000
– taille (Client1) = taille (Client2) = 2 000 • Utiliser la fragmentation verticale si forte
– coût de transfert de 1n-uplet = 1 affinité d'attributs et beaucoup d'attributs
– Qt>10 ~1%
• Stratégie 1 • L'optimisation reposant sur un modèle de
– transfert de Cde1 + Cde2 = 20 000 coût, est critique s'il y a beaucoup de sites
– transfert de Client1 + Client2 = 4000
• Stratégie 2
– transfert de C1 + C2 = 200
– transfert de C3 + C4 = 200

Transparence des requêtes


• Schéma de fragmentation
– définition des fragments
• Schéma d'allocation
– contient la localisation

8
13/11/2015

Transactions réparties
• OBJECTIF Transactions réparties
– Garantir que toutes les mises à jour d'une transaction
sont exécutées sur tous les sites ou qu'aucune ne l'est.
• EXEMPLE
• PROBLEME
– Transfert de la somme X du compte A vers le compte B – 1 transaction globale T
– DEBUT – => N transactions locales Ti
site 1: A = A – X
site 2: B = B + X PANNE --> INCOHERENCE – nécessité d'une coordination entre les sites
DONNEES locaux Si
- FIN
• SOLUTION
• PROBLEME
– Le contrôle est réparti : chaque site peut décider de – un site coordinateur C
valider ou d’annuler ... – un protocole de validation en 2 étapes

Commit en deux phases Protocole C/S


• Principe • PREPARER
– Diviser la commande COMMIT en deux phases – Le coordinateur C demande aux autres sites Si s’ils sont
– Phase 1 : prêts à commettre leurs mises à jour.
• Préparer à écrire les résultats des mises à jour dans la BD • 2a. SUCCES : COMMETTRE
• Centralisation du contrôle – Tous les participants effectuent leur validation sur ordre du
– Phase 2 : coordinateur.
• Écrire ces résultats dans la BD • 2b. ECHEC : ABORT
• Coordinateur : – Si un participant n’est pas prêt, le coordinateur demande à
tous les autres sites de défaire la transaction.
– Le composant système d'un site qui applique le protocole • REMARQUE
• Participant : – Le protocole nécessite la journalisation des mises à jour
– Le composant système d'un autre site qui participe dans préparées et des états des transactions dans un journal
l'exécution de la transaction local à chaque participant.

9
13/11/2015

• PHASE 1 • PHASE 2
• -> Le site C ajoute <T préparée> dans son • -> A partir des messages reçus des sites Si et
journal au terme d'un laps de temps déterminé, le
• -> Le site C envoie "prêt à commettre T" à site C prend une décision :
tous les sites Si – il valide T s'il a reçu "T prête" de tous les sites Si :
• il ajoute <T validée> à son journal
• -> Chaque site Si prend une décision :
• il envoie "valider T" à tous les sites
– s'il valide Ti , alors :
– il avorte T s'il a reçu au moins un message "abort
• Le site Si écrit <T prête à commettre> dans son journal
T" d'un site Si (ou au bout du laps de temps
• Le site Si envoie "T prête" au site C spécifié) :
– s'il ne valide pas Ti , alors : • il ajoute <T abortée> à son journal
• Le site Si écrit <non T> dans son journal • il envoie <abort T> à tous les sites Si
• Le site Si envoie "abort T" au site C

• Chaque site Si : Cas favorable


– inscrit dans son journal le message envoyé par le
site C
( <T validée> ou <T abortée> )
– envoie un accusé de réception au site C
• Quand le site C a reçu tous les accusés des
sites Si , il ajoute :
<T finie> à son journal

10
13/11/2015

Cas défavorable Panne d’un participant


• Un site participant Si tombe en panne
==> REPRISE A FROID DE Si
• Analyse du journal du site Si :
– <T validée> => refaire T
– <T abortée> => défaire T
– <T prête à commettre>
=> consulter le site C pour avoir l'état de T :
C répond => Si a connaissance de l'état de T
C ne répond pas => Si envoie une demande de l'état de
T à tous les sites
– Rien concernant T => Si sait que C a aborté T

Exemple
Cas de panne d’un participant • Exemple - Définition de la base de données :
• B : buveurs (N°B, nom, prénom, ville)
• V : vins (N°V, cru, millésime, degré)
• C : commandes (N°V,N°B, date, quantité)
• Exemple de requête, de sa traduction et de son
optimisation en l’absence de répartition :
• SELECT nom, prénom FROM buveurs (B), vins (V),
commandes (C)
WHERE V.cru = « Volnay » AND V.degré > 12 AND
C.quantité > 100
AND C.N°V = V.N°V AND C.date >1/1/2000 AND B.N°B =
C.N°B AND B.ville = « Paris »
44

11
13/11/2015

SELECT nom, prénom FROM buveurs (B), vins (V), commandes


(C) WHERE V.cru = « Volnay » AND V.degré > 12 AND C.quantité
> 100 AND C.N°V = V.N°V AND C.date >1/1/2000 AND B.N°B =
C.N°B AND B.ville = « Paris »

45 46

SELECT nom, prénom FROM


buveurs (B), vins (V), Recommandations de C.J Date (12)
commandes (C) • L'AUTONOMIE LOCALE
WHERE V.cru = « Volnay » – Chaque site doit fonctionner indépendamment des autres même s’il y a des
AND V.degré > 12 AND pannes. Donc chaque site est responsable de l'intégrité, la sécurité et la
gestion de sa base de données.
C.quantité > 100
• NE PAS SE REPOSER SUR UN SITE UNIQUE
AND C.N°V = V.N°V AND – Viser à éviter des arrêts de production lorsqu'un site tombe en panne. On
C.date >1/1/2000 AND B.N°B peut soit penser à ce que Oracle appelle la réplication avancée ou les données
= C.N°B sont entièrement répliquées d'un site à l'autre.
• OPERATION EN CONTINU
AND B.ville = « Paris » – 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.

12
13/11/2015

• 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 pas 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.

13