Question Stocker des images dans DB - Oui ou Non?


J'utilise donc une application qui stocke fortement les images dans la base de données. Quelle est votre perspective à ce sujet? Je suis plus d'un type pour stocker l'emplacement dans le système de fichiers, que de le stocker directement dans la base de données.

Que pensez-vous des avantages / inconvénients?


415


origine


Réponses:


Je suis en charge de certaines applications qui gèrent de nombreuses TB d'images. Nous avons trouvé 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 la base de données est généralement plus coûteux que celui du système de fichiers
  • vous pouvez accélérer au maximum l'accès au système de fichiers avec des produits standards
    • 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 à partir 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 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 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

350



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

  • Vous stockez des images qui sont changer dynamiquement, disons les 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 de stratégie de sauvegarde différente. Les images stockées sur le système de fichiers
  • 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 aller 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 un code supplémentaire pour extraire et diffusez 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

140



Magasin de fichiers. Les ingénieurs de Facebook en ont beaucoup 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


99



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

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

  1. Les Blobs sont stockés en tant que fichiers dans un dossier.
  2. Les Blobs peuvent être accédés en utilisant non plus une connexion de base de données ou sur le système de fichiers.
  3. Les sauvegardes sont intégrées.
  4. La migration "ne fait que fonctionner".

Toutefois, le "chiffrement transparent des données" de SQL ne crypte pas les objets FileStream. Par conséquent, si vous en tenez compte, il est préférable de les stocker 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 de système de fichiers Win32 fournissent un accès en continu aux données.
  FILESTREAM utilise le cache système NT pour la mise en cache des 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.


56



Les chemins de fichier dans la base de données sont absolument la voie à suivre - J'ai entendu des histoires de clients avec des images de TB que c'est devenu un cauchemar en essayant de stocker une quantité significative d'images dans une base de données - le seul coup de performance est trop.


39



D'après mon expérience, parfois la solution la plus simple est de 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 pas n'importe quoi à propos de l'image dans la base de données.


35



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

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 facilement 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.

Le bon plan d'action est de prendre la bonne décision pour votre scénario précis, et pour ce faire, vous aurez besoin de quelques chiffres et quelques estimations de cas d'utilisation.


31



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 que l'image et les métadonnées de 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 est seulement modifié en même temps et dans la même transaction que les métadonnées.


30