Stocker des Images dans DB-Yea ou Nay?

donc j'utilise une application qui stocke des images lourdement dans la base de données. Quel est votre regard sur ce? Je suis plus du genre à stocker l'emplacement dans le système de fichiers que dans la base de données.

Quels sont les avantages et les inconvénients?

415
demandé sur James Hall 2008-08-06 21:38:35
la source

30 ответов

je suis en charge de certaines applications qui gèrent de nombreuses TB d'images. Nous avons trouvé que le stockage de file paths dans la base de données pour être le meilleur.

Il ya un couple de questions:

  • le stockage dans une base de données coûte généralement plus cher que le stockage dans un système de fichiers
  • vous pouvez super-accélérer l'accès au système de fichiers avec des produits standard disponibles sur le marché
    • par exemple, beaucoup de web les serveurs utilisent le système d'exploitation sendfile() appel système pour envoyer asynchrone un fichier directement du système de fichiers à l'interface réseau. Les Images stockées dans une base de données ne bénéficient pas de cette optimisation.
  • les choses comme les serveurs web, etc, n'ont pas besoin de codage ou de traitement spécial pour accéder aux images dans le système de fichiers
  • les bases de données gagnent là où l'intégrité transactionnelle entre l'image et les métadonnées sont importantes.
    • il est plus complexe à gérer l'intégrité entre les bases de données des métadonnées et des données de système de fichiers
    • il est difficile (dans le contexte d'une application web) de garantir que les données ont été jetées sur le disque sur le système de fichiers
350
répondu Mark Harrison 2010-11-20 20:25:42
la source

comme pour la plupart des problèmes, ce n'est pas aussi simple que ça en a l'air. Il y a des cas où il serait logique de stocker les images dans la base de données.

  • vous stockez des images qui sont changer dynamiquement, dire factures et vous vouliez pour obtenir une facture telle Qu'elle était le 1er janvier 2007?
  • le gouvernement veut que vous mainteniez 6 ans d'histoire
  • les Images stockées dans la base de données ne nécessitent pas une stratégie de sauvegarde différente. Images stockées sur le système de fichiers do
  • Il est plus facile de contrôler l'accès aux images si elles sont dans une base de données. Les administrateurs inactifs peuvent accéder à n'importe quel dossier sur le disque. Il faut un administrateur vraiment déterminé pour aller fouiner dans une base de données pour extraire les images

d'autre part, il ya des problèmes associés

  • nécessite un code supplémentaire pour extraire et diffuser les images
  • latence may be plus lent que l'accès direct au fichier
  • charge plus lourde sur le serveur de base de données
140
répondu Rad 2011-04-01 02:43:38
la source

magasin de Fichier. Les ingénieurs de Facebook en ont beaucoup parlé. Une chose à retenir était de connaître la limite pratique des fichiers dans un répertoire.

aiguille dans une botte de foin: stockage efficace de milliards de Photos

99
répondu jason saldo 2008-08-20 22:35:15
la source

C'est peut-être un peu tiré par les cheveux, mais si vous utilisez (ou prévoyez d'utiliser) SQL Server 2008, je vous recommande de jeter un oeil au nouveau type de données FileStream .

FileStream résout la plupart des problèmes de stockage des fichiers dans la base de données:

  1. les Blobs sont en fait stockés sous forme de fichiers dans un dossier.
  2. les Blobs peuvent être consultés en utilisant soit une base de données connexion ou sur le système de fichiers.
  3. Les sauvegardes
  4. sont intégrées.
  5. Migration "fonctionne".

cependant le "cryptage Transparent de données" de SQL ne crypte pas les objets FileStream, donc si c'est une considération, vous pourriez être mieux de simplement les stocker comme varbinary.

extrait de L'Article de MSDN:

Transact-SQL peut insérer, mise à jour, interroger, rechercher et sauvegarder des données FILESTREAM. Les interfaces du système de fichiers Win32 offrent un accès continu aux données.

FILESTREAM utilise le cache du système NT pour la mise en cache des données du fichier. Cela permet de réduire tout effet que les données FILESTREAM pourraient avoir sur les performances du moteur de base de données. La mémoire tampon du serveur SQL N'est pas utilisée; cette mémoire est donc disponible pour le traitement des requêtes.

