Jeg snakker her om personlige erfaringer, og ikke test eller lign. Det forringer performance, når du gemmer filer (tekst, billeder osv) i databasen, fremfor bare at lägge et navn ind. Desuden, skal du gemme 3 mb filer, så kommer du hurtigt op i den limit som mange webhoteller har på deres databaser.
limit er heller ikke noget problem, det er på egen server.
Synes godt om
Slettet bruger
16. juli 2006 - 08:30#6
Der findes gode argumenter for at gemme "filer" i en database, men de er af gode grunde meget sjældent orienteret mod performance.
Et af argumenterne har at gøre med driften af systemerne, hvis du har alle applikationsdata i en database så skal du alene tage en backup af databasen for at sikre alle applikationsdata, hvorimod det er nødvendigt at tage en backup af såvel en database og et filsystem, hvis de to ting er adskilt. Tages backup under drift af systemet vil der også være en risiko for at den samlede backup ikke er konsistent, hvis "filer" både kan tilføjes og slettes.
Et andet argument kan være udvikling og vedligeholdelse af systemet, det er væsentligt letterer kun at skulle til en datakilde end at skulle hente referencer og derefter åbne filer. Ligeledes er der nogle ting omkring konsistens der skal håndteres, hvis filen ikke kan skrives må referencen ikke indsættes i databasen og omvendt.
Performance mæssigt vil der være nogle få scenarier hvor det at gemme "filer" i en database er en fordel, men langt de fleste scenarier har ikke gavn af det fra en performance orienteret vinkel.
En af de typiske scenarier, som man ser i web applikationer er at billeder til sitet placeres i en database. Fra et performance mæssigt synspunkt er det rent i skoven fordi hvert billeder kræver et dynamisk request til web serveren, hvor den skal hente billedet ud af databasen og sende det (streame) det til klienten. Transporten i denne process er billeder fra databaseserver til applikationsserver til klient. Hvis billederne derimod holdes på web serveren i et katalog som web serveren kan læse så kan billedet leveres som et statisk request.
Humlen er bare at verden ikke er sort hvid og performance for hvilken pris - det er en afvejning af hvormeget traffik et site skal tage kontra hvad de øvrige omkostninger ved at drive løsningen er.
Men jeg har lige gentaget den (i lettere udvidet form) med MySQL.
(med ASP.NET)
File (1 threads): 1,9 get per second File (10 threads): 2,1 get per second File with web app cache (1 threads): 16,8 get per second File with web app cache (10 threads): 17,8 get per second File directly by web server (1 threads): 17,6 get per second File directly by web server (10 threads): 20,1 get per second Database (1 threads): 10,7 get per second Database (10 threads): 11,6 get per second Database with web app cache (1 threads): 17,1 get per second Database with web app cache (10 threads): 19,5 get per second
Jeg kan ikke se det store performance tab ved at bruge database.
(hvis nogen er interesseret kan jeg godt poste hele koden)
Brug af script (d.v.s. ikke filer servet direkte af web server) giver mulighed for beskyttelse af indholdet.
Brug af database giver nemmere administration.
Jeg vil sige at man ligger billeder (og lyd) i database indtil man har grund til at tro at app vil køre bedre med filer.
Ovenstående test er med 25 KB filer.
Jeg lavede også en test med 2.5 MB på et tidspunkt i processen. Der var heller ikke nogen stor forskel på filer og database der. Faktisk var alle løsninger lige hurtige. Eller måske skal jeg sige lige langsomme.
Men imidlertid er 2.5 MB (og dermed også 3 MB) for store. Jeg måtte ind og ændre i MySQL konfigurationen for overhovedet at få applikationen til at fungere.
Så jeg vil ikke smide 3 MB filer i MySQL alligevel.
jeg er allerede langt i udviklingsprocessen, og har allerede lavet hvad der skal til for at det kører, og indtil videre kører det upåklageligt... Også med filer på +3mb Men nu må jeg se hvordan det kører fremover... Men i skal have tak for jeres hjælp! Smid et par svar, og få nogle point...
arne_v: Lige et ekstraspørgsmål der er opstået: Hvordan fik du konfigureret MySQL til at klare filer af den størrelse? For jeg er flyttet til en anden server, hvor mysql ikke tillader filer af den størrelse, men jeg kan ikke finde ud af hvor konfigurationen skal ske...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.