Quel est le meilleur endroit pour stocker des images téléchargées, une base de données SQL ou un système de fichiers sur disque?
J'écris une application qui permet aux utilisateurs de télécharger des images sur le serveur. Je m'attends à environ 20 images par jour tout en JPEG et probablement pas édité/redimensionné. (C’est une autre question, comment redimensionner les images côté serveur avant de les stocker. Peut-être que quelqu'un peut s’il vous plaît déposer une ressource .NET pour cela dans le commentaire ou à peu près). Je me demande maintenant quel est le meilleur endroit pour stocker les images téléchargées.
Stockez les images sous forme de fichier dans le système de fichiers et créez un enregistrement dans une table avec le chemin exact de cette image.
Ou stockez l'image elle-même dans une table en utilisant un type de données "image" ou "données binaires" du serveur de base de données.
Je vois des avantages et des inconvénients dans les deux. J'aime bien a) car je peux facilement déplacer les fichiers et il suffit de changer l'entrée de la table. Par ailleurs, je n'aime pas stocker de données professionnelles sur le serveur Web et je ne souhaite pas vraiment connecter le serveur Web à une autre source de données contenant des données professionnelles (pour des raisons de sécurité). J'aime bien b) car toutes les informations sont: au même endroit et facilement accessible par une requête. D'autre part, la base de données deviendra très grosse très bientôt. Externaliser ces données pourrait être plus difficile.
Je stocke généralement les fichiers sur le système de fichiers, car c'est la raison de son existence, bien qu'il existe des exceptions. Pour les fichiers, le système de fichiers est la solution la plus flexible et la plus performante (généralement).
Le stockage de fichiers dans une base de données pose quelques problèmes - les fichiers sont généralement beaucoup plus volumineux que votre ligne moyenne - les ensembles de résultats contenant de nombreux fichiers volumineux consomment beaucoup de mémoire. De même, si vous utilisez un moteur de stockage qui utilise des verrous de table pour les écritures (ISAM par exemple), il est possible que votre table de fichiers soit verrouillée en fonction de la taille/du débit des fichiers que vous stockez ici.
En ce qui concerne la sécurité - Je stocke généralement les fichiers dans un répertoire situé en dehors de la racine du document (non accessible via une requête http) et les sers via un script qui vérifie d'abord l'autorisation appropriée.
Le seul avantage de l'option B est d'avoir toutes les données dans un système, mais c'est un faux avantage! Vous pouvez faire valoir que votre code est également une forme de données et qu'il peut donc également être stocké dans une base de données - comment l'aimeriez-vous?
Sauf si vous avez un cas unique:
- La logique métier appartient au code.
- Les données structurées appartiennent à la base de données (relationnelle ou non relationnelle).
- Les données en bloc appartiennent au stockage (système de fichiers ou autre).
Il n'est pas nécessaire d'utiliser un système de fichiers pour conserver les fichiers. Au lieu de cela, vous pouvez utiliser le stockage en nuage (tel que Amazon S ) ou le service Infrastructure-as-a-service (tel que ploadcare ):
https://uploadcare.com/upload-api-cloud-storage-and-cdn/
Mais stocker des fichiers dans la base de données est une mauvaise idée.
Flickr utilise le système de fichiers - ils discutent des raisons ici
Des clients ont insisté plusieurs fois sur l’option B (stockage de base de données) sur différents serveurs, et nous toujours avons fini par revenir à l’option A ( système de fichiers).
Les grands BLOB comme celui-ci n’ont tout simplement pas été gérés de manière satisfaisante, même par SQL Server 2005, le dernier que nous avons essayé.
Plus précisément, nous avons constaté de graves problèmes de masse et, je pense, des problèmes bloquants.
Autre remarque: si vous utilisez un stockage basé sur NTFS (serveur Windows, etc.), vous pouvez envisager de trouver un moyen de mettre des milliers et des milliers de fichiers dans un seul répertoire. Je ne sais pas trop pourquoi, mais parfois, le système de fichiers ne résiste pas bien à cette situation. Si quelqu'un en sait plus à ce sujet, j'aimerais l'entendre.
Mais j'essaie toujours d'utiliser des sous-répertoires pour casser un peu les choses. La date de création fonctionne souvent bien pour cela:
Images/2008/12/17/.jpg
... Ceci fournit un niveau de séparation décent et aide également un peu lors du débogage. Les clients FTP et Explorer peuvent s’étouffer s’il ya de très gros répertoires.
EDIT: Juste une petite note pour 2017, dans les versions plus récentes de SQL Server, de nouvelles options permettent de gérer de nombreux BLOB censés éviter les inconvénients que j'ai décrits.
J'ai récemment créé une application PHP/MySQL qui stocke des fichiers PDF/Word dans une table MySQL (jusqu'à 40 Mo par fichier jusqu'à présent).
Avantages:
- Les fichiers téléchargés sont répliqués sur le serveur de sauvegarde avec tout le reste, aucune stratégie de sauvegarde séparée n'est nécessaire (tranquillité d'esprit).
- La configuration du serveur Web est un peu plus simple car je n’ai pas besoin d’avoir un dossier de téléchargement/télécharger et de dire à toutes mes applications où il se trouve.
- J'utilise des transactions pour les modifications afin d'améliorer l'intégrité des données - je n'ai pas à m'inquiéter des fichiers orphelins et manquants
Inconvénients:
- mysqldump prend maintenant très longtemps car il y a 500 Mo de données de fichier dans l'une des tables.
- Globalement pas très efficace en mémoire/cpu par rapport au système de fichiers
J'appelle ma mise en œuvre un succès, elle répond aux exigences de sauvegarde et simplifie la présentation du projet. La performance est correcte pour les 20-30 personnes qui utilisent l'application.
Je sais que c'est un ancien post. Mais beaucoup de visiteurs de cette page n’ont rien à voir avec la question. Surtout pour un débutant.
Comment télécharger et stocker des images ou des fichiers sur notre site Web:
Pour un site Web statique, il n’ya peut-être pas de problème puisque le stockage de fichiers pour un hébergement de partage reste adéquat. Le problème provient d'un site Web dynamique quand il devient plus grand. Plus gros dans la base de données peut être manipulé, mais plus gros dans les fichiers tels que les images devient un problème. Il y a deux types d'images sur un site web:
Les images proviennent de l'administrateur du blog dynamique. Généralement, ces images ont été optimisées avant le téléchargement.
Les images d'utilisateurs dans le cas d'utilisateurs sont autorisées à télécharger des images telles qu'un avatar. Ou les utilisateurs peuvent créer un contenu de blog et mettre des images de l'éditeur de texte. Ce type d'images est difficile à prédire la taille. Les utilisateurs peuvent télécharger de grandes images uniquement pour un petit contenu en redimensionnant la taille de la vue, mais pas la taille.
En ignorant l'item no. 1 ci-dessus, solution rapide pour le numéro d'article 2 peuvent être résolus temporairement par les conseils suivants si nous n'avons pas de fonctionnalité d'optimisation d'image sur notre site Web:
N'autorisez pas les utilisateurs à télécharger directement depuis un éditeur de texte en les redirigeant vers la galerie d'images. Sur cette page, les utilisateurs doivent télécharger le fichier à l’avance avant de pouvoir s’intégrer au contenu. Cette méthode s'appelle un gestionnaire de fichiers.
Utilisez une fonction de recadrage pour permettre aux utilisateurs de télécharger des images. Cela limitera la taille de l'image même lorsque les utilisateurs téléchargent un très gros fichier. L'image finale est le résultat de l'image recadrée. Nous pouvons définir la taille côté serveur et accepter uniquement, par exemple, 500 Ko ou moins.
Maintenant, ce n'est que temporaire. Pour la solution finale, la question est répétée:
- Comment gérer un grand stockage d'images?
- Redimensionner ou changer l'extension.
- Comment un site Web ou un commerce électronique grand ou moyen gère-t-il le stockage de fichiers pour ses images?
Que pouvons-nous faire alors:
Migrer à partir du partage d'hébergement VPS. Pas assez? Puis plus haut en passant à Dedicated.
Créez votre propre serveur pour le stockage de fichiers. Googler pour le faire. Ce n'est pas aussi difficile que vous le pensez. Certaines personnes le font pour leur site web.
Le moyen le plus simple est d’utiliser le service de stockage de fichiers CDN.
D'accord, 1 et 2 est un peu cher. Mais non 3 je pense est la meilleure solution.
Certains services CDN vous permettent de stocker autant de fichiers Web que vous le souhaitez.
Question "Comment télécharger un fichier sur CDN à partir de notre site Web?"
Ne vous inquiétez pas, une fois que vous vous êtes inscrit (généralement gratuitement), vous obtiendrez des instructions sur la manière de télécharger un fichier et d'obtenir son lien depuis/vers votre site Web. Vous obtiendrez une API et plus. C'est facile.
Certains fournisseurs nous offrent un service gratuit pendant 14 jours avec un stockage et une bande passante limités. Mais ce sera bon pour le point de départ. Le seul problème est que "les gens n'essayent jamais".
J'espère que cela aidera les débutants.
J'utilise des images téléchargées sur mon site Web et je dirais certainement l'option a).
Une autre chose que je recommande fortement est de changer immédiatement le nom de fichier de ce que l’utilisateur a nommé la photo, en quelque chose de plus facile à gérer. Par exemple, quelque chose avec la date et l'heure identifie de manière unique chaque image.
Il est également utile d'effacer le nom de fichier de l'utilisateur de tout caractère étrange pour éviter des complications futures.
Redimensionnez définitivement l'image et vérifiez son format si vous le pouvez. Il y a eu des cas de fichiers malveillants téléchargés et servis par des hôtes involontaires. Par exemple, la vulnérabilité GIFAR vous permettait de masquer un Java applet dans un fichier GIF, qui serait alors en mesure de lire les cookies dans le contexte actuel et de les envoyer vers un autre site pour une attaque de script entre sites (redimensionner les images l’empêche généralement, car cela endommage le code incorporé). Bien que cette attaque ait été corrigée par les correctifs de la machine virtuelle Java, le fait de servir naïvement des fichiers binaires sans les nettoyer, ouvre la porte à toute une série de vulnérabilités.
N'oubliez pas que la plupart des analyseurs de virus ne peuvent s'exécuter que sur le système de fichiers. Si vous stockez vos fichiers binaires dans la base de données, vous ne pourrez pas exécuter d'analyse très facilement.
C'est fondamentalement ce que je fais.
- Stocker une image téléchargée dans un répertoire temporaire ou dans une mémoire.
- Traitez cette image avant de la stocker définitivement. 2.1. Corrections de couleur 2.2. Compresser 2.3. Créer plusieurs copies en fonction des dimensions de l'image 2.4. Renommer avec les suffixes .xl, .lg, .md, .sm etc.
- Placez tous les fichiers image traités (à partir d’un seul fichier) dans un dossier portant le nom de dossier
id, qui sera stocké dans la base de données pour n’importe quelle ligne/document avecimage file name_ (ou peut être un nom aléatoire comme nom d'image). - Créez le dossier aaaa/mm/d
paths'il n'existe pas. Par exemple 2016/08/21. Mémorisez ce chemin et stockez-le dans la base de données pour le même document et la même ligne. - Déplacez le dossier image
iddans le dossierpath. (Le dossier du chemin peut se trouver dans le dossier/var/web-content.) - Videz la mémoire tampon ou supprimez le fichier temporaire.
Lorsque vous devez accéder à une image mentionnée dans un document, vous avez le chemin et l'id du dossier contenant des images. Par exemple /var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg
Ainsi, si vous devez supprimer tous les fichiers d’image traités, supprimez simplement le dossier et son contenu de manière récursive.
La plupart des implémentations sont l'option A.
Avec l'option B, vous ouvrez une grande boîte de whoop4ss lorsque vous regroupez ces éléments de la base de données en quelque chose qui peut être affiché sur un navigateur ... De plus, si la base de données est inactive, les images ne sont pas disponibles.
Je ne pense pas que cet espace pose trop de problèmes ... Les disques en téraoctets coûtent quelques centaines de dollars maintenant.
Nous implémentons avec l'option A car nous n'avons ni le temps ni les ressources pour faire l'option B.
Pour le redimensionnement automatique, essayez imagemagick ... il est utilisé dans de nombreux systèmes de gestion de contenu/photos open source ... et je pense qu'il existe quelques extensions .net.
Il existe une sorte d’approche hybride dans SQL Server 2008 appelée le type de données filestream dont il a été question à RunAs Radio # 74 , ce qui est un peu le meilleur des deux mondes. La plupart des gens n'ont pas l'otion 2008, mais si vous en avez, cette option est plutôt cool
Option A.
Une fois l'image chargée, vous pouvez vérifier le format et la redimensionner avant de l'enregistrer. Il existe un certain nombre d'échantillons de code .Net pour redimensionner les images sur http://www.codeproject.com . Par exemple: http://www.codeproject.com/KB/cs/Photo_Resize.aspx
Absolument, positivement, l'option A. D'autres ont mentionné que les bases de données ne traitent généralement pas bien les objets BLOB, qu'ils soient conçus pour le faire ou non. Les systèmes de fichiers, par contre, vivent pour ce genre de choses. Vous avez la possibilité d’utiliser la répartition RAID pour répartir les images sur plusieurs lecteurs, voire même sur des serveurs géographiquement disparates.
Un autre avantage est que vos sauvegardes/réplications de bases de données seraient monstrueuses.
Pour des raisons de sécurité, il est également préférable d'éviter les problèmes causés par Content Sniffing d'IE , qui permet aux pirates de télécharger du JavaScript dans des fichiers image, qui pourraient être exécutés dans le contexte de votre site. Donc, vous voudrez peut-être transformer les images (rogner/redimensionner) d'une manière ou d'une autre avant de les stocker pour éviter ce type d'attaque. Cette réponse a d'autres idées.
Nous utilisons A. Je le mettrais sur un lecteur partagé (sauf si vous ne prévoyez pas de lancer plus d'un serveur).
Si le moment venu ne vous convient pas, vous pouvez étudier les mécanismes de mise en cache.
Eh bien, j'ai un projet similaire dans lequel les utilisateurs téléchargent des fichiers sur le serveur. Selon moi, l'option a) est la meilleure solution car elle est plus flexible. Ce que vous devez faire, c'est stocker des images dans un dossier protégé classé par sous-répertoires. Le répertoire principal doit être configuré par l'administrateur car le contenu ne doit pas exécuter de scripts (très important) ni protégé (en lecture/écriture) pour ne pas être accessible dans une requête http.
J'espère que ceci vous aide.
Cela dépend de vos exigences, en particulier du volume, des utilisateurs et de la fréquence de recherche. Toutefois, pour les petites et moyennes entreprises, la meilleure option consiste à utiliser une application telle que Apple Photos ou Adobe Lighroom. Elles sont spécialisées dans le stockage, le catalogage, l’indexation et l’organisation de ce type de ressources. Mais pour les grandes entreprises, avec de fortes exigences de stockage et un grand nombre d'utilisateurs, il est recommandé d'instancier un plataform de gestion de contenu avec une gestion d'actifs numériques, comme Nuxeo ou Alfresco; ces deux ressources offrent de très bonnes ressources pour gérer de très grands volumes de données avec des méthodes simplifiées et très important: il existe une option libre (open source) pour les deux plates-formes.
S'il s'agit de petits fichiers qu'il n'est pas nécessaire de modifier, l'option B n'est pas une mauvaise option. Je préfère cela à l’écriture de logique pour stocker des fichiers et traiter des problèmes délirants de structure de répertoires. Avoir beaucoup de fichiers dans un répertoire est mauvais. emkay?
Si les fichiers sont volumineux ou nécessitent une édition constante, en particulier à partir de programmes tels que bureautique, l'option A est votre meilleur choix.
Dans la plupart des cas, c'est une question de préférence, mais si vous choisissez l'option A, assurez-vous que les répertoires ne contiennent pas trop de fichiers. Si vous choisissez l'option B, placez la table contenant les données BLOBed dans sa propre base de données et/ou groupe de fichiers. Cela facilitera la maintenance, en particulier les sauvegardes/restaurations. Vos données habituelles sont probablement assez petites, alors que vos données d’image seront énormes au fil du temps.