39 votes

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

Nous avons un projet à venir où nous allons construire ensemble backend CMS système d'alimentation de l'ensemble de notre extranet et intranet avec un seul paquet. La question que j'ai essayé de trouver une réponse à est ce qui est mieux: le stockage des images dans la base de données (SQL Server 2005) afin que nous puissions avoir de l'intégrité, de réplication unique plan, etc OU de stockage sur le système de fichiers?

Un problème que nous avons est que nous avons plusieurs serveurs d'équilibrage de charge qui nécessitent d'avoir les mêmes données à tout moment. À compter de maintenant, nous avons la réplication SQL, en prenant soin de cela, mais de réplication de fichiers semble être un peu plus dur. Une autre préoccupation que nous avons, c'est que nous aimerions avoir de multiples résolutions de la même image, nous ne sommes pas sûr si la création et le stockage de chaque version du système de fichiers, le mieux serait de ou peut-être de façon dynamique en tirant et la création de la résolution de l'image que l'on aimerait à la demande.

Nos préoccupations sont les suivantes:

  • L'intégrité des données
  • La réplication de données
  • Plusieurs résolutions
  • La vitesse de base de données vs système de fichiers
  • Les frais généraux de la charge de base de données vs système de fichiers
  • La gestion des données et de sauvegarde

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

57voto

marc_s Points 321990

Il y avait un beau document de recherche publié par Microsoft Research appelé À Goutte ou de ne pas Blob où ils ont regardé toutes sortes de variables et les impacts.

Leur découverte à la fin:

  • jusqu'à 256 KO de taille, les blobs sont stockées 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 les deux, c'est un tirage au sort

Depuis que le livre a été publié, SQL Server 2008 a également ajouté l'attribut FILESTREAM qui permet de stocker des choses dans le système de fichiers, mais sous le contrôle de transaction, une réalité. Hautement recommandé de vérifier ça!

6voto

Oded Points 271275

Cette question revient souvent - voir cette SORTE de résultat de recherche.

Il n'y a pas une seule bonne réponse - cela dépend des circonstances.

Personnellement, garder le chemin d'un fichier dans la base de données et les fichiers du système de fichiers. Chacun a ses propres points forts. Vous pouvez sauvegarder les fichiers, les bases de données. C'est également la conclusion de ce mec, qui gère to de données.

5voto

chris Points 10694

La réplication de fichiers statiques, en particulier à travers un certain nombre de serveurs, peut être difficile à gérer. Il s'agit vraiment de trouver un compromis entre la gestion, la surveillance et le débogage des problèmes de réplication vs la taille de la base et de la charge.

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

Suggestions pour stocker un chemin d'accès dans la base de données sont manquantes, le vrai problème, qui est de reproduire ce sur plusieurs machines.

3voto

APC Points 69630

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

  • Intégrité des données
  • Réplication de données
  • Plusieurs résolutions
  • Gestion des données et sauvegarde

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

  • Vitesse de la base de données par rapport au système de fichiers
  • Charge supplémentaire de la base de données par rapport au système de fichiers

Alors, décidez ce qui compte le plus et choisissez en conséquence.

2voto

Kyle Rozendo Points 15606

Eh bien, si vos deux premiers besoins de l'intégrité et de la réplication, alors la réponse est certainement DB.

Vous autres points, bien que l':

  • Intégrité - DB, c'est pourquoi les bases de données existent vs plat des systèmes de fichiers.

  • La réplication ne sais Pas si vous l'image moyenne de la réplication, mais si oui, alors évidemment DB que vous ne serez pas d'équilibrage de charge ce, sûrement.

  • Plusieurs solutions peuvent être effectuées à partir de la DB image, mais cela ajoute les coûts de traitement. Aussi, plus la résolution est élevée, plus la taille, plus le réseau d'attente. De multiples résolutions des métiers de l'espace pour la vitesse.

  • La vitesse en Fonction de l'accès aux images, il peut être négligeable. Si vous prenez des images à travers un partage de fichiers, vous devrez attendre sur le réseau dans tous les cas et que le réseau est à peu près toujours le goulot d'étranglement.

  • Frais généraux - Franchement, cela dépend de votre définition de la surcharge et de la façon dont vous accédez aux images.

  • De la gestion, de la DB, les mains vers le bas. Singulier de stockage = Un souci de moins, et vous devriez toujours être en cours d'exécution des sauvegardes de la base de données dans tous les cas. Système de fichiers sauvegardes sur de multiples serveurs est onéreuse à de nombreux égards.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X