Mappenindeling profielensite

[Verwijderd]

hallo ik wil graag weten hoe je bij een profielensite de fotos moet opslaan...ik neem aan dat niet alle fotos in 1 map worden gegooid..hoe pakken jullie dat aan..??

Het gaat dan om foto's van het profiel en bijvoorbeeld van een persoonlijk fotoalbum

de vraag is dus:

alles in 1 map bijv albums of in die albums submappen met de userid als naam en daarin de album pics

voordeel 1 map:
alles in een map

nadeel 1 map:
als je 4 miljoen fotos hebt duurt het wat lang

voordeel submappen
georganiseerd / fotos worden snel gevonden

nadeel
duizenden tot honderduizenden submappen

[Peedy]

Maar je de naam van de map (userid) is vast wel aan de rest gekoppeld d.m.v. een database. Ik vind je nadeel van 'duizenden tot honderduizenden submappen' dus niet echt een nadeel, meer een bijkomend effect van een goedlopende site

Overigens welkom op GoT

[ Voor 8% gewijzigd door Peedy op 27-09-2006 15:28 ]

[djluc]

Gewoon netjes in mappen zetten maar dan wel met een goede beheerstool. Dan zijn vele mappen geen enkel probleem.

[sariel]

Eeuhm.....geen mappen.
Zet alle plaatjes in een database. Kan je ze daarna weergeven zoals je wil, of dat nou in "directory structuur" of file-parameter vorm is. De database kan het wel aan, en je hebt minder gezeur als je gebruikers verwijderd. DB neemt dan meteen ook de plaatjes mee (als je dat tenminste instelt)

[Peedy]

sariel schreef op woensdag 27 september 2006 @ 15:22:
Eeuhm.....geen mappen.
Zet alle plaatjes in een database. Kan je ze daarna weergeven zoals je wil, of dat nou in "directory structuur" of file-parameter vorm is. De database kan het wel aan, en je hebt minder gezeur als je gebruikers verwijderd. DB neemt dan meteen ook de plaatjes mee (als je dat tenminste instelt)

Dat zal ik al helemaal niet doen, aangezien plaatjes uit een database als MySQL halen veel rekenwerk en tijd kost. Hij verwacht aan de TS te zien veel bezoekers, dus dan is plaatjes via een database opslaan veel tijdrovender dan via een filesystem.

Interessant stukje
Interessant stukje 2

[ Voor 14% gewijzigd door Peedy op 27-09-2006 15:27 ]

[Verwijderd]

voor de duidelijkheid..

de plaatjes worden op de server opgeslagen en de links er naar toe naar de database..

het probleem is wat is de goede oplossing??? de een zegt alles in een map de ander zegt elk lid een submap..ik vraag mij af wie het juiste antwoordt weet

[mrFoce]

ben ook met een profielen (plugin) bezig hier. Ik heb op de server een map Profielen. Hierin staat een map genaamd controls (met bepaalde plaatjes die gebruikt worden in de plugin), en voor elke gebruiker wordt (wanneer hij/zij een plaatje upload) een map aangemaakt met zijn/haar userID

[Peedy]

Er is in dit geval niet per sé een juist antwoord. Het gaat volledig om wat jij wilt bereiken; wil je snelheid voor de gebruikers, overzichtelijkheid voor jezelf, overzichtelijkheid voor de gebruikers (of juist niet), etc etc. Lees wat door over mappenstructuren en databasestructuren en maak op basis van die (vele) artikelen een keuze wat jij wilt doen.

[sariel]

Peedy schreef op woensdag 27 september 2006 @ 15:25:
[...]

Dat zal ik al helemaal niet doen, aangezien plaatjes uit een database als MySQL halen veel rekenwerk en tijd kost. Hij verwacht aan de TS te zien veel bezoekers, dus dan is plaatjes via een database opslaan veel tijdrovender dan via een filesystem.

Interessant stukje
Interessant stukje 2

Plaatjes uit databases halen is inderdaad wat trager. Maar hoeveel trager is een filesystem met plm 100k (niet al te veel profielen) aan bestanden/directories denk je? Ik heb een winbak gehad die zoveel mapjes had, en die stierf gewoon als je een explorer opende naar die map (dual P4 2ghz, 4g geheugen, win2k, iis, raid 1+0 hd). stekker trekken, en opnieuw booten.
als server wil je dat niet. zet het dan in een database, kost beetje performance, geeft hoop uptime.

heb je veel bezoek? loadbalanced database.

[Verwijderd]

welke vele artikelen? ik kom er geen tegen op het internet die hier over gaat..

plaatjes in de database? dat zegt iedereen vooral niet doen..

kijk we gaan zon 400000 of meer profielen krijgen...als je dan 10 pics per user laat uploaden heb je al 4 miljoen pics.....(en 400000 mappen)

ik wil graag weten wat het snelste en beste is om te doen

[djluc]

Je moet ze ook niet allemaal in 1 map zetten, dat is gewoon vragen om problemen. Verdeel ze bijvoorbeeld:
users0-1000
users1001-2000
Enzovoorts.

[Verwijderd]

djluc schreef op woensdag 27 september 2006 @ 15:40:
Je moet ze ook niet allemaal in 1 map zetten, dat is gewoon vragen om problemen. Verdeel ze bijvoorbeeld:
users0-1000
users1001-2000
Enzovoorts.

zijn dit mappen onder een hoofdmap? bijv ALBUMS??

