Organisation des Fichiers pour la Performance Gestion de Fichiers Organisation des Fichiers pour la Performance

Motivation et plan du cours Comment organiser ou re-organiser les fichiers de manière à en améliorer la performance? On a déjà couvert les techniques de compression des fichiers. Maintenant: Le triage des fichiers de facon à pouvoir appliquer la recherche binaire  tri interne Un tri plus sophistiqué: Tri par clé. La récuperation d’espace dans les fichiers qui ont connu des changements

Recherche rapide: vue générale Le coût de la recherche physique (seeking) est très élevé. Ce coût doit être pris en considération lorsque l’on détermine une stratégie pour la recherche directe. La même question se pose dans le contexte du tri, qui est le plus souvent la première étape d’une recherche efficace. Plutôt que d’essayer tout simplement de trier puis de chercher, on va essayer de le faire de manière à minimiser le nombre de recherches (“seeks”).

Recherche rapide: vue générale (suite) Jusqu’à maintenant, la seule facon que l’on ait de trouver des enregistrements rapidement est d’utiliser leur Numero d’Enregistrement Relatif (RRN). Ceci ne peut marcher que dans le cas d’enregistrement à taille fixe. Sans le RRN ou bien dans le cas d’enregistrements à taille variable, la seule facon de trouver un enregistrement est de faire une recherche séquentielle. Ceci es très inéfficace. On voudrait trouver une facon plus efficace de chercher un enregistrement en utilisant la valeur de leur clé.

Recherche rapide: recherche binaire Supposez que le fichier est trié et que l’on cherche un enregistrement dont la clé est “kelly” dans un fichier de 1000 enregistrements à taille fixe. 1 2 … 500 750 1000 1: Johnson 2: Monroe Comparaison Suivante

Recherche binaire versus rech. séquentielle La recherche binaire dans un fichier de n enregistrements prend O(log2 n) comparaisons. La recherche séquentielle prend O(n) comparaisons. Lorsque la recherche séquentielle est utilisée, doubler le nombre d’enregistrements dans un fichier double le nombre de comparaisons requises pour la recherche. Lorsqu’une recherche binaire est utilisée, doubler le nombre d’enregistrements ajoute une seule comparaison au pire. Afin d’utiliser une recherche binaire, cependant, le fichier doit tout d’abord être trié. Ceci peut prendre beaucoup de temps !

Recherche rapide: triage d’un fichier de disque en mémoire Si le contenu d’un fichier peut être sauvegardé entièrement en mémoire, on peut executer un tri interne. Trier en mémoire est très efficace. Cependant, si le fichier ne tient pas complètement en mémoire, tous les algorithmes de tri vont nécessiter un grand nombre de seeks. Trier serait, dans ce cas, extrêmement lent. Malheureusement, bien des fichiers sont rop large pour tenir en mémoire. Il faut trouver une solution à ce probleme.

Recherche rapide: les limitations de la recherche binaire et le tri interne La recherche binaire demande plus d’un ou deux accès. Par contre, l’accès aux enregistrements en utilisant un RRN peut être executé en un seul accès. Comment atteindre la performance d’une recherche par RRN tout en conservant l’avantage de l’accès par clé ? Conserver un fichier trié est très cher: en plus de la recherche pour la location précise de l’insertion, une fois cette location trouvée, il faut déplacer les enreg.s afin de dégager l’espace pour l’insertion. Le tri interne ne marche que sur des petits fichiers. Pour de grands fichiers, le tri par clé s’impose.

Recherche rapide: tri par clé Vue générale: Lorsque l’on trie un fichier en mémoire, les seules choses qui aient vraiement besoin d’être triées sont les clés. Les algorithmes de tri par clé marchent comme le tri interne, mais avec deux différences importantes: Plutot que de lire un enregistrement entier dans un tableau en mémoire, on lit chaque enregistrement dans une mémoire tampon temporaire, on en extrait la clé et on ignore le reste des informations Si on veut écrire les enregi.s en ordre, il faut les lire une seconde fois, car on les avait ignoré en 1ère lecture.

Limitation de la méthode de tri par clé L’écriture d’enregistrements en ordre demande autant de seeks au hasard qu’il y a d’enreg.s. Puisque l’écriture est parsemée parmi les opérations de lectures, l’écriture demande également autant de seeks au hasard qu’il y a d’enregistrements. Solution: Pourquoi re-écrire le fichier trié par ordre de clé? Il suffit de re-écrire l’index trié.

Récuperation d’espace dans les fichiers: effacement des enreg Récuperation d’espace dans les fichiers: effacement des enreg.s et compactage Lorsque beaucoup d’enreg.s ont été effacés, il faut essayer de récuperer l’espace perdu. Ceci peut se faire par compactage des données en stockage. Le compactage se fait en cherchant les emplacements du fichier qui n’ont pas de données et en récuperant ces espaces. Il est donc important, pour ce faire, d’avoir un moyen pour indiquer les enregistrements effacés. Une fois l’espace perdu est détecté, un programme de compactage le comprime.

Effacement dynamique des enregistrements à taille fixe Le désavantage de la méthode précédente est qu’il y a de l’attente entre l’effacement d’un enregistrement et le compactage. Parfois, cependant, il est nécessaire de récuperer l’espace immédiatement. Pour ce faire, on peut: Indiquer les enregistrements effacés Trouver l’endroit que les enregistrements effacés ont occuppé afin de le reutiliser lorsque l’on ajoute de nouveaux enregistrements Avoir un moyen de savoir immédiatement s’il y a de la place dans le fichier et sauter à ces endroits. Solution: Utiliser une liste chainée avec les RRN jouant le rôle de pointeurs.

