sql >> Database teknologi >  >> RDS >> Mysql

Langsomhed fundet, når base 64-billede vælger og koder fra databasen

Som en tommelfingerregel skal du ikke gemme filer i databasen.

Hvad har mysql-manualen at sige om det? http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-optimization-tips.html

Med webservere, gem billeder og andre binære aktiver som filer, med stinavnet gemt i databasen i stedet for selve filen. De fleste webservere er bedre til at cache filer end databaseindhold, sousing-filer er generelt hurtigere. (Selvom du selv skal håndtere sikkerhedskopier og lagringsproblemer i dette tilfælde.)

Gem slet ikke base4-kodede filer i en database

Virker fint, men tager så meget tid, som jeg havde forventet. Derfor er billedet 33 % større og ser fuldstændigt ud.

Som du opdagede, opbrugt uønsket overhead i kodning/afkodning + ekstra plads, hvilket også betyder ekstra dataoverførsel frem og tilbage.

Som @mike-m har nævnt. Base64-kodning er ikke en komprimeringsmetode. Hvorfor bruge Base64-kodning besvares også af et link, som @mike-m postede Hvad bruges base 64-kodning til?

Kort sagt er der intet at vinde og meget at tabe ved base64-kodning af billeder, før de gemmes på filsystemet, hvad enten det er S3 eller andet.

Hvad med Gzip eller andre former for komprimering uden at involvere base64. Igen er svaret, at der ikke er noget at vinde og meget at tabe. For eksempel har jeg lige gzippet et 1941980 JPEG-billede og gemt 4000 bytes, hvilket er en besparelse på 0,2 %.

Årsagen er, at billeder allerede er i komprimerede formater. De kan ikke komprimeres yderligere.

Når du gemmer billeder uden komprimering, kan de leveres direkte til browsere og andre klienter, og de kan cachelagres. Hvis de er komprimerede (eller base64-kodede), skal de dekomprimeres af din app.

Moderne browsere er i stand til at vise base64-billeder indlejret i HTML, men så kan de ikke cachelagres, og dataene er omkring 30 % større, end de behøver at være.

Er dette en undtagelse fra normen?

Brugeren kan poste data og billeder, og alle er sikre.

Jeg går ud fra, at du mener, at en bruger kan downloade billeder, der tilhører ham eller deles med ham. Dette kan nemt opnås ved at gemme filerne fra webområdet i filsystemet og kun gemme stien i databasen. Derefter sendes filen til klienten (efter at have udført de nødvendige kontroller) med fpassthru a>

Hvad med, når jeg vokser til 100.000 brugere

Hvordan de tager sig af billedfilen. I ydelsesproblemet, når store brugere er involveret, synes jeg, jeg har brug for 100000 mapper til 100000 brugere og deres undermappe. Når mange brugere gennemser den samme rodmappe, hvordan behandler filsystemet hver unik mappe.

Brug et CDN eller brug et filsystem, der er specielt egnet til dette, såsom BTRFS

Databasen har gode søgefaciliteter, god trådsikker forbindelse, god sessionsstyring. Er dette scenarie ændret, når store operationer involveret

Ja bestemt. Brug det fuldt ud ved at gemme alle oplysninger om filen og dens filsti i databasen. Gem derefter selve filen i filsystemet. Du får det bedste fra begge verdener.



  1. MariaDB CURRENT_DATE() Forklaret

  2. ASCII() eksempler – MySQL

  3. PgBouncer 1.7 - "Farver varierer efter opstandelse"

  4. Hvordan genererer man en GUID i Oracle?