56
répondu John Gietzen 2011-07-27 01:47:17
la source

les chemins de Fichier dans la base de données est certainement la voie à suivre - j'ai entendu l'histoire après histoire de clients avec la TUBERCULOSE de photos qu'il est devenu un cauchemar tentez de stocker des quantités considérables d'images dans une base de données - l'impact sur les performances seul, c'est trop.

39
répondu Greg Hurlman 2008-08-06 22:17:52
la source

d'après mon expérience, parfois la solution la plus simple est de nommer les images selon la clé primaire . Il est donc facile de trouver l'image qui appartient à un enregistrement particulier, et vice versa. Mais en même temps vous ne stockez pas quelque chose à propos de l'image dans la base de données.

35
répondu Patrick McElhaney 2008-08-06 21:59:59
la source

L'astuce ici est de ne pas devenir un zélote.

une chose à noter ici est que personne dans le système de fichiers pro camp a énuméré un système de fichiers particulier. Est-ce que cela signifie que tout, de FAT16 à ZFS Bat handily chaque base de données?

Pas de.

la vérité est que de nombreuses bases de données battent de nombreux systèmes de fichiers, même si nous ne parlons que de vitesse brute.

la bonne ligne de conduite est de faire la bonne décision pour votre scénario précis, et pour ce faire, vous aurez besoin de quelques chiffres et quelques cas d'utilisation d'estimations.

31
répondu dicroce 2008-08-31 21:54:01
la source

dans les endroits où vous devez garantir l'intégrité référentielle et la conformité à L'acide, le stockage des images dans la base de données est nécessaire.

vous ne pouvez pas garantir de manière transactionnelle que l'image et les méta-données sur cette image stockées dans la base de données se réfèrent au même fichier. En d'autres termes, il est impossible de garantir que le fichier du système de fichiers n'est modifié qu'en même temps et dans la même transaction que les métadonnées.

30
répondu mluebke 2009-09-03 04:48:15
la source

comme d'autres l'ont dit SQL 2008 est livré avec un type Filestream qui vous permet de stocker un nom de fichier ou un identifiant comme un pointeur dans la db et stocke automatiquement l'image sur votre système de fichiers ce qui est un grand scénario.

si vous êtes sur une base de données plus ancienne, alors je dirais que si vous la stockez comme données blob, alors vous n'allez vraiment pas obtenir quoi que ce soit hors de la base de données dans la façon de rechercher des fonctionnalités, il est probablement préférable de stocker une adresse sur un système de fichiers, et stocker l'image de cette façon.

de cette façon, vous économisez également de l'espace sur votre système de fichiers, car vous économisez seulement la quantité exacte d'espace, ou même de l'espace compacté sur le système de fichiers.

en outre, vous pourriez décider d'enregistrer avec une structure ou des éléments qui vous permettent de parcourir les images brutes dans votre système de fichiers sans aucune db hits, ou transférer les fichiers en vrac à un autre système, disque dur, S3 ou un autre scénario - mise à jour de l'emplacement dans votre programme, mais garder la structure, encore une fois sans beaucoup de succès essayer d'apporter les images hors de votre db en essayant d'augmenter le stockage.

probablement, il vous permettrait également de jeter un certain élément de cache, basé sur les urls d'image généralement frappé dans votre moteur/programme web, de sorte que vous économisez vous-même là aussi.

28
répondu crucible 2008-08-30 13:50:23
la source

