Sla bestanden als vuistregel niet op in de database.
Wat zegt de mysql-handleiding erover? http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-optimization-tips.html
Sla bij webservers afbeeldingen en andere binaire middelen op als bestanden, waarbij de padnaam in de database is opgeslagen in plaats van het bestand zelf. MostWeb-servers zijn beter in het cachen van bestanden dan in database-inhoud, het gebruiken van bestanden is over het algemeen sneller. (Hoewel u in dit geval zelf de back-ups en opslagproblemen moet oplossen.)
Sla base4-gecodeerde bestanden helemaal niet op in een database
Werkt prima, maar kost zoveel tijd die ik had verwacht. Vandaar dat de afbeelding 33% groter is en er helemaal uitpuilt.
Zoals je hebt ontdekt, wordt ongewenste overhead bij het coderen/decoderen + extra ruimte verbruikt, wat ook extra gegevensoverdracht heen en weer betekent.
Zoals @mike-m al zei. Base64-codering is geen compressiemethode. Waarom Base64-codering gebruiken wordt ook beantwoord door een link die @mike-m heeft gepost. Waar wordt base 64-codering voor gebruikt?
Kortom, er is niets te winnen en veel te verliezen door afbeeldingen met base64 te coderen voordat ze op het bestandssysteem worden opgeslagen, of het nu S3 is of anderszins.
Hoe zit het met Gzip of andere vormen van compressie zonder base64. Nogmaals, het antwoord is dat er niets te winnen en veel te verliezen is. Ik heb bijvoorbeeld zojuist een JPEG-afbeelding uit 1941980 gezipt en 4000 bytes opgeslagen, wat een besparing van 0,2% is.
De reden is dat afbeeldingen al in gecomprimeerde formaten zijn. Ze kunnen niet verder worden gecomprimeerd.
Wanneer u afbeeldingen zonder compressie opslaat, kunnen ze rechtstreeks aan browsers en andere clients worden geleverd en kunnen ze in de cache worden opgeslagen. Als ze zijn gecomprimeerd (of gecodeerd met base64), moeten ze worden gedecomprimeerd door uw app.
Moderne browsers kunnen base64-afbeeldingen weergeven die zijn ingesloten in de HTML, maar ze kunnen dan niet in de cache worden opgeslagen en de gegevens zijn ongeveer 30% groter dan nodig is.
Is dit een uitzondering op de norm?
De gebruiker kan daar gegevens en afbeeldingen plaatsen en ze zijn allemaal veilig.
Ik neem aan dat je bedoelt dat een gebruiker afbeeldingen kan downloaden die van hem zijn of die met hem zijn gedeeld. Dit kan eenvoudig worden bereikt door de bestanden van de webruimte in het bestandssysteem op te slaan en alleen het pad in de database op te slaan. Vervolgens wordt het bestand naar de client gestuurd (na het uitvoeren van de vereiste controles) met fpassthru
En als ik doorgroei naar 100.000 gebruikers
Hoe ze zorgen voor het afbeeldingenbestand. Bij een prestatieprobleem, als grote gebruikers erbij betrokken zijn, lijkt het me dat ik een map van 100000 nodig heb voor 100000 gebruikers en hun submap. Wanneer een groot aantal gebruikers door dezelfde rootmap bladert, hoe het bestandssysteem elke unieke map verwerkt.
Gebruik een CDN of gebruik een bestandssysteem dat hier speciaal voor geschikt is, zoals BTRFS
Database heeft een goede zoekfunctie, een goede thread-veilige verbinding, goed sessiebeheer. Is dit scenario veranderd als het om een grote operatie gaat
Ja inderdaad. Gebruik het ten volle door alle informatie over het bestand en het bestandspad in de database op te slaan. Sla vervolgens het bestand zelf op in het bestandssysteem. U krijgt het beste van twee werelden.