Servir des images à partir du serveur SQL par rapport au système de fichiers par rapport à S3, etc.

Mon application (classique asp yay!) A environ 2,1 millions d'images @ 25 Go et cela ne représente que 90 jours de données et j'aimerais en faire 365 au minimum. J'ai besoin de les contrôler et j'envisage toutes les options. Que pensez-vous des avantages et des inconvénients des pratiques suivantes:

• SQL Server Pour: Facile à sauvegarder Contre: Performances?
• Avantages du système de fichiers: Inconvénients de la vitesse: redondance, la sauvegarde est lente (recherche actuellement de faire des sauvegardes complètes synthétiques à la place, ce qui pourrait améliorer cela)
• S3 et autres avantages: la bande passante est déplacée de mon centre de données vers Amazon, un stockage pratiquement illimité. Inconvénients: le coût, l'analyse des coûts est délicat (estimer que 80% de ma bande passante sont des images à des fins de retour sur investissement), difficile / coûteux pour les fournisseurs de services de swtich si cela devenait nécessaire

Quelqu'un d'autre a-t-il relevé le défi de plusieurs millions d'images et comment l'avez-vous relevé?

Nous n'avons pas des millions d'images, mais nous en avons des centaines de milliers, et nous utilisons l'approche hybride - mysql pour les métadonnées, images stockées sur le disque local pour la sauvegarde et poussées vers Amazon s3 où elles sont servies aux utilisateurs. Nous n'avons eu aucun problème avec Amazon et la disponibilité. Passer au cloudfront est dans nos plans, il suffit de trouver le temps.

Cette discussion peut vous être utile dans votre décision:
http://ask.metafilter.com/59635/Millions-of-images

J'irais avec des métadonnées dans le serveur SQL et des fichiers sur le système de fichiers (ou s3 ou cloudfront). Mais la meilleure réponse dépend de certains autres modèles d'utilisation:

• les images changent souvent
• pouvez-vous servir les images directement à partir du système de fichiers (c'est-à-dire img src="...") ou en avez-vous besoin pour que l'accès soit contrôlé. Si ce dernier, alors une solution de base de données est la meilleure
• diffusez-vous un petit nombre d'images la plupart du temps (les 10% les plus récents) ou la distribution est-elle relativement répandue?

Les sauvegardes de millions d'images vont être compliquées, peu importe la façon dont vous les organisez - c'est juste beaucoup de données. Je voudrais trouver une bonne étude de cas sur la sauvegarde des objets blob dans SQL Server avant de m'engager dans cette solution. (Voici un article qui pourrait être utile: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm )

Si vous décidez de les stocker dans le système de fichiers, vous voudrez peut-être lire cette question de ServerFault pour certaines choses à faire et à ne pas faire: Stocker un million d'images dans le système de fichiers .

Ignorez les personnes qui disent « Ne stockez pas d'images / de données binaires dans la base de données » car elles basent leurs réponses sur d'anciennes informations (en supposant que vous stockerez les données dans une colonne de type VarBinary). Les problèmes de performances à l'aide de SQL Server pour stocker des images peuvent désormais être atténués en utilisant le type de données FILESTREAM dans SQL Server 2008. En substance, le type de données FILESTREAM vous permet de combiner la facilité de stockage des données dans la base de données avec les performances que vous obtenez en servant les fichiers d'un magasin de fichiers NTFS.

Pour citer SQL Mag :

"La nouvelle prise en charge FILESTREAM de SQL Server 2008 combine l'avantage d'accéder directement aux LOB depuis le système de fichiers NTFS avec l'intégrité référentielle et la facilité d'accès offertes par le moteur de base de données relationnelle SQL Server."

Pour plus d'informations, lisez ce blog de Ravi S.Maniam sur MSDN .

Bien que je ne traite pas le défi des millions d'images, j'utiliserais Amazon CloudFront. Tous les fichiers sont stockés dans un compartiment S3 mais sont serveur via le système de livraison de contenu d'Amazon. Je n'utiliserais pas S3 seul.

Mon deuxième choix serait le système de fichiers. Simple et facile, le seul problème est que si tous ces fichiers se retrouvent dans un répertoire, le tout va planter, dur.

Pour moi, SQL ne serait pas une option pour un système comme celui-ci. Non seulement vous êtes facturé pour le transfert de bande passante, mais vous serez également facturé pour le traitement de la requête - cela dépendra très fortement de l'hébergement, mais je suppose que vous utilisez un serveur dédié ou au moins un vps où vous serez facturé pour les cycles. Ensuite, il ralentira l'ensemble de votre site s'il utilise la même base de données que le serveur d'images. Sinon, vous ajoutez toute cette complexité d'avoir à gérer deux connexions à la base de données.

Les bases de données sont conçues pour les données transactionnelles / la cohérence et la sécurité.

Les fichiers multimédias (images, audio, vidéo) ont tendance à être créés et peut-être supprimés, mais très rarement mis à jour. Donc, en général, il n'est pas nécessaire de les garder cohérents sur le plan des transactions avec d'autres données et une base de données ne vous procurera aucun avantage réel. Le contenu du texte est peut-être différent.

Tant que vous n'avez aucun problème avec le concept de quelqu'un tirant votre fichier directement s'il a l'URL du fichier, alors un système de fichiers est parfait. Si vous gérez quelque chose comme une photothèque, où vous vous attendez à charger avant que les gens téléchargent le fichier, alors c'est probablement une autre affaire. C'est-à-dire qu'une fois qu'un utilisateur a payé, il peut obtenir une URL spécifique à cet utilisateur ou valide pour une courte période, et l'application gère plusieurs URL temporaires ou pointant vers la même image. Cela pourrait toujours être géré par l'application et un système de fichiers, mais vous finissez par servir les médias via l'application plutôt que comme un téléchargement de fichier simple (ce qui exclurait principalement tous les avantages de S3) et il y a moins de différence entre la base de données et le système de fichiers .