les petites images statiques (pas plus que quelques megs) qui ne sont pas fréquemment éditées, doivent être stockées dans la base de données. Cette méthode a plusieurs avantages, notamment une portabilité plus facile (les images sont transférées avec la base de données), une sauvegarde/restauration plus facile (les images sont sauvegardées avec la base de données) et une meilleure évolutivité (un dossier système de fichiers avec des milliers de petits fichiers miniatures sonne comme un cauchemar d'évolutivité pour moi).

servir des images à partir d'une base de données est facile, il suffit d'implémenter un gestionnaire http qui sert le tableau de bytes retourné du serveur DB en flux binaire.

27
répondu urini 2008-08-06 22:46:49
la source

Voici un intéressant livre blanc sur le sujet.

BLOB ou De ne Pas GOUTTE: Grand Objet de Stockage dans une Base de données ou un système de fichiers

la réponse est" cela dépend."Cela dépend certainement du serveur de base de données et de son approche du stockage blob. Il dépend également du type de données stockées dans les gouttes, ainsi que la façon dont les données sont accessibles.

les fichiers de plus petite taille peuvent être stocké et livré efficacement en utilisant la base de données comme mécanisme de stockage. Les fichiers de plus grande taille seraient probablement mieux stockés en utilisant le système de fichiers, surtout s'ils sont modifiés/mis à jour souvent. (la fragmentation par taches devient un problème en ce qui concerne la performance.)

voici un point supplémentaire à garder à l'esprit. L'une des raisons justifiant l'utilisation d'une base de données pour stocker les blobs est la conformité à L'acide. Toutefois, l'approche utilisée par les testeurs dans le livre blanc (en Option journalisée de SQL Server,) qui doublait le débit de SQL Server, changeait effectivement le " D "dans L'acide en un "d", car les données de blob n'étaient pas journalisées avec les Écritures initiales pour la transaction. Par conséquent, si la pleine conformité acide est une exigence importante pour votre système, coupez les chiffres de débit de SQL Server pour les Écritures de base de données en comparant l'entrée / sortie de fichier à la base de données blob I /O.

26
répondu user13550 2011-07-27 01:27:51
la source

une chose que je n'ai vu personne mentionner pour le moment, mais qui mérite certainement d'être notée, c'est qu'il y a des problèmes associés au stockage de grandes quantités d'images dans la plupart des systèmes de fichiers aussi. Par exemple, si vous adoptez l'approche mentionnée ci-dessus et que vous nommez chaque fichier image après la touche primaire, sur la plupart des systèmes de fichiers, vous rencontrerez des problèmes si vous essayez de mettre toutes les images dans un grand répertoire une fois que vous aurez atteint un très grand nombre d'images (par exemple dans les centaines de milliers ou de millions).

une fois la solution commune à cela est de les hachez dans un arbre équilibré de sous-répertoires.

25
répondu John 2008-08-20 22:25:12
la source

ce que personne n'a mentionné, c'est que la DB garantit les actions atomiques, l'intégrité transactionnelle et traite de la concurrence. Même l'intégrité référentielle est hors de la fenêtre avec un système de fichiers - alors comment savez-vous que vos noms de fichiers sont toujours corrects?

si vous avez vos images dans un système de fichiers et que quelqu'un lit le fichier pendant que vous écrivez une nouvelle version ou même la suppression du fichier-que se passe - t-il?

nous utilisons blobs parce que ils sont également plus faciles à gérer (sauvegarde, réplication, transfert). Ils travaillent bien pour nous.

22
répondu Draemon 2008-11-28 09:33:53
la source

le problème avec le stockage seulement des chemins de fichiers vers des images dans une base de données est que l'intégrité de la base de données ne peut plus être forcée.

si l'image réelle pointée par le chemin de fichier devient indisponible, La base de données a involontairement une erreur d'intégrité.

étant donné que les images sont les données réelles recherchées, et qu'elles peuvent être gérées plus facilement (les images ne disparaîtront pas soudainement) dans une base de données intégrée plutôt que d'avoir à interface avec une sorte de système de fichiers (si le système de fichiers est indépendamment accédé, les images pourraient soudainement "disparaître"), je dirais pour les stocker directement sous forme de BLOB ou autre.

20
répondu wiseguy 2009-04-08 20:35:09
la source

dans une entreprise où j'avais l'habitude de travailler, nous avons stocké 155 millions d'images dans une base de données Oracle 8i (puis 9i). 7.5 CT de la valeur.

17
répondu graham.reeds 2008-08-06 22:37:17
la source

normalement, je m'oppose catégoriquement à prendre la partie la plus chère et la plus difficile à dimensionner de votre infrastructure (la base de données) et y mettre toute la charge. D'un autre côté: il simplifie grandement la stratégie de sauvegarde, surtout lorsque vous avez plusieurs serveurs web et besoin de garder les données synchronisées.

comme la plupart des autres choses, cela dépend de la taille et du Budget prévus.

14
répondu Michael Stum 2008-08-06 21:42:21
la source

nous avons mis en place un système d'imagerie de documents qui stocke toutes ses images dans les champs de blob SQL2005. Il y a plusieurs centaines de GO en ce moment et nous voyons d'excellents temps de réponse et peu ou pas de dégradation des performances. En outre, la conformité réglementaire fr, Nous avons une couche middleware qui Archive les documents nouvellement affichés à un système jukebox optique qui les expose comme un système de fichiers NTFS standard.

nous avons été très satisfaits des résultats, notamment:

  1. facilité de réplication et de sauvegarde
  2. possibilité de mettre en œuvre facilement un système de gestion de versions de documents
13
répondu dan90266 2008-10-26 20:55:01
la source

si cette application est basée sur le web, il pourrait y avoir des avantages à stocker les images sur un réseau de livraison de stockage tiers, comme Amazon S3 ou la plate-forme Nirvanix.

11
répondu David 2008-08-06 21:52:51
la source

hypothèse: L'Application est activée sur le web / basée sur le web

je suis surpris que personne n'ait vraiment mentionné cela ... déléguez - le à d'autres spécialistes -> utilisez un fournisseur d'hébergement d'images/de fichiers tiers .

stocker vos fichiers sur un service en ligne payé comme

un autre fil continu parlant de ce ici .

ce fil de discussion explique pourquoi vous devriez utiliser un hébergeur tiers.

ça en vaut la peine. Ils le stockent efficacement. Pas de bande passante avec le fait d'être téléchargé de vos serveurs à des demandes de clients, etc.

11
répondu Pure.Krome 2017-05-23 14:47:22
la source

si vous n'êtes pas sur SQL Server 2008 et que vous avez de bonnes raisons de mettre des fichiers image spécifiques dans la base de données, alors vous pouvez utiliser l'approche" à la fois " et utiliser le système de fichiers comme cache temporaire et utiliser la base de données comme dépôt maître.

par exemple, votre logique d'entreprise peut vérifier si un fichier image existe sur le disque avant de le servir, extraire de la base de données si nécessaire. Cela vous permet d'acheter la capacité de plusieurs serveurs web et moins de synchronisation question.

10
répondu a7drew 2008-09-02 18:01:36
la source

Je ne suis pas sûr à quel point c'est un exemple de" monde réel", mais j'ai actuellement une application là-bas qui stocke les détails d'un jeu de cartes à Jouer, y compris les images pour les cartes. Étant donné que le nombre d'enregistrements pour la base de données n'est que de 2851 à ce jour, mais étant donné que certaines cartes sont sorties plusieurs fois et ont une autre œuvre d'art, il était en fait plus efficace sizewise de scanner le "carré primaire" de l'œuvre d'art, puis de générer dynamiquement la bordure et effets divers pour la carte lorsque demandé.

le créateur original de cette bibliothèque d'images a créé une classe d'accès aux données qui rend l'image basée sur la demande, et il le fait assez rapidement pour le visionnement et la carte individuelle.

cela facilite également le déploiement / mises à jour lorsque de nouvelles cartes sont émises, au lieu de fermer un dossier entier d'images et de les envoyer dans le tuyau et de s'assurer que la structure de dossier appropriée est créée, je mets simplement à jour le base de données et que l'utilisateur le télécharge à nouveau. Cette taille est actuellement de 56 Mo, ce qui n'est pas génial, mais je travaille sur une fonction de mise à jour incrémentale pour les prochaines versions. De plus, il existe une version" sans images " de l'application qui permet à ceux qui utilisent le service commuté d'obtenir l'application sans délai de téléchargement.

cette solution a très bien fonctionné à ce jour puisque l'application elle-même est ciblée comme une seule instance sur le bureau. Il y a un site Web où tout cela les données sont archivées pour l'accès en ligne, mais je voudrais en aucune façon utiliser la même solution pour cela. Je suis d'accord que l'accès au fichier serait préférable parce qu'il serait mieux adapté à la fréquence et au volume des demandes faites pour les images.

J'espère que ce n'est pas trop bavard, mais j'ai vu le sujet et je voulais fournir quelques-unes de mes idées à partir d'une application relativement réussie à petite/moyenne échelle.

7
répondu Dillie-O 2008-08-20 22:42:14
la source

SQL Server 2008 offre une solution qui a le meilleur des deux mondes : le type de données filestream .

le gérer comme une table régulière et avoir la performance du système de fichiers.

7
répondu Andrei Rînea 2008-08-29 01:37:10
la source

Il dépend du nombre d'images que vous allez stocker et aussi de leur taille. J'ai utilisé des bases de données pour stocker des images dans le passé, et mon expérience a été assez bonne.

IMO, les avantages d'utiliser la base de données pour stocker des images sont,

A. Vous n'avez pas besoin de structure de FS pour tenir vos images

B. Les index de base de données fonctionnent mieux que les arbres FS lorsque plus d'articles doivent être stockés

C. Intelligemment base de données tuned effectuer bon travail à la mise en cache des résultats de la requête

D. Les sauvegardes sont simples. Cela fonctionne aussi bien si vous avez installé la réplication et que le contenu est livré à partir d'un serveur proche de l'utilisateur. Dans de tels cas, une synchronisation explicite n'est pas nécessaire.

si vos images vont être petites (disons < 64k) et le moteur de stockage de vos supports db Inline (en enregistrement) BLOBs, il améliore encore les performances comme aucune requis (Localité de référence est obtenu).

stocker des images peut être une mauvaise idée lorsque vous avez affaire à un petit nombre d'images de grande taille. Un autre problème avec le stockage des images dans la base de données est que, les métadonnées comme la création, les dates de modification doivent être gérées par votre application.

7
répondu nikhilbelsare 2008-09-05 14:54:06
la source

j'ai récemment créé une application PHP/MySQL qui stocke des fichiers Pdf/Word dans une table MySQL (aussi grande que 40 Mo par fichier jusqu'à présent).

