Witold Litwin http://ceria.dauphine.fr/witold.html Structures physiques Witold Litwin http://ceria.dauphine.fr/witold.html

Schéma interne Définit les chemins d'accès aux données En général dans l'hypothèse que la BD est grande sur le disque Problèmes Allocation d'espace disque Accès direct aux enregistrement Tampons RAM

Livres de Support Voir le cours introductif (Cours 1) De plus Garcia-Molina, H. Ullman, J. Widom J. Database System Implementation. Prentice Hall, 1999 Description de LH Jointure bi-passes et multi-passes Optimisation de requêtes à base de coût

Principes typiques Espace disque est paginé en pages de 4-8 KO Appelés aussi blocs Une page est une unité de transfert entre disque et RAM Les pages sont structurées en fichiers séquentiels ou directs ou non-ordonnés hachés Arbres B autres

Les indexes sont des fichiers qui contiennent les paires attribut(s) d'accès -> numéro de page les indexes peuvent être séquentiels ou directs ou non-ordonnés hachés arbres B autres

Structure d'une page N# P Autres infos Enreg 1 Enreg 2 ...........

Utilisation d'indexes S’il n'y a pas de chemin d'accès au fichier par la valeur d'attribut, alors il faut faire une longue recherche séquentielle Un index crée le chemin d'accès aux pages pertinentes On peut en avoir autant d'indexes que l'on veut Avantage pour les recherches Désavantage pour les MAJ, car il faut aussi mettre à jour les indexes

Page d'index typique N# P Autres inf. 16 Paris........... Athens........ London 56 77 ........... ................. 32 NY...... Madrid....... Accélération de 10:1000 fois selon la capacité d'une page d'index Paris.......

Accès haché Le n# de page est obtenu par calcul à partir de la clé primaire de fichier 12 34 56 78 mod 100 = 78 ........ h Clé 78 ........ 99

