[DISC] Hoe behandel je plaatjes binnen een CMS?

[Reveller]

Grofweg zie je twee manieren waarop CMS'en plaatjes opslaan en weergeven:

• bij Geenstijl worden alle plaatjes in de /images map opgeslagen onder een leesbare naam (zoals zalmmetkoffer.jpg).
• bij Tweakers worden plaatjes opgeslagen met een nummer als naam (4324265464336.gif) en via i.dsp getoond

Zoals ik het zie hebben beide manieren voor- en nadelen:

• bij sites als Geenstijl zijn de plaatjes via het filesystem direct te benaderen, wat waarschijnlijk sneller is dan wanneer een plaatje via een serverside pagina (zoals i.dsp) opgevraagd moet worden
• bij een site als Geenstijl (draait overigens onder Movabletype) bevat de naam van het plaatje informatie over het plaatje, zodat ik als het moet ook zelf een src naar dat plaatje kan typen ipv gebruik te maken van een WYSIWYG oid
• als ik een plaatje tijdens het uploaden hernoem naar een uniek nummer, ontloop ik gedoe met 'het plaatje met naam zalmmetkoffer.jpg bestaat al op de server'-errors
• dispatchen via een pagina geeft me de mogelijkheid te tellen hoe vaak een plaatje werd getoond

Ik vraag me een aantal dingen af nu ik voor mijn eigen CMS een manier wil opzetten om plaatjes te behandelen:

• haalt Tweakers het plaatje uit een database of liggen de plaatjes in een map op de server opgeslagen (wellicht buiten de webroot?)
• wat zijn de voor- en nadelen van plaatjes opslaan in een database? Ik dacht altijd dat performance het grootste nadeel was
• hernoem jij geuploade plaatjes bij jouw systeem naar een nummer of niet? Waarom (niet)?
• als jij plaatjes in een map op de server opslaat (en dus niet in de database), geef je de gebruiker dan de mogelijkheid subdirectories aan te maken? Waarom (niet)?

Ik heb nog nooit eerder zelf een CMS gebouwd, en heb geen technische achtergrond. Ik hoop dus op een aantal reakties, zodat ik mijn eigen mening aan de hand daarvan kan vormen Ik neig naar hernoemen naar een nummer, opslaan in een map op de server en meta info bijhouden in de database. Geen mogelijkheid om submappen aan te maken, maar wel om de plaatjes in te delen in 'albums'.

[crisp]

haalt Tweakers het plaatje uit een database of liggen de plaatjes in een map op de server opgeslagen (wellicht buiten de webroot?)

Dat laatste. De plaatjes bestaan dus wel degelijk op het filesystem, maar de meta-informatie (zoals titel en beschrijving) zijn opgeslagen in de database

[BtM909]

Deze discussie hoort toch iets beter binnen Software Engineering & Architecture

edit:
GRRRRRRRRRRRRRRRRRR, en toen had ik geen knopjes meer

[ Voor 26% gewijzigd door BtM909 op 02-10-2006 10:04 ]

[MBV]

Daar is laatst nog een discussie over geweest hierzo: Mappenindeling profielensite
Hopelijk hier op een iets hoger niveau maar je kan er wat dingen uihalen

[Reveller]

crisp schreef op maandag 02 oktober 2006 @ 10:04:
[...]
Dat laatste. De plaatjes bestaan dus wel degelijk op het filesystem, maar de meta-informatie (zoals titel en beschrijving) zijn opgeslagen in de database

En zit de image map binnen of buiten de webroot? Het nadeel van buiten de webroot is natuurlijk dat je de plaatjes door PHP moet laten streamen ipv door Apache laat leveren. Het snelheidsvoordeel wat je met serveren vanaf het filesystem behaalt ten opzichte van serveren vanuit een database, zou hiermee teniet worden gedaan (toch?).

MBV schreef op maandag 02 oktober 2006 @ 16:51:
Daar is laatst nog een discussie over geweest hierzo: Mappenindeling profielensite
Hopelijk hier op een iets hoger niveau

Ik mag hopen van wel

maar je kan er wat dingen uihalen

Dat is zeker. Maar meer lezen over dit onderwerp brengt geen duidelijke best practice naar voren. Ik denk dat het een kwestie van voorkeur blijft. In z'n algemeenheid kun je, na het lezen van dat topic, zeggen dat het grootste voordeel van opslaan in een database is dat de rechten op het plaatje perfect te regelen zijn. Wil je dit via het filesystem regelen, moet je de plaatjes in een map buiten de webroot opslaan en door PHP laten streamen. Ik begrijp wel dat het serveren van grote hoeveelheden plaatjes vanuit een database een bottleneck kan opleveren die er, mits een juiste mappenindeling, bij serveren vanaf het filesystem niet is.

[ Voor 44% gewijzigd door Reveller op 02-10-2006 18:10 ]

[MBV]

en ik denk dus ook dat dat de meest toegepaste oplossing is: plaatjes in een filesystem, buiten de webroot. Database geeft daarvoor teveel technische problemen

[ Voor 19% gewijzigd door MBV op 02-10-2006 18:46 ]

[faabman]

Reveller schreef op maandag 02 oktober 2006 @ 10:01:
bij Geenstijl worden alle plaatjes in de /images map opgeslagen onder een leesbare naam (zoals zalmmetkoffer.jpg).

De URL waarmee de plaatjes op GS bereikt kunnen worden hoeft nog niets te zeggen over de fysieke locatie van het plaatje. Je kunt in je database namelijk ook een tabel bijhouden met daarin friendly URLs, die dan weer gekoppeld zijn aan een afbeelding of document die buiten de webroot opgeslagen staat.

[Reveller]

@faabman - dat is inderdaad waar. Mijn cms werkt ook met friendly url's via mod_rewrite, dus dat had ik moeten beseffen Ik heb nog wel de volgende vraag: de meeste plaatjes binnen een website zijn voor iedereen toegankelijk en zijn niet aan speciale rechten gebonden. Voor zulke plaatjes is het buiten de webroot opslaan en ze via PHP naar de client moeten streamen eigenlijk alleen maar inefficient, toch? Voor zover ik weet is het enige argument om plaatjes buiten de webroot op te slaan, dat je er toegangsrechten aan kunt koppelen. Of is er nog een ander voordeel?

[faabman]

Reveller schreef op maandag 02 oktober 2006 @ 10:01:dispatchen via een pagina geeft me de mogelijkheid te tellen hoe vaak een plaatje werd getoond

Nu ik je TS nog een keer doorlees, om te bepalen hoe vaak een bestand wordt hoor je voor zover mij bekend de logbestanden van je webserver te gebruiken

Reveller schreef op maandag 02 oktober 2006 @ 23:14:
Voor zover ik weet is het enige argument om plaatjes buiten de webroot op te slaan, dat je er toegangsrechten aan kunt koppelen. Of is er nog een ander voordeel?

Ja, er is nog een ander voordeel, je kunt als je toch al aan het mod_rewriten (of welke andere methode ook) bent gelijk serverside resizen. @hieronder: ik bedoel dus bij elke request (en heb het daarbij niet over performance)

[ Voor 5% gewijzigd door faabman op 03-10-2006 16:50 ]

[Verwijderd]

Nu ik je TS nog een keer doorlees, om te bepalen hoe vaak een bestand wordt hoor je voor zover mij bekend de logbestanden van je webserver te gebruiken

Ik kan me voorstellen dat er situaties zijn waarbij je dit direct in je database wilt opslaan.

Ja, er is nog een ander voordeel, je kunt als je toch al aan het mod_rewriten (of welke andere methode ook) bent gelijk serverside resizen.

Kun je dat niet altijd . Ik neem aan dat je een afbeelding maar eenmalig resized (bijvoorbeeld bij het uploaden).

Wanneer een afbeelding niet door iedereen bekeken mag worden zijn er dus twee gangbare manieren om een afbeelding op te slaan. Je kunt kiezen tussen het opslaan van een afbeelding in een database of het streamen van een afbeelding door PHP van buiten de web-root. Welke van de twee heeft dan de voorkeur?
Ik lees maar wat vaak dat het opslaan van bestanden in een database veel performance problemen geeft maar ik vroeg me af of iemand ervaring heeft m.b.t. de verschillen qua performance tussen beide bovenstaande oplossingen.

[Reveller]

faabman schreef op maandag 02 oktober 2006 @ 23:51:
Nu ik je TS nog een keer doorlees, om te bepalen hoe vaak een bestand wordt hoor je voor zover mij bekend de logbestanden van je webserver te gebruiken

Eenvoudiger, en volgens mij net zo accuraat is natuurlijk om dit in de database bij te houden, elke keer als je de afbeelding uit de database / van het filesystem (streaming via php) haalt even een counter updaten. Zou je logfiles analyseren, vergt dat toch meer performance (of je moet het 's nachts met een cron ofzo doen, maar dan zijn je statistieken weer niet real-time)

Verwijderd schreef op dinsdag 03 oktober 2006 @ 09:21:
[...]
Ik lees maar wat vaak dat het opslaan van bestanden in een database veel performance problemen geeft maar ik vroeg me af of iemand ervaring heeft m.b.t. de verschillen qua performance tussen beide bovenstaande oplossingen.

Dit zou ik ook graag willen weten. En daarop aansluitend: als je plaatjes hebt die toch voor iedereen toegankelijk mogen zijn, is het dan niet verstandiger om die plaatjes 'gewoon' in de webroot te zetten? Dat je dus alleen plaatjes die niet voor iedereen toegankelijk mogen zijn, buiten de webroot plaatst? Dit scheelt performance op de 'gewone' plaatjes. Die hoeven immers niet via PHP gestreamed te worden. Of is dat foute architectuur omdat je voor een uniforme oplossing moet kiezen en dus niet plaatjes en binnen en buiten de webroot moet opslaan?

[MBV]

Dat zou ik als fout klassificeren. Uiteraard kan het altijd erger, maargoed. De performance hit zal vrij laag zijn voor foto's, maar het zal veel meer onderhoud vergen (denk eens aan wat er gebeurt zodra je een foto 'publiek' zet die 'geheim' was). Niet onmogelijk, wel meer onderhoud.
Wat ik níet buiten de webroot zou zetten zijn layout-elementen, maar ik hoop dat je dat zelf al wel had verzonnen

[Reveller]

MBV schreef op dinsdag 03 oktober 2006 @ 21:14:
[...]
Wat ik níet buiten de webroot zou zetten zijn layout-elementen, maar ik hoop dat je dat zelf al wel had verzonnen

Dat had ik ook al bedacht, maar dan heb je dus tóch die scheiding nodig Layout elementen zijn plaatjes die binnen de webroot staan. Alle andere plaatjes, zoals foto's bij artikelen, zou jij dus buiten de webroot zetten? Overigens wil ik niet kijken wat makkelijker of moeilijker te implementeren is: mijn cms is gebouwd op een (vind ik zelf ) redelijk sterk rechtensysteem, dus daar zit het probleem niet. Ik zoek puur naar de meest professionele oplossing, waarbij er een goede balans zit tussen performance en mogelijkheden.

[ Voor 28% gewijzigd door Reveller op 03-10-2006 23:43 ]

[MBV]

Als je een goede structuur hebt zou ik nu niet bouwen wat je misschien ooit nodig hebt. Layout troep is 'statisch' (kan niet door 'alle' gebruikers veranderd worden, en iedereen mag er altijd bij), en moet dus in een aparte map in je webroot. De 'gegevens', dit keer in de vorm van een plaatje, bij een artikel ofzo moeten apart worden opgeslagen. Dit zou ik dus buiten de webroot opslaan, en streamen via een PHP script.
Mocht de performance te laag zijn, dan kan je alsnog gaan testen of het handig is om de publieke plaatjes in je webroot te zetten. Ik verwacht niet dat dat zo is, maar stel dat. Dan kan je dat alsnog veranderen. Ik zou het initieel niet doen, omdat het extra complexiteit toevoegt (met rechten wijzigen, opvragen vanaf 2 locaties enzo) voor een probleem wat zich waarschijnlijk niet voordoet.

offtopic:
Ik heb ooit het plan gehad om voor mijn eigen website, die ik thuis host achter een ADSL lijn, de meest populaire thumbnails via FTP naar wat webspaces te verdelen, om de lijn wat te ontlasten. Dat zou pas complexiteit gaan geven, om die automagisch bij te werken enzo

[ Voor 18% gewijzigd door MBV op 04-10-2006 01:58 ]

[djluc]

offtopic:
Heb het zelfs al ontwikkeld voor gebruik op forums als Got. Zodat je ook altijd het plaatje kunt zien als er een server down gaat. Helaas zijn er meer mensen die plaatjes willen uploaden dan het aanbod aan server-ruimte.

@TS: Heb je misschien een concrete case wat betreft de verhouding tussen performance en handigheid? Je geeft zelf al aan dat daar het punt van de beslissing ligt maar de feitelijke gegevens hierover geef je niet. Je weet nu dus wel de voor- en nadelen maar uiteindelijk krijgt dit topic zo nooit een oplossing of iets wat daar op lijkt.

[RayNbow]

Op deze pagina staan een aantal meningen over database vs filesystem.

crisp schreef op maandag 02 oktober 2006 @ 10:04:
[...]

Dat laatste. De plaatjes bestaan dus wel degelijk op het filesystem, maar de meta-informatie (zoals titel en beschrijving) zijn opgeslagen in de database

crisp, vraagje, hoeveel fysieke kopieën bestaan er van een willekeurig plaatje op Tweakers?

[Verwijderd]

djluc schreef op woensdag 04 oktober 2006 @ 02:11:
@TS: Heb je misschien een concrete case wat betreft de verhouding tussen performance en handigheid? Je geeft zelf al aan dat daar het punt van de beslissing ligt maar de feitelijke gegevens hierover geef je niet. Je weet nu dus wel de voor- en nadelen maar uiteindelijk krijgt dit topic zo nooit een oplossing of iets wat daar op lijkt.

Ik denk niet dat het zo zeer om handigheid gaat maar meer om de vraag wat de beste keuze is in een design.
Maar bij deze een mogelijke case:
Neem een druk bezochte profielensite waar mensen ieder een eigen profiel met meerdere pagina's kunnen onderhouden. Een gebruiker kan een profiel delen met andere gebruikers en het profiel is verder van de buitenwereld (en andere gebruikers) afgesloten.

Persoonlijk vind ik het opslaan van afbeeldingen (of andere bestanden) in een database een mooie oplossing omdat deze deel uit maken van een profiel. Nadeel wat ik vaak heb zien passeren (geen persoonlijke ervaring) is de performance van een database ten opzichte van een filesystem. Andere beweren echter dat dat allemaal overdreven is . Dan vraag ik me (misschien wel terrecht) af wat de juiste keuze is, zie bijvoorbeeld:

Op deze pagina staan een aantal meningen over database vs filesystem.

@djluc: Ik geloof niet dat er één juiste oplossing is en dat je die hier aan het einde van dit topic kunt verwachten. Ik denk dat TS hier gewoon ervaring wil uitwisselen met mensen die ervaring hebben op dit gebied.

[djluc]

RayNbow schreef op woensdag 04 oktober 2006 @ 07:09:
Op deze pagina staan een aantal meningen over database vs filesystem.
[...]

Dit is een boeiend stukje uit de link:

Using the database method, WebObjects would cache your images so you wouldn't actually have to go to the database each time.

Iemand ervaring?

Wat mij een leuke setup lijkt:
Alles in een database zetten. Vervolgens vraag je alle afbeeldingen dynamisch aan in je code, bijvoorbeeld:

PHP:

$conf=array(
  'width' = 100,
  'height' = 100,
);
echo '<img src="'.$imageHandler->show(32324, $conf).'">';

De image handler kijkt of er al een cache afbeelding in het filesystem staat welke voldoet aan de eisen 100x100. Als dit niet zo is zal deze aangemaakt worden. In beide gevallen wordt het pad gereturned.

Waarom is dit handig:
Je hebt het voordeel van 1 correcte backup, van 1 centrale plaats om je afbeeldingen te plaatsen enzovoorts. Mocht er iets mis gaan, wil je de kwaliteit van de afbeeldingen verhogen, of weet-ik-veel, verwijder je simpelweg je cache en je afbeeldingen worden allemaal met de nieuwe instellingen aangemaakt.

Wat betreft beveiliging plaats je de cache afbeeldingen buiten de webroot of sluit je de map af met een htaccess welke er voor zorgt dat je geen toegang krijgt op verkeerde momenten. De simpelste oplossing is, als de performance dat toelaat, gewoon buiten de webroot zetten en via PHP doorsturen.

Verwijderd schreef op woensdag 04 oktober 2006 @ 09:59:
[...]
@djluc: Ik geloof niet dat er één juiste oplossing is en dat je die hier aan het einde van dit topic kunt verwachten. Ik denk dat TS hier gewoon ervaring wil uitwisselen met mensen die ervaring hebben op dit gebied.

Klopt, maar zonder concrete eisen is er weinig discussie mogelijk aangezien dit geheel afhankelijk is van de eisen die gesteld worden.

[ Voor 22% gewijzigd door djluc op 04-10-2006 11:04 ]

[joepP]

Volgens mij zijn er bijna geen situaties denkbaar waarin je plaatjes in de database zal willen opslaan. Ik zie de volgende grote nadelen voor een -serieuze- toepassing:

Schaalbaarheid. Een extra fileserver hang je er zo bij, maar een database repliceer je niet zo makkelijk.
Backups. De database wordt groot, wat problemen gaat opleveren bij het backuppen.
Caching. Hoe groter de database, hoe minder voordeel je van caching zal hebben. Zowel van queries als van disc I/O. Door de plaatjes door het filesystem te laten server, eventueel vanaf een andere server, heb je dat probleem niet.
Performance. De database is hier vaak het kritische punt, en die wil je niet extra belasten met een grote hoeveelheid dataverkeer. Ook het netwerk gaat dit niet leuk vinden.
Onderhoud. Als je om wat voor reden dan ook snel bij de plaatjes wilt komen is het filesystem een stuk makkelijker.

De enige nadelen die ik kan bedenken zijn in mijn ogen geen echte problemen:

Security. Door plaatjes in de database te stoppen kan je makkelijker rechten toepassen. Echter, als je werkt met verwijzingen naar het filesystem kan je dezelfde security in je databaselaag toepassen. Dit is dus eigenlijk helemaal geen probleem.
Complexiteit. Je moet eenmalig even goed nadenken hoe je de boel precies inricht, zodat je geen overvolle directories krijgt, en de links naar je files intact blijven. Dit zijn echter geen complexe problemen, en volgens mij redelijk eenvoudig goed op te lossen.

[djluc]

joepP schreef op woensdag 04 oktober 2006 @ 11:33:
Volgens mij zijn er bijna geen situaties denkbaar waarin je plaatjes in de database zal willen opslaan. Ik zie de volgende grote nadelen voor een -serieuze- toepassing:

Schaalbaarheid. Een extra fileserver hang je er zo bij, maar een database repliceer je niet zo makkelijk.

Als je eenmaal 2 database servers hebt die repliceren lijkt het mij zo dat een 3e, een 4e enzovoorts er bij hangen allemaal net zo eenvoudig is? Daarnaast moet je toch ook je files gaan repliceren?

Backups. De database wordt groot, wat problemen gaat opleveren bij het backuppen.

Waarom is dat zo? Je moet die bestanden anders toch ook backuppen?

Caching. Hoe groter de database, hoe minder voordeel je van caching zal hebben. Zowel van queries als van disc I/O. Door de plaatjes door het filesystem te laten server, eventueel vanaf een andere server, heb je dat probleem niet.

Wat bedoel je in dit geval precies met caching? Je hebt toch nog steeds je indexen in de database e.d. waardoor je snel kunt zoeken? Verder kan je de gegenereerde resultaten (html e.d.) toch nog steeds cachen met een cachingmechanisme?

Performance. De database is hier vaak het kritische punt, en die wil je niet extra belasten met een grote hoeveelheid dataverkeer. Ook het netwerk gaat dit niet leuk vinden.

Waarom zou je dat dan wel willen met files? Dezelfde hoeveelheid data gaat toch over je netwerkverbindingen heen? Volgens mij zie je problemen die er zijn in beide situaties als problemen die specifiek bij de database opzet aanwezig zijn...

Onderhoud. Als je om wat voor reden dan ook snel bij de plaatjes wilt komen is het filesystem een stuk makkelijker.

Klopt, in het geval van een database moet je inderdaad alles scripten. Wel kan je hier natuurlijk goede beheerstools voor installeren en eventueel zelf programmeren, maar dit is zeker een nadeel.

offtopic:
Of je ook echt wilt dat je direct die data aan kunt passen weet ik trouwens niet wat betreft de integriteit van je data maar dat is een andere discussie.

[joepP]

djluc schreef op woensdag 04 oktober 2006 @ 12:02:
[...]
Als je eenmaal 2 database servers hebt die repliceren lijkt het mij zo dat een 3e, een 4e enzovoorts er bij hangen allemaal net zo eenvoudig is? Daarnaast moet je toch ook je files gaan repliceren?

Het is al lastig genoeg om twee database servers te repliceren. Sterker nog, in de meeste setups (tweakers bijvoorbeeld) is het eigenlijk bijna onmogelijk. Fileservers repliceren daarentegen is een heel stuk eenvoudiger.

[...]
Waarom is dat zo? Je moet die bestanden anders toch ook backuppen?

Een database backup wil je graag 's nachts maken, of eventueel zelfs meerdere keren per dag. Het is van belang dat dat niet te lang duurt, en ook geen nare belasting voor de server met zich meebrengt. Het lijkt me daarom niet echt handig om >10GB aan plaatjes in de database te hebben staan.

[...]
Wat bedoel je in dit geval precies met caching? Je hebt toch nog steeds je indexen in de database e.d. waardoor je snel kunt zoeken? Verder kan je de gegenereerde resultaten (html e.d.) toch nog steeds cachen met een cachingmechanisme?

Als de database volledig in het geheugen past (geen rare aanname met een fatsoenlijke server en een database van < 4GB) heb je veel betere performance. Dat zal niet meer lukken als er ook plaatjes in staan. Ook als query-results gecached moeten worden kan je problemen krijgen met plaatjes, want die nemen veel te veel ruimte in. Of je moet kunnen zorgen dat die juist niet gecached worden.

[...]
Waarom zou je dat dan wel willen met files? Dezelfde hoeveelheid data gaat toch over je netwerkverbindingen heen? Volgens mij zie je problemen die er zijn in beide situaties als problemen die specifiek bij de database opzet aanwezig zijn...

Nee. Ten eerste is het veel erger als de database wat trager is, dan als de plaatjes niet direct ingeladen worden. Verder heb je bij serieuze toepassingen vaak een setup met meerdere machines, zodat je de netwerk belasting verdeelt tussen de machines, en alleen de verbinding naar buiten toe een hele dikke bandbreedte nodig heeft.

Mijn punt komt eigenlijk op het volgende neer: ik zie geen enkel serieus voordeel aan het opslaan van plaatjes in de database, maar wel veel nadelen. Waarom zal je het dan uberhaubt willen doen?

[disjfa]

joepP schreef op woensdag 04 oktober 2006 @ 13:45:
[...]
Een database backup wil je graag 's nachts maken, of eventueel zelfs meerdere keren per dag. Het is van belang dat dat niet te lang duurt, en ook geen nare belasting voor de server met zich meebrengt. Het lijkt me daarom niet echt handig om >10GB aan plaatjes in de database te hebben staan.

Dus wat jij zegt is dat jij je database wel backupt, maar je bestanden niet. Ik backup graag alles. Dan maakt of het in een database of het op mijn filesystem staat niet uit. Het blijft 10 gig.

[djluc]

Verder wil je toch graag een consistente backup. Oftwel, je wilt niet dat er in de database een verwijzing staat naar een file welke helaas niet bestaat

[LauPro]

Als je met die tabel in de database geen gekke dingen gaat (full text indexes oid) doet maakt het qua performance volgens mij niets uit. Natuurlijk is een filesystem makkelijker. Maar zoals al gesteld je kan met caching altijd alsnog die images uit de DB trekken die lokaal op een webserevr cachen bijv..

Back-ups van de database worden inderdaad groter. Maar met een goede configuratie kan een database back-up volgens mij wel sneller zijn. NFS en FTP hebben behoorlijk wat overhead als je heel veel kleine files hebt, bij een database maakt het aantal records praktisch niet uit.

Als je inderdaad 1 miljoen plaatjes in je database hebt dan kan die wat groot worden, maar dan heb je ook wel de middelen om dat te ondersteunen als het goed is. Overigens valt MySQL best te repliceren alleen vereist het wel een bepaalde manier van denken/filosofie. 'Even' een server herstarten zit er bijvoorbeeld niet meer bij.

[RayNbow]

joepP schreef op woensdag 04 oktober 2006 @ 13:45:
[...]

Het is al lastig genoeg om twee database servers te repliceren.

http://www.howtoforge.com/mysql_database_replication
Verder ondersteunen Oracle, PostgreSQL, MSSQL, etc, ook database replication.

Sterker nog, in de meeste setups (tweakers bijvoorbeeld) is het eigenlijk bijna onmogelijk.

Want...?

Fileservers repliceren daarentegen is een heel stuk eenvoudiger.

In welk opzicht dan?

[netvor]

Plaatjes door PHP laten streamen zorgt voor een enorme performancehit. Ik draai DokuWiki op een vrij trage server, en ik heb deze feature maar uit moeten zetten, want een JPEG van ~100 kB veroorzaakte meer load op de server dan het parsen van zelfs de grootste pagina's tekst. Ik heb dit probleem uiteindelijk opgelost door wat te spelen met Apache's mod_rewrite.

Mod_rewrite is snel, dus volgens mij kan je het beste hier naar kijken. Mod_rewrite heeft de mogelijkheid een extern programma aan te roepen als RewriteRule. Je kan dan het volgende doen:
1. Apache krijgt request voor http://server/foo/bar/geheimplaatje.jpg. Dit is een friendly URL.
2. mod_rewrite ziet dat het een plaatje is en stuurt het door naar jouw Perl/PHP/whatever script.
3. Je script checkt de rechten, doet een databaselookup voor meta-info, wellicht wat resizen, etc...
4. Uit dit script komt een (absolute) path rollen naar het bestand, buiten de webroot. Bijvoorbeeld /tmp/img35468432163851.jpg
5. mod_rewrite zorgt ervoor dat dit bestand netjes als http://server/foo/bar/geheimplaatje.jpg aan de client wordt getoond.

N.B. Dit is mijn visie en ik heb het nooit echt geimplementeerd, dus ik weet niet of het gaat lukken en of het echt zo snel is als ik verwacht.

Het grootste vraagteken wat ik hierbij heb is: hoe kan zo'n extern script, dat door mod_rewrite aangeroepen wordt, de rechten checken? Kan je gebruik maken van cookies / session variables / HTTP authentication / etc. ?

[Wolfboy]

imp schreef op woensdag 04 oktober 2006 @ 14:27:
Het grootste vraagteken wat ik hierbij heb is: hoe kan zo'n extern script, dat door mod_rewrite aangeroepen wordt, de rechten checken? Kan je gebruik maken van cookies / session variables / HTTP authentication / etc. ?

In een .htaccess kan je ook HTTP authentication gebruiken dus das niet zo'n probleem, verder kan je php/perl/etc. gewoon door laten sturen naar het werkelijke bestand (of eventueel direct laten echo'en)

