Le stockage de nombreuses images dans un seul répertoire ralentit-il la récupération des images?

Question

Si j'ai un site sur lequel les utilisateurs peuvent télécharger autant d'images qu'ils le souhaitent (pensez photobucket-like), quel est le meilleur moyen de configurer le stockage de fichiers (tous les téléchargements reçoivent également un horodatage aléatoire unique)?

site root
--username
----image1.jpg
----image2.jpg
----image3.jpg
--anotheruser
----image1.jpg
----image2.jpg
----image3.jpg
...

ou

siteroot
--uploads
----image1.jpg
----image2.jpg
----image3.jpg
----image4.jpg
----image6.jpg
...
----image50000.jpg

Je pense que la première méthode est plus organisée. Mais je pense que la deuxième méthode est standard (en gardant tous les téléchargements dans le même répertoire), mais je me demande si ce serait plus lent lors de la récupération d’une image s’il ya des milliers d’images dans le même répertoire

--- modifier ---

Merci pour les bonnes réponses obtenues jusqu'à présent. De plus, je vais créer des vignettes, donc je devrais aussi insérer ce répertoire quelque part ... ou , créer une convention de dénomination telle que thumb_witely.jpg.

autant de façons différentes de le faire. Oui, l'espace disque posera problème. mais pour l'instant je suis préoccupé par le temps de récupération. Lorsque je dois envoyer une image au navigateur, si cette image se trouve dans un répertoire de 10 000 autres images, je suis inquiet de la lenteur avec laquelle cela pourrait être.

Answer 1

Le nombre de fichiers dans un répertoire ne devrait avoir aucune incidence sur le temps requis pour lire les données d'un fichier - mais cela peut considérablement affecter le temps nécessaire pour rechercher le fichier avant de pouvoir commencer à le lire.

Les points d'arrêt exacts au démarrage des principaux problèmes varieront d'un type de système de fichiers à l'autre, mais en général, si vous parlez de quelques centaines de fichiers, vous n'avez pas besoin de vous en soucier. Si vous parlez de quelques milliers, il convient de réfléchir et peut-être de faire un peu d'analyse comparative pour voir comment votre système de fichiers et votre matériel le gèrent. Si vous parlez de dizaines de milliers de fichiers, vous devez vraiment commencer à séparer les choses. (Auparavant, j’avais un serveur d’impression Linux / e2fs dans lequel CUPS ne supprimait pas ses fichiers de contrôle des travaux après l’impression et il contenait environ 100 000 fichiers dans un seul répertoire. Il a fallu une demi-heure pour obtenir la liste des répertoires. n’affiche aucun nom de fichier.)

Les séparer par nom d'utilisateur n'est peut-être pas le meilleur choix, car vous aurez probablement beaucoup d'utilisateurs qui téléchargent très peu d'images et peut-être un couple qui télécharge des centaines ou des milliers d'images, ce qui risque de créer des problèmes de temps d'accès. répertoires de stockage des utilisateurs. Le problème le plus important dans ce scénario est que vous vous retrouveriez probablement (avec un site performant) avec des milliers, voire des dizaines de milliers d’utilisateurs et un grand nombre de sous-répertoires, ce qui est aussi grave qu’un grand nombre de fichiers pour ralentir l’accès à votre ordinateur. données.

