Stockage d'images dans DB - Oui ou non?


415

J'utilise donc une application qui stocke beaucoup d'images dans la base de données. Quelles sont vos perspectives à ce sujet? Je suis plus du genre à stocker l'emplacement dans le système de fichiers qu'à le stocker directement dans la base de données.

Quels sont selon vous les avantages / inconvénients?


Eh bien, vous pouvez faire les deux avec un cache disque transactionnel .
Lilith River

Réponses:


350

Je suis en charge de certaines applications qui gèrent de nombreux To d'images. Nous avons constaté que le stockage des chemins de fichiers dans la base de données était le meilleur.

Il y a quelques problèmes:

  • le stockage de la base de données est généralement plus cher que le stockage du système de fichiers
  • vous pouvez super-accélérer l'accès au système de fichiers avec des produits standard prêts à l'emploi
    • par exemple, de nombreux serveurs Web utilisent l'appel système sendfile () du système d'exploitation pour envoyer de manière 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.
  • des 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 l'emportent là où l'intégrité transactionnelle entre l'image et les métadonnées est importante.
    • il est plus complexe de gérer l'intégrité entre les métadonnées db et les données du système de fichiers
    • il est difficile (dans le cadre d'une application Web) de garantir que les données ont été vidées sur le disque du système de fichiers

33
Quels sont les produits disponibles sur le marché pour "accélérer plus" le système de fichiers?
Andrei Rînea

22
Bien que je ne gère que 3 To de fichiers, je suis définitivement d'accord. Les bases de données sont destinées aux données structurées, pas aux blobs.
derobert

7
@derobert: tout à fait, si vous n'utiliserez jamais un élément de données dans une requête, comme condition ou pour une jointure, il n'appartient probablement pas à la base de données. Là encore, si vous avez une belle fonction de base de données pour interroger les images pour la ressemblance ...
Nils Weinander

14
Quels sont les produits disponibles sur le marché pour "accélérer plus" le système de fichiers?
ablmf

5
Re: produits "super accélérateurs": la plupart des serveurs Web peuvent désormais profiter de l'appel système sendfile () pour fournir des fichiers statiques de manière asynchrone au client. Il décharge au système d'exploitation la tâche de déplacer le fichier du disque vers l'interface réseau. Le système d'exploitation peut le faire beaucoup plus efficacement, fonctionnant dans l'espace du noyau. Cela, pour moi, semble être une grande victoire pour le système de fichiers contre db pour le stockage / la diffusion d'images.
Alan Donnelly

140

Comme pour la plupart des problèmes, ce n'est pas aussi simple qu'il y paraît. Il y a des cas où il serait judicieux de stocker les images dans la base de données.

  • Vous stockez des images qui changent dynamiquement, par exemple des factures et vous vouliez obtenir une facture telle qu'elle était au 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 de stratégie de sauvegarde différente. Les images stockées sur le système de fichiers font
  • Il est plus facile de contrôler l'accès aux images si elles se trouvent 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 fouiner dans une base de données pour extraire les images

D'un autre côté, il y a des problèmes associés

  • Exiger du code supplémentaire pour extraire et diffuser les images
  • La latence peut être plus lente que l'accès direct aux fichiers
  • Charge plus lourde sur le serveur de base de données

2
Ne pas avoir de stratégie de sauvegarde distincte peut être un gros problème lorsque vous écrivez des applications installées sur site (comme SharePoint). Lorsque vous créez une sauvegarde SharePoint, tout se trouve dans la base de données, ce qui le rend très facile.
Eric Schoonover

44
La sécurité par obscurité n'est pas vraiment une stratégie de contrôle d'accès!
Jon Cage

5
Je ne pense pas qu'il prône la sécurité par l'obscurité - il dit que le fait de mettre des images dans la base de données ajoute une autre couche de sécurité. (Je pense ... @Conrad, je ne veux pas mettre de mots dans la bouche)
AJ.

J'ai choisi de stocker des images dans la base de données en raison de l'avantage de sauvegarde unique (ou plus généralement, d'avoir toutes les données en un seul endroit), mais les problèmes que vous mentionnez sont également vrais, c'est pourquoi je mets en cache les images sur le système de fichiers. C'est le meilleur des deux mondes, et je suis surpris qu'aucune des meilleures réponses ici ne le mentionne.
Bart van Heukelom

Utilisez -vous, par hasard, la bibliothèque ImageResizing.Net pour gérer la mise en cache de votre image disque SQL->? C'est le cache disque le plus avancé, évolutif et robuste que vous puissiez obtenir ...
Lilith River


56

Cela peut être un peu long, mais si vous utilisez (ou prévoyez d'utiliser) SQL Server 2008, je vous recommande de jeter un œil au nouveau type de données FileStream .

FileStream résout la plupart des problèmes liés au 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ées en utilisant soit une connexion de base de données ou sur le système de fichiers.
  3. Les sauvegardes sont intégrées.
  4. La migration "fonctionne tout simplement".

Cependant, le "Transparent Data Encryption" de SQL ne crypte pas les objets FileStream, donc si cela est une considération, il vaut mieux les stocker simplement en varbinary.

De l'article MSDN:

Les instructions Transact-SQL peuvent insérer, mettre à jour, interroger, rechercher et sauvegarder des données FILESTREAM. Les interfaces du système de fichiers Win32 fournissent un accès en continu aux données.
FILESTREAM utilise le cache système NT pour mettre en cache les données de fichier. Cela permet de réduire tout effet que les données FILESTREAM peuvent avoir sur les performances du moteur de base de données. Le pool de mémoire tampon SQL Server n'est pas utilisé; par conséquent, cette mémoire est disponible pour le traitement des requêtes.


+1 pour FileStream. Il stocke en fait les blobs sous forme de fichiers sur le disque, mais les gère de manière transactionnelle.
John Gietzen du

En outre, le serveur SQL permet aux objets blob FileStream d'accéder directement à partir du disque, afin que vous puissiez éviter de
bloquer la

Pourtant, une latence supplémentaire entre la base de données et le serveur Web ... Et le serveur Web devra la charger en mémoire pour la diffuser sur le client au lieu de pouvoir la diffuser à partir du disque, sauf si vous utilisez la mise en cache du disque.
Lilith River

39

Les chemins de fichiers dans la base de données sont certainement la voie à suivre - J'ai entendu des histoires après des clients avec une TB d'images que c'est devenu un cauchemar d'essayer de stocker une quantité importante d'images dans une base de données - le rendement à lui seul est trop.


35

D'après mon expérience, la solution la plus simple consiste parfois à nommer les images en fonction de 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 rien sur l'image dans la base de données.


Très beau effectivement. Vos utilisateurs peuvent désormais facilement incrémenter votre nom de fichier pour accéder à d'autres fichiers ...
Marijn Huizendveld

6
@Marijn: C'est seulement si vous exposez les images au monde.
Seun Osewa

Nous avons fait quelque chose de très similaire avec nos documents imagés (notre clé primaire est une clé composite de trois éléments), mais nous avons ajouté la date et l'heure de numérisation du document afin que nous puissions avoir plusieurs versions dans le même répertoire.
Andrew Neely

@Osewa, comment ça? Oui, pour accéder directement au fichier, l'utilisateur final devrait avoir accès au dossier. Vous pourriez avoir un processus pour servir le fichier via FTP sur demande, et la sécurité serait comparable à celle du serveur SQL.
Andrew Neely

31

L'astuce ici est de ne pas devenir un fanatique.

Une chose à noter ici est que personne dans le camp du système de fichiers pro n'a répertorié un système de fichiers particulier. Est-ce à dire que tout, de FAT16 à ZFS, bat chaque base de données?

Non.

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

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


6
Je ne vois personne affirmer qu'un système de fichiers est plus rapide qu'une base de données 100% du temps (lire la réponse de Mark Harrison). C'est un peu un homme de paille. Il existe probablement des situations dans lesquelles il est préférable de ne pas porter votre ceinture de sécurité, mais de manière générale , le port d'une ceinture de sécurité est une bonne idée.
Calvin

30

Dans les endroits où vous DEVEZ garantir l'intégrité référentielle et la conformité ACID, le stockage d'images dans la base de données est requis.

Vous ne pouvez pas garantir de manière transactionnelle que l'image et les métadonnées de 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 sur le système de fichiers ne sera jamais modifié qu'en même temps et dans la même transaction que les métadonnées.


7
En fait, non, vous le pouvez. Tant que les fichiers image ne sont jamais supprimés, modifiés ou écrasés une fois créés, tous les fichiers image sont synchronisés avant de tenter de valider des transactions, il n'y a pas de corruption du système de fichiers, vous pouvez être sûr que les fichiers image et les métadonnées sont synchronisés. Pour certaines applications, ce sont trop de ifs, je suppose.
Seun Osewa

J'irais même plus loin et dirais qu'avec un système de fichiers de journalisation et une logique de programme supplémentaire, la conformité ACID peut être atteinte. Les étapes seraient d'écrire l'enregistrement db, d'écrire le fichier. Si le fichier est validé, validez la transaction db.
Andrew Neely

28

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 identificateur sous forme de pointeur dans la base de données et stocke automatiquement l'image sur votre système de fichiers, ce qui est un excellent scénario.

Si vous êtes sur une ancienne base de données, je dirais que si vous la stockez en tant que données blob, vous n'allez rien retirer de la base de données pour rechercher des fonctionnalités, il est donc probablement préférable pour 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 allez uniquement enregistrer la quantité exacte d'espace, ou même l'espace compacté sur le système de fichiers.

En outre, vous pouvez 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 aucun hit db, ou de transférer les fichiers en bloc vers un autre système, disque dur, S3 ou un autre scénario - mise à jour de l'emplacement dans votre programme, mais gardez la structure, encore une fois sans trop essayer de faire sortir les images de votre base de données lorsque vous essayez d'augmenter le stockage.

Probablement, cela vous permettrait également de jeter un élément de mise en cache, basé sur les URL des images généralement rencontrées dans votre moteur / programme Web, de sorte que vous vous y enregistriez également.


27

Les petites images statiques (pas plus de quelques mégas) qui ne sont pas fréquemment modifiées, doivent être stockées dans la base de données. Cette méthode présente 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 du 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 d'octets renvoyé par le serveur de base de données sous forme de flux binaire.


Je dirais que la base de données est meilleure pour les fichiers qui sont fréquemment modifiés, car la cohérence peut être un problème dans ce cas.
Seun Osewa

26

Voici un livre blanc intéressant sur le sujet.

Vers BLOB ou pas vers BLOB: stockage d'objets volumineux dans une base de données ou un système de fichiers

La réponse est "Cela dépend". Cela dépendrait certainement du serveur de base de données et de son approche du stockage d'objets blob. Cela dépend également du type de données stockées dans les objets blob, ainsi que de la façon dont ces données doivent être accessibles.

Les fichiers de plus petite taille peuvent être stockés et livrés efficacement en utilisant la base de données comme mécanisme de stockage. Les fichiers plus volumineux seraient probablement mieux stockés à l'aide du système de fichiers, surtout s'ils seront souvent modifiés / mis à jour. (La fragmentation des blobs devient un problème en termes de performances.)

Voici un point supplémentaire à garder à l'esprit. L'une des raisons justifiant l'utilisation d'une base de données pour stocker les objets blob est la conformité ACID. Cependant, l'approche utilisée par les testeurs dans le livre blanc (option Bulk Logged de SQL Server), qui a doublé le débit de SQL Server, a effectivement changé le «D» dans ACID en «d», car les données d'objets blob n'étaient pas enregistrées avec les écritures initiales pour la transaction. Par conséquent, si la conformité ACID complète est une exigence importante pour votre système, divisez par deux les chiffres de débit SQL Server pour les écritures de base de données lors de la comparaison des E / S de fichier aux E / S d'objets blob de base de données.


25

Une chose que je n'ai encore vu personne mentionner, mais qui vaut vraiment la peine d'être notée, c'est qu'il y a aussi des problèmes liés au stockage de grandes quantités d'images dans la plupart des systèmes de fichiers. Par exemple, si vous adoptez l'approche mentionnée ci-dessus et nommez chaque fichier image d'après la clé 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 atteignez un très grand nombre d'images ( par exemple des centaines de milliers ou des millions).

Une fois que la solution commune à ce problème consiste à les hacher dans un arbre équilibré de sous-répertoires.


On pourrait le penser, mais les problèmes sont en fait mineurs; J'ai une application avec des millions de fichiers dans un seul répertoire, accessible par des centaines d'utilisateurs, sans problème. Ce n'est pas intelligent, mais ça marche. Le plus gros problème est que si vous utilisez Explorer pour parcourir le répertoire, vous regardez une lampe de poche pour toujours.
SqlACID

1
Il est préférable d'utiliser un système de fichiers qui n'a aucun problème avec les grands répertoires
Seun Osewa

8
J'avais une application avec des millions de fichiers dans un répertoire (serveur exécutant RHEL 4) - même pour répertorier le contenu du répertoire (rediriger vers un fichier) a pris des jours et créé un fichier de sortie de 100 Mo de taille. Maintenant, ils sont dans une base de données, j'ai un seul fichier que je peux déplacer ou sauvegarder assez facilement.
Richard

1
@Seun Osewa: chaque système de fichiers a ses limites ... et si vous en connaissez un qui n'a aucun problème à stocker des millions d'entrées dans le même répertoire, faites-le moi savoir!
Guillaume

1
@Seun Osewa: la base de données atteint maintenant 28 Go, avec 5,4 millions d'enregistrements. J'ai fini par devoir partitionner la table de base de données, j'ai donc plusieurs fichiers à sauvegarder d'une taille d'environ 5 Go. Déplacer les images individuelles sur Amazon S3 maintenant, donc je n'ai plus qu'à stocker le nom de fichier dans la base de données (et Amazon peut faire les sauvegardes )
Richard

22

Personne n'a mentionné que la base de données 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 savoir 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 supprimez le fichier - que se passe-t-il?

Nous utilisons des blobs car ils sont plus faciles à gérer (sauvegarde, réplication, transfert). Ils fonctionnent bien pour nous.


Quelle est la probabilité d'avoir deux mises à jour simultanées d'une image particulière?
Arafangion

1
vous n'avez pas besoin de mises à jour simultanées pour avoir des problèmes - cela peut être une lecture et une écriture. Dans notre cas, cela est presque garanti.
Draemon le

20

Le problème avec le stockage uniquement des chemins de fichiers vers les 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 à s'interfacer avec une sorte de système de fichiers (si le système de fichiers est accessible indépendamment, les images POURRAIENT "disparaître" soudainement), j'irais les stocker directement en BLOB ou autre.


17

Dans une entreprise où je travaillais, nous avons stocké 155 millions d'images dans une base de données Oracle 8i (puis 9i). 7,5 To de valeur.


5
Absolument. Apparemment, la base de données est beaucoup plus grande maintenant. Avoir les données dans une base de données signifie que la réplication de la base de données sur différents sites est également beaucoup plus facile.
graham.reeds

J'ai vu une démonstration d'Oracle où le pourrait réellement monter un système de fichiers sur la base de données, ou quelque chose comme ça. Savez-vous si c'est ce que vous avez fait? (Désolé, je n'ai aucune idée d'Oracle, alors peut-être que je parle d'ordures.)
Stu Thompson

Je ne pense pas - il stockait des images dans la base de données en tant que base de données. La base de données a été ajustée de manière agressive - je me souviens de plusieurs discussions concernant la taille des images changeant à mesure que des champs étaient ajoutés et supprimés. Tout était aligné sur les limites.
graham.reeds

14

Normalement, je suis catégorique contre le fait de prendre la partie la plus chère et la plus difficile à mettre à l'échelle de votre infrastructure (la base de données) et d'y mettre toute la charge. D'un autre côté: cela simplifie considérablement la stratégie de sauvegarde, en particulier lorsque vous avez plusieurs serveurs Web et devez en quelque sorte garder les données synchronisées.

Comme la plupart des autres choses, cela dépend de la taille et du budget attendus.


13

Nous avons implémenté un système d'imagerie documentaire qui stocke toutes ses images dans les champs d'objets blob SQL2005. Il y a actuellement plusieurs centaines de Go et nous constatons d'excellents temps de réponse et peu ou pas de dégradation des performances. De plus, en conformité avec la réglementation, nous avons une couche middleware qui archive les nouveaux documents publiés sur un système de jukebox optique qui les expose comme un système de fichiers NTFS standard.

Nous sommes très satisfaits des résultats, en particulier en ce qui concerne:

  1. Facilité de réplication et de sauvegarde
  2. Capacité à mettre en œuvre facilement un système de gestion de versions de documents

11

S'il s'agit d'une application Web, le stockage des images sur un réseau de livraison de stockage tiers, tel que S3 d'Amazon ou la plate-forme Nirvanix, pourrait présenter des avantages.


11

Hypothèse: l'application est compatible avec le Web / basée sur le Web

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

Stockez vos fichiers sur un service en ligne payant comme

Un autre thread StackOverflow en parle ici .

Ce fil explique pourquoi vous devez utiliser un fournisseur d'hébergement tiers.

Ça en vaut vraiment la peine. Ils le stockent efficacement. Pas de bande passante téléchargée depuis vos serveurs vers les demandes des clients, etc.


10

Si vous n'êtes pas sur SQL Server 2008 et que vous avez de bonnes raisons de placer des fichiers image spécifiques dans la base de données, vous pouvez alors adopter l'approche "les deux" et utiliser le système de fichiers comme cache temporaire et utiliser la base de données comme référentiel maître. .

Par exemple, votre logique métier peut vérifier si un fichier image existe sur le disque avant de le servir, en le récupérant de la base de données si nécessaire. Cela vous permet d'acheter plusieurs serveurs Web et de réduire les problèmes de synchronisation.


+1 Cela vous permet également de stocker l'image d'origine, en fournissant la version mise en cache / optimisée tout en permettant de modifier la taille / compression ultérieurement
Deebster

7

Je ne sais pas dans quelle mesure il s'agit d'un exemple du "monde réel", mais j'ai actuellement une application qui stocke les détails d'un jeu de cartes à collectionner, y compris les images des cartes. Étant donné que le nombre d'enregistrements pour la base de données n'est que de 2851 enregistrements à ce jour, mais étant donné que certaines cartes ont été publiées plusieurs fois et ont des illustrations alternatives, il était en fait plus efficace de scanner le "carré principal" de l'illustration, puis dynamiquement. générer la bordure et divers effets pour la carte sur demande.

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 la visualisation et la carte individuelle.

Cela facilite également le déploiement / les mises à jour lorsque de nouvelles cartes sont publiées, au lieu de compresser un dossier entier d'images et de les envoyer dans le tuyau et de s'assurer que la structure de dossiers appropriée est créée, je mets simplement à jour la base de données et je demande à l'utilisateur de la télécharger à nouveau. Cela taille actuellement jusqu'à 56 Mo, ce qui n'est pas génial, mais je travaille sur une fonctionnalité de mise à jour incrémentielle pour les futures versions. De plus, il existe une version «sans images» de l'application qui permet à ceux qui se connectent à distance 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 existe un site Web où toutes ces données sont archivées pour un accès en ligne, mais je n'utiliserais en aucun cas la même solution pour cela. Je suis d'accord que l'accès aux fichiers serait préférable car il serait mieux adapté à la fréquence et au volume des demandes effectuées pour les images.

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


Lorsqu'il s'agit de réplication, le stockage des images dans la base de données est de loin supérieur à l'OMI.
Bip bip


7

Cela dépend du nombre d'images que vous allez stocker et également 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.

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

A. Vous n'avez pas besoin de la structure FS pour contenir vos images
B.Les index de base de données fonctionnent mieux que les arbres FS lorsque plus de nombre d'éléments doivent être stockés
C. La base de données bien réglée effectue un bon travail de mise en cache des résultats de la requête
D. Les sauvegardes sont simples. Cela fonctionne également bien si vous avez configuré la réplication et que le contenu est fourni par un serveur proche de l'utilisateur. Dans de tels cas, une synchronisation explicite n'est pas requise.

Si vos images vont être petites (disons <64k) et que le moteur de stockage de votre base de données prend en charge les BLOBs en ligne (en enregistrement), cela améliore encore les performances car aucune indirection n'est requise (la localité de référence est atteinte).

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


7

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 distincte n'est nécessaire (tranquillité d'esprit).
  • La configuration du serveur Web est légèrement plus simple car je n'ai pas besoin d'avoir un dossier de téléchargement / téléchargement et de dire à toutes mes applications où il se trouve.
  • Je peux utiliser des transactions pour des modifications pour améliorer l'intégrité des données - je n'ai pas à me soucier des fichiers orphelins et manquants

Les inconvénients:

  • mysqldump prend maintenant beaucoup de temps car il y a 500 Mo de données de fichier dans l'une des tables.
  • Globalement pas très efficace en mémoire / processeur par rapport au système de fichiers

J'appellerais ma mise en œuvre réussie, elle prend en charge les exigences de sauvegarde et simplifie la mise en page du projet. Les performances sont bonnes pour les 20 à 30 personnes qui utilisent l'application.


6

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

La première solution, les images dans la base de données, est quelque peu "plus propre" car votre couche d'accès aux données devra traiter uniquement les objets de la base de données; mais ce n'est bon que lorsque vous devez faire face à des chiffres faibles.

De toute évidence, les performances d'accès à la base de données lorsque vous traitez des objets binaires volumineux se dégradent, et les dimensions de la base de données augmenteront considérablement, entraînant à nouveau une perte de performances ... et normalement, l'espace de base de données est beaucoup plus cher que l'espace du système de fichiers.

D'un autre côté, le fait d'avoir de gros objets binaires stockés dans le système de fichiers vous obligera à avoir des plans de sauvegarde qui doivent prendre en compte à 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 sons, vidéo, peu importe) avec un accès tiers: de nos jours, je développe une application web qui utilise des images accessibles depuis "l'extérieur". "ma ferme Web de telle manière qu'un accès à la base de données pour récupérer des données binaires est tout simplement impossible. Il y a donc parfois des considérations de conception qui vous conduiront à un choix.

