Stocker un petit nombre d'images: blob ou fs?

Question

J'ajoute certaines fonctionnalités à mon site afin que les utilisateurs puissent télécharger leurs propres images de profil. Je me demandais si je devais les stocker dans la base de données sous forme de BLOB ou les mettre dans le système de fichiers.

J'ai trouvé une question similaire à celle-ci ici: Stockage d'images dans la base de données: Oui ou Nay , mais les réponses données étaient davantage destinées aux personnes qui attendaient plusieurs milliers, voire des millions d’images, alors que je suis davantage préoccupé par les petites images (JPEG jusqu’à 150x150 pixels), et par un petit nombre d’entre elles: peut-être jusqu'à un ou deux mille.

Quels sont les sentiments vis-à-vis de DB BLOB vs système de fichiers pour ce scénario? Comment les clients placent-ils la mise en cache des images de la base de données vs du système de fichiers?

Si les BLOB stockés dans la base de données sont la voie à suivre, puis-je savoir quelque chose sur où où les stocker? Puisque j'imagine qu'une majorité de mes utilisateurs ne téléchargeront pas d'image, devrais-je créer une table user_pics pour joindre (externe) à la table utilisateurs régulière si nécessaire?

Modifier: je rouvre cette question, car ce n'est pas une copie de ces deux personnes auxquelles vous avez lié un lien. Cette question concerne spécifiquement les avantages / inconvénients de l’utilisation d’une base de données ou d’un système de fichiers pour un petit nombre d’images. Comme je l'ai dit plus haut, l'autre question s'adresse aux personnes qui doivent stocker des milliers et des milliers de grandes images.

Answer 1

Pour répondre à des parties de votre question:

  

Comment les clients utilisent-ils la mise en cache des images de la base de données et du système de fichiers?

Pour une base de données: insérez un champ last_modified dans votre base de données. Utilisez l'en-tête HTTP Last-Modified afin que le navigateur du client puisse mettre en cache correctement. Assurez-vous d’envoyer les réponses appropriées lorsque le navigateur demande une image "si plus récente". (je ne me souviens plus de son nom; un en-tête de requête HTTP).

Pour un système de fichiers: Faites la même chose, mais avec l'heure de modification du fichier.

  

Si les BLOB stockés dans la base de données sont la solution, puis-je savoir quelque chose à propos de leur stockage? Étant donné que j'imagine qu'une majorité de mes utilisateurs ne téléchargeront pas d'image, devrais-je créer une table user_pics pour rejoindre (externe) à la table des utilisateurs normaux si nécessaire?

Je mettrais le BLOB et les métadonnées associées dans sa propre table, avec une sorte de relation entre celle-ci et votre table d'utilisateurs. Cela facilitera l'optimisation de la méthode de stockage de la table pour vos données, rendra les choses plus claires et laissera de la place pour une évolutivité (par exemple, une "table" générale ".

Answer 2

J'ai déjà eu à faire face à une question similaire avec un petit DMS pour les fichiers pdf. Le scénario était différent du vôtre: un maximum de 100 fichiers d’une taille maximale de 10 Mo chacun peut correspondre à ce que vous attendez - ce que vous attendez des images de profil. Mais la réponse qu'un ami m'a donnée à l'époque s'applique également à votre cas:

  

Utilisez chaque système de stockage pour ce à quoi il est conçu.

     

Stockez des données dans une base de données . Stocker des fichiers dans un système de fichiers .

Ce n’est pas la réponse ultime (*), mais c’est une bonne règle pour commencer.

Je n'ai jamais entendu parler de Windows FS comme étant lent et parfois peu fiable, comme le dit Aaron Digulla dans sa réponse. S'il y a de tels problèmes, il faudra certainement en tenir compte. Mais pour les images d'avatar, cela ne me semble pas aussi important.

(*) Je sais, je sais, 42 ...

Answer 3

Qu'est-ce qui serait plus pratique, du point de vue de les servir, d'écrire le code pour les servir, des procédures de sauvegarde, etc.? Vous voulez la bonne réponse pour vous, pas la bonne pour quelqu'un d'autre.

Answer 4

De mon point de vue, tout ce qui peut rester en dehors de la base de données doit rester en dehors de la base de données. Il peut s'agir d'un système de fichiers ou de tables distinctes que vous ne répliquez pas ni ne sauvegardez tous les jours. Elle rend la base de données beaucoup plus légère, croît plus lentement et est plus facile à comprendre et à gérer.

Si vous êtes sur MSSQL, assurez-vous que les blobs sont stockés dans un fichier de données séparé. Pas dans PRIMARY comme tout le reste.

Answer 5

Sous Windows, mettez autant que possible dans la base de données. Le système de fichiers est un peu lent et parfois même peu fiable.

Sous Linux, vous avez plus d'options. Ici, vous devriez envisager de déplacer de gros fichiers dans un système de fichiers et de simplement conserver le nom dans la base de données. Si vous utilisez un système de fichiers moderne tel qu'Ext3 ou ReiseFS, vous pouvez même créer de nombreux petits fichiers avec de très bonnes performances.

Vous devez également prendre en compte la manière dont vous pouvez accéder aux données. Si vous avez tout dans la base de données, vous avez un chemin d'accès, vous n'avez pas à vous soucier d'un autre ensemble d'autorisations, mais vous devez faire face à la complexité supplémentaire de la lecture / écriture des BLOB. Dans de nombreuses bases de données, les BLOB ne peuvent pas être recherchés.

Sur le système de fichiers, vous pouvez exécuter d'autres outils sur vos données, ce qui n'est pas possible si les fichiers sont stockés dans une base de données.

Answer 6

Je les stockerais dans la base de données:

1. La sauvegarde / restauration est simple (si vous sauvegardez des fichiers ainsi que la base de données, la récupération à un moment donné est plus compliquée)
2. Les transactions dans la base de données signifient que vous ne devriez jamais vous retrouver face à un nom de fichier qui n’existe pas
3. Moins de chance que quelqu'un découvre un moyen sournois de mettre un script sur votre serveur via un hack de téléchargement d'images louche

Étant donné que vous parlez d’un petit nombre d’images, la facilité d’utilisation / administration doit primer sur les problèmes de performances discutés dans les questions liées.

Answer 7

Je pense qu’il existe un avantage de facilité de gestion en les stockant dans la base de données; elles peuvent être sauvegardées et restaurées de manière cohérente avec les autres données - vous n'oublierez pas de supprimer les données obsolètes (enfin, vous pouvez le faire, mais c'est un peu moins probable), et si vous migrez la base de données sur une autre machine, les images sont conservées. il.