Stockage d'images dans une base de données - Oui ou non ?

https://stackoverflow.com/questions/3748

08-06-2019
|

Question

J'utilise donc une application qui stocke massivement les images dans la base de données.Quel est votre point de vue à ce sujet ?Je suis plus du genre à stocker l'emplacement dans le système de fichiers plutôt qu'à le stocker directement dans la base de données.

Selon vous, quels sont les avantages/inconvénients ?

Pas de solution correcte

Autres conseils

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

Il y a quelques problèmes :

le stockage de base de données est généralement plus cher que le stockage du système de fichiers
vous pouvez accélérer l'accès au système de fichiers avec des produits standard disponibles dans le commerce
- par exemple, de nombreux serveurs Web utilisent le système d'exploitation envoyer le fichier() appel système pour envoyer de manière asynchrone un fichier directement du système de fichiers vers l’interface réseau.Les images stockées dans une base de données ne bénéficient pas de cette optimisation.
des éléments tels que les serveurs Web, etc., ne nécessitent aucun codage ou traitement spécial pour accéder aux images du 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 de la base de données et les données du système de fichiers
- il est difficile (dans le contexte d'une application Web) de garantir que les données ont été vidées sur le disque du système de fichiers

Comme pour la plupart des problèmes, ce n’est pas aussi simple qu’il y paraît.Il existe des cas où il serait judicieux 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 En 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 le 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 en extraire les images

D'un autre côté, il existe des problèmes liés

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

Magasin de fichiers.Les ingénieurs de Facebook en ont beaucoup parlé.L’un des points à 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

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

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

Les Blobs sont en fait stockés sous forme de fichiers dans un dossier.
Les Blobs sont accessibles en utilisant soit une connexion à une base de données ou sur le système de fichiers.
Les sauvegardes sont intégrées.
La migration « fonctionne ».

Cependant, le « cryptage transparent des données » de SQL ne crypte pas les objets FileStream, donc si cela est une considération, vous feriez peut-être mieux de simplement les stocker en tant que varbinary.

Extrait 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 streaming aux données.
FILESTREAM utilise le cache du système NT pour mettre en cache les données des fichiers.Cela permet de réduire tout effet que les données FILESTREAM pourraient 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.

Les chemins de fichiers dans la base de données sont certainement la voie à suivre - j'ai entendu histoire après histoire de clients possédant des To d'images selon lesquelles c'était devenu un cauchemar d'essayer de stocker une quantité importante d'images dans une base de données - la performance à elle seule est trop importante.

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

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

Une chose à noter ici est que personne dans le camp des systèmes de fichiers professionnels n'a répertorié un système de fichiers particulier.Cela signifie-t-il que tout, de FAT16 à ZFS, bat facilement toutes les bases de données ?

Non.

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

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

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

Vous ne pouvez pas garantir transactionnellement que l'image et les métadonnées sur cette image stockées dans la base de données font référence au même fichier.En d’autres termes, il est impossible de garantir que le fichier sur le système de fichiers n’est modifié qu’en même temps et dans la même transaction que les métadonnées.

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

Si vous utilisez une base de données plus ancienne, je dirais que si vous la stockez sous forme de données blob, vous n'obtiendrez vraiment rien de la base de données en termes de recherche de fonctionnalités, c'est donc probablement mieux. 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 n'économiserez que la quantité exacte d'espace, voire 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 de votre système de fichiers sans aucun accès à la base de données, ou de transférer les fichiers en masse vers un autre système, disque dur, S3 ou un autre scénario - en mettant à jour l'emplacement dans votre programme, mais conservez la structure, encore une fois sans trop de succès en essayant de faire sortir les images de votre base de données lorsque vous essayez d'augmenter le stockage.

Probablement, cela vous permettrait également d'ajouter un élément de mise en cache, basé sur les URL d'images fréquemment consultées, dans votre moteur/programme Web, de sorte que vous vous y sauvez également.

Les petites images statiques (pas plus de quelques Mo) 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 de système de fichiers avec des milliers de petits fichiers miniatures ressemble à un cauchemar d'évolutivité pour moi).

Servir des images à partir d'une base de données est simple, 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.

Voici un livre blanc intéressant sur le sujet.

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

La réponse est : "Ça dépend." Certes, cela dépendrait du serveur de base de données et de son approche du stockage blob.Cela dépend également du type de données stockées dans les blobs, ainsi que de la manière 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 en utilisant le système de fichiers, surtout s'ils doivent être modifiés/mis à jour souvent.(la fragmentation des blobs devient un problème en termes de performances.)

Voici un point supplémentaire à garder à l’esprit.L’une des raisons qui justifient l’utilisation d’une base de données pour stocker les blobs 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 blob n'étaient pas enregistrées avec les écritures initiales pour la transaction.Par conséquent, si la conformité ACID totale est une exigence importante pour votre système, réduisez de moitié les chiffres de débit de SQL Server pour les écritures de base de données lorsque vous comparez les E/S de fichiers aux E/S de blob de base de données.

Une chose que personne n'a encore mentionnée, mais qui mérite certainement d'être notée, est qu'il existe également des problèmes associé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 après la clé primaire, sur la plupart des systèmes de fichiers, vous rencontrerez des problèmes si vous essayez de placer toutes les images dans un grand répertoire une fois que vous avez atteint un très grand nombre d'images ( par exemple.en centaines de milliers ou en millions).

Une solution courante consiste à les hacher dans une arborescence équilibrée de sous-répertoires.

Quelque chose que personne n'a mentionné, c'est que la base de données garantit les actions atomiques, l'intégrité transactionnelle et gère 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 si vos noms de fichiers sont vraiment 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 également plus faciles à gérer (sauvegarde, réplication, transfert).Ils fonctionnent bien pour nous.

Le problème du stockage uniquement des chemins d'accès aux 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 du fichier devient indisponible, la base de données présente 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 soudainement "disparaître"), j'opterais pour les stocker directement sous forme de BLOB ou autre.

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

Normalement, je suis fermement opposé au fait de prendre la partie la plus coûteuse et la plus difficile à faire évoluer de votre infrastructure (la base de données) et d'y mettre toute la charge.D'autre part:Cela simplifie grandement la stratégie de sauvegarde, en particulier lorsque vous disposez de plusieurs serveurs Web et que vous devez d'une manière ou d'une autre maintenir les données synchronisées.

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

Nous avons implémenté un système d'imagerie documentaire qui stocke toutes ses images dans des champs blob SQL2005.Il existe 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, conformément à la réglementation, nous disposons d'une couche middleware qui archive les documents nouvellement publiés sur un système de juke-box optique qui les expose comme un système de fichiers NTFS standard.

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

Facilité de réplication et de sauvegarde
Capacité à mettre en œuvre facilement un système de versionnage de documents

S'il s'agit d'une application Web, il pourrait être avantageux de stocker les images sur un réseau de stockage tiers, tel que le S3 d'Amazon ou la plate-forme Nirvanix.

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

Je suis surpris que personne n'en ait vraiment parlé...déléguez-le à d'autres spécialistes -> utiliser un fournisseur d'hébergement d'images/fichiers tiers.

Stockez vos fichiers sur un service en ligne payant comme

Un autre fil de discussion StackOverflow en parle ici.

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

Ça vaut vraiment le coup.Ils le stockent efficacement.Aucune bande passante n'est téléchargée depuis vos serveurs vers les demandes des clients, etc.

Si vous n'utilisez pas 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 principal. .

Par exemple, votre logique métier peut vérifier si un fichier image existe sur le disque avant de le diffuser, en le récupérant dans la base de données si nécessaire.Cela vous offre la capacité de plusieurs serveurs Web et moins de problèmes de synchronisation.

Je ne sais pas à quel point 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.Certes, le nombre d'enregistrements pour la base de données n'est que de 2 851 à ce jour, mais étant donné que certaines cartes ont été publiées plusieurs fois et comportent des illustrations alternatives, il était en fait plus efficace en termes de taille de numériser le « carré principal » de l'illustration, puis de manière dynamique. générer la bordure et les effets divers de la carte lorsque cela est demandé.

Le créateur original de cette bibliothèque d'images a créé une classe d'accès aux données qui restitue l'image en fonction de la demande, et 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 garantir que la structure de dossiers appropriée est créée, je mets simplement à jour la base de données et demande à l'utilisateur de la télécharger à nouveau.Cela fait actuellement jusqu'à 56 Mo, ce qui n'est pas génial, mais je travaille sur une fonctionnalité de mise à jour incrémentielle pour les versions futures.De plus, il existe une version « sans images » de l'application qui permet aux personnes utilisant une connexion commutée d'obtenir l'application sans délai de téléchargement.

Cette solution a très bien fonctionné jusqu'à présent puisque l'application elle-même est ciblée comme une instance unique sur le bureau.Il existe un site Web sur lequel 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 s'adapterait mieux à la fréquence et au volume des demandes faites pour les images.

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

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

Gérez-le comme une table ordinaire et bénéficiez des performances du système de fichiers.

Cela dépend du nombre d’images que vous allez stocker ainsi que de leurs tailles.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 de l'utilisation d'une base de données pour stocker des images sont,

UN.Vous n'avez pas besoin de structure FS pour conserver vos images
B.Les index de base de données fonctionnent mieux que les arbres FS lorsqu'un plus grand nombre d'éléments doivent être stockés
C.Une base de données intelligemment optimisé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 à partir d'un serveur proche de l'utilisateur.Dans de tels cas, une synchronisation explicite n'est pas requise.

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

Stocker des images peut être une mauvaise idée lorsque vous traitez un petit nombre d’images de grande taille.Un autre problème lié au stockage des images dans la base de données est que les métadonnées telles que la création et les dates de modification doivent être gérées par votre application.

J'ai récemment créé une application PHP/MySQL qui stocke les fichiers PDF/Word dans une table MySQL (jusqu'à présent jusqu'à 40 Mo par fichier).

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 uploads/ et d'indiquer à toutes mes applications où il se trouve.
Je peux utiliser des transactions pour les modifications afin d'améliorer l'intégrité des données - je n'ai pas à me soucier des fichiers orphelins ou manquants

Les 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, pas très efficace en termes de mémoire/processeur par rapport au système de fichiers

Je qualifierais ma mise en œuvre de succès, elle répond aux exigences de sauvegarde et simplifie la présentation du projet.Les performances sont bonnes pour les 20 à 30 personnes qui utilisent l’application.

D'après 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 la base de données.

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 cela 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 la 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 des objets binaires volumineux 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, ce qui peut poser 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 :en ce moment, je développe une application Web qui utilise des images auxquelles il faut accéder depuis "l'extérieur" de 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.Parfois, il y a aussi des considérations de conception qui vous amèneront à faire un choix.

Considérez également, lorsque vous faites ce choix, si vous devez gérer les autorisations et l'authentification lors de l'accès aux objets binaires :ces conditions peuvent normalement être résolues de manière plus simple lorsque les données sont stockées dans la base de données.

J'ai déjà travaillé sur une application de traitement d'image.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, etc.

Dans un projet précédent, j'ai stocké des images sur le système de fichiers, ce qui a causé beaucoup de problèmes avec les sauvegardes, la réplication et la désynchronisation du système de fichiers 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.

Deuxièmement, la recommandation sur les chemins de fichiers.J'ai travaillé sur quelques projets qui nécessitaient de gérer des collections d'actifs volumineuses, et toute tentative de stocker des éléments directement dans la base de données entraînait des douleurs et de la frustration à long terme.

Le seul véritable "pro" auquel je puisse penser concernant leur stockage dans la base de données est le potentiel de facilité de gestion des images individuelles.S'il n'y a aucun chemin de fichier à utiliser et que toutes les images sont diffusées directement depuis la base de données, il n'y a aucun risque qu'un utilisateur trouve des fichiers auxquels il ne devrait pas avoir accès.

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

Le bruit court est qu'à moins que vous ne soyez un fournisseur de bases de données essayant de prouver que votre base de données peut le faire (comme, disons, Microsoft se vantant du fait que Terraserver stocke un milliard d'images dans SQL Server), ce n'est pas une très bonne idée.Alors que l’alternative – stocker les images sur des serveurs de fichiers et les chemins dans la base de données est tellement plus simple, pourquoi s’embêter ?Les champs de blob sont un peu comme les capacités tout-terrain des SUV : la plupart des gens ne les utilisent pas, ceux qui le font ont généralement des ennuis, et puis il y a ceux qui le font, mais seulement pour le plaisir.

Stocker une image dans la base de données signifie toujours que les données de l'image se retrouvent quelque part dans le système de fichiers mais sont masquées afin que vous ne puissiez pas y accéder directement.

+ves :

intégrité de la base de données
c'est facile à gérer puisque 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é en termes de performances : une recherche dans une base de données est généralement plus lente qu'une recherche dans un système de fichiers
vous ne pouvez pas modifier l'image directement (recadrer, redimensionner)

Les deux méthodes sont courantes et pratiquées.Jetez un œil aux avantages et aux inconvénients.Quoi qu’il en soit, vous devrez réfléchir à la manière de surmonter les inconvénients.Le stockage 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 mise en cache.L’utilisation du système de fichiers nécessite que vous trouviez un moyen de synchroniser le système de fichiers et la base de données.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow