Gestion de Fichiers GF-16: Addressage Disperse Extensible (Extendible Hashcoding) (Base sur le Chapitre 12 de Folk, Zoellick & Riccardi, File Structures, An Object-Oriented Approach with C++;)

2 Motivation Les Arbres B sont des structures de fichiers efficaces vis a vis du nombres de seeks necessaires pour trouver un enregistrement. De plus, ce sont des structures dynamiques qui s’adaptent tres bien aux nouvelles donnees ajoutees ou au donnees effacees. L’addressage disperse (Hashcoding), neanmoins, est plus efficace que les arbres B dans le cas ou le fichier n’est pas modifie. En d’autres termes ce sont des structures efficaces mais pas dynamiques. La question posee dans ce cours est: Est-il possible de creer des structures basees sur le Hashcoding qui soient egalement dynamiques?

3 Hashcoding Extensible: Vue Generale La reponse a cette question est: “oui”. L’idee principale est d’utiliser une structure d’arbre appelee un “trie” et de comprimer ce trie en une table de reference. Cette table va doubler de taille lorsque certaines insertions sont effectuees et va etre reduite de moitie lorsque certains effacements sont effectues. Dans d’autres cas, comme on l’a vu pour les arbres B, il y aura un mecanisme proche de la “re-distribution”. L’idee generale est de se debarasser des resolution de collisions lineaires utilisees dans le Hashcoding non- extensible (qui sont un type de “patch”) en changeant l’echelle de la table de hashcoding mais en gardant ses caracteristiques originales.

4 Example I d’un “Trie” a b b d n l r d e r able abrahms adams anderson andrews baird Ce trie a un radix de 26

5 Example II d’un “Trie” Ce trie a un radix de 10

6 Qu’est ce que le trie a a voir avec Hashcoding? On peut utiliser un trie de radix 2 (avec les valeurs 0 et 1). Les buckets du hashcoding representent les feuilles de ce trie A B C

7 Representation du Trie I Si on represente le Trie par un arbre, on doit faire beaucoup de comparaisons, en decendant vers les feuilles de l’arbre. Pire encore, si le Trie est trop grand pour tenir en memoire, on retrouve les problemes de storage d’arbres sur disque  A quoi bon, dans ce cas, utiliser le hashcoding? Solution: Applatir le trie et le representer en un tableau.

8 Representation du Trie II (Figure 12.4, p.528)

9 Pourquoi Representer la table de Hashing en un Trie? L’idee est qu’une table reguliere n’a pas de maniere simple et elegante de s’aggrandir lors de debordement alors qu’un trie peut s’aggrandir elegament. 2 cas: Cas simple: le trie etait sous-utilise et un bucket peut etre divise en deux nouveaux buckets et les enregistrements redistribues selon leurs addresse. Cas plus complexe: On peut etendre notre prefixe de n a n+1 bits, doublant, ainsi, le nombre de buckets present dans notre structure.

10 Que faire en cas de Debordement? 1. Cas simple (Figure 12.5, p.529)

11 Que faire en cas de Debordement? 2. Cas complexe (Figure 12.6, p.530)

12 Effacement d’enregistrements Afin d’etre considere rellement dynamique, le hashcoding extensible doit avoir la possibilite de s’aggrandir lors de debordements, mais aussi de retrecir si beaucoup d’enregistrements sont effaces Questions: Quand doit-on combiner des buckets et Quels buckets doivent etre combines?  Buddy Buckets Autre Question: Peut-on egalement reduire la taille de l’index en trie? Oui si chaque bucket a au moins 2 cellules de cet index dirigees sur lui.

13 Performance du Hashcoding Extensible: Temps Performance au niveau du temps requis pour acceder a un enregistrement: Si l’index en trie peut etre sauvegarde en memoire, 1 seul acces au disque est requis. Si l’index en trie ne tient pas en memoire, deux acces peuvent etre necessaires.  Ce qui importe c’est que le temps d’acces est fixe et donc le hashcoding extensible a une performance de O(1).

14 Performance du Hashcoding Extensible: Utilisation d’Espace I Une analyse du hashcoding extensible a montre que: L’utilisation d’espace par les buckets est tres fortement periodique et fluctue entre les valeurs de 53% et 94%  Puisque les cles sont distribues aleatoirement, l’espace se remplit jusqu’a environ 90%. Ceci est suivi d’une serie de division d’espace et qui reduit l’utilisation jusqu’a moins de 50% et le cycle se repete. En moyenne, l’utilisation d’espace par les buckets est de 69%.

15 Performance du Hashcoding Extensible: Utilisation d’Espace II L’utilisation d’espace par l’indexe en trie change en fonction du nombre de cles et de la taille des buckets. Elle peut etre estimee par la formule suivante: ( 3.92 / b ) r (1+1/b) Ameliorer l’utilisation d’espace en retardant le moment de la division causee par le debordement: on peut retarder la division en buckets additionelles en creant un bucket de debordement. Ceci a l’interet de retarder egalement le dedoublement de l’index en trie. Ceci peut ameliorer l’utilisation d’espace mais empirer le temps requis pour un acces aux donnees

16 Autres Approches I: Hashcoding Dynamique I Le hashcoding dynamique represente l’indexe en utilisant aussi des tries. Cependant, plutot que d’utiliser un simple trie, le hashcoding dynamique creee une foret de tries. En hashcoding dynamique, 2 fonctions de hashcoding peuvent etre utilisees. La premiere trouve le bon trie et la deuxieme trouve le bucket dans ce trie. L’utilisation d’espace est similaire a celle du hashcoding extensible, mis a part le fait que l’indexe s’aggrandit plut graduellement. Par contre, la recherche d’enregistrement peut demander plus d’acces au disque.

17 Autres Approches I: Hashcoding Dynamique II (Figure 12.23, p. 552)

18 Autres Approches II: Hashcoding Lineaire I Au contraire du Hashcoding extensible et dynamique, le hashcoding lineaire n’utilise pas d’indexe. L’espace necessaire est etendu lineairement. Le hashcoding lineaire utilise aussi deux fonctions de hashcoding. Le nombre d’acces au disque pour la recherche reste proche de 1, neanmoins, l’utilisation d’espace est moins bonne que pour le hashcoding extensible ou dynamique car il est, en moyenne de 60%.

19 Autres Approches II: Hashcoding Lineaire II (Figure 12.24, p. 554)