Images dans la base de données contre le système de fichiers

Question

Nous avons un projet à venir où nous allons construire un back-end tout le système CMS qui alimentera notre extranet et intranet entier avec un seul paquet. La question que je tente de trouver une réponse à est ce qui est mieux: stocker des images dans la base de données (SQL Server 2005) afin que nous puissions avoir l'intégrité, un seul plan de réplication, etc ou le stockage sur le système de fichiers

Un problème que nous avons est que nous avons plusieurs serveurs qui nécessitent un équilibrage de charge d'avoir les mêmes données à tout moment. A partir de maintenant, nous avons la réplication SQL en prenant soin de cela, mais la réplication de fichiers semble être un peu plus difficile. Une autre préoccupation que nous avons est que nous aimerions avoir plusieurs résolutions de la même image, nous ne savons pas si la création et le stockage de chaque version sur le système de fichiers serait le mieux ou peut-être tirer dynamique et de créer l'image de résolution que nous voudrions sur demande.

Nos préoccupations sont les ce qui suit:

• L'intégrité des données
• La réplication des données
• résolutions multiples
• Vitesse de base de données vs système de fichiers
• cariste de base de données vs système de fichiers
• Gestion et sauvegarde des données

Quelqu'un at-il une situation similaire ou avez des commentaires sur ce qui serait recommandé? Merci d'avance pour l'aide!

Answer 1

Il y avait un document de recherche publié par Microsoft belle recherche appelé blob ou pas Blob où ils ont examiné toutes sortes de variables et les impacts.

Leur conclusion à la fin:

• jusqu'à 256 Ko en taille, blobs sont stockés dans la base de données de manière plus efficace que dans le système de fichiers
• pour 1 Mo et plus, le système de fichiers est plus efficace
• entre c'est un haut-Toss

Depuis que le papier a été publié, SQL Server 2008 a également ajouté l'attribut FILESTREAM qui rend le stockage des choses dans le système de fichiers, mais sous le contrôle des transactions, une réalité. fortement recommandé de vérifier cela!

Answer 2

Cette question revient souvent - voir cette recherche ENTRAÎNER

.

Il n'y a pas de bonne réponse -. Cela dépend des circonstances

Personnellement - garder un chemin de fichier dans la base de données et le fichier sur le système de fichiers. Chacun a ses propres forces. Vous pouvez sauvegarder des fichiers ainsi que des bases de données. Ceci est aussi la conclusion de ce type , qui gère téraoctets des données.

Answer 3

La réplication des fichiers statiques, en particulier à travers un certain nombre de serveurs, peut être difficile à gérer. Il est vraiment à un compromis entre la gestion, le suivi et le débogage des problèmes de réplication par rapport à la taille de la base de données et de la charge.

Je pense que je choisirais probablement l'approche de base de données, et si la charge est devenue une question regarde mettre en place une sorte de couche de cache autour des appels d'images.

Suggestions pour stocker un chemin dans la db manque le vrai problème, qui est reproduit ce sur plusieurs machines.

Answer 4

Vos préoccupations se décomposent en deux camps. Les préoccupations suivantes favorisent le stockage des documents dans la base de données:

• L'intégrité des données
• La réplication des données
• résolutions multiples
• Gestion et sauvegarde des données

Ces préoccupations (probablement) favorisent le stockage des documents sur le système de fichiers:

• Vitesse de base de données vs système de fichiers
• cariste de base de données vs système de fichiers

Alors, décider ce qui compte le plus et choisir en conséquence.

Answer 5

Eh bien, si vos deux besoins sont l'intégrité et la réplication, la réponse est sans aucun doute DB.

d'autres points de bien:

• Intégrité -. DB, qui est la raison pour laquelle il existe des bases de données par rapport aux systèmes de fichiers plats

• réplication -. Je ne sais pas si vous voulez dire la réplication d'image, mais si oui, alors il est évident DB que vous ne serez pas l'équilibrage de charge cela, sûrement

• résolutions multiples peuvent être effectuées à partir de l'image DB, mais cela ajoute des coûts de traitement. En outre, plus la résolution, plus la taille, plus l'attente du réseau. Plusieurs résolutions espace pour la vitesse de métiers.

• Vitesse - En fonction de l'accès aux images, il pourrait être négligeable. Si vous prenez des images sur un partage de fichiers, vous devrez attendre sur le réseau dans tous les cas et le réseau est à peu près toujours le goulot d'étranglement.

• Frais généraux - Franchement, cela dépend de votre définition des frais généraux et comment vous accédez aux images

.

• Gestion, DB, mains vers le bas. stockage Singulier = un souci de moins, et vous devriez toujours être en cours d'exécution des sauvegardes sur la base de données dans tous les cas. Les sauvegardes du système de fichiers sur plusieurs serveurs est coûteux à bien des égards.

