Hoe nieuws met veel plaatjes?

[Verwijderd]

Ik ben bezig met een website te maken die uit verschillende subwebsites bestaat(verder niet zo belangrijk). Elk van deze subwebsites heeft zijn eigen nieuws. Bij elk nieuwsitem kunnen er plaatjes worden toegevoegd door deze via het managementsysteem te uploaden. Van elk van deze plaatjes wordt ook een thumpnail gemaakt.

Nu vraag ik me af of het verstandig zou zijn in de database voor ieder plaatje een record aan te maken en hierin de naam van het plaatje enz op te slaan. En vervolgens alle plaatjes in een directory op de server te zetten. Maar kan een bestandssysteem zoals ntsf of Linux wel 10.000 of 100.000 plaatjes in een directory aan? Of is het misschien verstandiger om per nieuwsitem een subdirectory aan te maken met daarin alle plaatjes van dat nieuwsitem.

[DeverauX]

Maar kan een bestandssysteem zoals ntsf of Linux wel 10.000 of 100.000 plaatjes in een directory aan?

Ik denk niet dat dit problemen zal opleveren

Verder is het inderdaad de beste practice gewoon alle images in een bepaalde directory te plaatsen en vervolgens in de tabel waar je je nieuwsitems in vastlegt ook een veld bij te houden waar het pad naar de locatie van de image in vast wordt gelegd.
Zorg echter wel dat je op een gestructureerde manier te werk gaat!

[ACoolDude]

Je kunt binnen bijvoorbeeld MySQL een veld aanmaken van een bepaald type. Er is 1 bepaald type die max. 4GB aan karakters kan hebben.
Binnen dit veld kun je dus plaatjes opslaan e.d. Dan heb je gewoon 100.000 records in een nette en stabiele database.

[Verwijderd]

devraux schreef op 04 mei 2003 @ 09:51:
...

Zorg echter wel dat je op een gestructureerde manier te werk gaat!

Je bedoelt dat het verstandig zou zijn om dirs per nieuwsitem aan te maken?

ACoolDude schreef op 04 May 2003 @ 09:58:
Je kunt binnen bijvoorbeeld MySQL een veld aanmaken van een bepaald type. Er is 1 bepaald type die max. 4GB aan karakters kan hebben.
Binnen dit veld kun je dus plaatjes opslaan e.d. Dan heb je gewoon 100.000 records in een nette en stabiele database.

Ik wil de plaatjes zowiezo niet in de database opslaan. Dat wordt alleen maar trager. Ik heb het zelf nog nooit geprobeerd, maar ik hoor steeds dat je dat niet moet doen.

[ Voor 55% gewijzigd door Verwijderd op 04-05-2003 10:03 ]

[Ramon]

ACoolDude schreef op 04 mei 2003 @ 09:58:
Je kunt binnen bijvoorbeeld MySQL een veld aanmaken van een bepaald type. Er is 1 bepaald type die max. 4GB aan karakters kan hebben.
Binnen dit veld kun je dus plaatjes opslaan e.d. Dan heb je gewoon 100.000 records in een nette en stabiele database.

Lijkt me niet echt slim opzich. Volgens mij is een bestandssysteem veel efficienter in het serveren van plaatjes dan een database.

[ACoolDude]

IMHO is een zoekopdracht op MFT (disk) niveau trager dan een op een juiste wijze geindexeerde database en zeker als je met meerdere subdirs en +10.000 bestanden gaat werken.
Waar baseer jij je mening dat de database trager wordt als je er plaatjes inzet? Voor de database zelf maakt het niet uit of de string die in een veld staat je achternaam is of een string die uiteindelijk het hele plaatje vormt.

[DeverauX]

IMHO is het in ieder geval zeer onverstandig de images in de db te plaatsen aangezien dit het geheel toch minder flexibel maakt.

Wat ik bedoelde met gestructureerd is dat aangezien het feit dat het niet om enkele images zal gaan het misschien handig is in de bestandsnaam een verwijzing te maken naar het betreffende nieuwsitem waarin de image wordt gebruikt.

Als je nieuwsberichten zijn onder te verdelen in categorieën is het wellicht ook handig deze categorisering te handhaven in de structuur van je directory.

[gorgi_19]

ACoolDude schreef op 04 May 2003 @ 10:02:

IMHO is een zoekopdracht op MFT (disk) niveau trager dan een op een juiste wijze geindexeerde database en zeker als je met meerdere subdirs en +10.000 bestanden gaat werken.
Waar baseer jij je mening dat de database trager wordt als je er plaatjes inzet? Voor de database zelf maakt het niet uit of de string die in een veld staat je achternaam is of een string die uiteindelijk het hele plaatje vormt.