Pour:

  • 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).
  • configurer le serveur web est légèrement plus simple parce que je n'ai pas besoin d'avoir un téléchargement/ dossier et dire à tous mes les applications où il est.
  • je peux utiliser transactions for edits pour améliorer l'intégrité des données - je n'ai pas à me soucier des fichiers orphelins et manquants

Inconvénients:

  • mysqldump prend maintenant un looooong temps parce qu'il y a 500 Mo de données de fichier dans l'une des tables.
  • globalement pas très efficace mémoire / cpu par rapport au système de fichiers

j'appellerais ma mise en œuvre un succès, il prend en charge les besoins de sauvegarde et simplifie la mise en page du projet. Le rendement est très bien pour les 20-30 personnes qui utilisent l'application.

7
répondu too much php 2008-12-08 07:31:54
la source

D'après mon expérience, j'ai dû gérer les deux situations: les images stockées dans la base de données et les images sur le système de fichiers avec le chemin stocké dans la base de données.

la première solution, les images dans la base de données, est un peu plus" propre " car votre couche d'accès aux données n'aura à traiter que des objets de base de données; mais cela n'est bon que lorsque vous avez à traiter de petits nombres.

évidemment la performance d'accès à la base de données lorsque vous traitez avec de grands objets binaires est dégradant, et le les dimensions de la base de données vont beaucoup augmenter, causant encore une fois une perte de performance... et normalement l'espace de base de données est beaucoup plus cher que l'espace de système de fichiers.

