Pour les fichiers partagés entre les instances j'utiliserais effectivement MongoDB. Dans mon cas j'ai surtout utilisé Amazon S3 dont j'apprécies toutes les fonctionnalités complémentaires et le service coûte très peu cher si le stockage se calcule en Go plutôt qu'en To. Si tu n'est pas hébergé chez AWS, la latence additionnelle peut être compensé par un cache local à l'application.
Afin de se simplifier la vie avec le cache, dans la plupart de scénarios, le fichier était stocké avec comme nom/clé son md5 ce qui simplifie grandement l'implémentation du cache local. Les métas data du fichier étant, si besoin, dans MySQL. Dans la plupart des cas il est simple de déterminer le type de fichier en lisant les 1ers octets aussi (si on a pas besoin de récupérer le nom original par exemple mais juste de renvoyer les bon headers).
[^] # Re: Mon avis
Posté par RB . En réponse au message Architecture tolérance de panne en LAMP : des conseils ?. Évalué à 1.
Pour les fichiers partagés entre les instances j'utiliserais effectivement MongoDB. Dans mon cas j'ai surtout utilisé Amazon S3 dont j'apprécies toutes les fonctionnalités complémentaires et le service coûte très peu cher si le stockage se calcule en Go plutôt qu'en To. Si tu n'est pas hébergé chez AWS, la latence additionnelle peut être compensé par un cache local à l'application.
Afin de se simplifier la vie avec le cache, dans la plupart de scénarios, le fichier était stocké avec comme nom/clé son md5 ce qui simplifie grandement l'implémentation du cache local. Les métas data du fichier étant, si besoin, dans MySQL. Dans la plupart des cas il est simple de déterminer le type de fichier en lisant les 1ers octets aussi (si on a pas besoin de récupérer le nom original par exemple mais juste de renvoyer les bon headers).