Stockage des images dans DB – Oui ou non?

J’utilise donc une application qui stocke fortement les images dans la firebase database. Quelle est votre vision à ce sujet? Je suis plus du genre à stocker l’emplacement dans le système de fichiers que de le stocker directement dans la firebase database.

Que pensez-vous des avantages / inconvénients?

Je suis en charge de certaines applications qui gèrent de nombreuses TB d’images. Nous avons constaté que le stockage des chemins de fichiers dans la firebase database était le meilleur.

Il y a quelques problèmes:

  • le stockage de la firebase database est généralement plus coûteux que celui du système de fichiers
  • vous pouvez accélérer au maximum l’access au système de fichiers avec des produits standards
    • 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 firebase database ne bénéficient pas de cette optimisation.
  • des choses comme les serveurs Web, etc., ne nécessitent aucun codage ou traitement particulier pour accéder aux images du système de fichiers
  • les bases de données gagnent 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 firebase database 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 avec 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 firebase database.

  • Vous stockez des images qui changent de manière dynamic, par exemple des factures et vous souhaitez 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 firebase database 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’access aux images si elles se trouvent dans une firebase database. Les administrateurs en veille peuvent accéder à n’importe quel dossier sur le disque. Il faut un administrateur vraiment déterminé pour fouiller dans une firebase database pour extraire les images

Par contre 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’access direct au fichier
  • Charge plus lourde sur le serveur de firebase database

Magasin de fichiers. Les ingénieurs de Facebook en ont bien parlé. L’une des solutions consistait à connaître la limite pratique des fichiers dans un répertoire.

Aiguille dans une meule de foin: stockage efficace de milliards de photos

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

FileStream résout la plupart des problèmes liés au stockage des fichiers dans la firebase database:

  1. Les blobs sont en fait stockés sous forme de fichiers dans un dossier.
  2. Les Blobs sont accessibles via une connexion à une firebase database ou via le système de fichiers.
  3. Les sauvegardes sont intégrées.
  4. La migration “ne fait que fonctionner”.

Cependant, le “chiffrement des données transparentes” de SQL ne chiffre pas les objects FileStream. Par conséquent, il est préférable que vous les stockiez uniquement en tant que 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 access en continu aux données.
FILESTREAM utilise le cache du système NT pour mettre en cache les données de fichier. Cela permet de réduire les effets éventuels des données FILESTREAM sur les performances du moteur de firebase database. 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 firebase database sont certainement la voie à suivre – j’ai entendu des histoires de clients avec TB d’images, que c’était devenu un cauchemar d’essayer de stocker une quantité significative d’images dans une firebase database.

Selon 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 firebase database.

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 que cela signifie que tout, de FAT16 à ZFS, bat toutes les bases 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 la vitesse brute.

La bonne solution 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 firebase database est requirejs.

Vous ne pouvez pas garantir transactionnellement que l’image et les métadonnées concernant cette image stockée dans la firebase database 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 soit modifié que simultanément 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 en tant que pointeur dans la firebase database et stocke automatiquement l’image sur votre système de fichiers.

Si vous êtes sur une firebase database plus ancienne, alors je dirais que si vous la stockez en tant que données blob, alors vous n’obtiendrez rien de la firebase database dans la recherche de fonctionnalités, donc c’est probablement mieux stocker une adresse sur un système de fichiers et stocker l’image de cette manière.

De cette façon, vous économiserez également de l’espace sur votre système de fichiers, car vous ne ferez que gagner de la place, voire de l’espace compacté sur le système de fichiers.

En outre, vous pouvez décider de sauvegarder avec une structure ou des éléments vous permettant de parcourir les images brutes de votre système de fichiers sans aucun access db, ou de transférer les fichiers vers un autre système, disque dur, S3 ou un autre scénario. votre programme, mais conservez la structure, encore une fois sans trop de difficultés à essayer de sortir les images de votre firebase database lorsque vous essayez d’augmenter le stockage.

Probablement, cela vous permettrait également de lancer un élément de mise en cache, basé sur les URL d’impression couramment utilisées dans votre moteur / programme Web, vous vous sauvegardez donc également.