moet je dus zelf die mappen aanmaken? en hoe check je dan of die vol is?

[sariel]

Tsja, je kan ook op naam doen:
Sariel -> /Profielen/s/a/r/iel/fotos/001.jpg
Sariel -> /Profielen/s/a/r/iel/fotos/002.jpg

Misschien zou het aardig werken. Probeer het, en zie of het lukt. Als het niet lukt, herschrijf de file-upload-module, de laat-plaatjes-zien-module en wijzig de links in de database.

[Janoz]

Zeker voor een profielensite heeft het opslaan van de images in de database grote voordelen. Security is makkelijker te regelen, Integriteit is beter af te dwingen en backups zijn makkelijker.

[TeeDee]

Verwijderd schreef op woensdag 27 september 2006 @ 15:41:
[...]


zijn dit mappen onder een hoofdmap? bijv ALBUMS??

moet je dus zelf die mappen aanmaken? en hoe check je dan of die vol is?

Dat is helemaal aan jou om te controleren/in te bouwen.

users0-1000 met een limiet van 10 files per user: reken maar uit 10.000 files op een filesystem stelt niet veel voor.

Janoz schreef op woensdag 27 september 2006 @ 15:45:
Zeker voor een profielensite heeft het opslaan van de images in de database grote voordelen. Security is makkelijker te regelen, Integriteit is beter af te dwingen en backups zijn makkelijker.

Ik ben het in zoverre met je eens: daar moet je dan toch wel redelijk wat verwerkings capaciteit tegenover zetten, maar als TS van '400000' profielen uitgaat neem ik ook aan dat er aardig wat capaciteit is.

nofi, maar je hebt het over een vrij grote site (>400k users/profiles) en je moet hier vragen hoe je het e.e.a. moet doen?

[ Voor 43% gewijzigd door TeeDee op 27-09-2006 15:49 ]

[Verwijderd]

een filesystem is neem ik aan gewoon je harddisk ...

ik denk dan toch submappen als ik het zo lees..

Sariel -> /Profielen/s/a/r/iel/fotos/001.jpg
Sariel -> /Profielen/s/a/r/iel/fotos/002.jpg

is idt niet makkelijker?

Albums/userid/pic1.jpg
Albums/userid/pic2.jpg

etc?

Zouden jullie een enkele profiel foto wel in 1 map keilen?

[Janoz]

Nadeel daarvan is dat je bij 40000 users ook 40000 directory entries krijgt. Er zijn filesystemen die daar wat traag van worden en er zijn er ook zlefs die dat helemaal niet toestaan.

Ik ben trouwens benieuwd hoe je de afscherming gaat doen, of worden alle foto's en albums openbaar.

[djluc]

Nadeel aan de database oplossing is vooral dat je voor elke afbeelding weer een connectie moet maken naar de database. Als je hardware dit kan verwerken is het uiteraard prima maar wel heftig: 1 pagina met 20 afbeeldingen zijn 21 verbindingen die gemaakt worden met de database. Het komt niet echt effcient over.

[Janoz]

Zolang je gebruikt maakt van connectie pooling (wat over eht algemeen gewoon gebeurt) is dat geen enkel probleem.

[Montaner]

Als ik jou was zou ik voor ieder profiel een map maken, en dan de afbeelding een logische naam geven, bijvoorbeeld user ID 1324 heeft 2 afbeeldingen, dan zijn ze namen:
13241.jpg
13242.jpg

Dan kan je dus ook dmv een simpel PHP stukje de afbeeldingen weergeven ipv een database query.

Succes .

[Janoz]

En is het vervolgens voor de gebruikers ook lekker makkelijk te gokken hoe ze bij alle plaatjes komen.

[Pete]

Ik zou denk ik voor iedere image een db-record aanmaken en dan de plaatjes gewoon in submappen gooien, gesorteerd op tijd bijv-> 2006->09->27

Op deze manier krijg je nooit teveel bestanden in 1 map (zowel dan maak je er ook nog een uurverdeling in). De beveiliging kun je gewoon aan de db-record koppelen en de files niet direct beschikbaar maken, maar doorlaten geven met een php-script.

[Janoz]

phsmit schreef op woensdag 27 september 2006 @ 17:24:
De beveiliging kun je gewoon aan de db-record koppelen en de files niet direct beschikbaar maken, maar doorlaten geven met een php-script.

Precies, en daarmee ben je gelijk alweer een deel van je snelheids voordeel kwijt aangezien je de bestanden door php moet halen.

[Pete]

Janoz schreef op woensdag 27 september 2006 @ 18:40:
[...]

Precies, en daarmee ben je gelijk alweer een deel van je snelheids voordeel kwijt aangezien je de bestanden door php moet halen.

Maar het lijkt me nog steeds sneller dan dat je de images in de db hebt opgeslagen. Zoiets als de gulden middenweg.

Het proberen te beveiligen van bestanden door gewoon moeilijk raadbare bestandsnamen te verzinnen klinkt mij nl. niet echt als beveiliging. (oftwel, direct uit het bestandssysteem is eigenlijk nooit beveiligd)

[aex351]

Afbeeldingen opslaan als bin in een database lijkt mij niet echt zo'n goed plan. Wat ik zou doen is inderdaad mappen aanmaken op userID en vervolgens de afbeeldingen daarin opslaan. De links ernaar toe inc naam sla je gewoon op in een db. En links naar de afbeeldingen toe op de website zelf doe je dan via een PHP script. Op deze manier heb je toch altijd controle over de naam van een afbeelding etc gezien je deze makkelijk en snel via de database kan veranderen.

Nadeel is natuurlijk wel dat indien je afbeeldingen gaat verplaatsen je ook direct de mysql gegevens moet updaten. Maar of dat zo heel erg is !

[Janoz]

Wat ik meer met mijn postings wil laten zien is dat files fanuit het filesysteem serveren helemaal niet zo voor de hand liggend is. Natuurlijk is het sneller om apache rechtstreeks een bestand op te laten halen ivm een php script dat een bestand uit de database moet halen. Echter zie je in deze discussie gelijk al dat een deel van dit voordeel alweer teniet gedaan wordt omdat er weer een security laag tussen moet. Daarnaast is efficientie alleen in de meeste omstandigheden bij lange na niet de enige randvoorwaarde. Je hebt niks aan een rete snel efficient systeem dat zo lek is als een mandje (security by obscurity is no security at all ).

Conclusie: Er is niet per definitie een enkele juiste keuze in de DB vs FS discussie

[Janoz]

Aangezien dit topic meer over ontwerp beslissingen gaat verplaats ik het naar SEA

[Verwijderd]

aex351 schreef op woensdag 27 september 2006 @ 22:36:

Nadeel is natuurlijk wel dat indien je afbeeldingen gaat verplaatsen je ook direct de mysql gegevens moet updaten. Maar of dat zo heel erg is !

Waarom zou ik gaan verplaatsen? En in de database staat alleen de naam van het plaatje dus iets als 123.jpg

dus niet de url die staat in een php file dus die kun je in 1 sec veranderen..

maar nog een vraag..iedereen heeft het over plaatjes beveiligen..waarom zou je dat doen? ze kunnen toch gewoon opslaan of printscreen gebruiken?? of zie ik nu iets over het hoofd qua beveiliging

[faabman]

Verwijderd schreef op donderdag 28 september 2006 @ 07:45:
[...]
of zie ik nu iets over het hoofd qua beveiliging

Ja, het uberhaupt kunnen bereiken van een plaatje...

[Verwijderd]

faabman schreef op donderdag 28 september 2006 @ 08:24:
[...]

Ja, het uberhaupt kunnen bereiken van een plaatje...

van mij mogen ze:) of bedoel je iets anders?

[webfreakz.nl]

Er is hier in NOS ook eens een topic over geweest van de beheerder v/d site www.sugababes.nl wat ook een profielen site is. Je zou het topic kunnen opzoeken en/of zo'n site eens een mailtje sturen.

Modbreak: Verbasteringen van bedrijfsnamen zoals Micro$oft en dergelijke staan we niet toe, dus ongefundeerd ranten op profielensites als SugaBabes ook niet. Laat die overdreven smilies dus liever achterwege.

[ Voor 36% gewijzigd door NMe op 28-09-2006 18:23 ]

[MBV]

Verwijderd schreef op donderdag 28 september 2006 @ 14:00:
[...]


van mij mogen ze:) of bedoel je iets anders?

Als het geen probleem is om alle plaatjes van iedereen te mogen zien, dan kan je ze idd gewoon in mappen neerzetten. Als je wilt dat gebruikers afgeschermde plaatjes kunnen maken zal je iets aan beveiliging moeten doen.

Maar zet dus niet alle 400.000 profielen in dezelfde map, dan wordt je filesystem traag. Per duizend in een aparte map lijkt me een mooi begin, en is zoals gezegd makkelijk aan te passen met een script

[ Voor 20% gewijzigd door MBV op 28-09-2006 17:53 ]

[Verwijderd]

heb je ook een voorbeeldje daarvan????of een opzetje?

aub

[ Voor 5% gewijzigd door Verwijderd op 28-09-2006 19:33 ]

[Janoz]

Mwah, de uitleg lijkt me redelijk duidelijk. Wat stel je je uberhaupt bij 'een voorbeeldje' voor?

[Alex)]

Mijn idee:

code:

+               siteroot
\albums         albums
  \a
   \l
    \e
     \alex
      \pic1.jpg
      \afb2.png
      \plaatje.bmp

Op deze manier kun je snel zoeken als je ooit via FTP er komt. Met een .htaccess in \albums kun je hotlinking vanaf andere sites voorkomen. En met een filemanager en een database kun je alles precies in de gaten houden (piet mag nooit in \a komen, laat staan in \a\l\e\alex)

[Freezerator]

Ik weet dat vbulletin dit opvangt door de volgende structuur. Daar wordt trouwens ook afgeraden om veel images in je db op te slaan omdat dit een negatief effect heeft op de performance. Je kan je plaatjes bv via lighttpd oid laden.

Maar die hebben de structuur voor bv user 13785:
/images/1/3/7/8/5/filenummer1.attach

User 1378 zou dezelfde structuur hebben, alleen zijn files zijn een level up.
/images/1/3/7/8/filenummer2.attach

Ik gebruik dit systeem ook, en met 25.000 users ondervindt ik geen problemen op een linux setup.

[Verwijderd]

Freezerator schreef op donderdag 28 september 2006 @ 19:42:
Ik weet dat vbulletin dit opvangt door de volgende structuur. Daar wordt trouwens ook afgeraden om veel images in je db op te slaan omdat dit een negatief effect heeft op de performance. Je kan je plaatjes bv via lighttpd oid laden.

