Като практическо правило, не записвайте файлове в базата данни.
Какво казва ръководството на mysql за това? http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-optimization-tips.html
С уеб сървъри съхранявайте изображения и други двоични активи като файлове, като името на пътя се съхранява в базата данни, а не в самия файл. Повечето уеб сървъри са по-добри в кеширането на файлове от съдържанието на базата данни, използването на файлове като цяло е по-бързо. (Въпреки че в този случай трябва сами да се справите с проблемите с архивирането и съхранението.)
Изобщо не запазвайте кодирани base4 файлове в база данни
Работи добре, но отнема толкова много време, което очаквах. Следователно изображението е с 33% по-голям размер и изглежда напълно издуто.
Както открихте, нежелани разходи при кодиране/декодиране + изразходвано допълнително пространство, което също означава допълнителен трансфер на данни напред и назад.
Както @mike-m спомена. Base64 кодирането не е метод за компресиране. Защо да използвате кодиране Base64, отговаря и връзка, която @mike-m публикува За какво се използва кодирането на base64?.
Накратко, няма какво да спечелите и много да загубите чрез кодиране на изображения с base64, преди да ги съхраните във файловата система, било то S3 или друго.
Какво ще кажете за Gzip или други форми на компресия без участието на base64. Отново отговорът е, че няма какво да спечелите и много да загубите. Например аз току-що gzip 1941980 JPEG изображение и запазих 4000 байта, което е спестяване от 0,2%.
Причината е, че изображенията вече са в компресирани формати. Те не могат да бъдат компресирани повече.
Когато съхранявате изображения без компресия, те могат да се доставят директно на браузъри и други клиенти и да се кешират. Ако са компресирани (или кодирани в base64), те трябва да бъдат декомпресирани от приложението ви.
Съвременните браузъри могат да показват base64 изображения, вградени в HTML, но след това те не могат да бъдат кеширани и данните са с около 30% по-големи, отколкото трябва да бъдат.
Това изключение от нормата ли е?
Потребителят може да публикува там данни и изображение и всички са защитени.
Предполагам, че имате предвид, че потребителят може да изтегля изображения, които му принадлежат или споделени с него. Това може лесно да се постигне чрез запазване на файловете извън уеб пространството във файловата система и запазване само на пътя в базата данни. След това файлът се изпраща на клиента (след извършване на необходимите проверки) с fpassthru
Ами когато нарасна до 100 000 потребители
Как се грижат за файла с изображения. При проблем с производителността, когато участва голям потребител, ми се струва, че имам нужда от 100 000 папка за 100 000 потребители и тяхната подпапка. Когато голямо количество потребители преглеждат една и съща главна папка, как файловата система обработва всяка уникална папка.
Използвайте CDN или файлова система, която е специално подходяща за това, като BTRFS
Базата данни има добро средство за търсене, добра връзка, безопасна за нишки, добро управление на сесиите. Променя ли се този сценарий при голяма операция
Да, именно. Използвайте го максимално, като запазите цялата информация за файла и неговия път в базата данни. След това запазете самия файл във файловата система. Получавате най-доброто от двата свята.
