Gestion de Fichiers Hachage (suite et fin)

2 Plan du cours d’aujourd’hui Utilisation des “buckets” Effacements dans des fichiers hachés Autres méthodes de résolution de collision: “double hashing”, débordement progressif chainé; enchainement avec une aire de débordement séparée; “scatter tables” Patrons d’accès aux enregistrements

3 Stockage de plus d’un enregistrements par adresse: “bucket” Nous allons maintenant voir une éthode de hachage qui stocke plus d’un enregistrement par adresse physique. Un “bucket” est un bloc d’enregistrements partageant la même adresse h(k); il est recupéré dans un même accès au disque. Lorsqu’un enregistrement va être mis en stockage ou recupéré du stockage, son adresse de bucket est déterminée par la fonction de hachage. Lorsqu’un bucket est remplit, on doit toujours résoudre le problème de débordement d’enreg.s.

4 Stockage de plus d’un enregistrements par adresse: “bucket” Exemple pour un bucket de 3 enregistrements Clé Adresse Green |Green …|Hall … | | Hall | | | | Jenks32 32 |Jenks … | | | King33 33 |King … |Land …|Marx …| Land33 34 |Nutt …. | | | Marx33 Nutt33

5 Effet des buckets sur la performance La formule de calcul de la densité d’enregistrement d’un fichier change un peu: PD = r/(b*N) N = # d’adresses disponibles r = # d’enreg.s dans le fichier b = # d’enreg.s par adresse Bien que PD ne change pas lorsque l’on réduit de moitié le nombre d’adresses et que l’on double la taille des buckets, le nombre de débordements attendu diminue dramatiquement.

6 Effet des buckets sur la performance Pour illustrer l’effet des buckets sur la performance, Considerons le deux alternatives suivantes: 1. Stocket 750 enreg.s dans un fichier haché de 1000 adresses, chacune contenant un enregistrement. 2. Stocket 750 enreg.s dans un fichier haché de 500 adresses, chacune contenant 2 enregistrements. Alternative 1: PD = r/(b*N) = 750/(1*1000) = 0.75 = 75% Alternative 2: PD = r/(b*N) = 750/(2*500) = 0.75 = 75% Alternative 1: r/N = 750/1000 = 0.75 Alternative 2: r/N = 750/500 = 1.50

7 Effet des buckets sur la performance L’estimation des probabilités de collision se fait comme avant: p(0) (p1) p(2) p(3) p(4) p(5) … Alt. 1: r/N = 0.75: Alt. 2: r/N = Pourcentage de collision pour différentes taille de buckets: Alt. 1: (r/N = 0.75): # de débordements = r – N * (1 – p(0)) (Voir dernier cours) = 750 – 1000 * (1 – 0.472) = 750 – 528 = 222  29.6% de déb.s Alt. 2: (r/N = 1.50): # de débordements = 1 * [1*p(3) + 2*p(4) + 3.p(5)+ …)] = r – N*p(1) – 2*N*[p(2) + p(3) + p(4) + …] = r – N * [p(1) + 2*[1 – p(0) – p(1)]] = r – N * [2 – 2* p(0) – p(1)] = 750 – 500 * (2 – 2 * – 0.335) =  18.7% de déb.s

8 Effet des buckets sur la performance Avec l’estimation des probabilités des collisions en main, on peut faire une estimation du pourcentage de collision pour différentes tailles de buckets (Voir table 11.4): Pourcentage par taille des buckets PD (%) …

