En règle générale, n'enregistrez pas de fichiers dans la base de données.
Que dit le manuel mysql à ce sujet ? http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-optimization-tips.html
Avec les serveurs Web, stockez les images et autres actifs binaires sous forme de fichiers, avec le nom du chemin stocké dans la base de données plutôt que le fichier lui-même. La plupart des serveurs Web sont meilleurs pour mettre en cache les fichiers que le contenu de la base de données, l'extraction des fichiers est généralement plus rapide. (Bien que vous deviez gérer vous-même les sauvegardes et les problèmes de stockage dans ce cas.)
N'enregistrez pas du tout les fichiers encodés en base4 dans une base de données
Fonctionne bien, mais prend tellement de temps que prévu. Par conséquent, l'image est 33 % plus grande et semble totalement volumineuse.
Comme vous l'avez découvert, surcharge indésirable lors de l'encodage/décodage + espace supplémentaire utilisé, ce qui signifie également un transfert de données supplémentaire dans les deux sens.
Comme @mike-m l'a mentionné. L'encodage Base64 n'est pas une méthode de compression. Pourquoi utiliser l'encodage Base64 est également répondu par un lien que @mike-m a posté À quoi sert l'encodage base 64 ?.
En bref, il n'y a rien à gagner et beaucoup à perdre en encodant les images en base64 avant de les stocker sur le système de fichiers, qu'il soit S3 ou autre.
Qu'en est-il de Gzip ou d'autres formes de compression sans impliquer base64. Là encore, la réponse est qu'il n'y a rien à gagner et beaucoup à perdre. Par exemple, je viens de compresser une image JPEG 1941980 et j'ai enregistré 4000 octets, soit 0,2 % d'économie.
La raison en est que les images sont déjà dans des formats compressés. Ils ne peuvent plus être compressés.
Lorsque vous stockez des images sans compression, elles peuvent être livrées directement aux navigateurs et autres clients et elles peuvent être mises en cache. S'ils sont compressés (ou encodés en base64), ils doivent être décompressés par votre application.
Les navigateurs modernes sont capables d'afficher des images base64 intégrées au HTML, mais elles ne peuvent pas être mises en cache et les données sont environ 30 % plus volumineuses que nécessaire.
Est-ce une exception à la norme ?
L'utilisateur peut y publier des données et des images et tout est sécurisé.
Je suppose que vous voulez dire qu'un utilisateur peut télécharger des images qui lui appartiennent ou qu'il partage avec lui. Cela peut être facilement réalisé en enregistrant les fichiers hors de l'espace Web dans le système de fichiers et en enregistrant uniquement le chemin dans la base de données. Ensuite, le fichier est envoyé au client (après avoir effectué les vérifications requises) avec fpassthru
Qu'en est-il lorsque j'atteindrai 100 000 utilisateurs ?
Comment ils prennent soin du fichier d'images. En ce qui concerne les performances, lorsqu'un grand utilisateur est impliqué, il me semble que j'ai besoin de 100 000 dossiers pour 100 000 utilisateurs et de leur sous-dossier. Lorsqu'un grand nombre d'utilisateurs parcourent le même dossier racine, comment le système de fichiers traite chaque dossier unique.
Utilisez un CDN ou utilisez un système de fichiers spécialement adapté à cela, comme BTRFS
La base de données a une bonne fonction de recherche, une bonne connexion thread-safe, une bonne gestion de session. Ce scénario est-il modifié lorsqu'une grande opération est impliquée
Oui en effet. Utilisez-le au maximum en enregistrant toutes les informations sur le fichier et son chemin d'accès dans la base de données. Enregistrez ensuite le fichier lui-même dans le système de fichiers. Vous obtenez le meilleur des deux mondes.