d'autre part avoir de grands objets binaires stockés dans le système de fichiers vous fera avoir des plans de sauvegarde qui doivent considérer à la fois la base de données et le système de fichiers, et cela peut être un problème pour certains systèmes.

une autre raison d'opter pour le système de fichiers est lorsque vous devez partager vos données d'images (ou des sons, video, whatever) avec accès tiers: en ce moment, je développe une application web qui utilise des images qui doivent être accessibles à partir de "l'extérieur" de ma ferme web de telle sorte qu'un accès à une base de données pour récupérer des données binaires est tout simplement impossible. Donc, parfois, il ya aussi des considérations de conception qui vous conduiront à un choix.

tenir compte aussi, en faisant ce choix, si vous avez à traiter avec la permission et l'authentification lors de l'accès à des objets binaires: ces conditions préalables peuvent normalement être résolu d'une manière plus facile lorsque les données sont stockées dans la bd.

6
répondu ila 2011-12-14 14:36:43
la source

j'ai déjà travaillé sur une application de traitement d'image. Nous avons stocké les images téléchargées dans un dossier qui était quelque chose comme /images/[aujourd'hui]/[numéro d'identification]. Mais nous avons aussi extrait les métadonnées (données exif) des images et les avons stockées dans la base de données, avec un horodatage et autres.