Étant donné que vous allez avoir un horodatage dessus, ce que je ferais probablement, c’est de les placer dans des sous-répertoires basés sur les derniers trois chiffres de l’horodatage. Cela répartira les fichiers de manière relativement uniforme dans 1000 sous-répertoires et devrait garder un nombre de fichiers relativement faible dans chaque répertoire. (Si vous utilisez les trois premiers chiffres, un répertoire sera rempli avant de passer au suivant au lieu de les distribuer équitablement.) Si vous vous retrouvez avec trop de fichiers dans chaque sous-répertoire (ce qui signifierait probablement que vous traitez avec plusieurs millions d'images téléchargées), vous pouvez ajouter un deuxième niveau pour les trois derniers chiffres, de sorte que upload-1234567890.jpg se termine à /567/890/upload-1234567890.jpg.

Answer 2

La réponse à cette question est "peut-être". Il est possible que la récupération des fichiers soit correcte, mais si vous devez effectuer une maintenance sur le dossier, ce serait un casse-tête énorme car les processus tentent d’énumérer les listes de répertoires.

Ce qui améliorerait la situation serait un certain nombre de sous-répertoires dans le dossier images (ou deux niveaux, en fonction du nombre d'images que vous souhaitez stocker), de sorte que vous disposiez d'une hiérarchie semblable à celle-ci:

siteroot
-- uploads
---- a
---- b
---- c
  :
---- z

... puis stockez les fichiers en fonction de leur première lettre (ainsi, toutes les images dont le nom commence par 'a' vont dans le dossier 'a'). Vous pourriez avoir ceci comme suffixe de deux ou trois lettres (aa, ab, ac, ad ..., ba, bb, bc ..., zx, zy, zz) et éventuellement avoir une hiérarchie sous celle-ci afin de diviser fichiers sur plusieurs dossiers en fonction des quatre premiers caractères du nom.

Si les noms se voient attribuer un nom alphanumérique aléatoire, les fichiers sont répartis uniformément dans tous les dossiers (avec une taille d'échantillon suffisante).

Vous pouvez envisager de combiner votre option (1) et le fractionnement des images sur une hiérarchie, comme je l’ai décrit ci-dessus. Cela garantirait que si un seul utilisateur télécharge un grand nombre de fichiers, vous êtes couvert. De même, si vous consultez de nombreux annuaires d'utilisateurs, le même principe s'applique pour vous assurer que vous n'avez pas 1 000 000 annuaires d'utilisateurs sous un seul parent.

Answer 3

essayez d’utiliser mongodb ... une base de données à valeur de clé permettant également de stocker des données binaires. Il est très rapide et efficace et prend en charge le sharding (placer des données sur plusieurs machines) dès la sortie de la boîte

vous ne voulez vraiment pas avoir des dossiers et des dossiers pleins de fichiers. La gestion de ces dossiers prend une éternité et la modification ultérieure du schéma de dénomination / division est un cauchemar. En outre, si vous manquez d'espace disque, vous rencontrez un problème. Également pour l'équilibrage de la charge, avoir un disque dur plein avec des fichiers n'est pas efficace

Answer 4

J'utilise souvent un schéma comme celui-ci: uploads / (# id% 1000) /img_#id.jpg

Où #id est ofc. numéro d'identification (entier) de la photo stockée dans la base de données. Cela fournit un schéma simple basé uniquement sur l'identifiant de la photo.

Answer 5

Cela dépend du système de fichiers. Par exemple, FAT16 a tendance à être assez lent si vous avez plus de 512 fichiers dans un répertoire. FAT32 et NTFS n'ont pas les mêmes limitations, mais s'exécutent beaucoup plus lentement si vous avez une très grande quantité de fichiers. Même si vous utilisez l'un des systèmes de fichiers Linux les plus robustes, vous pourrez toujours analyser les répertoires plus rapidement s'ils sont plus petits.

J'irais certainement avec # 2 - diviser les images en répertoires par utilisateur.

Answer 6

Je pense que les sous-répertoires du répertoire uploads seraient les meilleurs.

site root
--uploads
----username
------image1.jpg
------image2.jpg
------image3.jpg
----anotheruser
------image1.jpg
------image2.jpg
------image3.jpg
...

En fonction du système d'exploitation hôte, la présence d'un trop grand nombre de fichiers dans un répertoire peut entraîner des problèmes de compatibilité. De plus, en fonction de la manière dont vous obtenez la liste des images, des problèmes de performances pourraient en résulter.

De plus, l'option 2 serait un gâchis. :)