1 Survol du Stockage et de lIndexage Chapitre 8

2 Objectifs Stockage persistant Organisation des fichiers Fichiers de données Fichiers dindexes Operations sur les fichiers Performance Comparaison Sortes dindexes Primaires Secondaires Groupés vs non-groupés; primaires vs secondaires, …

3 Stockage des Données dans des Fichiers Un SGBD stocke les relations dans des fichiers denregistrements (« records »). Dans larchitecture dun SGBD, le niveau des méthodes daccès aux fichiers supporte le concept de fichier. Le niveau des méthodes daccès aux fichiers stocke les fichiers sous forme dune ou plusieurs pages sur disque et administre ces pages. Ladministrateur des tampons (buffer manager) emmène les pages de la mémoire secondaire à la mémoire principale (dans la réserve tampon -- buffer pool). Le niveau des méthodes daccès aux fichiers fait appel à ladministrateur des tampons.

4 Données sur Stockage Externe Disques: Peuvent puiser des pages au hasard à un coût fixe Cependant la lecture de plusieurs pages consécutives est moins coûteuse que une lecture dans un ordre aléatoire Bandes magnétiques: Peuvent ne lire les pages que séquentiellement Moins coûteux que les disques; utilisées pour archivage Gestion des fichiers (GF): Méthode pour arranger un fichier denregistrements sur stockage externe. La GF utilise Identité denregistrement (Record id -- rid): Suffisant pour localiser physiquement lenregistrement Indexes: structures de données permettant de trouver les identités des enregistrements à partir des valeurs des clés de recherche

5 Organisation des Fichiers Plusieurs alternatives existent, chacune étant idéale pour certaines situations, et pas pour dautres : Tas (Heap files): Adapté au scannage de tous les enregistrements. Fichiers triés: Adapté aux situations où les enregistrements doivent être puisés dans un certain ordre, ou lorsque une plage (range) denregistrements est requis. Indexes: Structures des données en forme darbres ou de hachage pour organiser les enregistrements. Comme les fichiers triés, ils accélèrent les recherches pour un sous ensemble denregistrements sur base des valeurs des clés. Les modifications sont plus rapides que dans les fichiers triés.

6 Indexes Un index sur un fichier accélère les sélections sur les clés de recherche pour cet index. Tout sous-ensemble des attributs dune relation peut servir de clé de recherche pour un index sur cette relation. Une clé de recherche nest pas la même chose quune clé au sens densemble minimal dattributs qui identifie de manière unique un enregistrement de la relation. Un index contient une collection (généralement une liste triée) d entrées des données et permet de puiser de manière efficiente toutes les entrées des données k* en utilisant une valeur de clé k.

7 Entrées des Données k* dans un Index Trois alternatives: une entrée des données peut être un enregistrement de données avec une valeur de clé k une paire Le choix dune des alternatives dépend de la technique dindexage utilisée pour localiser les entrées des données ayant une valeur de clé k. Exemples de techniques dindexage: Arbres B+, Arbres ISAM, hachage Typiquement, un index contient de linformation qui oriente les recherches vers les entrées des données désirées.

8 Entrées des Données k* dans un Index (Suite) Les pages feuilles contiennent les entrées des données et sont chaînées. Les pages internes contiennent les entrées de lindex et dirigent la recherche. Pages internes feuilles pages

9 Entrées des Données k* dans un Index (Suite) Alternative 1: La structure de lindex est une organisation de fichier pour les enregistrements de données (en lieu et place dun tas ou dun fichier trié). Un maximum dun index peut être créé sur une collection denregistrements de données suivant lalternative 1. (Sinon, les enregistrements seront dupliqués, ce qui conduit à des redondances et à des inconsistances potentielles.) Si les enregistrements des données sont très nombreux, le # de pages contenant les entrées des données sera très élevé.

10 Entrées des Données k* dans un Index (Suite) Alternatives 2 et 3: Ici, les entrées des données sont typiquement plus petites que les enregistrements de données. Ainsi, ces 2 alternatives sont meilleurs que la première pour traiter les enregistrements de données larges. Elles sont encore bien meilleures lorsque les clés de recherche sont petites. Lalternative 3 est plus compacte que lalternative 2, mais utilise des enregistrements à taille variée, même si les clés de recherche sont à taille fixe.

11 Classification des Indexes Primaire vs. secondaire : Selon que la clé de recherche contient la clé primaire ou pas, on a un index primaire ou secondaire. Index unique : La clé de recherche contient une candidate clé. Groupé vs. nongroupé (Clustered vs. unclustered) : Si lordre des enregistrements des données est le même que ou proche de celui des entrées des données, alors lindex est groupé; sinon il est nongroupé. Eparpillé vs. dense (« sparse » vs. « dense »): Si une entrée des données apparait pour chaque valeur de la clé de recherche, alors lindexe est dense, sinon il est éparpillé.

12 Index Groupé vs. Nongroupé Supposez que lalternative 2 est utilisée pour les entrées des données et que les enregistrements de données sont stockés sur un tas (heap file). Pour construire un index groupé, dabord trier le tas (tout en réservant de lespace libre sur chaque page). Les pages en dépassement de capacité peuvent être utiles pour les insertions. (Doù, lordre des enregistrements de données est proche de celui utilisé pour trier le tas.) Entrées dindex Entrées des données (Fichier Index) (Fichier des données) Enregistrements des données Entrées des données Enregistrements des données Groupé Nongroupé

13 Index Groupé vs. Nongroupé (Suite) Quelques remarques: Lalternative 1 implique un index groupé; dans la pratique, linverse est aussi vrai car les fichiers triés sont rares. Un fichier ne peut être groupé que sur au plus une clé de recherche. Le coût de puiser des enregistrements de données en utilisant les index varie beaucoup selon que lindex en question est groupé ou pas. Lalternative 3 est la plus naturelle pour les indexes secondaires.

14 Indexes à Hachage Bon pour les sélections dégalité. Lindex est une collection de compartiments ( buckets ). Bucket = page domiciliaire plus zéro ou plus des pages de dépassement. Fonction de hachage h : h ( r ) = bucket auquel lenregistrement r appartient. h utilise la clé de recherche de r. Si lalternative 1 est utilisée, les buckets contiennent les enregistrements des données; sinon, ils contiennent des pairs ou.

15 Indexes à Arbre B+ Rappel: les pages feuilles contiennent les entrées des données et sont chaînées; les pages internes contiennent les entrées de lindex et dirigent la recherche Structure dune entrée de lindex: P 0 K 1 P 1 K 2 P 2 K m P m Pages internes feuilles pages

16 Exemple dArbre B+ Trouvez 28*? 29*? Tous les x tels que 15* < x < 30*. Insertion/effacement: Trouvez les entrées des données dans les feuilles et changez les. Besoin dajustage des parents quelques fois. Les changements peuvent parfois sétendre jusquà la racine 2*3* Racine *16* 33*34* 38* 39* 135 7*5*8*22*24* 27 27*29* Entree <= 17Entree > 17

17 Modèle de Coût pour Comparer des Organisations de Fichiers * Nous ignorons les coûts en unités CPU, pour simplifier les choses: P: nombre de pages de données E: nombre denregistrements par pages T: temps moyen de lecture/écriture dune page sur disque Nous ignorons aussi les gains obtenus en faisant de la prélecture dune séquence de pages; Doù les coûts de I/O ne sont que approximatifs Average-case analysis avec des simplifications simplistes Ce modèle simpliste ne sert quà indiquer les tendances

18 Organisations de Fichiers Heap files (ordre aléatoire; insertions à la fin) Fichiers triés suivant Fichier groupé en arbre B+, alternative 1 avec comme clé de recherche Heap file avec index à arbre B + nongroupé et avec comme clé de recherche Heap file avec un indexe à hachage nongroupé; avec comme clé de recherche

19 Opérations A Comparer Scan: Puiser tous les enregistrements du disque Recherche sur base dégalité Range selection (sélection dune plage de valeurs) Insertion denregistrement Effacement denregistrement

20 Simplifications dans lAnalyse Heap Files: Sélection sur base de légalité utilisant la clé; exactement un enregistrement correspond à la valeur de la clé. Fichiers triés: Compactage du fichier après effacement. Indexes: Alt (2), (3): taille de lentrée = 10% de enregistrement. Hachage: pas de buckets de dépassement. 80% doccupation => tailles du fichier = 1.25 fois la taille des données. Arbre: 67% doccupation (typique en pratique). Implique une taille de fichier = 1.5 fois la taille des données.

21 Coût des Opérations

22 Considérations sur la Charge de Travail Importantes questions pour le choix des indexes Questions à se poser pour chaque requête: A quelle relations a-t-elle accès? Quels attributs sont puisés? Quels attributs sont impliqués dans les conditions de sélection ou de join? Quelle est la sélectivité de ces conditions? Pour chaque opération de modification: Quels attributs sont impliqués dans les conditions de sélection ou de join? Quelle est la sélectivité de ces conditions? Le type de la modification ( INSERT/DELETE/UPDATE ) ainsi que les attributs affectés.

23 Choix dIndexes Quels indexes devraient être créés? Quelles relations devraient avoir des indexes? Quels attributs devraient former la clé de recherche? Devrait-on avoir plusieurs indexes? Quelle sorte dindex devrait-on avoir? Primaire? Groupé? Dense? Haschage? Arbre?