Laat een database doen waaar het goed in is: Snel gegevens opzoeken. Laat een filesystem doen waar het goed in is: snel bestanden weergeven. Een database wordt niet trager als je er veel plaatjes inzet. Hij wordt ook al trager als je er 1 plaatje in zet.

Zet alleen een link naar het juiste bestand in de database; het plaatje zelf kan je dan in je filesystem zetten.

Je kan me namelijk niet wijsmaken dat het sneller is om een plaatje op te halen uit de database en deze via een script te outputten naar de client. Een pagina met 10 plaatjes kost zo 11 databaserequests. 1 voor de plaatjes per pagina, en 10 voor de plaatjes. Daarnaast moeten ook nog die 10 plaatjes 'geconverteerd' worden via php, asp of whatever naar het juiste formaat.

Als je het filesystem er bij gebruikt, heb je maar 1 databaserequest nodig. 1 voor de plaatjes per pagina. De rest hoeft geen bewerking aan uitgevoerd te worden.

Als je heel veel plaatjes hebt, kan je bovendien ook nog overwegen om een fileserver neer te zetten.

[ Voor 8% gewijzigd door gorgi_19 op 04-05-2003 10:12 ]

[ACoolDude]

Mocht iemand zich bedenken en alsnog bestanden in een database willen proppen volgen hier enkele links....
http://www.phpbuilder.com...9991014.php3?print_mode=1
http://www.onlamp.com/pub/a/php/2000/09/15/php_mysql.html

[ Voor 17% gewijzigd door ACoolDude op 04-05-2003 10:13 . Reden: linkjes toegevoegd. ]

[DeverauX]

ACoolDude schreef op 04 May 2003 @ 10:02:
IMHO is een zoekopdracht op MFT (disk) niveau trager dan een op een juiste wijze geindexeerde database en zeker als je met meerdere subdirs en +10.000 bestanden gaat werken.

Maar waarom een zoekopdracht? Er wordt toch een concrete locatie gespecificeerd waar de betreffende image te vinden is?

Waar baseer jij je mening dat de database trager wordt als je er plaatjes inzet? Voor de database zelf maakt het niet uit of de string die in een veld staat je achternaam is of een string die uiteindelijk het hele plaatje vormt.

Welke string denk je dat langer is? Een die uiteindelijk een afbeelding moet vormen of een die alleen de locatie van de afbeelding aangeeft

[MisterData]

Ik heb in de database een tabel id-naam-path staan en in path staat dan een path naar een geupload plaatje. Hou er rekening mee dat het opvragen van plaatjes uit een database wel trager wordt als je een aparte databaseserver en webserver hebt. Het is daarom slimmer om de plaatjes op de webserver te zetten, omdat anders de webserver de plaatjes steeds bij de database-server moet opvragen

[ACoolDude]

OK, volgens http://groups.google.nl/g...540oslonett.no%26rnum%3D3 is het dus ook niet slim om je bestanden in de database zelf te zetten, maar wel om in je database een bestands-pointer te plaatsen. (een bericht uit 1995, maar databases zullen in de loop der tijd niet veel veranderd zijn....)

I rest my case. Suc6

[ Voor 13% gewijzigd door ACoolDude op 04-05-2003 10:18 ]

[Verwijderd]

Ja, ik denk eventjes door...

Is het niet een mooie tussenweg om voor elk nieuwsitem een apart db te openen?

Dan zit je niet met het probleem dat je 1 db hebt voor alle items met weet ik veel hoeveel plaatjes en omvang, maar ook niet met het probleem dat (bij veel requests) de cache en I/O van de schijf vollopen en het systeem gaan vertragen als er met een path-relatieve db wordt gewerkt.

[gorgi_19]

Verwijderd schreef op 04 May 2003 @ 10:21:
Ja, ik denk eventjes door...

Is het niet een mooie tussenweg om voor elk nieuwsitem een apart db te openen?

Nee. 1 aparte database per newsitem
1 database voor al het nieuws; om de boel te ordenen heb je queries nodig. Het hoort immers allemaal bij elkaar. 1 nieuwssite (de database) heeft 0 of meerdere nieuwsitems, met 0 of meerdere plaatjes per nieuwsitem.

Ik zie geen reden voor extra databases?

Dan zit je niet met het probleem dat je 1 db hebt voor alle items met weet ik veel hoeveel plaatjes en omvang, maar ook niet met het probleem dat (bij veel requests) de cache en I/O van de schijf vollopen en het systeem gaan vertragen als er met een path-relatieve db wordt gewerkt.