[LauPro]

Persoonlijk vind ik Mod_rewrite niet echt 'done' in bijv. een PHP/MySQL omgeving. Je moet bij het ontwerp bepaalde keuzes maken. En persoonlijk vind ik als je kiest voor PHP en MySQL dat je dan ook deze gebruikt om de applicatie te relealiseren. De webserver doet er dan eigenlijk niet meer toe, dit kan Apache zijn zolang hij maar de PHP-engine aan roept (en daar heeft mod_php5 bijv. een hele interessante performancewinst in Apache). Wat basic instellingen als Multiviews kan nog, maar echt je hele omgeving af te laten hangen van htaccesjes vind ik niet goed. Tenzij je echt een 100% static website hebt met misschien hier en daar een cgi-scriptje. Maar dan is je omgeving Apache2 bijv. en niet PHP/MySQL.

[Wolfboy]

En hoe realiseer jij dan 'mooie' urls zoals tweakers gebruikt zonder mod_rewrite?

[netvor]

Ik heb zojuist eventjes TFM doorgelezen en heb wat toevoegingen:

- Het aanroepen van een extern programma kan via RewriteMap en vervolgens RewriteRule
- Dit programma is persistent (wordt samen met Apache gestart en communiceert via stdin/stdout)
- HTTP authentication en cookies lijken beschikbaar te zijn voor mod_rewrite.