4
répondu Thomas Owens 2008-08-20 22:51:56
la source

dans un projet précédent, j'ai stocké des images sur le système de fichiers, et cela a causé beaucoup de maux de tête avec des sauvegardes, la réplication, et le système de fichiers se désynchroniser avec la base de données.

dans mon dernier projet, je stocke des images dans la base de données, et les cache sur le système de fichiers, et ça marche vraiment bien. Je n'ai pas eu de problèmes jusqu'à présent.

4
répondu Christoffer Hammarström 2009-12-16 17:29:05
la source

Deuxième recommandation sur les chemins de fichiers. J'ai travaillé sur quelques projets qui devaient gérer des collections de biens de grande envergure, et toute tentative de stocker des choses directement dans le DB a entraîné des douleurs et des frustrations à long terme.

le seul " pro " réel que je peux penser de les stocker dans le DB est le potentiel pour facile des actifs d'image individuels. S'il n'y a pas de chemin de fichier à utiliser, et que toutes les images sont streamées directement à partir de la base de données, il n'y a pas de danger de les utilisateurs trouvent des fichiers auxquels ils ne devraient pas avoir accès.

qui semble comme il serait mieux résolu avec un script intermédiaire tirant des données d'un Web-inaccessible magasin de fichiers, cependant. Donc le stockage DB n'est pas vraiment nécessaire.

3
répondu Jeff 2008-08-06 21:51:00
la source

le mot dans la rue est que sauf si vous êtes un vendeur de base de données essayant de prouver que votre base de données peut le faire (comme, disons Microsoft se vantant de Terraserver stocker un bajillion d'images dans SQL Server) ce n'est pas une très bonne idée. Quand l'alternative - stocker des images sur des serveurs de fichiers et des chemins dans la base de données est tellement plus facile, pourquoi s'embêter? Blob fields sont un peu comme les capacités off-road de SUVs - la plupart des gens ne les utilisent pas, ceux qui ne sont généralement en difficulté, et puis il y a ceux qui le font, mais seulement pour le plaisir.

3
répondu deadprogrammer 2008-08-07 01:19:16
la source

stocker une image dans la base de données signifie toujours que les données d'image finissent quelque part dans le système de fichiers mais obscurci de sorte que vous ne pouvez pas y accéder directement.

+ves:

  • intégrité de la base de données
  • c'est facile à gérer car vous n'avez pas à vous soucier de synchroniser le système de fichiers lorsqu'une image est ajoutée ou supprimée.""

- ves:

  • performance penalty -- une recherche de base de données est généralement plus lente qu'une recherche de système de fichiers
  • vous ne pouvez pas éditer l'image directement (recadrer, redimensionner)

les deux méthodes sont courantes et pratiquées. Avoir un regard sur les avantages et les inconvénients. Quoi qu'il en soit, vous devrez réfléchir à la façon de surmonter les désavantages. Stocker dans la base de données signifie généralement modifier les paramètres de la base de données et mettre en œuvre une sorte de cache. L'utilisation du système de fichiers exige que vous trouviez une façon de synchroniser le système de fichiers+de la base de données.

3
répondu Salman A 2009-05-18 10:43:25
la source

Autres questions sur image database theory storage blob