J'ai, dans ma vie, fait de la distribution vidéo avec S3 (fichiers cloud Rackspace inclus) et MongoDB.
La plupart des gens, sans un second regard, opteraient pour S3, mais j'ai constaté que les deux avaient leurs inconvénients. L'un des gros problèmes est que S3 n'est pas un CDN, c'est en fait un stockage redondant dans une région spécifique qui n'est pas répliqué dans d'autres régions S3, cela signifie que vous devrez utiliser quelque chose comme cloudfront au-dessus de S3 pour cingler vos images à une sorte de cache si vous deviez obtenir une charge importante sur votre site.
S3 possède également d'autres fonctionnalités qui le rendent moins CDN et plus un entrepôt de stockage. Cela étant dit, pour les fichiers rarement consultés, S3 est extrêmement rapide.
Cette double couche crée bien sûr des complexités telles que la maintenance. Non seulement cela, mais un CDN fonctionnera sur les TTL et même si de nos jours de nombreux CDN ont des capacités de purge de bord, ils ne sont toujours pas un moyen sûr à 100 % de s'assurer que vos fichiers ne sont pas accessibles.
Donc, en raison de la configuration et des accès (accès possibles à des fichiers qui devraient également être supprimés), cela pourrait devenir assez coûteux assez rapidement.
C'est là que MongoDB pourrait gagner. MongoDB pourrait, selon votre scénario, être moins cher ici en raison du fait que vous pourriez utiliser tout un tas de micro-instances sur AWS pour conserver vos informations, en ajoutant une réservation d'instance ponctuelle à ces instances (très bon marché) et tout ce dont vous avez besoin est un gros disque sur une seule machine.
Enfer, vous pouvez même utiliser S3 pour stocker les images, puis MongoDB en remplacement du cloudfront.
Lorsque vous souhaitez cingler des images vers différentes régions, il vous suffit de créer quelques instances ponctuelles dans cette région cible et de demander à MongoDB de répliquer ses données. Vous pouvez également faire des trucs sympas avec la réplication pour vous assurer que seuls les fichiers fréquemment consultés de cette région sont placés dans cette région.
Donc, je ne jetterais pas MongoDB (ou même Cassandra), je ferais plutôt un test de ressources entre les deux.
Modifier
En tant que note supplémentaire sur la tarification de S3, si vous stockez vos fichiers en RR (redondance réduite), le prix diminue de moitié (environ), ce qui rend S3 très bon marché, cependant, vous avez toujours le problème que S3 n'est pas un CDN.
Autre modification
Étant donné que je n'ai vraiment continué qu'à partir de la réponse de @cirrus, je vais en fait réévaluer votre question à laquelle il a été répondu ci-dessus.
Par exemple, Youtube stocke en fait toutes ses images sur des ordinateurs uniques qui sont ensuite distribués, de sorte qu'ils peuvent facilement gérer 200 millions de vignettes et... eh bien... beaucoup de vues chaque jour facilement à partir du système de fichiers. Je pense donc que votre inquiétude concernant le système de fichiers est surestimée.
Quant à savoir quelle base de données est la meilleure... Je ne sais pas, cela dépend de vos tests.
Je veux dire que la réponse à votre problème dépend de votre scénario, de votre budget, de votre matériel et de vos ressources, c'est-à-dire que si vous avez des serveurs AWS, ce serait une réponse totalement différente de celle des serveurs dédiés en interne.
