A faire ou à ne pas faire: stocker des Images dans une base de données [dupliquer]

Avantages de mettre des images dans une base de données.

1. Des Transactions. Lorsque vous enregistrez le blob, vous pouvez le valider comme n'importe quel autre morceau de données DB. Cela signifie que vous pouvez valider le blob avec l'une des méta-données associées et être assuré que les deux sont synchronisés. Si vous manquez d'espace disque? Pas de commettre. Le fichier n'a pas la télécharger complètement? Pas de commettre. Erreur d'application stupide? Pas de commettre. Si garder les images et leurs méta données associées cohérentes les unes avec les autres est important pour votre application, alors les transactions qu'une base de données peut fournir peuvent être une aubaine.

2. Un système à gérer. Besoin de sauvegarder les méta-données et les blobs? Sauvegarder la base de données. Besoin de les reproduire? Répliquer la base de données. Besoin de récupérer d'une défaillance partielle du système? Rechargez la base de données et faites rouler les journaux vers l'avant. Tous les avantages que les bases de données apportent aux données en général (mappage de volume, contrôle du stockage, sauvegardes, réplication, récupération, etc.) appliquer à vos blobs. Plus de cohérence, plus facile gestion.

3. De Sécurité. Les bases de données ont des fonctionnalités de sécurité très fines qui peuvent être exploitées. Schémas, rôles d'utilisateur, même des choses comme des "vues en lecture seule" pour donner un accès sécurisé à un sous-ensemble de données. Toutes ces fonctionnalités fonctionnent également avec des tables contenant des blobs.

4. Gestion Centralisée. Lié à #2, mais fondamentalement les DBA (comme s'ils n'avaient pas assez de puissance) arrivent à gérer une chose: la base de données. Les bases de données modernes (en particulier les plus grandes) fonctionnent très bien avec de grandes installations sur plusieurs machines. Source unique de gestion simplifie les procédures, simplifie le transfert de connaissances.

5. La plupart des bases de données modernes gèrent très bien les blobs. Avec la prise en charge de première classe des blobs dans votre niveau de données, vous pouvez facilement diffuser des blobs de la base de données vers le client. Bien qu'il y ait des opérations que vous pouvez faire qui vont "aspirer" tout le blob à la fois, si vous n'avez pas besoin de cette installation, alors ne l'utilisez pas. Étudiez L'interface SQL pour votre base de données et l'effet de levier ses caractéristiques. Aucune raison de les traiter comme des "grosses chaînes" qui sont traitées monolithiquement et transforment vos blobs en grosses bombes mémoire engloutissant le cache.

6. Tout comme vous pouvez configurer des serveurs de fichiers dédiés pour les images, vous pouvez configurer des serveurs Blob dédiés dans votre base de données. Donnez-leur des volumes de disque dédiés, des schémas dédiés,des caches dédiés, etc. Toutes vos données dans la base de données ne sont pas les mêmes, ou se comporte de la même manière, aucune raison de le configurer tout de même. Les bonnes bases de données ont le niveau fin de contrôle.

Le nit principal concernant la distribution d'un blob à partir d'une base de données est de s'assurer que votre couche HTTP exploite réellement tout le protocole HTTP pour effectuer le service.

De nombreuses implémentations naïves attrapent simplement le blob, et les vident en gros sur le socket. Mais HTTP a plusieurs fonctionnalités importantes bien adaptées à la diffusion d'images, etc. Notamment la mise en cache des en-têtes, des ETags et du transfert en morceaux pour permettre aux clients de BLOB.

Assurez - vous que votre service HTTP respecte correctement toutes ces requêtes, et votre base de données peut être un très bon citoyen Web. En mettant en cache les fichiers dans un système de fichiers pour les servir par le serveur HTTP, vous gagnez certains de ces avantages " gratuitement "(car un bon serveur le fera de toute façon pour les ressources" statiques"), mais assurez-vous que si vous faites cela, vous honorez des choses comme les dates de modification, etc. pour les images.

Par exemple, quelqu'un demande spaceshuttle.jpg, une image créée le 1er janvier, 2009. Cela finit par être mis en cache sur le système de fichiers à la date de la demande, par exemple, le 1er février 2009. Plus tard, l'image est purgée du cache (Politique FIFO, ou autre), et quelqu'un, plus tard, le 1er mars 2009 le demande à nouveau. Eh bien, maintenant il a un Mar 1, 2009 "create date", même si tout le temps sa date de création était vraiment Jan 1. Donc, vous pouvez voir, surtout si votre cache tourne beaucoup, les clients qui peuvent utiliser des en-têtes If-Modified peuvent obtenir plus de données qu'ils n'en ont réellement besoin, puisque le serveur pense la ressource a changé, alors qu'en fait ce n'est pas le cas.

Si vous maintenez la date de création du cache synchronisée avec la date de création réelle, cela peut être moins problématique.

Mais le fait est que c'est quelque chose à réfléchir à l'ensemble du problème afin d'être un "bon citoyen du web", et d'économiser vous et vos clients potentiellement de la bande passante, etc.

Je viens de passer par tout cela pour un projet Java servant des vidéos à partir d'une base de données, et tout cela fonctionne un régal.

Je comprends que la majorité des professionnels de la base de données vont croiser les doigts et siffler si vous stockez des images dans la base de données (ou même le mentionner). Oui, il y a certainement des implications de performance et de stockage lors de l'utilisation de la base de données comme référentiel pour de gros blocs de données binaires de toute nature (les images ont tendance à être les bits de données les plus courants qui ne peuvent pas être normalisés). Cependant, il y a très certainement des circonstances où le stockage de base de données d'images est non seulement autorisé mais souhaitable .

Par exemple, dans mon ancien travail, nous avions une application où les utilisateurs attachaient des images à plusieurs points différents d'un rapport qu'ils écrivaient, et ces images devaient être imprimées quand c'était fait. Ces rapports ont été déplacés via la réplication SQL Server, et il aurait introduit un énorme casse-tête pour essayer de gérer ces images et les chemins de fichiers sur plusieurs systèmes et serveurs avec toute sorte de fiabilité. Les stocker dans la base de données nous a donné tous cela "gratuitement", et l'outil de reporting n'a pas eu à aller dans le système de fichiers pour récupérer l'image.

Mon conseil général serait de ne pas vous limiter à une approche ou l'autre-aller avec la technique qui correspond à la situation. Les systèmes de fichiers sont très bons pour stocker des fichiers, et les bases de données sont très bonnes pour fournir des morceaux de données sur demande. D'autre part, l'un des produits de mon entreprise a l'obligation de stocker l'état entier de l'application dans la base de données, ce qui signifie que les pièces jointes y vont également. Avec notre serveur DB (SQL Server 2005), je n'ai pas encore exécuté dans les problèmes de performance observables, même avec les grands clients et les bases de données.

SQL 2008 de Microsoft vous donne le meilleur des deux mondes avec la fonctionnalité FileStream - peut-être la peine de vérifier. http://technet.microsoft.com/en-us/library/bb933993.aspx

L'un des avantages du stockage des images dans la base de données est qu'il est portable sur tous les systèmes et indépendant de la mise en page du ou des systèmes de fichiers.

La solution la plus simple / la plus performante / la plus évolutive consiste à stocker vos images sur le système de fichiers. Si la sécurité est un problème, placez - les dans un emplacement qui n'est pas accessible par le serveur web et écrivez un script qui gère la sécurité et sert les fichiers.

