Come regola pratica, non salvare i file nel database.
Cosa dice il manuale di mysql a riguardo? http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-optimization-tips.html
Con i server Web, archivia immagini e altre risorse binarie come file, con il nome del percorso memorizzato nel database anziché nel file stesso. La maggior parte dei server Web sono più bravi a memorizzare nella cache i file rispetto ai contenuti del database, in genere sousing file è più veloce. (Anche se in questo caso devi gestire i backup e i problemi di archiviazione.)
Non salvare affatto i file con codifica base4 in un database
Funziona bene, ma ci vuole così tanto tempo che mi aspettavo. Quindi, l'immagine è più grande del 33% e sembra completamente gonfia.
Come hai scoperto, sovraccarico indesiderato nella codifica/decodifica + spazio extra utilizzato, il che significa anche trasferimento di dati extra avanti e indietro.
Come ha detto @mike-m. La codifica Base64 non è un metodo di compressione. Perché usare la codifica Base64 risponde anche da un link pubblicato da @mike-m A cosa serve la codifica Base 64?.
In breve, non c'è niente da guadagnare e molto da perdere codificando le immagini in base64 prima di salvarle sul file system, sia esso S3 o altro.
Che dire di Gzip o altre forme di compressione senza coinvolgere base64. Ancora una volta la risposta è che non c'è niente da guadagnare e molto da perdere. Ad esempio, ho appena compresso un'immagine JPEG 1941980 e ho salvato 4000 byte con un risparmio dello 0,2%.
Il motivo è che le immagini sono già in formati compressi. Non possono essere ulteriormente compressi.
Quando si archiviano immagini senza compressione, possono essere inviate direttamente ai browser e ad altri client e possono essere memorizzate nella cache. Se sono compressi (o codificati in base64), devono essere decompressi dalla tua app.
I browser moderni sono in grado di visualizzare immagini Base64 incorporate nell'HTML, ma non possono essere memorizzate nella cache e i dati sono circa il 30% più grandi di quanto dovrebbero essere.
Si tratta di un'eccezione alla norma?
L'utente può postare lì dati e immagini e tutti sono al sicuro.
Presumo che intendi dire che un utente può scaricare immagini che gli appartengono o condivise con lui. Questo può essere ottenuto facilmente salvando i file dallo spazio web nel file system e salvando solo il percorso nel database. Quindi il file viene inviato al client (dopo aver eseguito i controlli richiesti) con fpassthru
Che ne dici di quando raggiungo i 100000 utenti
Come si prendono cura del file di immagini. Per quanto riguarda le prestazioni, quando è coinvolto un utente grande, mi sembra che ho bisogno di 100000 cartelle per 100000 utenti e la loro sottocartella. Quando una grande quantità di utenti esplora la stessa cartella radice, come il file system elabora ciascuna cartella univoca.
Usa una CDN o usa un file system particolarmente adatto a questo come BTRFS
Il database ha una buona funzione di ricerca, una buona connessione thread-safe, una buona gestione delle sessioni. Questo scenario è cambiato quando è coinvolta un'operazione di grandi dimensioni?
Si Certamente. Usalo al meglio salvando tutte le informazioni sul file e il suo percorso nel database. Quindi salva il file stesso nel file system. Ottieni il meglio da entrambi i mondi.