9 Implémentation des buckets La structure des buckets: maintenir un compteur d’enreg.s stockés dans le bucket, et marquer les entrées vides par une suite de symbole spéciaux (p.ex. “//////// …/”); un exemple de bucket est: |2|JONES |BRICE |//////// |////////| Initialiser le fichier avant le hachage: 1. Fixer la taille logique (= # d’adresses disponible) du fichier ainsi que le # de buckets par adresses. 2. Créer a fichier de buckets vides devant contenir des enregistrements à venir dont les buckets ont la forme suivante: |0|////////|////////|////////|////////| Pour charger un fichier haché, faire attention à revenir au début du fichier lors de la recherche d’espace vide ainsi qu’au problème de boucle infini lorsque le fichier est plein.

10 Effacer des enregistrements L’effacement d’un enregistrement d’un fichier haché est plus compliqué que l’addition d’enreg.s pour 2 raisons: L’espace dans lequel l’effacement s’est fait ne doit pas deranger les recherches futures. Il devrait être possible de re-utiliser les espaces liberes dans des additions futures. Pour illustrer le type de dérangements qui apparaissent dans ce contexte, nous utilisons le débordement progressif. Ici un enreg. effacé peut interrompre de manière invalide la recherche pour un autre enreg. qui se trouverait dans le fichier après l’emplacement de l’enreg. effacé (Fig. 11.9). La solution à ce problème consiste à utilser des pierre tombales (“tombstones”).

11 Effacer des enregistrements Une pierre tombale est un marqueur indiquant qu’un enregistrement était à un emplacement donnée auparavant mais n’y est plus. Les pierres tombales résolvent les 2 problèmes causés par l’effacement: L’espace dans lequel l’effacement s’est fait n’interrompt plus les recherches futures. Il est possible de re-utiliser les espaces libérés pour des additions futures. N’inserez une pierre tombale que si le prochain enreg. Est occupé ou est une pierre tombale, car sinon on re- introduit les problème que l’on vient juste de résoudre. L’insertion d’enregistrements est un petit peu différente lorsque l’on utilise des pierres tombales: inserez un nouvel enreg. lorsque vous rencontrez soit un espace vide ou une piere tombale.

12 Effets des effacements et des additions sur la performance Une fois qu’un large nombre d’effacements et d’additions ont pris place, il y aura beaucoup de pierres tombales occuppant des emplacements qui pourraient être occuppés par des enregistrements dont l’adresse précède ces pierres tombales, mais qui sont mises en stockages plus loin. Ceci détériore la longueur de recherche moyenne. Il y a 3 solutions possibles à ce problème: 1. réorganisation locale pendant les effacements 2. réorganisation globale lorsque la longueur de recherche moyenne est trop grande 3. utilisation d’une diff. techn. de résolution de collision

13 Autres techniques de résolution de collisions: double hachage Il y a quelques variations sur le hashing au hasard qui peut ameliorer la performance. Double Hashing: lorsqu’un débordement se produit, utiliser une séconde fonction de hachage pour trouver la location de débordement de l’ enregistrement débordant. Exemple: k ADAMS JONES MORRIS SMITH h1(k) h2(k) adresse … … enreg.s ADAMS JONES SMITH MORRIS Note: h2(k) et N (= # d’adresses disponibles) sont relativement premiers l’un à l’autre; l’adresse définitive est obtenu en prenant h1(k)+h2(k). On ajoute autant de fois h2(k) à h1(k) que nécessaire jusqu’à ce qu’on trouve un espace libre.

14 Autres techniques de résolution: débordement progressif chainé Le débordement progressif chainé est comme le débordement progressif mis à part le fait que les synonymes sont liés l’un à l’autre avec des pointeurs (Fig ). Cela réduit la longueur de la recherche dans un regroupement d’enreg.s. Problème: Supposez que DEAN a en fait 22 comme adresse et que COLE est déjà à sa place. Nous ne pourrions plus avoir un pointeur de vers DEAN à partir de son adresse domiciliaire. Solution: “two pass loading”: 1. Premier passage: charger seulement les enreg.s qui entrent dans leur adresse domiciliaire. 2. Deuxième passage: charger les enreg.s débordants.

15 Autres techniques de résolution de collisions Enchainement avec une aire de debordement separée: Comme le débordement progressif chainé mis a part le fait que les adresses de debordement n’occuppe pas les adresses normales (de non- débordement) Scatter Tables: Le fichier hash ne contient pas d’enregistrements, mais seulement des pointeurs à ces enregistrements. Autrement dit, c’est un un index. Voir les figures appropriées dans le livre.

16 Patron d’accès aux enregistrements Si on a des informations sur les enregistrements qui sont accédés le plus souvent, on peut optimiser leur location de facon à ce que ces enregistrements aient des longueurs de recherche courtes. On fait cela pour diminuer la longueur effective moyenne de recherche même si la longueur nominale moyenne de recherche reste la même. Ce principe est similaire à celui utilisé dans l’encodage Huffman.