Les petites images statiques (pas plus de quelques Mo) qui ne sont pas fréquemment modifiées doivent être stockées dans la firebase database. Cette méthode présente plusieurs avantages, notamment une portabilité facilitée (les images sont transférées avec la firebase database), une sauvegarde / restauration simplifiée (les images sont sauvegardées avec la firebase database) et une meilleure évolutivité (un dossier de système de fichiers contenant des milliers de petites vignettes moi).

Il est facile de servir des images à partir d’une firebase database, il vous suffit d’implémenter un gestionnaire http qui sert le tableau d’octets renvoyé par le serveur de firebase database en tant que stream binary.

Voici un livre blanc intéressant sur le sujet.

To BLOB ou Not To BLOB: stockage d’objects volumineux dans une firebase database ou un système de fichiers

La réponse est “ça dépend”. Cela dépend certainement du serveur de firebase database et de son approche du stockage des objects 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 consultées.

Les fichiers de plus petite taille peuvent être stockés et livrés efficacement en utilisant la firebase database comme mécanisme de stockage. Les fichiers plus volumineux seraient probablement mieux stockés en utilisant le système de fichiers, en particulier s’ils seront modifiés / mis à jour souvent. (La fragmentation des objects blob devient un problème de performance.)

Voici un point supplémentaire à garder à l’esprit. L’une des raisons pour lesquelles l’utilisation d’une firebase database pour stocker les blobs est la conformité ACID. Cependant, l’approche utilisée par les testeurs dans le livre blanc (option de stockage en bloc de SQL Server), qui doublait le débit SQL Server, a transformé le «D» en ACID en «d», les données de blob n’étant pas consignées avec les premières écritures 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 firebase database lorsque vous comparez les E / S de fichiers aux E / S de blob de firebase database.

Une chose que je n’ai encore jamais vue, mais qui mérite 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. Par exemple, si vous prenez l’approche mentionnée ci-dessus et nommez chaque fichier image après la clé primaire, vous rencontrerez des problèmes sur la plupart des systèmes de fichiers si vous tentez de placer toutes les images dans un grand répertoire. par exemple dans les centaines de milliers ou de millions).

Une fois la solution commune à cela consiste à les hacher dans un arbre équilibré de sous-répertoires.

Quelque chose que personne n’a mentionné, c’est que la firebase database garantit des actions atomiques, l’intégrité transactionnelle et la gestion des access simultanés. Même référentiellement, l’intégrité 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 lorsque vous écrivez une nouvelle version ou que vous 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.

Le problème avec le stockage des chemins de fichiers uniquement dans les images d’une firebase database est que l’intégrité de la firebase database ne peut plus être forcée.

Si l’image réelle désignée par le chemin d’access au fichier devient indisponible, la firebase database a involontairement une erreur d’intégrité.

Étant donné que les images sont les véritables données recherchées et qu’elles peuvent être gérées plus facilement (les images ne disparaissent pas soudainement) dans une firebase database intégrée plutôt que d’être connectées à un système de fichiers quelconque (si le système de fichiers est accessible indépendamment), les images pourraient soudainement “disparaître”, je les enregistrerais directement comme BLOB ou autre.

Dans une entreprise où je travaillais, nous stockions 155 millions d’images dans une firebase database Oracle 8i (alors 9i). 7,5To valeur.

Normalement, je suis catégoriquement opposé à l’idée de prendre en charge la partie la plus coûteuse et la plus difficile de votre infrastructure (la firebase database) et d’y intégrer 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 en quelque sorte conserver 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 les champs blob SQL2005. Il y a plusieurs centaines de Go en ce moment et nous assistons à d’excellents temps de réponse et à une dégradation faible ou nulle des performances. De plus, en conformité avec la réglementation, nous avons une couche de middleware qui archive les documents nouvellement publiés sur un système de jukebox optique qui les expose comme un système de fichiers NTFS standard.

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

  1. Facilité de réplication et de sauvegarde
  2. Possibilité d’implémenter facilement un système de gestion des versions de documents

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