Considérez également, lorsque vous faites ce choix, si vous devez faire face à l'autorisation et à l'authentification lors de l'accès aux objets binaires: ces conditions peuvent normalement être résolues plus facilement lorsque les données sont stockées dans db.


4

J'ai déjà travaillé sur une application de traitement d'images. Nous avons stocké les images téléchargées dans un répertoire qui ressemblait à / images / [date d'aujourd'hui] / [numéro d'identification]. Mais nous avons également 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

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

Dans mon dernier projet, je stocke des images dans la base de données et les mets en cache sur le système de fichiers, et cela fonctionne très bien. Je n'ai eu aucun problème jusqu'à présent.


3

Deuxièmement, la recommandation sur les chemins de fichiers. J'ai travaillé sur quelques projets qui avaient besoin de gérer des collections d'actifs de grande envergure, et toute tentative de stocker des choses directement dans la base de données a entraîné de la douleur et de la frustration à long terme.

Le seul vrai "pro" auquel je puisse penser en ce qui concerne leur stockage dans la base de données est la possibilité de faciliter la création d'images individuelles. S'il n'y a pas de chemin de fichier à utiliser et que toutes les images sont diffusées directement depuis la base de données, il n'y a aucun danger qu'un utilisateur trouve des fichiers auxquels il ne devrait pas avoir accès.

Cela semble cependant mieux résolu avec un script intermédiaire tirant les données d'un magasin de fichiers inaccessible sur le Web. Le stockage DB n'est donc PAS VRAIMENT nécessaire.


3

Le mot dans la rue est qu'à moins que vous ne soyez un fournisseur de base de données essayant de prouver que votre base de données peut le faire (comme, disons, Microsoft se vantant que Terraserver stocke un bajillion d'images dans SQL Server), ce n'est pas une très bonne idée. Lorsque l'alternative - stocker des images sur des serveurs de fichiers et des chemins d'accès dans la base de données est tellement plus facile, pourquoi s'embêter? Les champs blob sont un peu comme les capacités hors route des VUS - la plupart des gens ne les utilisent pas, ceux qui ont généralement des ennuis, et puis il y en a qui le font, mais uniquement pour le plaisir.


3

Le stockage d'une image dans la base de données signifie toujours que les données d'image se retrouvent quelque part dans le système de fichiers mais obscurcies 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 garder le système de fichiers synchronisé lorsqu'une image est ajoutée ou supprimée

-ves:

  • pénalité de performances - 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 modifier directement l'image (recadrer, redimensionner)

Les deux méthodes sont courantes et pratiquées. Jetez un oeil sur les avantages et les inconvénients. Quoi qu'il en soit, vous devrez réfléchir à la façon de surmonter les inconvénients. Le stockage dans la base de données signifie généralement peaufiner les paramètres de la base de données et implémenter une sorte de mise en cache. L'utilisation du système de fichiers nécessite que vous trouviez un moyen de synchroniser le système de fichiers + la base de données.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.