Je développe un projet PHP sur la plate-forme Linux. Y a-t-il des inconvénients de mettre plusieurs milliers d'images (fichiers) dans un répertoire? C'est un ensemble fermé qui ne poussera pas. L'alternative serait de séparer ces fichiers à l'aide de la structure de répertoires en fonction de certains identifiants (de cette façon, il y aurait seulement seulement 100 dans un répertoire d'un).
Je pose cette question, car souvent je vois une telle séparation lorsque je regarde les URL d'images sur différents sites. Vous pouvez voir que cette séparation de répertoire est effectuée de manière à ce que plusieurs centaines d'images ne figurent dans un répertoire.
Que ferais-je gagner en ne mettant pas plusieurs milliers de fichiers (de non-définis de croissance) dans un répertoire, mais en les séparant en groupes d'E.G. 100? Vaut-il la peine de compliquer des choses?
Pourquoi séparer plusieurs fichiers sur différents répertoires:
7 Réponses :
La seule raison pour laquelle je pouvais imaginer où il serait préjudiciable était lors de l'itération sur le répertoire. Plus de fichiers, signifie plus d'itérations. Mais c'est essentiellement tout ce que je peux penser à une perspective de programmation.
Je pense qu'il y a deux aspects à cette question:
Le système de fichiers Linux que vous utilisez efficacement des répertoires de support avec des milliers de fichiers. Je ne suis pas un expert, mais je pense que les nouveaux systèmes de fichiers n'auront pas de problèmes.
Y a-t-il des problèmes de performance avec des fonctions PHP spécifiques? Je pense que l'accès direct aux fichiers devrait être correct, mais si vous faites des listes d'annuaires, vous pourriez éventuellement fonctionner dans des problèmes de temps ou de mémoire.
En plus d'un accès de fichiers plus rapide en séparant des images en sous-répertoires, vous étendez également considérablement le nombre de fichiers que vous pouvez suivre avant de frapper les limites naturelles du système de fichiers.
Une approche simple consiste à MD5 () le nom du fichier, puis utilisez les caractères premiers n comme nom de répertoire (par exemple, substr (MD5 ($) Nom de fichier), 2) ). Cela garantit une distribution raisonnablement uniforme (vs prenant les premiers caractères n du nom de fichier droit).
Plus d'un niveau serait utile dans d'autres niveaux de sous-répertoires. Par exemple: ./12/34/56/78/1234567890ABC.JPG.
Ok, donc MD5 serait une approche générale. Dans mon cas, j'ai déjà une carte d'identité unique, car chaque image est associée à une ligne de base de données exacte (qui a sa principale ligne de base de données). Je pense que c'est un scénario typique.
Il convient de penser que ces chiffres ne peuvent pas être aussi répartis que les hachage de MD5.
Merci de votre réponse (et de poser une telle question aussi). C'était tellement serviable pour moi. Je produisais un cache HTML dans un répertoire mais il y avait tellement de fichiers à la fin. Donc, j'ai divisé la génération sur des répertoires avec substr (MD5 (Nom de fichier $), 2) et maintenant il fonctionne comme un charme.
Plusieurs mille images sont toujours bien. Lorsque vous accédez à un répertoire, les systèmes d'exploitation indiquent la liste de ses fichiers par blocs de 4k. Si vous avez une structure de répertoire ordinaire, il peut prendre le temps de lire la liste des fichiers entière s'il y a beaucoup (e. G. Cent mille fichiers.
Il n'y a aucune raison de diviser ces fichiers en plusieurs répertoires, si vous n'attendez pas de conflits de nom de fichier et si vous n'avez pas besoin de itérer ces images à un moment donné.
Mais toujours, si vous pouvez penser à une catégorisation suggestive, ce n'est pas une mauvaise idée de trier les images un peu, même si c'est juste pour des raisons de maintenance.
Si la modification du système de fichiers est une option, je vous recommanderais de déplacer partout où vous stockez toutes les images dans un système de fichiers Reatefs. Il est excellent au stockage / accès rapide de nombreux petits fichiers.
Sinon, la réponse de la puissante de les briser dans des dossiers est la plus logique et augmentera les temps d'accès par une marge considérable.
Habituellement, la raison de cette division est la performance du système de fichiers. Pour un ensemble fermé de 5000 fichiers, je ne suis pas sûr que cela vaut la peine. Je vous suggère d'essayer une approche simple de mettre tous les fichiers dans une seule chose de répertoire, mais gardez un œil ouvert sur le temps réel nécessaire pour accéder aux fichiers.
Si vous voyez que ce n'est pas assez rapide pour vos besoins, vous pouvez le scinder comme vous le suggérez.
J'ai dû diviser les fichiers moi-même pour des raisons de performance. De plus, j'ai heurté une limite de fichiers de 32k par répertoire lors de l'utilisation ext3 sur NFS (pas sûre s'il s'agit d'une limite de NFS ou EXT3). C'est donc une autre raison de se diviser en plusieurs répertoires. Dans tous les cas, essayez avec un seul dir et seulement divisé si vous voyez que ce n'est pas assez rapide.
(pas sûr s'il s'agit d'une limite de NFS ou EXT3) C'est une limite ext3.