Answer 6

Il y a des préoccupations légitimes de chaque côté du débat, il faut donc toujours donner à vos besoins. Comment beaucoup de données, le nombre d'images, la taille?

stockage Inline / BLOB

Upside : simplifie l'architecture et la mise en œuvre, simplifie la sauvegarde et la récupération ou à la migration du système; il suffit de faire une décharge, la sauvegarde, l'exportation (quel que soit le terme pour votre goût de la DB) et le déplacer vers la nouvelle base de données. Le contrôle de version / cohérence est assurée par la DB, donc permet la récupération à temps. Contrôle de sécurité / d'accès est également plus propre, car l'accès à un blob d'image est intrinsèque pour accéder à la ligne générale. Déplacement de l'image du DB et de laisser le serveur HTTP chercher vers le haut, tout en mieux pour l'évolutivité et la concurrence, peuvent avoir des problèmes avec assurer que les gens ne peuvent pas pirater les URL et demander des images qu'ils ne possèdent pas. Si vous les loger en dehors de la DB, assurez-vous que ce soit votre politique de sécurité couvre le contrôle d'accès des images entre utilisateurs. Soit votre authentification du serveur HTTP doit intégrer l'authentification globale du système, ou votre programme de serveur HTTP qui sert les images utilise une sorte de mécanisme de session pour assurer la requête HTTP est valide. Ceci est une préoccupation très importante dans les bases de données multi-locataires. Moins d'une préoccupation à usage unique, les systèmes à locataire unique, avec authentification simple.

Downside : Pour les bases de données vraiment très grandes, la sauvegarde et la récupération devient frustrant, voire problématique et coûteuse, parce que là où vous pouvez avoir un petit jeu de données de base sinon, vous pouvez avoir de Go ou To de des données d'image. Traiter tout comme une base de données cohérente est à la fois le bien du point de vue de l'intégrité, mais mauvais pour les sauvegardes sauf si vous utilisez DBMSes avec la sauvegarde à l'écoute de qualité de l'entreprise, l'entrepôt de données et de récupération (exemple des sauvegardes Oracle RMAN et laminage).

Il faut toujours considérer le temps de récupération dans tout système. Si vos besoins de stockage sont

Answer 7

En général, la persistance des données d'image dans le DB pourrait ne pas être aussi efficace que le FileSystem, dans la mesure où un CMS est concerné. À un moment donné il vous suffit probablement pour afficher l'image statique, à d'autres moments que vous voulez que l'image soit disponible à vos graphistes pour les mises à jour.

Considérons les frais généraux de traitement associé à la récupération de l'image à chaque fois que vous voulez travailler avec elle.

Quelques points pourquoi vous devriez considérer le FileSystem

1. Le navigateur fait tout le travail, et la mise en cache vous bénéficiez d'proxy d'images etc
2. Comme conséquence de ce qui précède, vous obtenez d'utiliser facilement Content Delivery Networks
(CDN)
3. La réplication des données d'image est facile avec des outils comme rsync etc
4. Traitement (à savoir CPU) de temps est considérablement optimisé

Answer 8

En supposant que vous êtes dans un environnement de fenêtres il n'y a pas grande raison d'utiliser le système de fichiers. Vous voudrez peut-être prudent de stocker les images dans les tableaux afin d'éviter des ruptures de page indésirables, mais c'est un tweak de performance, pas un énorme problème.

Downsides au système de fichiers

-Ne automatiquement répliquées

-Peut compliquer la réplication en ayant des emplacements physiques différents pour chaque instance

-Slow avec un très grand nombre de fichiers

Upside au système de fichiers

-Si vous stockez quelques fichiers très volumineux, il exécute un peu mieux.

Answer 9

Je voudrais;

1) Attribuer l'identificateur unique (GUID) à chaque image 2) Tag / Nom de l'image avec ce GUID 3) GUID de magasin dans le système d'exploitation (File System) 4) pointeur magasin Nom de fichier qualifié (FQN) dans la base de données.

Enregistrement d'images dans la base de données est trop coûteuse en termes de stockage et de maintenance. Le stockage que le pointeur FQN offrirait une meilleure solution. Vous pouvez également créer vérification de l'intégrité arrière-plan par des déclencheurs et des procédures stockées.

Answer 10

Je ne stocker des images dans la base de données pour une raison (ma réponse vient du serveur SQL):

Je ne veux pas des serveurs SQL cache de données par des images simples Peuplée pour le site Web. Je veux que le cache de données pour avoir réellement les données qu'il contient. Aussi, si vous avez une architecture à plusieurs niveaux est beaucoup plus facile de passer une URL d'une image d'un blob de données binaires. Où vous ne rencontrez des problèmes mais si vous voulez que certaines personnes de voir les images (sécurité).