Hypothèse: l’application est compatible Web / Web

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

Stockez vos fichiers sur un service en ligne payant comme

  • Amazon S3
  • Moso Cloud Storage

Un autre thread StackOverflow parle de cela ici .

Cette discussion explique pourquoi vous devez utiliser un fournisseur d’hébergement tiers.

C’est tellement la peine. Ils le stockent efficacement. Pas de bande passante téléchargée de vos serveurs sur les demandes des clients, etc.

Si vous ne travaillez pas sur SQL Server 2008 et que vous avez de bonnes raisons de placer des fichiers image spécifiques dans la firebase database, vous pouvez utiliser l’approche “two” et utiliser le système de fichiers comme cache temporaire et utiliser la firebase database 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 servir, en le récupérant si nécessaire. Cela vous permet d’utiliser plusieurs serveurs Web et de réduire les problèmes de synchronisation.

Je ne suis pas sûr de savoir à quel point c’est un exemple “réel”, mais j’ai actuellement une application qui stocke des détails pour un jeu de cartes à collectionner, y compris les images pour les cartes. Certes, le nombre d’enregistrements pour la firebase database n’est que de 2851 enregistrements à ce jour, mais étant donné que certaines cartes sont libérées plusieurs fois et ont des illustrations différentes, il était également plus efficace de scanner le “carré principal” générer la bordure et divers effets pour la carte lorsque cela est demandé.

Le créateur original de cette bibliothèque d’images a créé une classe d’access 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 les déploiements / mises à jour lorsque de nouvelles cartes sont publiées, au lieu de compresser un dossier d’images complet et de l’envoyer pour s’assurer que la structure de dossiers appropriée est créée. Cela mesure 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. En outre, il existe une version “sans image” de l’application qui permet aux utilisateurs ayant un access par ligne commutée d’obtenir l’application sans le délai de téléchargement.

Cette solution a bien fonctionné à ce jour car l’application elle-même est ciblée en tant qu’instance unique sur le bureau. Il existe un site Web où toutes ces données sont archivées pour un access en ligne, mais je n’utiliserais en aucun cas la même solution pour cela. Je suis d’accord que l’access 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 babillage, mais j’ai vu le sujet et je voulais donner quelques idées à partir d’une application relativement réussie à petite ou moyenne échelle.

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

Gérez-le comme une table normale et obtenez les performances du système de fichiers.

Cela dépend du nombre d’images que vous allez stocker et de leur taille. J’ai utilisé des bases de données pour stocker des images dans le passé et mon expérience a été plutôt bonne.

OMI, Avantages d’utiliser la firebase database pour stocker des images sont,

A. Vous n’avez pas besoin de la structure FS pour contenir vos images
B. Les index de firebase database sont plus performants que les arbres FS lorsque le nombre d’éléments à stocker est plus élevé
C. Une firebase database 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 la configuration de la réplication et le contenu sont fournis à partir d’un serveur proche de l’utilisateur. Dans ce cas, la synchronisation explicite n’est pas requirejse.

Si vos images vont être petites (disons <64 ko) 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).

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 lié au stockage des images dans la firebase database est que les métadonnées telles que la création, les dates de modification doivent être gérées par votre application.

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 rest, aucune stratégie de sauvegarde séparée 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’un dossier de téléchargement ni de toutes les applications.
  • Je peux utiliser les transactions pour les éditer afin d’améliorer l’intégrité des données – je n’ai pas à m’inquiéter des fichiers orphelins et manquants

Les inconvénients:

  • mysqldump prend maintenant un temps considérable car il y a 500 Mo de données de fichier dans l’une des tables.
  • Dans l’ensemble pas très mémoire / cpu efficace par rapport au système de fichiers

J’appellerais mon implémentation un succès, il prend en charge les exigences de sauvegarde et simplifie la mise en page du projet. La performance est bonne pour les 20-30 personnes qui utilisent l’application.

