2010-04-12 7 views
8

Je dois stocker environ 600 000 images sur un serveur Web utilisant NTFS. Suis-je préférable de stocker des images dans des blocs de 20 000 images dans des sous-dossiers? (Windows Server 2008)Conséquences sur les performances du stockage de 600 000 images dans le même dossier (NTFS)

Je suis préoccupé par encourir les frais généraux du système d'exploitation lors de la récupération d'image

+0

20 000 fichiers, c'est encore beaucoup. mieux divisé de l'ordre de 1000 fichiers/dir – Javier

+0

Je suppose que je serais tenté de demander si 600 répertoires tous dans un répertoire devient un problème. J'imagine que les systèmes d'exploitation sont optimisés pour moins de 100. Je ne pense pas que 600 serait un problème si. –

+0

Auparavant, le fait de placer autant de fichiers dans un répertoire NTFS causait des dommages au FS lui-même, provoquant une croissance de quelque part quelque part qui ne rétrécirait jamais. Est-ce que ça a été réparé? (Désolé d'être vague ici, j'oublie les détails.) –

Répondre

6

Allez-y. Tant que vous avez un index externe et un chemin d'accès direct à chaque fichier sans afficher la liste du contenu du répertoire alors vous êtes ok.

J'ai un dossier de plus de 500 Go avec plus de 4 millions de dossiers (qui ont plus de dossiers et de fichiers). J'ai quelque part de l'ordre de 10 millions de fichiers au total.

Si j'ouvre accidentellement ce dossier dans Windows Explorer, il reste coincé à 100% de l'utilisation du processeur (pour un noyau) jusqu'à ce que je mette fin au processus. Mais aussi longtemps que vous vous référez directement aux performances du fichier/dossier est important (ce qui signifie que je peux accéder à l'un de ces 10 millions de fichiers sans surcharge)

1

dossiers NTFS Pour stocker un fichier d'index avec des liens vers son contenu. Avec une grande quantité d'images, ce fichier va beaucoup augmenter et affecter négativement vos performances. Donc, oui, sur cet argument seul, vous feriez mieux de stocker des morceaux dans les sous-dossiers. Les fragments dans les index sont une douleur.

+0

Alors que vous pourriez avoir raison, est-ce basé sur autre chose que l'hypothèse? Nous avons des dossiers avec des fichiers de 450k, il n'y a pas de problèmes jusqu'à présent - bien que je suppose que les parcourir, même dans un gestionnaire de fichiers ne serait pas rapide. – leeeroy

+0

En fait, ce n'est pas une supposition (expérience avec différentes implémentations de NTFS et surtout ses limitations). C'est une erreur de conception. Ma réponse a été de clarifier si cela affecterait la performance (oui), pas si cela donnerait des «problèmes» comme un échec. Le fichier d'index n'est pas un fichier intelligent. Si elle pousse, vous obtenez plus d'entretien pour récupérer les fragments. Et je me cite: Les fragments dans les index sont une douleur. – Shyam

3

Selon que NTFS possède des index de répertoire, ça devrait aller de l'application niveau. Je veux dire, que l'ouverture de fichiers par nom, suppression, changement de nom, etc, par programme devrait fonctionner correctement.

Mais le problème est toujours d'outils. Les outils tiers (tels que MS Explorer, votre outil de sauvegarde, etc) sont susceptibles de sucer ou au moins être extrêmement inutilisable avec un grand nombre de fichiers par répertoire. Tout ce qui effectue une analyse de répertoire est susceptible d'être assez lent, mais pire, certains de ces outils ont des algorithmes médiocres qui ne s'adaptent pas aux nombres de fichiers, même modestes (10k +), par répertoire.