En supposant que votre serveur web / app et votre serveur DB sont des machines différentes, vous obtiendrez quelques hits en mettant des images dans la base de données: (1) latence réseau entre les deux machines, (2) surcharge de connexion DB, (3) Consommation d'un Connexion DB pour chaque image servie. Je serais plus préoccupé par le dernier point: si votre site sert beaucoup d'images, vos serveurs web vont consommer de nombreuses connexions DB et pourraient épuiser vos pools de connexion.

Si votre application s'exécute sur plusieurs serveurs, Je stockerais la copie de référence de vos images dans la base de données, puis je les mettrais en cache à la demande sur les systèmes de fichiers. Cela est juste beaucoup moins une douleur sujette aux erreurs dans le cul que d'essayer de synchroniser les systèmes de fichiers latéralement.

Si votre application est sur un seul serveur, alors oui, respectez le système de fichiers et demandez à la base de données de conserver un chemin d'accès aux données.

La plupart des bases de données SQL ne sont bien sûr pas conçues pour servir des images à l'esprit, mais il y a une certaine commodité associée à les avoir dans la base de données.

Par exemple, si vous avez déjà une base de données en cours d'exécution et que la réplication est configurée. Vous avez instantanément un magasin D'images HA plutôt que d'essayer de travailler une réplication de système de fichiers rsync ou NFS. En outre, avoir un tas de processus web (ou concevoir un nouveau service) pour écrire des fichiers sur le disque augmente votre la complexité un peu. Vraiment, il est juste plus de pièces mobiles.

À tout le moins, je recommanderais de conserver les données 'meta' sur l'image (telles que les autorisations, qui en est propriétaire, etc.) et les données réelles séparées en différentes tables afin qu'il soit assez facile de passer à un magasin de données différent en bas de la ligne. Cela couplé à une sorte de CDN ou de mise en cache devrait vous donner de très bonnes performances jusqu'à un certain point, donc je suppose que cela dépend de l'évolutivité de cette application et de la façon dont vous équilibrer cela avec facilité de mise en œuvre.

Vous n'avez pas besoin de stocker L'URL (si vous pensez que c'est dangereux). Vous pouvez simplement stocker un id unique qui référence l'image ailleurs.

Le stockage de base de données a tendance à être plus coûteux et coûteux à maintenir qu'un système de fichiers - par conséquent, je ne stockerais pas beaucoup d'images dans une base de données.

La reprise après sinistre n'est absolument pas amusante lorsque vous avez des téraoctets de données d'image stockées dans la base de données. Vous feriez mieux de trouver une meilleure façon de distribuer vos données pour les rendre plus fiables, etc... Bien sûr, tous les frais généraux (mentionnés ci-dessus) sont multipliés lors de la réplication et ainsi de suite...

Ne le fais pas!

Cela ressemble vraiment à un problème de baiser (keep it simple stupide). Les systèmes de fichiers sont faits pour gérer facilement le stockage des fichiers image, mais il n'est pas facile à faire dans une base de données et facile de gâcher les données. Pourquoi prendre un coup de performance et toute la difficulté dans le sql et le rendu quand vous pouvez simplement vous soucier de la sécurité des fichiers? Vous pouvez également gérer des systèmes mixtes avec NFS ou CIFS. Les systèmes de fichiers sont des technologies matures. Beaucoup plus simple, plus robuste.

J'ai stocké des images dans une base de données pour une application de démonstration. La raison pour laquelle je l'ai fait était la sécurité-la suppression d'un enregistrement que je n'aurais pas dû n'était pas un gros problème, mais la suppression d'un fichier que je n'aurais pas dû être un problème!

Si la performance devenait un problème, j'aurais cherché à savoir si la suppression de fichiers voyous était une possibilité réelle ou non.

Si ce sont des images qui sont extraites régulièrement de la base de données, j'essaierais toujours d'utiliser le système de fichiers.

S'il s'agissait d'images qui doivent sortir de temps en temps, et les enregistrer dans la base de données rend la vie plus facile, je n'ai aucun problème avec cela.

• Base de données pour les données
• système de fichiers pour les fichiers