Daar waren we net met n'z allen al over uit dat je best een linkje kan doen in de database naar de juiste locatie..

Alle plaatjes opslaan en het goed serven:
Daar hebben ze ook fileservers voor uitgevonden als het te gek wordt, welke als enige taak heeft om het serven van plaatjes. Je komt dan weliswaar op meerdere servers uit, maar dit zou anders ook gebeurd zijn als je alles op 1 server houdt.

[ Voor 17% gewijzigd door gorgi_19 op 04-05-2003 10:26 ]

[Verwijderd]

Een andere optie die ik had bedacht is alleen een link naar een directory met daarin de plaatjes van een specifiek nieuwsitem. Dus niet per plaatje een record maar alleen een link naar een dir met daarin de plaatjes van het nieuwsitem. Vervolgens leest de voorkant alle plaatjes uit deze directory in en geeft ze weer. Dan zit je ook niet met het probleem dat als plaatjes gewist worden de links niet in de db meer kloppen.

[ Voor 34% gewijzigd door Verwijderd op 04-05-2003 10:39 ]

[Verwijderd]

Puntje van kritiek: er staat nergens genoemd op wat voor systeem de hele bende komt te draaien... Roep je: Himalaya, dan mag je wat mij betreft een db openen met ALLE data erin... Roep je 386, dan moet je toch iets anders verzinnen.

Dus, wat voor systeem, welk OS, welke db-server etc... Gezien mijn ervaring met db's en grote server-parken, kan ik misschien een duidelijker antwoord formuleren voor je.

[Verwijderd]

Verwijderd schreef op 04 May 2003 @ 10:35:
Puntje van kritiek: er staat nergens genoemd op wat voor systeem de hele bende komt te draaien... Roep je: Himalaya, dan mag je wat mij betreft een db openen met ALLE data erin... Roep je 386, dan moet je toch iets anders verzinnen.

Dus, wat voor systeem, welk OS, welke db-server etc... Gezien mijn ervaring met db's en grote server-parken, kan ik misschien een duidelijker antwoord formuleren voor je.

OS: Linux of Windows 2000
Server: dedicated (dacht dell), (weet niet precies hoe snel, ga ik niet over, maar het is een nieuwe server met 1gb werkgeheugen)

[ Voor 3% gewijzigd door Verwijderd op 04-05-2003 10:39 ]

[gorgi_19]

Verwijderd schreef op 04 mei 2003 @ 10:34:
Een andere optie die ik had bedacht is alleen een link naar een directory met daarin de plaatjes van een specifiek nieuwsitem. Dus niet per plaatje een record maar alleen een link naar een dir met daarin de plaatjes van het nieuwsitem. Vervolgens leest de voorkant alle plaatjes uit deze directory in en geeft ze weer. Dan zit je ook niet met het probleem dat als plaatjes gewist worden de links niet in de db meer kloppen.

Wat is daar het voordeel van? Een persoon mag namelijk imho geen enkel plaatje direct van het FS wissen. Dit mag alleen gebeuren 'via de database'. Dus of het loopt synchroon, of het gebeurd niet.

Je zult wel moeten zorgen voor een goede synchronisatie tussen het FS en de database.

Eveneens wat mensen doen: delen van plaatjes, dwz: plaatjes op meerdere locaties gebruiken. Of het moeten standaard / templateplaatjes zijn, of ze uploaden een plaatje maar 2 keer. Anders krijg je namelijk heel snel dubbele, gekke verwijzingen (naar plaatjes van andere nieuwsitems), waar binnen de kortste keren geen enkel onderhoudt maar aan te plegen is.

[ Voor 21% gewijzigd door gorgi_19 op 04-05-2003 10:41 ]

[Verwijderd]

gorgi_19 schreef op 04 May 2003 @ 10:39:
[...]
Eveneens wat mensen doen: delen van plaatjes, dwz: plaatjes op meerdere locaties gebruiken. Of het moeten standaard / templateplaatjes zijn, of ze uploaden een plaatje maar 2 keer. Anders krijg je namelijk heel snel dubbele, gekke verwijzingen (naar plaatjes van andere nieuwsitems), waar binnen de kortste keren geen enkel onderhoudt maar aan te plegen is.

Als een gebruiker een plaatje uit een bestaand nieuwsitem wil hergebruiken, hoe zou je dit het beste kunnen oplossen? Als gebruikers in 10.000 tot 100.000 plaatjes moeten gaan zoeken om de juiste te vinden gaat dat niet werken. Op naam zoeken is ook niet echt een oplossing denk ik.

[ Voor 5% gewijzigd door Verwijderd op 04-05-2003 10:47 ]

