MySQL - Base64 vs BLOB
Par souci de simplicité, supposons que je développe une application mobile comme Instagram. Les utilisateurs peuvent télécharger des images à partir du serveur et télécharger leurs propres images. Actuellement, le serveur stocke toutes les images (en réalité, seulement de petites vignettes) dans une base de données MySQL en tant que BLOB. Il semble que la façon la plus courante de transférer des images soit d'utiliser l'encodage Base64, ce qui me laisse deux options:
- Le serveur stocke toutes les images sous forme de BLOB. Pour télécharger une image, le client l'encode en chaîne Base64, puis l'envoie au serveur. Le serveur décode l'image BACK au format binaire et la stocke comme BLOB dans la base de données. Lorsque le client demande une image, le serveur réencode l'image en tant que chaîne Base64 et l'envoie au client, qui la décode ensuite en binaire pour affichage.
- Le serveur stocke toutes les images sous forme de chaînes Base64. Pour télécharger une image, le client l'encode dans la chaîne Base64 et l'envoie au serveur. Le serveur ne fait ni encodage ni décodage, mais stocke simplement la chaîne dans la base de données. Lorsque le client demande une image, la chaîne Base64 est renvoyée au client, qui la décode ensuite pour l'affichage.
De toute évidence, l'option n ° 1 nécessite beaucoup plus de traitement sur le serveur, car les images doivent être codées/décodées à chaque demande. Cela me fait pencher vers l'option # 2, mais certaines recherches ont suggéré que le stockage de la chaîne Base64 dans MySQL est beaucoup moins efficace que le stockage de l'image directement en BLOB et est généralement déconseillé.
Je ne suis certainement pas la première personne à rencontrer cette situation, alors quelqu'un a-t-il des suggestions sur la meilleure façon de faire fonctionner cela?
JSON suppose utf8, est donc incompatible avec les images à moins qu'elles ne soient encodées d'une manière ou d'une autre.
Base64 est presque exactement 8/6 fois plus volumineux que binaire (BLOB). On pourrait dire qu'il est facilement abordable. 3000 bytes devient environ 4000 bytes.
Tout le monde devrait pouvoir accepter des codes arbitraires à 8 bits, mais pas tout le monde. La Base-64 peut être le compromis le plus simple et global pour ne pas avoir à traiter des données 8 bits.
Comme ils sont "petits", je les stocke dans une table, pas dans un fichier. Je voudrais cependant les stocker dans une table séparée et JOIN par un id approprié lorsque vous en avez besoin. Cela permet aux requêtes qui n'ont pas besoin de l'image de s'exécuter plus rapidement car elles ne dépassent pas les BLOB.
Techniquement, TEXT CHARACTER SET ascii COLLATE ascii_bin ferait l'affaire, mais BLOB indique plus clairement qu'il n'y a pas vraiment de texte utilisable dans la colonne.
Pourquoi voudriez-vous encoder en base64 les images sur le fil? Je pense que vous partez d'une mauvaise hypothèse.
Je ne vois pas pourquoi le serveur DB ne devrait pas toujours conserver les données binaires dans leur forme native. Utilisez donc un BLOB. (Mais même si vous avez stocké les données dans la chaîne Base64, vous n'avez pas à vous soucier des performances d'encodage/décodage car l'impact de l'IO sera plus important.)
Je ne comprends pas pourquoi le client doit envoyer les données en base64. Pourquoi ne pas simplement le "diffuser" en utilisant un simple appel HTTP?