Maar die hebben de structuur voor bv user 13785:
/images/1/3/7/8/5/filenummer1.attach

User 1378 zou dezelfde structuur hebben, alleen zijn files zijn een level up.
/images/1/3/7/8/filenummer2.attach

Ik gebruik dit systeem ook, en met 25.000 users ondervindt ik geen problemen op een linux setup.

inderdaad zie ik dit wel eens voorbij komen

maar hoe doe je dat? moet je dus veel mapjes aanmaken? en wat is het voordeel daarvan dan??dat zie ik nog niet helemaal

wat is het verschil of je gewoon zo doet: /images/1/3/7/8/filenummer2.attach of /images/1378/filenummer2.attach doet???

#Janoz

nou een voorbeeld hoe dat aan te pakken...hoe weet je of een map vol is en dat de andere map gebruikt moet gaan worden

[Verwijderd]

wat is het verschil of je gewoon zo doet: /images/1/3/7/8/filenummer2.attach of /images/1378/filenummer2.attach doet???

Voordeel hiervan is dat er in iedere map maximaal 10 submappen zitten. Bij het gebruik van /images/1378/... is het aantal mappen gelijk aan het aantal leden wat hopelijk groter is dan 10 .

Als iedereen de afbeeldingen mag zien is het gebruik van je filesystem waarschijnlijk voldoende en is de bovenstaande manier prima. Persoonlijk zou ik ook wel iets zien in het gebruik van SQLite, zeker wanneer veiligheid wel een issue is. Gebruik hiervan maakt het mogelijk om bestanden in een RDBMS op te slaan welke snel te accessen is. Hoewel ik het idee nu bedenk lijkt het me interessant om eens te bekijken (maar misschien zijn er wel grote nadelen).

[mulder]

Gebruik hiervan maakt het mogelijk om bestanden in een RDBMS op te slaan welke snel te accessen is. Hoewel ik het idee nu bedenk lijkt het me interessant om eens te bekijken (maar misschien zijn er wel grote nadelen).

Is dat wel zo? Volgens mij is een filesysteem nog wel sneller. (Wat al een soort db is in feite)

[Verwijderd]

Don Facundo schreef op vrijdag 29 september 2006 @ 10:23:
[...]

Is dat wel zo? Volgens mij is een filesysteem nog wel sneller. (Wat al een soort db is in feite)

Waarschijnlijk is een filesysteem sneller, dat zal ik niet ontkennen. Ik weet wat van filesystems af maar ik ben geen expert op dat gebied. Ik kan me echter voorstellen dat het ook redelijk wat tijd kan kosten om de afbeelding (van user 147543) in de map /images/1/4/7/5/4/3/afb1.jpg op te halen (afhankelijk van de diepte van je tree), misschien dat anderen daar meer over weten.

Het lezen vanuit SQLite zal redelijk vlug zijn t.o.v. andere db's aangezien er geen interprocescommunicatie nodig is. Daarnaast is de betreffende BLOB vlug op te zoeken middels een index.

[TeeDee]

Doel je hier specifiek op SQLite of heb je het hier over een willekeurige RDBMS? In het geval van SQLite, leg eens uit waarom die sneller zou zijn?

[NMe]

Verwijderd schreef op vrijdag 29 september 2006 @ 08:01:
[...]

wat is het verschil of je gewoon zo doet: /images/1/3/7/8/filenummer2.attach of /images/1378/filenummer2.attach doet???

De diepte in je filesystem.

#Janoz

nou een voorbeeld hoe dat aan te pakken...hoe weet je of een map vol is en dat de andere map gebruikt moet gaan worden

Simpel toch? Domweg tellen hoeveel bestanden er in je mapje staan lijkt me niet zo lastig? Nog los ervan dat je andere criteria kan kiezen om te zien of een map vol is; wanneer je bijvoorbeeld mappen per userid indeelt.

[Verwijderd]

Verwijderd schreef op vrijdag 29 september 2006 @ 10:03:
[...]
Voordeel hiervan is dat er in iedere map maximaal 10 submappen zitten. Bij het gebruik van /images/1378/... is het aantal mappen gelijk aan het aantal leden wat hopelijk groter is dan 10 .

misshien ben ik een digibeet maar ik zie hte nog niet helemaal ..wel bijna

ik heb een hoofdmap images

/images

ik ben een user 12345

krijg je dus IN de map images 5 submapjes namelijk 1,2,3,4,5 (wordt dus /images/1/2/3/4/5/plaatje.jpg)

de volgende user is 12346

krijg je dus /images/1/2/3/4/6/plaatje.jpg

maar hoe doe je user 1 dan? Ik begrijp dus niet hoe dit te implementeren...moet je zelf al die mapjes aanmaken of laten creeeren en hoe stop je dan alles in het goede vakje?

ik snap vooral niet hoe dit aan te maken (ik bedoel meer de logistiek)

[Verwijderd]

Ja, ik doel hier specifiek op SQLite. Ik beweer overigens niet dat SQLite sneller is dan een filesystem maar ik wil niet op voorhand aannemen dat een filesystem altijd sneller is. Daarnaast denk ik dat de overhead van SQLite minimaal is, zeker in vergelijking met een ander RDBMS.

TeeDee schreef op vrijdag 29 september 2006 @ 10:49:
...leg eens uit waarom die sneller zou zijn?

