Servir des images hors du serveur SQL, système de fichiers, S3, etc.
Mon application (classic asp yay!) Contient environ 2,1 millions d’images @ 25 Go, ce qui ne représente que 90 jours de données et j’aimerais 365 au minimum. Je dois les maîtriser et je considère toutes les options. Que pensez-vous des avantages et des inconvénients des pratiques suivantes:
- Avantages de SQL Server: Facile à sauvegarder Inconvénients: performances?
- Avantages du système de fichiers: inconvénients: redondance, la sauvegarde est lente (nous recherchons actuellement des sauvegardes synthétiques complètes à la place, ce qui pourrait l'améliorer)
- S3, etc. Avantages: La bande passante est transférée de mon centre de données vers Amazon, stockage pratiquement illimité. Inconvénients: Coût, l'analyse des coûts est délicate (estimer 80% de ma bande passante sont des images pour les objectifs de retour sur investissement), Difficile/coûteux à changer de fournisseur de services si cela devenait nécessaire
Quelqu'un d'autre a-t-il relevé le défi des millions d'images et comment l'avez-vous résolu?
Nous n'avons pas des millions d'images, mais des centaines de milliers, et nous utilisons l'approche hybride: mysql pour les métadonnées, les images stockées sur le disque local pour la sauvegarde et transférées vers Amazon s3 où elles sont servies aux utilisateurs. Nous n'avons eu aucun problème avec Amazon et la disponibilité. Le passage à Cloudfront fait partie de 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
Je voudrais aller avec les métadonnées dans le serveur SQL et les fichiers sur le système de fichiers (ou S3 ou Cloudfront). Mais la meilleure réponse dépend d’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 avez-vous besoin qu'elles soient contrôlées par un accès? Si ce dernier cas, une solution de base de données est préférable - servez-vous la plupart du temps un petit nombre d’images (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 - il s'agit simplement de beaucoup de données. Avant de m'engager dans cette solution, j'aimerais trouver une bonne étude de cas sur la sauvegarde des blobs dans SQL Server. (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 )
Ignorez les personnes qui disent " ne stockez pas les images/données binaires dans la base de données ", car elles basent leurs réponses sur des informations anciennes (en supposant que vous le fassiez). stocker les données dans une colonne de type VarBinary). Les problèmes de performances liés à l'utilisation de SQL Server pour stocker des images peuvent désormais être atténués à l'aide du type de données FILESTREAM dans SQL Server 2008. Le type de données FILESTREAM vous permet essentiellement de combiner la facilité de stockage des données dans la base de données avec les performances que vous obtenez en servant des fichiers à partir d’un magasin de fichiers NTFS.
Pour citer SQL Mag :
"La nouvelle prise en charge de FILESTREAM de SQL Server 2008 associe l’avantage d’accéder aux LOB directement à partir du 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 .
Si vous décidez de les stocker dans le système de fichiers, vous voudrez peut-être lire cette question ServerFault pour connaître les choses à faire et à ne pas faire: Stocker un million d'images dans le système de fichiers .
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 diffusion de contenu d'Amazon. Je ne voudrais pas utiliser 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, tout s’arrêtera brutalement.
SQL pour moi ne serait pas une option pour un système comme celui-ci. Non seulement vous serez facturé pour le transfert de bande passante, mais vous serez facturé pour le traitement de la requête. Cela dépendra beaucoup de l'hébergement, mais je suppose que vous utilisez un serveur dédié ou au moins un vps sur lequel vous serez facturé. pour les cycles. Ensuite, tout votre site sera ralenti s'il utilise la même base de données que le serveur d'images. Sinon, vous ajoutez toute cette complexité à devoir gérer deux connexions de base de données.
Les bases de données sont conçues pour les données transactionnelles/cohérence et 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 règle générale, il n'est pas nécessaire de les conserver sur le plan transactionnel avec d'autres données et une base de données ne vous apportera aucun avantage réel. Le contenu du texte peut être une question différente.
Tant que vous n'avez pas de problème avec le concept de quelqu'un tirant votre fichier directement s'il a l'URL du fichier, un système de fichiers est bon. Si vous utilisiez quelque chose comme une bibliothèque de photos, où vous vous attendez à charger avant que les gens téléchargent le fichier, 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 seulement, et l'application gère des URL multiples ou temporaires menant à la même image. Cela pourrait toujours être géré par l'application et un système de fichiers, mais vous finissez par servir le média via l'application plutôt que par un téléchargement de fichier direct (ce qui exclurait la plupart des avantages de S3) et il y a moins de différence entre la base de données et le système de fichiers .