[gorgi_19]

Verwijderd schreef op 04 mei 2003 @ 10:46:
[...]


Als een gebruiker een plaatje uit een bestaand nieuwsitem wil hergebruiken, hoe zou je dit het beste kunnen oplossen? Als gebruikers in 10.000 tot 100.000 plaatje moeten gaan zoeken om de juiste te vinden gaat dat niet werken.

Opnieuw uploaden. Niet hergebruiken. Ik kan me voorstellen dat je 100 template plaatjes hebt (waar iedereen met z'n vingers vanaf moet blijven c.q. niet aan kan komen). Verder heb je ms 40 standaard plaatjes, welke als illustratie gebruikt worden.

En de rest gaan ze maar opnieuw uploaden.
"Ik wil plaatje x van nieuwsitem a gebruiken in nieuwsitem b". Dan moet je plaatje x voor nieuwsitem b nog maar een keertje uploaden.

[DeverauX]

"Ik wil plaatje x van nieuwsitem a gebruiken in nieuwsitem b". Dan moet je plaatje x voor nieuwsitem b nog maar een keertje uploaden.

Hier is imo een meer efficiente manier voor te bedenken, wat zou het probleem zijn het image-pad van nieuwsitem b gelijk te stellen aan die van a?
Voordeel is dat je ruimte op de server bespaard, eventueel nadeel is dat het het beheren van de afbeeldingen natuurlijk iets complexer maakt. (al moet dit met het leggen van relaties wel op te lossen zijn)
Kijk als dit een paar keer voorkomt is het natuurlijk geen probleem, maar stel dat van alle 100.000 images er 2500 duplicaten zijn
Ik denk dat dit een afweging is die je zal moeten maken. In ieder geval is de oplossing die Gorgi_19 je aanbiedt uiteraard eenvoudiger te implementeren, alleen wanneer de verwachting is dat veel van de images hergebruikt gaan worden (wat ik me eerlijk gezegd niet kan voorstellen maar stel) dan is uit efficientie-overwegingen wellicht beter te zoeken naar een manier waarin deze wel op een gestructureerde manier hergebruikt kunnen worden.

[gorgi_19]

devraux schreef op 04 May 2003 @ 11:04:
[...]

Hier is imo een meer efficiente manier voor te bedenken, wat zou het probleem zijn het image-pad van nieuwsitem b gelijk te stellen aan die van a?
Voordeel is dat je ruimte op de server bespaard, eventueel nadeel is dat het het beheren van de afbeeldingen natuurlijk iets complexer maakt. (al moet dit met het leggen van relaties wel op te lossen zijn)
Kijk als dit een paar keer voorkomt is het natuurlijk geen probleem, maar stel dat van alle 100.000 images er 2500 duplicaten zijn

Dit lijkt een vrij extreem voorbeeld. Echter, het is een illustratie bij een nieuwsitem. Ik kan me niet voorstellen dat deze groter zijn dan bijvoorbeeld 50 kb. Immers, groter en een pagina wordt 'onlaadbaar'

Laten we ook, voor het voorbeeld, 50 kb als gemiddeld nemen. Mijn oplossing kost dan dus 50kb * 2500 = 12500 kb, ongeveer 11 MB extra ruimte. Voor die 11 MB vraag ik me af of je hele moeilijke oplossingen moet nemen.

[DeverauX]

Laten we ook, voor het voorbeeld, 50 kb als gemiddeld nemen. Mijn oplossing kost dan dus 50kb * 2500 = 12500 kb, ongeveer 11 MB extra ruimte. Voor die 11 MB vraag ik me af of je hele moeilijke oplossingen moet nemen.

Ik gaf ook aan dat de oplossing die jij aanbiedt een is die eenvoudiger is
Daarnaast lijkt het mij ook niet voor de handliggend dat het hergebruik van afbeeldingen buiten-proportionele waarden zal gaan aannemen en het is dus idd een vrij extreem voorbeeld (Echter altijd goed om rekening mee te houden)

[BierPul]

Ik zou in ieder geval voor elke site een verschillende dir maken anders krijg je dat plaatjes elkaar gaan overschrijven en je zo ook andere sites lastig valt

Of natuurlijk checken of het plaatje al bestaat

[Apache]

Desnoods kan je voor je directory structuur gaan voor jaar/maand/ en misschien nog dag afhankelijk van de hoeveelheid images per maand. Aangezien je de "pointer" opslaat in je db maakt het niet uit waar het fysiek op de server staat.

Alle files in 1 dir zal het zoiezo wel wat trager maken, enkel reiserfs bied daar een duidelijk snellere oplossing dan andere filesystems.