Ik zal een poging wagen .
Wanneer gebruik gemaakt wordt van de beschreven folder structuur kan het zijn dat in ieder folder gezocht moet worden naar de volgende folder, een sooft van linked list. Mijn expertise op het gebied van filesystems schiet hier danig te kort dus ik weet niet hoe snel dit is maar in een worst-case scenario kan ik me voorstellen dat iedere folder van disk af gehaald moet worden om daarna pas de inhoud te kunnen bekijken (correct me if I'm wrong). Dit zijn dus 6 lees acties om bij de file uit te komen.

Bij het gebruik van SQLite kun je aan iedere afbeelding een userId en fileId knopen en een index over beide laten genereren. Hierbij wordt er gebruik gemaakt van een B-tree die een directe verwijzing maakt naar de locatie van de BLOB (record) in de file. Deze B-tree zal waarschijnlijk niet dieper zijn dan drie lagen (ervaring) waardoor er maar 3 lees acties nodig zijn om bij het bestand te komen.

Hierbij moet nog worden opgemerkt dat:

• er een indirectie zit tussen de SQLite file en de fysieke opslag op de harde schijf die nadelige gevolgen kan hebben voor de performance van SQLite. Maar dat probleem kan je ook op een filesystem hebben (fragmentatie);
• dit de korte uitleg is. Er zijn nog vele op- en aanmerkingen te maken waarvoor een goede kennis van SQLite noodzakelijk is.

Verder kunnen er andere problemen bij het gebruik van SQLite zijn wanneer er bijvoorbeeld veelvuldig updates worden uitgevoerd (locken van de complete database), maar dat even terzijde.

[Verwijderd]

Verwijderd schreef op vrijdag 29 september 2006 @ 11:14:
maar hoe doe je user 1 dan? Ik begrijp dus niet hoe dit te implementeren...moet je zelf al die mapjes aanmaken of laten creeeren en hoe stop je dan alles in het goede vakje?

Wat dacht je van images/0/0/0/0/0/1/afb1.jpg . Idd alle mappen zelf aanmaken en beheren.

[Dutch2007]

eventussen door..


en iets als zoals ze dat met gallery2 doen?

http://gallery.menalto.com/

en met apache re-write, is het


http://domain.com/user (je kan zeggen elkes keer als user registreerd dat ie dan new map aanmaakt)

[Verwijderd]

ok dus je moet alvast rekening houden met het aantal leden

zeg max 7 mapjes dan zit je altijd goed

drie vraagjes...

1.ik heb even bij TMF gekeken en die doen de laatste 4 cijfers van het userid..welke truck is dat? terwijl ze toch meer dan 500000 leden hebben...

2. hoe kun je een userid uit elkaar trekken? stel ik heb 2345 als string of integer..er valt niks te exploden?

3. op deze manier hoef je niet te tellen of een map volzit toch?

[Verwijderd]

Verwijderd schreef op vrijdag 29 september 2006 @ 11:26:
...

Heb je wel enig idee wat je aan het doen bent? Iets gaan maken waarvan je zelf niet weet hoe het werkt gaat zeer waarschijnlijk fout. Probeer eerst voor jezelf duidelijk te krijgen wat je wilt en hoe je het wilt oplossen!!! Overtuig jezelf ervan dat de oplossing werkt zoals jij het bedoelt. Ik krijg nu een beetje het idee dat je totaal niet weet waar je mee bezig bent.

[TeeDee]

Verwijderd schreef op vrijdag 29 september 2006 @ 11:16:

Mjah, een blob in een db uitlezen lijkt mij persoonlijk iets trager dan een FileSystem. Er zijn gewoon voor- en nadelen aan beide manieren.

Verwijderd schreef op vrijdag 29 september 2006 @ 11:18:
[...]
Wat dacht je van images/0/0/0/0/0/1/afb1.jpg . Idd alle mappen zelf aanmaken en beheren.

Wat dacht je van images/1/afb1.jpg

Verwijderd schreef op vrijdag 29 september 2006 @ 11:26:
ok dus je moet alvast rekening houden met het aantal leden

nee, je houdt rekening met je capaciteit, en dat heeft niks met je afbeeldingen te maken.

zeg max 7 mapjes dan zit je altijd goed

Doe dat gewoon lekker dynamisch... zit je altijd goed

1.ik heb even bij TMF gekeken en die doen de laatste 4 cijfers van het userid..welke truck is dat? terwijl ze toch meer dan 500000 leden hebben...

Mail TMF hiervoor? Zo moeilijk is het niet, maar of het een verstandige keuze is is een 2e.

2. hoe kun je een userid uit elkaar trekken? stel ik heb 2345 als string of integer..er valt niks te exploden?

De userid karakter voor karakter door loopen?

3. op deze manier hoef je niet te tellen of een map volzit toch?

Eer dat je aan de limit van de huidige filesystems, dat duurt nog wel even.

[Verwijderd]

Mjah, een blob in een db uitlezen lijkt mij persoonlijk iets trager dan een FileSystem. Er zijn gewoon voor- en nadelen aan beide manieren.

Ik denk het ook maar en in dit geval is het gebruik van mappen goed.

[...]
Wat dacht je van images/1/afb1.jpg

Kan ook maar ik weet niet of dat beter is . Stel user 1 heeft 200.000 bestanden in zijn profiel staan ... wat doet dat me de performance voor user 135543 die zijn bestanden in map /images/1/3/5/5/4/3/ heeft staan?

[ Voor 8% gewijzigd door Verwijderd op 29-09-2006 12:01 ]

[Verwijderd]

Heb je wel enig idee wat je aan het doen bent?

kijk ik probber hier uit te zoeken hoe je dus album fotos kunt opslaan dus ik probber fouten te voorkomen door er nu al over na te denken..dit is het enige forum waar ze het een beetje weten en zo leer ik het

ja is het niet beter om achterste voren de userid en de mappen te maken?

dus ipv

/images/1/2/3/4/plaatje.jpg

doe je

/images/0/4/3/2/1/plaatje.jpg

dan heb je maar 1 nul ???

o ja hoe zouden jullie de thumbs opslaan?

zelfde principe dus /thumbs/1/2/3/4/5

of in /images/1/2/3/4/thumbs/t_plaatje.jpg

??

[Verwijderd]

Verwijderd schreef op vrijdag 29 september 2006 @ 12:24:
[...]

kijk ik probber hier uit te zoeken hoe je dus album fotos kunt opslaan dus ik probber fouten te voorkomen door er nu al over na te denken..dit is het enige forum waar ze het een beetje weten en zo leer ik het

Van te voren probberen () is natuurlijk goed, maar als je een profielensite met 400.000(!!!) gebruikers gaat opzetten lijkt me dit nog wel 1 van de kleinere (architecture) problemen. Of doe jij alleen het foto gedeelte?

[engelbertus]

je legt vast hoeveel mb en hoeveel stuks fotos een gebruiker mag opslaan en dat kun je wel controleren door dat bij te houden in een database. ik denk dat als je een filesystem / database vergelijkt je ook moet kijken dat een leesactie van schijf ook een leesactie in de db is. en dat die db ook van schijf moet komen?

voordeel van database is dan dat je makkelijker de limieten voor de gebruikers, en overzichten voor gebruikers kunt genereren uit de database. voor de gebruiker is alleen het erformance verschil tussen beiden belangrijk.

uiteindelijk werk je voor de gebruikeren moet je overzicht kunnen hebben.

de manier van op limieten checken kan ook zonder dat in een database bij tehouden, en bijvoorbeeld snachts een check te doen, en per upload een limiet op de MB zetten. anders heb je straks dat mensen complete images van dvd op je server gooien, om ze makkelijk te kunnen delen, je mert er namelijk niets van als je snacht controleert op quotas en zo.

uiteindelijk maakt het niet uit qwelke anier je een userid uit elkaar trekt, maar wil je wel graag dat navigeren door de directoriestructuur goed en snel gaat, en je dus de bestanden uitsluitend in de laatste directorie van een structuur hebben, anders heb ej op elk nivo kans dat een of meerdere van de gebruikers een serieuze hoeveelheid entries in een tussenliggende map maakt.

je kunt dus denk ik het beste kiezen de userid niet om te draaien, en de userid in een script om te zetten naar een id met vaste lengte, door er nullen voor te zetten, dan kun je tijdens onderhoud je directoriestructuur ff omgooien door een extra laagje toe te voegen zodat je weer 10 keer meer gebruikers toe kunt voegen, en in de scripts voor userid-map conversie doe je er gewoon een extra 0 voor zetten.

werk je met linux dan is directoriestructuur evt. snel met een symlink uit te breiden, zodat de downntime nagenoeg 0,0 hoeft te zijn.

wil je het nog beter dan kun je het vergroten van de userid capaciteit meteen meeprogrameren in de cripts, alleen lijkt het me niet echt handig ivm security. als je directories laat toevoegen door een script. dan kunnen ze de hele zooi in de war schoppen bij een klein lekje.

[Verwijderd]

probberen die site is al bijna klaar alleen deze architectuur nog

wauw het is haast hogere wiskunde:)

het rare is dat je hier nergens tutorials over tegenkomt of als je eenboek koopt wordt dit helemaal niet behandeld

ik had nog twee vraagjes/opmerkingen:

1. hoe zouden jullie de thumbs opslaan?

zelfde principe dus /thumbs/1/2/3/4/5

of in /images/1/2/3/4/thumbs/t_plaatje.jpg

??

2. Je kunt het maximum toch ook bepalen door in je dtatabase te tellen? Stel ik mag 10 fotos uploaden, dan staan er ook 10 linkverwijzingen in je database. Als ik dus 10 fotos hebt laat je gewoon het uploadformulier niet zien..of denk ik simpel? of is het op de server/map tellen sneller?

[ Voor 4% gewijzigd door Verwijderd op 29-09-2006 13:08 ]

[TeeDee]

Verwijderd schreef op vrijdag 29 september 2006 @ 13:07:
probberen die site is al bijna klaar alleen deze architectuur nog

Proberen Maar ben je er niet een beetje laat mee om hier nog over na te denken.

wauw het is haast hogere wiskunde:)

het rare is dat je hier nergens tutorials over tegenkomt of als je eenboek koopt wordt dit helemaal niet behandeld

Heeft niks met wiskunde of een boek te maken. Maar inzicht en logica.

zelfde principe dus /thumbs/1/2/3/4/5

Nope

of in /images/1/2/3/4/thumbs/t_plaatje.jpg

Dat is het logisch, alleen zou je er ook nog over na kunnen denken om de thumbs door een script on demand te kunnen laten zien.

[Verwijderd]

TeeDee schreef op vrijdag 29 september 2006 @ 13:15:
[...]

Proberen Maar ben je er niet een beetje laat mee om hier nog over na te denken.


Dat is het logisch, alleen zou je er ook nog over na kunnen denken om de thumbs door een script on demand te kunnen laten zien.

1. Eigenlijk wel..maar overal zeggen ze gooi het maar in 1 map of voor elke user een aparte map..

ik zat erover na te denken en dacht dat dat niet echt slim zou zijn maar niemand wist hoe anders dus kwam ik hier gelukkig

"Dat is het logisch, alleen zou je er ook nog over na kunnen denken om de thumbs door een script on demand te kunnen laten zien."

kan ook maar is mij ontraden want dat kost veel load naar de server en minder snel

dus een boek of tut is wel logisch..dan leert iedereen het meteen goed

edit: hier van nog en profeil site:

http://www.xxx.nl/dg/mime...b9f0f1ddb25272b0e_new.jpg

volgens mij creeren zij 3 mappen van de eerste 9 karakters van die gecodeerde string. dan krijg je echt wel tig mappen

[ Voor 20% gewijzigd door Verwijderd op 29-09-2006 14:46 ]

[Freezerator]

Je kan bv de orginele filenaam + grootte tijdens het uploaden in de db zetten. Stel de filename is bla.jpg, maar jij kan het opslaan als 00001.attach. Voordeel is dat users niet direct je plaatjes kunnen benaderen, dit moet via jouw software zodat je ook eventueel rechten eraan kan koppelen.

ALs je tijdens het uploaden de filegrootte vastlegt, zal je ook dus maximums kunnen stellen per user. Je zal dan ook geen mappen krijgen met 200.000 files erin, want ik neem aan dat je users niet unlimited space geeft? Thumbs genereer je tijdens het uploaden ook meteen, en geef je bv een 2e filenaam, bv 00002.attach? Belangrijkste is denkik dat je het schaalbaar houd, dus eventueel de mogelijkheid tot een aparte image server en een aparte www server en apart db server. Als je gaat coden, zorg voor een goede basis zodat je in de toekomst minder problemen hebt als het echt druk wordt en je dan makkelijker kan uitbreiden.

[engelbertus]

sorry voor de caps hieronder (Modbreak: doe het dan ook niet. ), maar eehm de thumbs zou ik gewoon in dezelfde dir als de plaatjes doen. voordat er dan teveel files in een directorie komen valt wel mee, als je toch per user / map hebt opgeslagen. en anders is een alternatief de thumbs in een submap van de plaatjesmap te gooien.
dan kun je altijd nog de thumbs er appart afgooien en bijvoorbeeld nieuwe maken als je besluit grotere of kleiner thumbs te gaan gebruiken, of een beetr script hiervoor wilt gebruiken.

Een script om een thumb te maken, volgens mij was een thumbnail vooral bedoeld om trafic te sparen, terwijl nu alle grote plaatjes tochvan schijf gelezen moeten worden om er dan een thumb van te maken. Haal dan het hele plaatje ook binnen bij de gebruikers, dan hoeft niet later weer het grote plaatje opgehaald te worden.

[ Voor 75% gewijzigd door NMe op 29-09-2006 15:34 ]

[EdwinG]

engelbertus schreef op vrijdag 29 september 2006 @ 14:54:
een script om een thumb te maken, volgens mij was een thumbnail vooral bedoeld om trafic te sparen, terwijl nu alle grote plaatjes tochvan schijf gelezen moeten worden om er dan een thumb van te maken.

Gelukkig gebeurt het maken van de thumbnail op de server, en wordt alleen het resultaat naar de client verstuurd.

edit:
strtolower() over de quote gehaald

[ Voor 41% gewijzigd door EdwinG op 29-09-2006 15:32 ]

[Verwijderd]

ah mooi..maar Freezerator (of iemand anders)

ik denk dat dit het best is ja dus met /images/1/2/3/4/5/plaatje.jpg en daarin ook de thumbs

maar ik twijfel nog of de opzet van TMF niet beter is...

die hebben max 4 subfolders:

/fotos/1/2/3/4/0000001234.jpg

dit staat mooier dan

/fotos/0/0/0/0/0/1/2/3/4/plaatje.jpg

en geeft minder mappen maar wel meer files per map ..volgens mij

[*CableGuy*]

Foto's in een database zetten moet je absoluut niet doen, dit is een enorme speedhog (je connecties blijven heel lang open terwijl ze data streamen), het is er niet voor bedoeld (los van het feit dat het kan) en een dump van je database wordt ontzettend groot.
Zolang je niet zoveel profielen/bezoekers hebt maakt dit niet zoveel uit, maar met 2 miljoen+ gebruikers ECHT wel.

Je moet gewoon folders maken met ranges/limiet op aantal fotos. Dit kun je naar eigen inzicht invullen: per aantal gebruikers, per gebruiker, geneste hierarchische structuur. Bedenk dat 10.000 of 20.000 files in een folder geen probleem is, je slaat immers in je database de locatie op. Alleen als je in bijvoorbeeld windows explorer zo'n map wilt bekijken krijg je problemen, dan kun je kiezen voor bijvoorbeeld 500-1000 files per folder.

Oh, en nog een opmerking: thumbnails maken on demand is een verspilling van je cpu-tijd. Leuk dat het kan, maar niet doen dus. Thumbnails gewoon opslaan op disk bij het uploaden, zorg wel dat je alle IPCT/EXIF data eraf stript want zeker voor kleine images neemt het een aanzienlijk deel van de bestandsgrootte voor z'n rekening. Opslagruimte is minder kostbaar en beter uit te breiden dan cpu-tijd.

[ Voor 19% gewijzigd door *CableGuy* op 29-09-2006 16:10 ]

[Freezerator]

Verwijderd schreef op vrijdag 29 september 2006 @ 15:49:
ah mooi..maar Freezerator (of iemand anders)

ik denk dat dit het best is ja dus met /images/1/2/3/4/5/plaatje.jpg en daarin ook de thumbs

maar ik twijfel nog of de opzet van TMF niet beter is...

die hebben max 4 subfolders:

/fotos/1/2/3/4/0000001234.jpg

dit staat mooier dan

/fotos/0/0/0/0/0/1/2/3/4/plaatje.jpg

en geeft minder mappen maar wel meer files per map ..volgens mij

In principe maak het toch niet zoveel uit voor de mooiheid? De einduser laat je niks merken, want die laadt bv gewoon image.php?=idvanhetplaatje

Denk de voor en nadelen performance wise al besproken zijn van de verschillende structuren in dit topic

[Verwijderd]

optroodt schreef op vrijdag 29 september 2006 @ 16:03:
Thumbnails gewoon opslaan op disk bij het uploaden, zorg wel dat je alle IPCT/EXIF data eraf stript

wat is dat?

[Alex)]

Dat zijn gegevens zoals: waarmee is de foto gemaakt? Wanneer? Met welke lens? Met welk programma is het bewerkt? Wat is de resolutie? etc etc.

[RobIII]

Verwijderd schreef op zaterdag 30 september 2006 @ 09:03:
[...]


wat is dat?

Kom op zeg...
http://en.wikipedia.org/wiki/Exif

[ Voor 21% gewijzigd door RobIII op 30-09-2006 16:29 ]

[Verwijderd]

ok..sorry

[Verwijderd]

hmmm..ik moet dus als ik dit doe:

/images/0/0/0/1/plaatje.jph

400 mappen aanmaken! ben ik wel een week zoet mee of kan dat sneller?

[MBV]

ehm, waarom maak je die mappen van te voren aan? Die maak je toch dynamisch aan zodra je ze nodig hebt? Of je maakt het simpelst mogelijke php-scriptje dat even die mappen voor je aanmaakt, doe ik voor je in 4 (onleesbare) regels of 8 leesbare.

* MBV vraagt zich heel sterk af hoe jij die profielensite hebt kunnen bouwen, en nog sterker of hij wel die geplande 400.000 bezoekers aan zal kunnen, inclusief veiligheidskwesties....

[Verwijderd]

als je wat code wilt laten graag:)

nou die fotos architectuur opslaan is een vak apart! ik was er van uitgegaan om alles in 1 map te proppen of desnoods voor elke userid een map aan te maken..dus de rest is niet zo moeilijk..maar de bedoeling was als je zon structuur neemt als we hierboven bespreken je het met de hand moet aanmaken

/images/0/0/0/0/1 staat voor userid 1
/images/1/3/4/5/6 staat voor userid 13456

dus die mappen zijn van te voren aangemaakt(zie posts hiervoor)


als dit vooraf automatisch kan graag

[MBV]

Ja dag . Ik bedoel meer dat het zo simpel is dat je het zelf best moet kunnen doen. Ok, 2 hints:
http://nl3.php.net/for i
http://nl3.php.net/for j
http://nl3.php.net/for k
http://nl3.php.net/for l
http://nl3.php.net/mkdir
Enneh, als je het nu nog niet weet mag je je beginnerscursus php gaan doen, of natuurlijk voor straf 10.000 mappen aanmaken

[Verwijderd]

Of je maakt het simpelst mogelijke php-scriptje dat even die mappen voor je aanmaakt, doe ik voor je in 4 (onleesbare) regels of 8 leesbare.

je stelde het zelf v oor..

ok..ik weet wel wat een for loop is en mkdir
er moeten wat for loopen in for loopen

waarom zet je 4 links naar hetzelfde? of is dat eenhint van 4 for loopen in elkaar

[Janoz]

Shigella, een interessante discussie over de manier van opslag van bestanden voor een mogelijk grote site is 1 ding. Constant bij de meest simplistische dingen om vragen om voorbeeldcode en uitleg is een ander. Door die eerder genoemde discussie is dit topic nog open. Als het echter uiloopt in een 'bij het handje neem' topic waarbij de meest futiele dingen moeten worden voorgedaan en er nauwelijks enige ondernemingsdrang bij jezelf is (bv door EXIF in google in te tikken), dan gaat hij alsnog op slot.

[NMe]

Verwijderd schreef op vrijdag 29 september 2006 @ 11:36:
Ik krijg nu een beetje het idee dat je totaal niet weet waar je mee bezig bent.

Ik kan eigenlijk niet anders dan dat concluderen inderdaad. De vragen die ik hier voorbij zie komen zijn ofwel met een beetje zoeken ofwel met wat gezond verstand ook wel op te lossen. Het topic begon leuk, maar nu verzandt het een beetje in een basaal topic waarin iedereen de topicstarter aan het handje moet nemen, en dat zien we hier liever niet. Vandaar ook dat ik dit topic ondanks Janoz' melding hierboven sluit.