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?

Question

J'écris une application qui permet aux utilisateurs de télécharger des images sur le serveur. J'attends environ 20 images par jour, toutes en JPEG et probablement pas éditées / redimensionnées. (Ceci 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, supprimer 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 à l'aide d'un "image". ou " données binaires " type de données du serveur de base de données.

Je vois des avantages et des inconvénients dans les deux cas. 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 commerciales sur le serveur Web et je ne souhaite pas vraiment connecter le serveur Web à une autre source de données contenant des données commerciales (pour des raisons de sécurité). J'aime b) car toutes les informations sont réunies au même endroit et facilement accessibles 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.

Answer 1

Je stocke généralement les fichiers sur le système de fichiers, car c’est la raison de son existence, à quelques exceptions près. Pour les fichiers, le système de fichiers est la solution la plus flexible et la plus performante (généralement).

Il existe quelques problèmes avec le stockage de fichiers dans une base de données - 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.

Concernant la sécurité - Je stocke généralement les fichiers dans un répertoire situé en dehors de la racine du document (inaccessible via une requête http) et les signale via un script qui recherche d'abord l'autorisation appropriée.

Answer 2

Le seul avantage de l'option B est de disposer de 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 S3 ) ou un service d'infrastructure en tant que service (tel que Uploadcare ):

https://uploadcare.com/upload-api-cloud-storage-and-cdn/

Mais stocker des fichiers dans la base de données est une mauvaise idée.

Answer 3

Flickr utilise le système de fichiers - il discute des raisons pour lesquelles ici

Answer 4

Certains clients ont insisté à plusieurs reprises sur l’option B (stockage de base de données) sur plusieurs serveurs différents et nous toujours avons fini par revenir à l’option A (stockage de système de fichiers).

De 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 que nous pourrions peut-être résoudre certains problèmes.

Une 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 un peu lorsqu'il existe de très gros répertoires.

MODIFIER: Juste une petite remarque 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.

Answer 5

J'ai récemment créé une application PHP / MySQL qui stocke des fichiers PDF / Word dans un tableau 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 distincte 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 / upload 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 peu efficace en mémoire / cpu par rapport au système de fichiers

Je dirais que mon implémentation a été 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.

Answer 6

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 aucun problème, car le stockage de fichiers pour certains hébergements 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 existe deux types d’images sur un site Web:

1. Les images proviennent de l'administrateur du blog dynamique. Généralement, ces images ont été optimisées avant le téléchargement.

2. Les images des utilisateurs au cas où les utilisateurs sont autorisés à télécharger des images telles que l'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 de la redimensionner.

En ignorant l'item no. 1 ci-dessus, solution rapide pour le numéro d'article 2 peuvent être résolus temporairement par les astuces suivantes si nous n'avons pas de fonctionnalité d'optimisation d'image sur notre site Web:

1. N'autorisez pas les utilisateurs à télécharger directement depuis l'é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.

2. 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 stockage d'images volumineuses?
• Redimensionnez ou modifiez l'extension.
• Comment un site Web grand ou moyen ou le commerce électronique gèrent-ils le stockage de fichiers de leurs images?

Ce que nous pouvons faire alors:

1. Migrer à partir du partage d'hébergement VPS. Pas assez? Puis plus haut en passant à Dedicated.

2. 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.

3. 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, je pense que c'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 pour télécharger un fichier et 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.

Answer 7

J'utilise des images téléchargées sur mon site Web et je dirais certainement l'option a).

Une autre chose que je vous recommande vivement 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 de supprimer les caractères étranges du nom de fichier de l'utilisateur pour éviter toute complication future.

Answer 8

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, le GIFAR vous permettait de masquer une applet Java illicite 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 intersite. Le redimensionnement des images empêche généralement cela, 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 de nombreuses vulnérabilités.

N'oubliez pas que la plupart des antivirus 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.

Answer 9

La plupart des implémentations sont l'option A.

Avec l'option B, vous ouvrez toute une boîte de conserve lorsque vous associez ces éléments de la base de données à un élément pouvant ê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 l’espace soit un problème trop important ... Les disques en téraoctets coûtent maintenant quelques centaines de dollars.

Nous implémentons avec l'option A car nous n'avons ni le temps ni les ressources nécessaires pour exécuter l'option B.

Answer 10

Pour le redimensionnement automatique, essayez imagemagick ... il est utilisé dans de nombreux systèmes de gestion de contenu / photos open source ... et je crois qu’il existe quelques extensions .net.

Answer 11

Il existe une sorte d’approche hybride dans SQL Server 2008 appelée type de données filestream dont on a parlé le RunAs Radio # 74 , qui ressemble un peu au 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

Answer 12

C’est ce que je fais.

1. Stocker une image téléchargée dans un répertoire temporaire ou dans la mémoire.
2. Traitez cette image avant de la stocker définitivement. 2.1. Corrections de couleur 2.2. Compresse 2.3. Créer plusieurs copies en fonction des dimensions de l'image 2.4. Renommez avec les suffixes .xl, .lg, .md, .sm, etc.
3. 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 toute ligne / tout document ainsi que nom de fichier image (ou peut être un nom aléatoire comme nom d'image).
4. Créez un dossier aaaa / mm / d s'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.
5. Déplacez le dossier id de l'image dans le dossier chemin . (Le dossier du chemin peut se trouver dans le dossier / var / web-content.)
6. Videz la mémoire tampon ou supprimez le fichier temporaire.

Lorsque vous devez accéder à une image mentionnée dans un document, vous devez indiquer le chemin d'accès et l'id du dossier contenant les images. Par exemple, / var / web-content / {{chemin}} / {{id}} / nom-fichier-image.sm.jpg

Ainsi, si vous devez supprimer tous les fichiers image traités, supprimez simplement le dossier et son contenu de manière récursive.

Answer 13

Nous utilisons A. Je le mettrais sur un lecteur partagé (à moins que vous ne prévoyiez d’exécuter plus d’un serveur).

Si le moment venu ne vous permet pas de faire évoluer votre système, vous pouvez étudier les mécanismes de mise en cache.

Answer 14

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 les sauvegardes / réplications de votre base de données seraient monstrueuses.

Answer 15

Option A.

Une fois l'image chargée, vous pouvez vérifier le format et le redimensionner avant de l'enregistrer. Plusieurs exemples de code .Net permettant de redimensionner les images sont disponibles sur http://www.codeproject.com . Par exemple: http://www.codeproject.com/KB/cs/Photo_Resize.aspx

Answer 16

Pour des raisons de sécurité, nous vous recommandons également d'éviter les Sniffing de contenu d'IE qui peut permettre à des attaquants de télécharger du code 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.

Answer 17

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 la requête http.

J'espère que cela vous aide.

Answer 18

S'il s'agit de petits fichiers qu'il ne sera 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 de structure de répertoires loufoques. 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.

Answer 19

Cela dépend de vos besoins, en particulier du volume, des utilisateurs et de la fréquence des recherches. Toutefois, pour les petites et moyennes entreprises, la meilleure option consiste à utiliser une application telle que Apple Photos ou Adobe Lighroom. Ils sont spécialisés pour stocker, cataloguer, indexer et organiser ce type de ressource. 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; les deux offres offrent de très bonnes ressources, mais gèrent de très gros volumes de données avec des méthodes simplifiées pour les récupérer. Et, ce qui est très important: il existe une option libre (open source) pour les deux plates-formes.