Het voordeel van een persistent programma is dat het snel is: je kan een snelle memorycache bijhouden, en ook heb je geen last van opstartoverhead.

Het nadeel: als je programma crasht of hangt neemt het waarschijnlijk Apache met zich mee. Niet leuk. Dit is waarschijnlijk ook de reden dat je RewriteMap niet in een .htaccess kan zetten, alleen in de httpd.conf.

[MTWZZ]

^^ Alias keyword in Apache en dat naar een php pagina laten wijzen.

code:

Alias /nx /index.php

en dan in index.php de $_SERVER variabele uitlezen.

[LauPro]

Wolfboy schreef op woensdag 04 oktober 2006 @ 15:02:
En hoe realiseer jij dan 'mooie' urls zoals tweakers gebruikt zonder mod_rewrite?

Door slim gebruik te maken van multiviews kom je een heel eind.

[Reveller]

Ik denk dat het zinvol is een onderscheid te maken tussen layout plaatjes en "content" plaatjes. Ik het regelmatig reakties gelezen (ook op andere fora) waarin gesteld wordt dat de eerste sowieso vanaf de filesystem geleverd moeten worden, vanwege de zware load die op die plaatjes komt. Plaatjes die je in je database opslaat, moeten een relatie hebben met overige database data, bijvoorbeeld een artikel ondersteunen. Nadeel is dat je op deze manier geen uniforme methode hebt om plaatjes op te slaan. Hieronder een aantal quotes die hiermee te maken hebben:

Michael Halliday schreef op Wikibooks:
I haven't had any problems storing [dynamic images (or images that the user can change/upload)] in our database [...] I think it's the most effective approach. That being said, we do use apache to serve up our static images.

MBV schreef op dinsdag 03 oktober 2006 @ 21:14:
Wat ik níet buiten de webroot zou zetten zijn layout-elementen [...]

djluc schreef op woensdag 04 oktober 2006 @ 14:00:
Verder wil je toch graag een consistente backup. Oftwel, je wilt niet dat er in de database een verwijzing staat naar een file welke helaas niet bestaat

Oracle zegt in het artikel The Move to Store Images In the Database:
If an image is stored in a file system, then it is possible for external processes to delete or modify that image, causing the image itself to either become orphaned or lose synchronicity with its corresponding relational data.

Kijk nou, Oracle is pro database! Het grootste nadeel van opslaan op filesystem is het synchroon houden met de meta data in de database. Wel geeft Oracle in hetzelfde artikel toe dat images uit een 10g database ophalen trager is dan van het filesystem, hoewel het verschil steeds kleiner wordt. Zie ook een benchmark uit 2001 met een MySQL database. In het geval van data-ondersteunende plaatjes, is het wellicht zinvol deze in de database op te slaan en het (kleine) performance verlies voor lief te nemen.