À mon expérience, j’ai dû gérer les deux situations: images stockées dans la firebase database et images sur le système de fichiers avec chemin d’access stocké dans la firebase database.

La première solution, les images dans la firebase database, est quelque peu “plus propre”, car votre couche d’access aux données ne devra traiter que des objects de firebase database. mais ce n’est bon que lorsque vous devez composer avec des nombres faibles.

Évidemment, les performances d’access aux bases de données lorsque vous traitez des objects volumineux binarys sont dégradées et les dimensions de la firebase database augmentent considérablement, entraînant à nouveau des pertes de performances …

D’un autre côté, avoir de gros objects binarys stockés dans le système de fichiers vous amènera à avoir des plans de sauvegarde qui doivent prendre en compte à la fois la firebase database et le système de fichiers, ce qui peut poser problème pour certains systèmes.

Une autre raison de choisir un système de fichiers est de partager les données de vos images (ou sons, vidéos, etc.) avec un access tiers: en ce moment, je développe une application Web qui utilise des images auxquelles il faut accéder “ma ferme Web de telle manière qu’un access à la firebase database pour récupérer des données binarys est tout simplement impossible. Il y a donc parfois des considérations de conception qui vous pousseront à choisir.

Pensez également, lors de ce choix, si vous devez gérer la permission et l’authentification lors de l’access aux objects binarys: ces conditions peuvent normalement être résolues plus facilement lorsque des données sont stockées dans la firebase database.

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 similaire à / images / [date du jour] / [numéro d’identifiant]. Mais nous avons également extrait les métadonnées (données exif) des images et les avons stockées dans la firebase database, avec un horodatage, etc.

Dans un projet précédent, je stockais des images sur le système de fichiers, ce qui entraînait de nombreux problèmes avec les sauvegardes, la réplication et le système de fichiers qui se désynchronisait de la firebase database.

Dans mon dernier projet, je stocke des images dans la firebase database et les place en cache sur le système de fichiers, et cela fonctionne très bien. Je n’ai eu aucun problème jusqu’ici.

Deuxièmement, la recommandation sur les chemins de fichiers. J’ai travaillé sur quelques projets qui nécessitaient la gestion de vastes collections d’actifs, et toute tentative de stocker des éléments directement dans la firebase database entraînait de la peine et de la frustration à long terme.

Le seul vrai “pro” que je puisse imaginer en ce qui concerne leur stockage dans la firebase database est le potentiel de simplification des ressources d’image individuelles. S’il n’y a pas de chemin d’access à utiliser, et que toutes les images sont diffusées directement depuis la firebase database, l’utilisateur ne risque pas de trouver des fichiers auxquels il ne devrait pas avoir access.

Cela semble être mieux résolu avec un script intermédiaire qui extrait les données d’un magasin de fichiers inaccessible sur le Web. Le stockage de la firebase database n’est donc pas vraiment nécessaire.

Le mot dans la rue est que sauf si vous êtes un fournisseur de firebase database essayant de prouver que votre firebase database peut le faire (comme, disons Microsoft vantant Terraserver stocker 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 dans la firebase database est tellement plus facile, pourquoi s’en préoccuper? 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 des problèmes en général, et il y a ceux qui le font, mais seulement pour le plaisir.

Stocker une image dans la firebase database signifie toujours que les données d’image se retrouvent quelque part dans le système de fichiers, mais qu’elles sont masquées pour que vous ne puissiez pas y accéder directement.

+ ves:

  • intégrité de la firebase database
  • Il est facile à gérer car vous n’avez pas à vous soucier de la synchronisation du système de fichiers lorsqu’une image est ajoutée ou supprimée.

-ves:

  • Pénalité de performance – une recherche dans une firebase database 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. Découvrez les avantages et les inconvénients. Dans tous les cas, vous devrez réfléchir à la manière de surmonter les inconvénients. Stocker dans une firebase database signifie généralement modifier les parameters de la firebase database et implémenter une sorte de mise en cache. L’utilisation du système de fichiers nécessite de trouver un moyen de maintenir la synchronisation entre le système de fichiers et la firebase database.