Comment gère-t-on des Tera-octets de fichiers sur un server?

WRInaute occasionnel
Voila mon futur problème, je dois gérer une quantité astronomique de photos de taille moyenne 50ko.

Je pense répartir ça dans un repertoire "virtuel" pointant vers plusieurs disques dur avec NFS. Mais la question que je me pose c'est est-ce que je peux mettre toute mes photos à la racine genre photos/1.jpg, photos/2.jpg, .. ou faut-il scinder la masse en plusieurs sous rep?

En gros, est-ce qu'il ne faut pas mieux limiter le nombre de de fichier d'un repertoire en créant des sous repertoires avec chacun un nb limité de photos ou est-ce qu'un seul et bon gros rep peut marcher?
 
WRInaute impliqué
salut,
intuitivement vaudrait mieux partitionner
tu peux par exemple calculer un md5 sur le nom de la photo
et dire que le substr des deux derniers caractères te donne le nom du sous rép
 
WRInaute impliqué
julienr a dit:
intuitivement vaudrait mieux partitionner
tu peux par exemple calculer un md5 sur le nom de la photo
et dire que le substr des deux derniers caractères te donne le nom du sous rép
C'est effectivement une méthode très utilisée et qui je pense est bonne :wink:

Après il faut voir comment tes photos sont "différenciées" logiquement (par exemple tu pourrais les classer soit par date, par utilisateur ...)...
Puis faut aussi gérer les doublons (d'où le MD5 très utile)...

En tous les cas, pas tout mettre dans un seul répertoire...
 
WRInaute impliqué
Bonjour,
tu peux mettre 3 profondeurs de répertoire décrites par les premiers caractères du nom du fichier

style : images1.gif
tu le mets dans le répertoire /i/m/a/images1.gif

Par rapport à la méthode précédente avec md5, il n'y a pas répartition équilibré entre les différents répertoires.
 
WRInaute passionné
le mieux est de combiner les deux methodes: profondeur et md5. Et plutot que du NFS, je ferais du HTTP.
 
WRInaute impliqué
Serious a dit:
Et plutot que du NFS, je ferais du HTTP.
??? pourquoi ? Ca allourdirait pas les échanges ?
(je ne suis pas spécialiste du NFS, mais étant implanté au noyau Linux, je vois ça comme "plus optimisé" par rapport au HTTP...)
 
WRInaute discret
Perso je pencherai + vers une solution repartie sur plusieurs serveurs avec un ou plusieurs load balancers qui envoyent les requettes vers le serveur concerné (la repartition peut se faire selon un motif du nom du fichier). Un ou plusieurs serveurs d'upload font le travail en sens inverse ;) L'avantage c'est que tu peux augmenter la taille du stockage avec trés peu de changements (suffit d'ajouter un serveur et de configurer le LB avec le nouveau serveur)
Avoir un seul serveur avec des tera de données c'est risqué, car en cas de panne la verification du (ou des) volumes prendra forcement du temps et pendant ce temps aucune donnée ne sera disponible, sans oublier que l'upgrade sera forcement plus délicat.
Sinon pour le FS en lui même ReiserFS est le plus adapté à un grand nombre de fichiers dans un répertoire unique, mais il faut quand même faire une repartition par nom de fichier à plusieurs niveaux ;)

MADdanny
 
Discussions similaires
Haut