Wie is het hier niet mee eens?

[Genoil]

Mja uiteindelijk staan de bits van het plaatje in min of meer of exacte hetzelfde op de harde schijf. de metadata is ook hetzelfde, alleen verwijst het een naar een BLOB en het ander naar een (relatieve) URI.

Het voordeel van de URI is dattie niet hoeft te verwijzen naar hetzelfde systeem als waar de databaseserver op draait. Maar dat is, in een andere opzicht, ook een voordeel van de BLOB.

Wat is de toegevoegde waarde van een BLOB ipv een VARCHAR(255) (of TEXT) met een URI op SQL niveau? Wat voor zinnige dingen kunnen je doen met de binaire data in SQL (in de WHERE clause), tov binaire data waarnaartoe verwezen wordt in een URI? Op het moment dat je zou kunnen gaan zoeken op patronen e.d in SQL wordt het een andere verhaal.

De metadata van een afbeelding verwijst meestal niet specifiek naar een pixel-word binnen de BLOB. en als het dat wel doet moeten zowel metadata als BLOB eerst uit de database worden gehaald, wil je er wat mee kunnen doen. Niet dat het met een URI-verwijzing veel anders gaat, maar wat zijn dan de echte voordelen van het wegstoppen van binaire data in een BLOB, waarover deze artikelen reppen?

--

En over het hernoemen naar bv nummers: Dat is jammer. Dan gooi je de belangrijkste en meest basele metadata over de kling. Als ik hier zeg: {img:smilie.jpg} weten jullie meteen waarover ik het heb, {img:1634} zegt helemaal niets. Als ik dan een plaatje wil downloaden van je server en bij Save As... wordt de naam "getimage.php?id=1634.jpg" of iets dergelijks, dan is dat gewoon vervelend. En als je het dan nog in een BLOB hebt gezet, zet je een extra veld bij met daarin de naam (en nog een paar met de afmetingen etc.) en dan vind je dat de BLOB beter op z'n plaats is bij de metadata. Terwijl je die anders helemaal niet had hoeven opslaan?

[ Voor 22% gewijzigd door Genoil op 04-10-2006 20:41 ]

[Wolfboy]

MTWZZ schreef op woensdag 04 oktober 2006 @ 15:09:
^^ Alias keyword in Apache en dat naar een php pagina laten wijzen.

code:

Alias /nx /index.php

en dan in index.php de $_SERVER variabele uitlezen.

Daar kan je inderdaad wel wat mee doen maar is imho onvoldoende (ik heb vaak genoeg gehad dat het niet echt werkt op die manier, of een gigantische rommel zou worden)

LauPro schreef op woensdag 04 oktober 2006 @ 15:17:
[...]
Door slim gebruik te maken van multiviews kom je een heel eind.

De mogelijkheden daarvan zijn nog steeds redelijk beperkt.

[joepP]

disjfa schreef op woensdag 04 oktober 2006 @ 13:52:
[...]

