mboost-dp1
Fordele og ulemper ved at gemme binær data i en database
Hvilke fordele og ulemper er der ved at gemme større mængder binær data i en database?
Sidder og overvejer om jeg skal udvide et photoshop-agtigt webmodul til ikke at gemme data i fysiske mapper på serveren, men i en database
Fordelen for mig er at al data følger med databasen og det er lidt lettere at holde styr på, pga. den måde jeg strukturerer det på
Samtidig åbner det også op for nogle lidt mere avancerede ting og sager, da jeg kan bruge scripts ved billedload så, da de let kan sendes via en asp-fil (ved godt de også kan det normalt, men det er lettere ved bare at hente det ud)
Men kan huske en tidligere kollega gloede mærkeligt på mig, da jeg overhovedet foreslog det at gemme billeder i en database, så gætter på der er nogle ulemper på hastighed eller sådan noget?
Sikkerhed er også vigtigt, ihvertfald at det ikke er mindre sikkert end at gemme det i mapper på serveren, der er tilgængelige via http
Sidder og overvejer om jeg skal udvide et photoshop-agtigt webmodul til ikke at gemme data i fysiske mapper på serveren, men i en database
Fordelen for mig er at al data følger med databasen og det er lidt lettere at holde styr på, pga. den måde jeg strukturerer det på
Samtidig åbner det også op for nogle lidt mere avancerede ting og sager, da jeg kan bruge scripts ved billedload så, da de let kan sendes via en asp-fil (ved godt de også kan det normalt, men det er lettere ved bare at hente det ud)
Men kan huske en tidligere kollega gloede mærkeligt på mig, da jeg overhovedet foreslog det at gemme billeder i en database, så gætter på der er nogle ulemper på hastighed eller sådan noget?
Sikkerhed er også vigtigt, ihvertfald at det ikke er mindre sikkert end at gemme det i mapper på serveren, der er tilgængelige via http
#1
Fordelene er primaert overskuelighed..
Ulemperne vil typisk vaere hastighed - men det kan sagtens lade sig goere..
Umiddelbart kan jeg ikke se det store hastighedsproblem i det, da dataene alligevel skal hentes fra disken af..
Nu har du blot introduceret endnu et lag af "management" som skal vide hvor de forskellige bytes ligger henne ;)
Jeg har selv overvejet det, men har ikke testet det netop fordi jeg var bange for problemer med hastigheden :)
Fordelene er primaert overskuelighed..
Ulemperne vil typisk vaere hastighed - men det kan sagtens lade sig goere..
Umiddelbart kan jeg ikke se det store hastighedsproblem i det, da dataene alligevel skal hentes fra disken af..
Nu har du blot introduceret endnu et lag af "management" som skal vide hvor de forskellige bytes ligger henne ;)
Jeg har selv overvejet det, men har ikke testet det netop fordi jeg var bange for problemer med hastigheden :)
Største ulempe: alle dele af systemet der skal bruge billederne skal have adgang til databasen. Fx hvis du en del vil lave noget FTP halløj, eller andet, så skal du selv lave en FTP-server der forstår din datakilde.
Generelt er det en fordel kun at gemme filen fysiske placering i databasen, og resten i en filstruktur (evt. lave den fysiske placering i en flad struktur, og lave mappestrukturen i databasen).
Rent administrationsmæssigt bliver det også en mere overkommelig opgave, da en daglig backup af databasen ikke fylder 2GB men 20MB...
Generelt er det en fordel kun at gemme filen fysiske placering i databasen, og resten i en filstruktur (evt. lave den fysiske placering i en flad struktur, og lave mappestrukturen i databasen).
Rent administrationsmæssigt bliver det også en mere overkommelig opgave, da en daglig backup af databasen ikke fylder 2GB men 20MB...
#2 det er også hastigheden jeg er mest bange for.. hvis jeg laver det, så skal det bruges i en større satsning, der ikke må lide under hastighedsproblemer
Jeg vil formentlig lave billeddatabasen som en helt seperat database, hvis det skulle have nogen effekt på resten af dataen..
Som det er nu, så gemmer jeg bare alle billederne i en mappe og gemmer dets navn, så alt ligger hulter til bulter i én brugerbilled-mappe og så struktuerer jeg det via databasen.. så det er fjerner egentlig et lag af struktur for mig
#3 der skal ingen ftp adgang være, som kunden får lov at gøre brug af.. det hele foregår via et interface i hans cms.. og alle siderne i systemet har adgang til den database
Mht. backup, så tager min host sig af alle filer alligevel, så om det er 2 gb database eller 10 mb database og ~2gb filer, det kommer ud på et..
Jeg vil formentlig lave billeddatabasen som en helt seperat database, hvis det skulle have nogen effekt på resten af dataen..
Som det er nu, så gemmer jeg bare alle billederne i en mappe og gemmer dets navn, så alt ligger hulter til bulter i én brugerbilled-mappe og så struktuerer jeg det via databasen.. så det er fjerner egentlig et lag af struktur for mig
#3 der skal ingen ftp adgang være, som kunden får lov at gøre brug af.. det hele foregår via et interface i hans cms.. og alle siderne i systemet har adgang til den database
Mht. backup, så tager min host sig af alle filer alligevel, så om det er 2 gb database eller 10 mb database og ~2gb filer, det kommer ud på et..
karga:
Bare fordi din hosting provider tager sig af det, så betyder det ikke at de bliver glade for det. Medmindre du har en god aftale, så koster det normalt pr. MB i database.
Reelt set kan jeg ikke se nogen fordele ved at putte billeder i databaser.
Et eks.:
En bruger uploader et 5MB billede. Dit system skal nu lave en række thumbnails. For at gøre dette skal din DBMS hente dataene fra, sende dem (kopiere) til din SQL klient, hvor du skal lave en memory stream (vi har nu brugt mindst 10MB hukommelse på disse to ting), som et Image objekt kan indlæse billedet fra (nogle implementation opretter et bitmap, der igen koster mindst 5MB), som der så kan laves et thumbnail fra.
Ved at anvende et filsystem kan man nøjes med at lave en filestream (der læser blocks fra disken) og det reelle hukommelsesforbrug skulle helst ikke overstige filestørrelse+bitmap størrelse.
Bare fordi din hosting provider tager sig af det, så betyder det ikke at de bliver glade for det. Medmindre du har en god aftale, så koster det normalt pr. MB i database.
Reelt set kan jeg ikke se nogen fordele ved at putte billeder i databaser.
Et eks.:
En bruger uploader et 5MB billede. Dit system skal nu lave en række thumbnails. For at gøre dette skal din DBMS hente dataene fra, sende dem (kopiere) til din SQL klient, hvor du skal lave en memory stream (vi har nu brugt mindst 10MB hukommelse på disse to ting), som et Image objekt kan indlæse billedet fra (nogle implementation opretter et bitmap, der igen koster mindst 5MB), som der så kan laves et thumbnail fra.
Ved at anvende et filsystem kan man nøjes med at lave en filestream (der læser blocks fra disken) og det reelle hukommelsesforbrug skulle helst ikke overstige filestørrelse+bitmap størrelse.
Jeg har selv undersøgt det samme for år tilbage, men der var konklusionen også, at det kunne kunne betale sig, netop pga. forringet performance.
#5 jeg kan ikke lige finde hoved og hale i den proces du beskriver der.. men jeg kunne forestille mig at jeg ville lave den nogenlunde sådan her:
- Upload det pågældende billede til hukommelsen
- Load billedet ind i billedredigeringen
- Lav x antal versioner af billedet og gør hvad der skal gøres ved billedet
Her kommer det nye:
- Gem billederne binært i databasen
Hvor jeg ellers bare ville:
- Gemme billedet fysisk og smide et filnavn i databasen
Pladsmæssigt ser jeg ingen forskel, ud over at dataen ligger i databasen istedet for på harddisken
- Upload det pågældende billede til hukommelsen
- Load billedet ind i billedredigeringen
- Lav x antal versioner af billedet og gør hvad der skal gøres ved billedet
Her kommer det nye:
- Gem billederne binært i databasen
Hvor jeg ellers bare ville:
- Gemme billedet fysisk og smide et filnavn i databasen
Pladsmæssigt ser jeg ingen forskel, ud over at dataen ligger i databasen istedet for på harddisken
karga:
Hvis du vil lave alt processering af billedet inden du putter det i databasen er det rigtigt at der ikke er det performance hit jeg omtalte.
Men når det er sagt ser jeg ingen fordele ved at bruge databasen som lager. Arbejdet ved at bruge filsystemet er minimalt større hvis du skifter host, men tilgengæld mister du mange andre fordele som et reelt filsystem giver dig (seperate programmer der laver thumbnails, flere klienter, mindre arbejde til DBMSen osv.).
Hvis du vil lave alt processering af billedet inden du putter det i databasen er det rigtigt at der ikke er det performance hit jeg omtalte.
Men når det er sagt ser jeg ingen fordele ved at bruge databasen som lager. Arbejdet ved at bruge filsystemet er minimalt større hvis du skifter host, men tilgengæld mister du mange andre fordele som et reelt filsystem giver dig (seperate programmer der laver thumbnails, flere klienter, mindre arbejde til DBMSen osv.).
Jeg kan se nogle klare fordele ved at gemme det i databasen, pga. den måde jeg henter dem ud på.. jeg har nogle formater, der bruges bestemte steder på siden og for at få det bedste layout, laver hvert format et antal thumbnails af det endelige billede, der bliver beskåret, klippet og forstørret/formindsket efter brugerens ønske, så alle billederne har den størrelse, de skal bruges i
Måden jeg så henter dem ud på vil være bedre, da jeg linker til en fil, jeg ikke skal ind og lede i databasen over billedet for at finde urlen på, men istedet bare linker til en fil med billedets id, der smider billedet ud
Samtidig så ligger billederne skjult for den nysgerrige søger, så de kun kan ses hvis scriptet giver adgang til det
Hvis jeg skifter host skal jeg kun skifte billedredigeringskomponenten ud (hvilket lige meget hvad er et teoretisk helvede) - jeg sender dataen ud med binarywrite som jo er en del af asp
Ved ikke lige hvordan du vil få et fso til at lave thumbnails til mig og hvad du mener med flere klienter?
Måden jeg så henter dem ud på vil være bedre, da jeg linker til en fil, jeg ikke skal ind og lede i databasen over billedet for at finde urlen på, men istedet bare linker til en fil med billedets id, der smider billedet ud
Samtidig så ligger billederne skjult for den nysgerrige søger, så de kun kan ses hvis scriptet giver adgang til det
Hvis jeg skifter host skal jeg kun skifte billedredigeringskomponenten ud (hvilket lige meget hvad er et teoretisk helvede) - jeg sender dataen ud med binarywrite som jo er en del af asp
Ved ikke lige hvordan du vil få et fso til at lave thumbnails til mig og hvad du mener med flere klienter?
Mht. at skjule billeder:
Du ligger billederne i en mappe som kun kan læses af ASP, men ikke IIS'en. Du laver så en asp(.net?) fil som tjekker referer-headeren og giver lov til at læse hvis den svarer til dit domæne (evt. med en cookie med et rnd tal der gemmes internet på serveren, for total kontrol). Dette lille script laver en raw copy til outpu (minimalt overhead).
Mht. kopier/beskræringer: Hver variant af et billede gives et ID, baseret på masterbilledet og beskæringstypen. Billede 44, med beskræing type 2 vil hedde picture_44_2.jpg. For at hente billedet skal man altså blot vid billedets ID og beskæringstype, og databasen skal derfor kun forespørges ID (hvis det overhovedet er nødvendigt).
Btw. om du skal spørge databasen om billede stien, eller de binære data er vel ligegyldigt? Du får bare et performance hit den dag din database ligger på en anden server end dit script, da din SQL-servers upstream bliver brugt på at sende billeder, noget der burde være en fil-servers opgave.
Du ligger billederne i en mappe som kun kan læses af ASP, men ikke IIS'en. Du laver så en asp(.net?) fil som tjekker referer-headeren og giver lov til at læse hvis den svarer til dit domæne (evt. med en cookie med et rnd tal der gemmes internet på serveren, for total kontrol). Dette lille script laver en raw copy til outpu (minimalt overhead).
Mht. kopier/beskræringer: Hver variant af et billede gives et ID, baseret på masterbilledet og beskæringstypen. Billede 44, med beskræing type 2 vil hedde picture_44_2.jpg. For at hente billedet skal man altså blot vid billedets ID og beskæringstype, og databasen skal derfor kun forespørges ID (hvis det overhovedet er nødvendigt).
Btw. om du skal spørge databasen om billede stien, eller de binære data er vel ligegyldigt? Du får bare et performance hit den dag din database ligger på en anden server end dit script, da din SQL-servers upstream bliver brugt på at sende billeder, noget der burde være en fil-servers opgave.
Der er store praktiske fordele ved at have billeder i databasen. Det er langt nemmere at sikre konsistens mellem referencer til billeder og selve billederne (transactional integrity). Det er nemmere at lave en konsistent backup. Nemmere at restricte adgangen til billederene. Nemmere at håndtere flytninger fra en server til en anden server.
Det har været god latin i mange år blandt web udviklere at billeder i en database ødelagde performance. Og det er da også helt rigtigt at billeder i en Access 95 på Windows NT 4 på en Pentium II totalt dræbte performance. Men der er jo ligesom sket lidt siden. Med en god database på noget moderne hardware kører det udmærket. Efter min bedste overbevisning er den gode latin i dag en myte.
Jeg har testet det nogle gange og database plejer at performe udmærket.
Eksempel:
ASP.NET
MySQL
1000 billeder af 25 KB
test client + ASP.NET + MySQL på samme server
single core CPU
File (1 threads): 1,9 get per second
File (10 threads): 2,2 get per second
File with web app cache (1 threads): 6,6 get per second
File with web app cache (10 threads): 16,1 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,8 get per second
Database with web app cache (1 threads): 15,4 get per second
Database with web app cache (10 threads): 19,6 get per second
File (1 threads): 1,9 get per second
File (10 threads): 2,2 get per second
File with web app cache (1 threads): 16,7 get per second
File with web app cache (10 threads): 19,4 get per second
File directly by web server (1 threads): 17,1 get per second
File directly by web server (10 threads): 20 get per second
Database (1 threads): 10,7 get per second
Database (10 threads): 11,9 get per second
Database with web app cache (1 threads): 17,3 get per second
Database with web app cache (10 threads): 19,6 get per second
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
Det har været god latin i mange år blandt web udviklere at billeder i en database ødelagde performance. Og det er da også helt rigtigt at billeder i en Access 95 på Windows NT 4 på en Pentium II totalt dræbte performance. Men der er jo ligesom sket lidt siden. Med en god database på noget moderne hardware kører det udmærket. Efter min bedste overbevisning er den gode latin i dag en myte.
Jeg har testet det nogle gange og database plejer at performe udmærket.
Eksempel:
ASP.NET
MySQL
1000 billeder af 25 KB
test client + ASP.NET + MySQL på samme server
single core CPU
File (1 threads): 1,9 get per second
File (10 threads): 2,2 get per second
File with web app cache (1 threads): 6,6 get per second
File with web app cache (10 threads): 16,1 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,8 get per second
Database with web app cache (1 threads): 15,4 get per second
Database with web app cache (10 threads): 19,6 get per second
File (1 threads): 1,9 get per second
File (10 threads): 2,2 get per second
File with web app cache (1 threads): 16,7 get per second
File with web app cache (10 threads): 19,4 get per second
File directly by web server (1 threads): 17,1 get per second
File directly by web server (10 threads): 20 get per second
Database (1 threads): 10,7 get per second
Database (10 threads): 11,9 get per second
Database with web app cache (1 threads): 17,3 get per second
Database with web app cache (10 threads): 19,6 get per second
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
arne_v:
Kunne du prøve at køre den test igen, med større filer? MySQL bruger som standard 32KB page sizes for data, og du får dermed ikke det performancehit det giver når DBMSen skal finde næste datablock.
MSSQL bruger pagesizes på 2KB (så vist jeg kunne finde) og vil derfor skulle lave endnu flere lookups end MySQL (jeg antager at karga vil bruge MSSQL).
Kunne du prøve at køre den test igen, med større filer? MySQL bruger som standard 32KB page sizes for data, og du får dermed ikke det performancehit det giver når DBMSen skal finde næste datablock.
MSSQL bruger pagesizes på 2KB (så vist jeg kunne finde) og vil derfor skulle lave endnu flere lookups end MySQL (jeg antager at karga vil bruge MSSQL).
Well, man mister en klar fordel:
Det er nemmere at have en separat db-server og storage-server, og så kæde det sammen fra den primære kasse, end det er at lave et db-cluster.
Min pointe er her, at lighttpd o.lign. kan serve statiske filer ekstremt hurtigt.
Men det er selvfølgeligt kun relevant når vi snakker om sites der er lidt større end det som du sidder og laver.
Det er nemmere at have en separat db-server og storage-server, og så kæde det sammen fra den primære kasse, end det er at lave et db-cluster.
Min pointe er her, at lighttpd o.lign. kan serve statiske filer ekstremt hurtigt.
Men det er selvfølgeligt kun relevant når vi snakker om sites der er lidt større end det som du sidder og laver.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund