Question

Nous créons un site MVC ASP.NET qui devra stocker 1 million de photos +, tout autour de 2k-5k. D'après Ressearch précédent, il semble qu'un serveur de fichiers soit probablement meilleur qu'une base de données (n'hésitez pas à commenter autrement).

Y a-t-il quelque chose de spécial à considérer lors du stockage de nombreux fichiers? Y a-t-il des problèmes avec Windows pour trouver la photo rapidement s'il y a tellement de fichiers dans un dossier? Une structure de répertoire segmentée doit-elle être créée, par exemple les divisant par nom de fichier? Ce serait bien si la solution évoluerait à au moins 10 millions d'images pour les besoins potentiels de future expansion.

Était-ce utile?

La solution

4KB est la taille du cluster par défaut pour NTFS. Vous pouvez régler ces paramètres en fonction de la taille de l'image habituelle.http://support.microsoft.com/kb/314878

Je construisais un arbre avec des sous-répertoires pour pouvoir passer d'un FS à l'autre: Combien de fichiers puis-je mettre dans un répertoire?Et évitez certains problèmes: http://www.frank4dd.com/howto/various/maxfiles-per-dir.htm

Vous pouvez également avoir des archives contenant des images associées pour les charger avec un seul fichier ouvert. Les archives peuvent être compressées est le goulot d'étranglement est des E / S, non compressés s'il est CPU.

Une base de données est plus facile à entretenir mais plus lente ... donc c'est à vous!

Autres conseils

Voir également cette question de défaut de serveur pour une discussion sur les structures d'annuaire.

Le problème n'est pas que le système de fichiers ne soit pas en mesure de stocker autant de fichiers dans un répertoire, mais que si vous souhaitez accéder à ce répertoire à l'aide de Windows Explorer, il faudra une éternité, donc si vous avez besoin d'accéder manuellement à ce dossier, vous devez segmenter Il, par exemple, avec un répertoire pour chaque 2-3 premières lettres / numéros du nom ou même une structure plus profonde.

Si vous pouviez diviser cela dans des dossiers 1K avec des fichiers 1K, chacun sera plus que suffisant et le code à le faire est assez simple.

En supposant des NTF, il y a une limite de 4 milliards de fichiers par volume (2 ^ 32 - 1). C'est la limite totale pour tous les dossiers du volume (y compris les fichiers du système d'exploitation, etc.)

Un grand nombre de fichiers dans un seul dossier ne devraient pas être un problème; NTFS utilise un arbre B + pour la récupération rapide. Microsoft vous recommande de désactiver la génération de noms courts-fichiers (la fonctionnalité qui vous permet de récupérer MyPictureOfyou.html en tant que mypic ~ 1.htm).

Je ne sais pas s'il y a un avantage de performance pour les segmenter en plusieurs répertoires; Je suppose qu'il n'y aurait pas d'avantage, car NTFS a été conçu pour les performances avec de grands répertoires.

Si vous décidez de les segmenter en plusieurs répertoires, utilisez une fonction de hachage sur le nom du fichier pour obtenir le nom du répertoire (plutôt que le nom du répertoire étant la première lettre du nom de fichier par exemple) afin que chaque sous-répertoire ait à peu près le même numéro des fichiers.

Je n'exclurais pas en utilisant un réseau de livraison de contenu. Ils sont conçus pour ce problème. J'ai eu beaucoup de succès avec Amazon S3. Puisque vous utilisez une solution basée sur Microsoft, Azure pourrait peut-être être un bon ajustement.

Y a-t-il une sorte d'exigence qui vous empêche d'utiliser une solution tierce?

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top