Dus wat jij zegt is dat jij je database wel backupt, maar je bestanden niet. Ik backup graag alles. Dan maakt of het in een database of het op mijn filesystem staat niet uit. Het blijft 10 gig.

Je probeert wel heel hard om "slechte" dingen in mijn posts te lezen: dat zeg ik helemaal nergens. Alleen kost een backup van de database wel flinke performance, of je moet alles tijdelijk read-only zetten met allerlei nare consequenties. Ik wil graag dat die backup snel gaat.

RayNbow schreef op woensdag 04 oktober 2006 @ 14:21:
http://www.howtoforge.com/mysql_database_replication
Verder ondersteunen Oracle, PostgreSQL, MSSQL, etc, ook database replication.
[...]
In welk opzicht dan?

Leuk, maar database replication werkt ontzettend matig in MySQL. Waarom denk je dat ze er hier geen gebruik van maken? Met PostgreSQL heb ik geen ervaring, maar voor Oracle en SQL Server vrees ik dat het belachelijk duur wordt. Plus dat er ook nadelen aan zullen kleven.

[Wolfboy]

joepP schreef op woensdag 04 oktober 2006 @ 20:44:
Leuk, maar database replication werkt ontzettend matig in MySQL. Waarom denk je dat ze er hier geen gebruik van maken? Met PostgreSQL heb ik geen ervaring, maar voor Oracle en SQL Server vrees ik dat het belachelijk duur wordt. Plus dat er ook nadelen aan zullen kleven.

Met PostgreSQL zijn de replication mogelijkheden ook bijhoorlijk duur, tenminste, als je een replicatiesysteem neemt die gegarandeerd (met service) bedrijfsmatig te gebruiken is.

[ Voor 21% gewijzigd door Wolfboy op 04-10-2006 22:24 ]

[Reveller]

In de reaktie van Genoil staan een hoop argumenten die ik inmiddels ook onderschrijf:

Genoil schreef op woensdag 04 oktober 2006 @ 20:33:
[...]
Wat voor zinnige dingen kunnen je doen met de binaire data in SQL (in de WHERE clause), tov binaire data waarnaartoe verwezen wordt in een URI? Op het moment dat je zou kunnen gaan zoeken op patronen e.d in SQL wordt het een andere verhaal.
[...]
De metadata van een afbeelding verwijst meestal niet specifiek naar een pixel-word binnen de BLOB. en als het dat wel doet moeten zowel metadata als BLOB eerst uit de database worden gehaald, wil je er wat mee kunnen doen.
[...]
En over het hernoemen naar bv nummers: Dat is jammer. Dan gooi je de belangrijkste en meest basele metadata over de kling.

De overige nadelen van opslaan in een database zijn al eerder genoemd: trager dan laden vanaf het filesystem, een grote database wat dus langer duurt om te backuppen, lastige of dure replication, het feit dat plaatjes als binaire data slechts in kleine mate relationele data zijn.

Ik kies ervoor om de plaatjes onder hun originele naam op te slaan op het filesystem. Als een plaatje met die naam al bestaat, plak ik er een cijfer achter (smiley_1.gif). Gebruikers krijgen de mogelijkheid om zelf submappen in de /images-map aan te maken. Tijdens het uploaden wordt er automatisch een thumbnail (smiley_1.thumb.gif) aangemaakt. Beperkte meta-data wordt in de database opgeslagen. Voor het geval dat een gebruiker plaatjes liever via FTP naar de server kopieert, schrijf ik een synchronisatiescript dat via een crontab elk uur zal draaien. Ik plaats een mapje buiten de webroot waar plaatjes naar geupload kunnen worden die rights-managed moeten zijn. Met behulp van mod_rewrite zal het voor de eindgebruiker net zijn alsof hij vanuit de webroot downloadt: site.com/images/secure/plaatje.jpg. Als een plaatje vanuit deze map naar de images-dir in de webroot wordt verplaatst, vervallen alle ingestelde rechten en heeft iedereen toegang.

Ik ben er overigens van overtuigd dat er wel degelijk situaties zijn waarin plaatjes vanuit een database een logische keuze is, bijvoorbeeld voor een site als gettyimages.com (een photo-stock site). Plaatjes hernoemen naar een getal kan ook logisch zijn, als je dagelijks -tig artikelen met begeleidende plaatjes publiceert. Mijn CMS is echter een product dat een algemene functie heeft: het opzetten en onderhouden van een middelgrote website zonder specifieke functie (nieuws, e-commerce, etc.).

Ik voorzie wel enige problemen bij het schrijven van het synchronisatiescript (bijvoorbeeld: waar haal ik de user-id van de gebruiker die de plaatjes uploadt vandaan om bij de meta-data op te slaan als de gebruiker via FTP de plaatjes uploadt?) en de eventuele puinhoop die gebruikers van de submappen structuur in de /images map gaan maken. Misschien beperk ik het aanmaken van submappen wel, zowel qua niveau (dus: niet dieper mogelijk dan images/submap) en aantal.

Graag jullie reaktie! En alvast bedankt voor de discussie zover; deze is wat mij betreft erg zinvol