Effacement dynamique des enregistrements à taille fixe (suite) Idée: construire une liste chainée de tous les enreg.s disponibles. Une telle liste est appelée “avail list”. Les pointeurs sont une référence à l’enreg. suivant sur la liste avail list. Lorque une insertion est à faire dans un fichier à enreg.s à taille fixe, il suffit de prendre le premier enregistrement sur la liste avail list. Puisque tous les enreg.s sont de même taille, il n’y a aucune raison de trier la liste avail list, car n’importe lequel des enreg.s disponibles convient.

Effacement dynamique des enregistrements à taille fixe (suite) Le moyen le plus commode pour administrer avail list est d’utiliser une pile (“stack”): Le stack est constitué de noeuds de la forme suivante: [enregistrement|suivant] enregistrement = RRN suivant = RRN (pointeur de tête)  [4|8][8|3][3|5][5|2][2|-1] Effacer un eneg. = “push”; récuperer de l’espace = “pop”. Si le pointeur au dessus du stack est “-1” (NULL), il n’ y a plus d’espace libre dans le fichier. Trouver l’endroit que les enreg.s effacés ont occuppé afin de les reutiliser est donc réalisé en exécutant un pop.

Effacement dynamique des enregistrements à taille fixe (suite) Une question pratique: à quel endroit stocke-t-on le stack? Le fait-on physiquement séparé du fichier lui-même? Le stack n’est pas physiquement stocké de manière séparée du fichier, mais conceptuellement. Les enregistrements ne se déplacent donc pas physiquement; seuls les pointeurs sont réarrangés. Il est à se rappeler que les pointeurs dont il est question ici sont des pointeurs logiques et non physiques; ce sont les RRN et non des variables formelles pour pointer que l’on utilise dans un language de programmation.

Effacement dynamique des enregistrements à taille fixe (suite) Considérons un fichier avec 7 enreg.s à longueur fixe: LH  -1 |Edwards…|Bates … |Wills… |Jone |Masters…|Bouche |Chavez… | 0 1 2 3 4 5 6 Le fichier après l’effacement de l’enreg. 1: LH 1 |Edwards…|*-1 … |Wills… | Saul… |Masters…|Jane… |Chavez… | 0 1 2 3 4 5 6 Le fichier après l’effacement de l’enreg. 5: LH 5 |Edwards…|*-1 … |Wills… | Saul… |Masters…| *1 |Chavez… | 0 1 2 3 4 5 6 Le fichier après l’insertion des enreg.s “Jone” et “Bouche”: LH -1 |Edwards…|Bouche … |Wills… |Saul… |Masters…|Jone… |Chavez… | 0 1 2 3 4 5 6

Effacement dynamique des enregistrements à taille variable Meme idée que pour les enreg.s à taille fixe, mais une implementation différente doit être utilisée. En particulier, on doit conserver un compte d’octets de chaque enreg. au début de celui-ci. De plus, les liens vers le prochain enreg. sur la liste avail list ne peuvent pas être les RRN, mais les décalages en octets (Pourquoi?). De plus, la structure de données utilisée pour la liste avail list ne peut pas être un stack puisque l’on doit s’assurer que, lorsque l’on réutilise un emplacement, ce dernier a la bonne taille !

Effacement dynamique des enregistrements à taille variable (suite) Considérons un fichier avec 5 enreg.s à longueur variable: LH -1 |40Edwards…|64Bates … |45Wills… |87Masters…|53Chavez…| 0 1 2 3 4 Le fichier après l’effacement des enreg. 1: LH 43 |40Edwards…|64*-1… |45Wills… |87Masters…|53Chavez…| 0 1 2 3 4 Le fichier après l’effacement des enreg. 1 et 3: LH 156 |40Edwards…|64* … |45Wills… |87*43…|53Chavez…| Le fichier après l’insertion de l’enreg. “Jone”: |40Edwards…|64* … |45Wills… |87Jone…|53Chavez…| 0 1 2 3 4 Nous devons faire autant de pops que possible pour trouver un enreg. de taille convenable !

Fragmentation de stockage L’espace perdu à l’intérieur d’un enregistrement s’appelle la fragmentation interne. Les enregistrements à taille variable ne souffre pas de fragmentation interne. Par contre, la fragmentation externe ne peut pas être évitée. Il y a 3 façons de traiter la fragmentation externe: compactage de stockage (voir début du cours) Coalescence/fonte des trous L’utilisation d’une stratégie de placement

Strategies de placement Stratégie First Fit: accepter le premier emplacement libre capable d’accomoder le nouvel enregistrement. Stratégie Best Fit: choisir le plus petit emplacement de libre qui peut accomoder le nouvel enregistrement. Stratégie Worst Fit: choisir le plus grand emplacement de libre.

Stratégies de placement (suite) Quelques remarques générales sur les stratégies de placement: Les stratégies de placement s’appliquent seulement aux enregistrements à taille variable Si l’espace est perdu à la fragmentation interne, les meilleurs choix de stratégies de placement sont first fit et best fit. Une strategie worst fit aggrave la fragmentation interne. Si, par contre, l’espace est perdu à la fragmentation externe, la stratégie worst fit peut être très utile.

Enregistrements fixes Tout comme dans le tri rapide, les indexes sont utiles dans le contexte des enregistrements effacés. La liste avail list indicant la location des enregistrements non-utilisés consiste en des enregistrements fixes (“pinned records”) dans le sens ou ces enregistrements ne peuvent pas être déplacés car les déplacer créerait des pointeurs pendants (“dangling pointers”). Les enregistrements fixes, par contre, rendent le tri difficile. Une solution consiste à utiliser un index ordonné et à ne pas déplacer les enregistrements.