24 Choix dIndexes (Suite) Une approche: Considérer les requêtes les plus importantes à tour de rôle. Pour chacune de ces requêtes, considérer le meilleur plan dexécution qui utiliserait le choix actuel. Voir si un meilleur plan nest pas réalisable avec des indexes additionnels. Si cest le cas, créer ces derniers. Cette approche suppose que lon comprend comment un SGBD évalue des requêtes et crée des plans dexécution. La présente discussion considère des requêtes mono relationnelles. Avant de créer un index, lon doit aussi prendre son impact sur les modifications (dans la charge de travail du système) en considération, car Les indexes peuvent accélérer les requêtes et en même temps ralentir les modifications. Ils requièrent aussi de lespace disque !

25 Guide pour la Sélection des Indexes Les attributs dans la clause WHERE sont des candidats appropriés pour être des clés dindexes: Une recherche sur base dégalité suggère un indexe à hachage. Une plage des valeurs suggère un index à arbre. Le regroupement est particulièrement utile pour des requêtes à plage; il est aussi utile pour des recherches sur base dégalité en cas de duplicata. Des clés de recherche à attributs multiples devraient être utilisées si la clause WHERE contient plusieurs conditions: Lordre des attributs est important pour les requêtes à plage. On essaie dabord de choisir des indexes qui sont bénéfiques à autant de requêtes que possible. Le choix dun index regroupé devrait être basé sur les requêtes importantes qui en bénéficieraient le plus.

26 Exemples dIndexes Groupés Un index à arbre B+ sur E.age peut être utilisé pour retrouver les tuples qualifiés. Considérons la requête avec GROUP BY. Si le nombre de tuples avec E.age > 10 est très élevé, utiliser un index sur E.age et ensuite faire un tri peut coûter bien cher. Un index groupé sur E.dno peut faire mieux. Requêtes à égalité et duplicatas: Un groupement sur E.hobby aiderait. SELECT E.dno FROM Emp E WHERE E.age>40 SELECT E.dno, COUNT (*) FROM Emp E WHERE E.age>10 GROUP BY E.dno SELECT E.dno FROM Emp E WHERE E.hobby=Stamps

27 Indexes avec Clés de Recherche Composées Clés de Recherche Composées : Recherche sur une combinaison de champs. Requêtes à égalité: Chaque valeur de champs est égale à une constante. P.ex.: pour lindex, on peut avoir: age=20 AND sal =75 Requêtes à plage: Un champ donné nest pas une constante. P.ex.: age =20; ou age=20 AND sal > 10 Les entrées des données dans lindex sont triées par la clé de recherche pour supporter des requêtes à plages. sue1375 bob cal joe nameagesal 12,20 12,10 11,80 13,75 20,12 10,12 75,13 80, Enregistrements des données triés par name Entrées des données dans lindex triées par Entrées des données triées par Exemples dindexes utilisant lordre lexicographique.

28 Clé de recherche Composée Pour retrouver des enregistrements de la relation Emp avec age =30 AND sal =4000, un index sur serait meilleur que un index sur age ou un index sur sal. Si la condition est 20< age <30 AND 3000< sal <5000: Un index à arbre groupé sur ou est le meilleur choix. Si la condition est age =30 AND 3000< sal <5000: Un index groupé sur est meilleur quun index sur. Les indexes composés sont plus larges et plus souvent modifiés que les indexes simples.

29 Spécification des Indexes en SQL Le standard ne supporte pas (encore) les indexes !!! En pratique, chaque système commercial supporte les indexes. Un exemple générique de création dindexe est: CREATE INDEX IndexAgeGpa ON Students WITH STRUCTURE = BTREE KEY = (age, gpa) Indexes en Oracle: Création: CREATE INDEX index_name ON table_name (attribute) Indexes composés: CREATE INDEX index_name ON table_name (att1, …,attn) Destruction: DROP INDEX index_name

30 Résumé Plusieurs alternatives dorganisations de fichiers existent, chacun étant approprié dans chaque situation. Si des requêtes de sélection sont fréquentes, trier le fichier ou construire un index est important. Index à hachage seulement bons pour les sélections sur base de légalité. Fichiers triés et indexes à arbre bons pour les sélections des plages de valeurs; mais aussi bon pour sélections sur base de légalité. (Puisque les fichiers sont rarement trié en pratique, les arbres B+ sont de bien meilleurs indexes.) Un index est une collection dentrées des données plus une manière rapide de trouver ces entrées en usant des valeurs dune clé de recherche.

31 Résumé (Suite) Les entrées des données peuvent être des enregistrements, ou des paires ou. On peut avoir plusieurs indexes sur un fichier denregistrements donné, chacun ayant une clé de recherche différente. Un index peut être groupé ou nongroupé, primaire ou secondaire, ainsi que dense ou éparpillé. Les différences ci haut ont des conséquences sur lutilité des données et la performance des opérations.