J' ai eu à réfléchir sur ce genre de problème, en fait il y a une limite plutôt basse (quelques milliers) pour la plupart des fs au nombre de fichiers par répertoire. On peut en fait avoir beaucoup de fichiers par répertoire, mais souvent avec une augmentation du temps d'accés rédibitoire.
Il est donc judicieux de classer les fichiers dans plusieurs sous-rep, avec un moyen rapide de les retrouver - par ex année/mois/jour, ou tout autre système de classement. Là on se rapproche des pbs de cléfs dans les tables de hash, il faut essayer de répartir le plus uniformément les fichiers (ie ne pas avoir 90 % des fichiers dans 10 % des répertoires).
Concernant les temps d'accés, je pense qu'un fs comme reiserfs devrait mieux supporter la charge que ext2/3 ; il utilise un sytème d'arbre balancé pour atteindre les données rapidement. D'autres fs sont sûrement équivalent, cf les nombreux benchs dispo...
Reste aussi la solution sus-mentionné d'une base de données ; je pense que le choix dépend de la taille de fichiers, de leur nombre, du nombre d'accés, le mieux est de faire des tests ;-)
# Re: FS pour stocker plusieurs millions de docs
Posté par jigso . En réponse au journal FS pour stocker plusieurs millions de docs. Évalué à 2.
Il est donc judicieux de classer les fichiers dans plusieurs sous-rep, avec un moyen rapide de les retrouver - par ex année/mois/jour, ou tout autre système de classement. Là on se rapproche des pbs de cléfs dans les tables de hash, il faut essayer de répartir le plus uniformément les fichiers (ie ne pas avoir 90 % des fichiers dans 10 % des répertoires).
Concernant les temps d'accés, je pense qu'un fs comme reiserfs devrait mieux supporter la charge que ext2/3 ; il utilise un sytème d'arbre balancé pour atteindre les données rapidement. D'autres fs sont sûrement équivalent, cf les nombreux benchs dispo...
Reste aussi la solution sus-mentionné d'une base de données ; je pense que le choix dépend de la taille de fichiers, de leur nombre, du nombre d'accés, le mieux est de faire des tests ;-)