Hachage Il existe de nombreuses fonctions de hachage Il existe deux types de hachage statique (classique) virtuel (espace d'adressage peut grandir avec les insertions) hachage dynamique (Larson) hachage extensible (Fagin & al) hachage linéaire (Litwin) Implémenté dans nombreux produits IIS, Frontpage, MsExchange, Netscape, Unify, LH Server… Le fichier haché n'est pas ordonné pas de requêtes à intervalle

Fichiers ordonnés Arbre-B est le plus populaire (tout SGBD) En fait l’arbre B+ lié (linked B+ - tree de Lehma & Yao) Pour le parcours séquentiel et l’accès concurrent + efficace Loquets individuels sur chaque page parcourue Une page contient d>>1 paires en ordre lexicographique de clés clé - enreg. ou clé-pointeur de page avec l'enreg. Une page qui devient pleine éclate en deux pages semi-pleines La clé d'éclatement est dupliquée dans la page de niveau supérieur avec les pointeurs vers les nouvelles pages

dodo mom racine dada dede dodo dudu mom coco.. ... dada.. Feuilles avec les enreg coco.. ... dada..

Insert bébé dodo mom racine dada dede dodo dudu mom bébé ... coco.. Feuilles avec les enreg ... coco.. dada.. dede..

... Insert bébé dodo mom racine dada dede dodo dudu mom bébé.. coco..

... Insert bébé dodo mom racine coco dada dede dodo dudu mom bébé..

... insert bébé dede dodo mom coco dada dede dodo dudu mom bébé..

Structures de Données Distribuées et Scalables Serveur Client Multiordinateur

Opérations relationnelles Restrictions A = 'C' sur attribut-clé du fichier - + rapides avec hachage sur autres attributs - rech. seq. ou par indexe Restrictions à intervalle sur attribut-clé ou pas - + rapide avec les arbres-B Projections recherche séquentielle (peut être plus efficace avec le hachage) pourquoi ?

Jointures Equijointures + rapides avec le hachage comment faire ? - jointures: technique générale Boucles imbriquées Tri-interclassement (sort-merge) Index Hash Linear Hash

Boucles imbriquées Coût CPU ? Soit J = S[n].A * R[m].A où "*" note JOIN do i=1 to m ; /* Boucle ext. do j = 1 to n ; /* Boucle int. if R[i].A = S[j].A then R := R + R[i] * S[j] ; /* end ; Coût CPU ?

Tri-Interclassement Si la table R S n’est pas ordonnée sur l’attribut de jointure A, alors on trie R et S ou au moins S sur A Il y a des multiples algorithmes dans la littérature Si la table rentre entièrement en RAM, alors Quicksort est en général le plus rapide Sinon alors le « Multiway Sort Merge » est recommandé Ce type de jointure est surtout utile si Les tables sont déjà triés sur A La requête inclue ORDER BY A

Tri-Interclassement R et S sont triés sur A ; la jointure est m:n r = 1 ; s = 1 ; do while r <= m and s <= n ; v := R[r].A ; do j = s by 1 while s[j].A < v ; end ; s := j ; do j = s by 1 while S[j].A = v ; do i = r by 1 while R[i].A = v ; J := J + R[i]*S[j] ; end r := i ; Coût CPU ?

Index Lookup En général bien plus rapide que les méthodes précédentes Coût CPU ? X indexe S.A do i = 1 to m /* Il y a k entrées dans X avec la valeur R[i].A do j = 1 to k J := J + R[i] * S[j] ; end ;

Hash Lookup En général la méthode la plus efficace pour les équijointures La table temporaire H c’est S haché sur A do j = 1 to n ; /* hache S k= hash S[j].A ; H[k] := H[k] + S[j] ; do i = 1 to m ; k = hash R[i].A ; /* Il y a h tuples de S dans la case H(k) do i= 1 to h ; /* visite de H[k] if S[j].A = R[i].A then J := J + S[j] * R[i] ; end ; Coût CPU ?

Linear Hash Lookup La taille de la table S peut être inconnue S peut être une table temporaire crée pendant l’évaluation d’une restriction Mode pipeline Hachage statique est alors peu performant LH solutionne ce problème Si H est en RAM, alors la variante LKRHash semble le plus efficace Conçu par P. Larson & al (Microsoft) Utilisée dans de nombreux produits MS LH est aussi préférable pour l’évaluation bi-passe ou multi-passe

Mode d'exécution d'une opération relationnelle Matérialisation La table résultante est créée pour l'opération suivante dans l'arbre d'exécution Pipeline On passe un tuple à la fois par l'arbre Moindre coût mémoire Pas toujours possible ORDER BY, Hash Lookup… Mixte

Optimisation de requêtes L'optimiseur assigne un coût à toute opération relationnelle de la requête Typiquement: nombre de pages examinées Surtout on examine les jointures Le coût prévisible de chaque méthode possible En général les indexes diminue les coûts L'arbre algébrique d'exécution de la requête devient annoté Chaque arbre annoté devient un plan d'exécution

Optimisation de requêtes (Choix des arbres algébriques) Pour générer des plans on examine Les arbres gauches résultants des améliorations algébriques Approche générale Les arbres gauches et ramifiés Surtout pour les BDs parallèles L'espace des plans est en général très grand Des milliers de plans pour déjà pour quelques relations à joindre

Optimisation de requêtes On choisi le plan minimisant le coût total System R (IBM) Surtout, il faut choisir l'ordre des jointures On examine Tout plan possible Programmation dynamique Meilleur coût de tout (R1 JOIN R2) Sur cette base, meilleur coût de tout (R1 JOIN R2) JOIN R3 etc Programmation dynamique à la "Selinger" On peut conserver un coût non optimal s'il permet optimiser une opération plus tard Jointure par tri-interclassement suivie par ORDER BY

Optimisation de requêtes On examine par une heuristique certains plans seulement "Hill Climbing" On commence avec un plan OK On varie des composantes Une autre méthode pour la jointure… On choisi le plan moins cher alors On continue les variations jusqu'au temps limite où le meilleur plan "Greedy Algorithm" Une simplification de la programmation dynamique A chaque étape on ne retient que le meilleur plan.

Gestion de tampons (buffers) Cachez les pages peut largement améliorer les performances Particulièrement pour les RAMs 32-256 MO, populaires aujourd'hui, mais rares et chères hier

Concept de cache CPU Cache Disque

Strategies pour la gestion de caches Stratégie typique: LRU remplacer la page le moins usité Il a été prouvé que pour les BDs il vaut mieux une stratégie dite LRU-2 (Waikum & al, Sigmod 1993)

Bases parallèles Partitionnement d'une table sur les mémoires de plusieurs CPUs mémoire partagée (shared memory) CPUs d'une même machine mémoires locales (shared-nothing) même machine ou multiordinateur réseau réseau 10 Mb/s au moins partionnement statique ou scalable Exécution en parallèle d'opérations sur une BD Amélioration notable de temps de réponse traitement parallèle traitement en RAM Amélioration possible de la fiabilité partitionnement redondant

Partitionnement Aléatoire Localité de référence Haché Ordonné par place disponible Localité de référence Tuples de Paris sur le site à Paris etc. Haché le plus simple ex. Teradata, Sybase statique ou scalable (LH*...) problème de non-uniformité Ordonné Statique (ex. Teradata, Sybase ?) Scalable (RP*...) Multi-attribut Scalable (k-RP*...)

Opérations relationnelles Sélection et/ou projection sur l'attribut de partitionnement message au site concerné sur un autre attribut messages à tous les sites sur un intervalle de l'attribut de partitionnement messages aux sites concernés message(s) à tous les sites sur un autre intervalle

Jointures parallèles Equi-jointures Theta-jointures Hachage "Probing" la méthode en général la plus efficace "Probing" quand une de tables est petite Theta-jointures fichiers ordonnés parallèles

Fonctions agrégats Sum somme de sommes parallèles Count somme de comptages parallèles Avg SUM et COUNT parallèles somme de sommes / somme de comptages Autres (MIN, MAX, VAR, TOP... ) selon le cas

Conclusion Gestion de structures physiques est un aspect fondamental de la conception des SGBD Leur choix détermine les performances Les principes changes rapidement: RAMs bien plus grandes et moins chères Nouveaux supports : RAIDs par exemple Nouveaux types de données: k-d et multimédia nécessitant nouvelles structures: arbre-R, arbre k-d, arbres quad.... Structures parallèles ou distribuées: DLH, LH*, RP*...

FIN