Stratégie de gestion de nombreuses images pour un site Web
Je commence un nouveau site Web qui (espérons-le) aura beaucoup d'images générées par les utilisateurs. J'essaie de trouver le meilleur moyen de stocker et de servir ces images.
Le CMS que j'utilise (umbraco) possède une bibliothèque multimédia qui place un dossier sur le serveur pour chaque image. À l'intérieur, vous pouvez avoir différentes tailles de la même image. Ce dossier a un identifiant et la base de données contient des informations supplémentaires pour cette image ainsi que l'identifiant du dossier.
Cela fonctionne très bien pour les petits sites, mais que se passe-t-il si les images atteignent 10 000, 100 000 ou 1 000 000? Il semble que la recherche sur le répertoire prendrait beaucoup de temps pour trouver le bon dossier. Je suis sur Windows 2008 si cela fait une différence.
Je ne suis pas si inquiet pour la charge. Je peux facilement équilibrer la charge de mon serveur et répliquer les images sur tous les serveurs. La nature du site n’aura pas beaucoup d’utilisateurs, mais il pourrait y avoir beaucoup de photos.
Merci.
-Nate
EDIT
Après réflexion, je pense que je vais créer un répertoire pour chaque utilisateur sous un dossier d’images racine puis avoir les images de l’utilisateur sous celui-ci. Je serais assez content si j'avais même 5 000 utilisateurs, cela ne devrait donc pas être trop mauvais d'une recherche linéaire. Si cela devient lent, je le répartirai dans des dossiers tels que /media/a/adam/image123.png.
Si cela devient vraiment gros, je développerai la méthode ci-dessus pour construire un arbre plus grand. Cela prendrait beaucoup de contenu si.
Générez une valeur de hachage pour chaque image, en fonction du contenu de celle-ci (comme SHA-1 ou SHA-2) et séparez la structure de répertoires en fonction de la valeur de début du hachage (c.-à-d. 64 répertoires couvrant une plage de valeurs de hachage:
/ images/00-03/images/04-07/images/08-0B ... (etc)
OU une autre panne
/ images/0000/images/0001/images/0002 .../images/000A ... (etc)
Certains fichiers seraient nommés 0003ABC2EFA23.png. Il se trouverait dans le répertoire:/images/0003
Le numéro du répertoire représenterait les premiers chiffres de la valeur de hachage. Vous pouvez le configurer pour utiliser une plus grande gamme de valeurs de hachage OR plus petite. Cela vous permet de diviser les fichiers dans des répertoires distincts et de trouver rapidement le fichier souhaité en fonction de ce hachage.
REMARQUE: assurez-vous de prendre en compte la résolution de collision du hachage (car cela peut et va probablement arriver). Quelque chose comme 0003ABC2EFA23-01.png pour la première collision, 0003ABC2EFA23-02.png pour la seconde.
De tels problèmes d'échelle ont des solutions efficaces sur les plates-formes cloud telles que Azure ou AWS. Même si nous parlons d'un système de fichiers local, les mêmes concepts peuvent être appliqués ici. Trois éléments à prendre en compte dans votre solution:
1) Supprimez toute association entre les attributs de la ressource et son emplacement physique. Par exemple, évitez d'utiliser des noms de fichiers, des titres, des valeurs de hachage calculées, etc. pour déterminer l'emplacement de la photo.
2) Utilisez un algorithme de partage adapté à l'échelle souhaitée et aux ressources disponibles pour déterminer l'emplacement physique des photos. Par exemple, si vous avez trois volumes de taille égale, votre algorithme de partage peut être conçu pour répartir les photos dans des sous-dossiers sur les volumes de sorte que l'utilisation de l'espace sur ces volumes soit équilibrée. Vous pouvez également distribuer des photos de manière à ce que la lecture soit plus performante en utilisant plusieurs piles de disques. Il est préférable de garder les choses simples. Les séquences numériques de noms de dossiers fonctionnent le mieux. Voici quelque chose à titre purement illustratif et non destiné à être une recommandation:
00000000/000 à 999/000.jpg à 999.jpg
00000001/000 à 999/000.jpg à 999.jpg
3) Utilisez la table de base de données pour stocker les métadonnées et un pointeur sur le ou les fichiers physiques.
En utilisant cette approche, vous serez en mesure de faire évoluer cette image vers un grand nombre d'images avec de bonnes performances.
Avoir chaque image dans son propre répertoire est vraiment excessif, et vous avez raison, cela va causer des problèmes de performances lorsque vous obtenez des tonnes d'images. Le point auquel vous atteignez cela dépend du système d'exploitation. Mais cela peut ralentir considérablement les choses.
Puisque vous suivez l'image dans une base de données, vous pouvez utiliser le id unique de la ligne pour le nom de l'image. Donc, pour l'image de la rangée 1, enregistrez le nom sous "1.jpg". Si vous devez suivre différentes versions ou révisions, vous pouvez les nommer comme '1-resized.jpg', '1-original.jpg', etc. Dans la base de données, vous pouvez stocker le nom de fichier d'origine et/ou l'extension de fichier utilisé.
Si vous attendez beaucoup d'images, divisez-les en plusieurs répertoires en fonction de l'ID à l'aide d'une expression. Par exemple, truncate( id / 1000), qui placerait les 1000 premières images dans le répertoire 0 ("0/1.jpg", "0/1-resized.jpg"), les 1000 suivantes dans "1", etc. Lorsque vous avez besoin de référencer l'image # 15025, vous savez que cette image est '15 /15025.jpg '. (si vous voulez être lisse, insérez des zéros dans le nom du répertoire pour qu'ils puissent être triés)
Si vous vous retrouvez avec un million d'images, elles seront décomposées en 1 000 répertoires de 1 000 images chacun, qui peuvent encore être navigués via la ligne de commande si vous devez gérer les choses manuellement.
Vous avez mentionné que les informations étaient stockées dans la base de données ... pourquoi ne pas effectuer une recherche dans la base de données puis accéder directement au dossier?