Persistance: arbres de données stockés en tant qu'arborescences de répertoires

Question

Je m'interrogeais sur les aspects pratiques du stockage d'une structure d'arborescence en mémoire en tant qu'arborescence de répertoires à des fins de persistance. Dans mon cas, le système de fichiers cible sera ZFS et, une fois la structure créée, plusieurs processus l’auront rarement accès.

Comment performant utilise-t-il une arborescence de répertoires comme mécanisme de persistance pour les arborescences de données?

Answer 1

Pour lire et écrire votre arbre, vous appelerez le système de fichiers plusieurs fois par noeud. C’est beaucoup plus cher que n’importe quel code sensé que vous pourriez concevoir pour parcourir une image mémoire.

Le choix d'une approche raisonnable dépend de ce que votre modèle d'utilisation est censé être. Si, dans une invocation typique de votre code, vous vous attendez à lire dans toute l'arborescence, travaillez dessus, puis écrivez-le en entier. Vous feriez mieux de le rassembler dans un seul fichier. Si, toutefois, vous vous attendez à lire / travailler sur / ne muter que quelques nœuds, sans lire dans la plus grande partie de l’arborescence, différence de performance entre parcourir la structure de répertoires et effectuer plusieurs recherches / lectures à parcourir. un arbre stocké dans un seul fichier sera beaucoup plus petit, et il peut être intéressant de le faire par souci de simplicité / clarté / en évitant de réinventer les roues. De plus, si plusieurs processus le font simultanément, le verrouillage des nœuds et des sous-arbres devient beaucoup plus facile avec l’approche basée sur les répertoires.

Sachez que pour certains systèmes de fichiers couramment utilisés, le temps d'ouverture d'une entrée de répertoire dépend du nombre total d'entrées dans le répertoire.

EDIT: J'ai utilisé des méthodes similaires avec ext3 pour le back-end CGI d'un site; ne pas réinventer la roue a rendu le prototypage plus rapide et la maintenance plus simple, lit / écrit / verrouille plutôt bien, mais des modifications très fréquentes - de l'ordre de centaines par seconde - de la structure de répertoires elle-même ont mal fonctionné avec un stockage réel ; à la fin j'ai restructuré les choses pour que les sections de l'arborescence de répertoires auxquelles des entrées de répertoires seraient très fréquemment ajoutées / supprimées se retrouvent sur un volume tmpfs - pour moi cet ensemble d'état pourrait (à coût élevé) être reconstruit à partir de celui stocké dans un stockage moins volatile suite à un redémarrage. J'ai peu d'expérience de ZFS et je ne connais pas votre modèle d'utilisation. Par conséquent, je ne sais pas si cela poserait un problème pour vous. Si je le faisais maintenant pour un site très utilisé, je lirais probablement ma propre bibliothèque de verrous nommés à la place.

Answer 2

La plupart des systèmes de fichiers sont optimisés pour l'accès à un fichier ouvert. L'ouverture / la fermeture d'un fichier prend donc beaucoup de temps. Si chaque feuille de votre arbre est petite, la lecture / écriture de la structure entière prendrait plusieurs fois plus de temps que nécessaire.

En outre, la plupart des systèmes de fichiers ont un bloc d’allocation minimal, généralement compris entre 2 et 8 Ko. si vos feuilles sont beaucoup plus petites que cela, vous perdrez beaucoup d’espace.

En bref, plus vos feuilles sont petites, plus l'idée est mauvaise.

Answer 3

Si je vous ai bien compris, vous parlez de créer une arborescence qui donnerait une représentation codée de votre système de fichiers. Je suppose donc que vous devrez supporter une surcharge au début si vous lisez dans votre arborescence, mais les recherches et les traversées ultérieures de l’arbre seraient probablement plus rapides que de toucher le stockage sur disque à chaque fois.

Answer 4

Problèmes possibles:

• Cela peut entraîner une utilisation inefficace de l'espace disque (dans de nombreux systèmes de fichiers, un répertoire est un fichier et occupe par conséquent tout un bloc sur le disque ...)
• La lecture / écriture sera lente car vous effectuez de nombreux accès au système de fichiers
• Le système de fichiers peut imposer ou imposera des limites quant à la longueur de chaque nom d'élément et / ou des caractères que vous pouvez utiliser pour les noms
• Il sera facile pour d'autres processus de corrompre vos données et / ou d'exiger un coût de verrouillage considérable
• L'utilisation de "disques" à l'état solide peut entraîner plus d'écritures que d'autres méthodes et raccourcir la durée de vie du support

En bout de ligne: cela ne vaut peut-être pas la peine.