30.000 bestanden in een dir werkt dat nog?

[muis|IA]

Ik heb hier voor een site, zo'n 30.000 bestanden die opgevraagd moeten kunnen worden. De bestanden zijn allemaal rond de 2Kb. Is het verstandig om dit in 1 directory te zetten of wordt het super traag als ik met mijn php scrippie een bestand hiervan wil openen en inlezen? Een DB hiervoor gebruiken kan (nog) niet omdat ik tot nu toe niet genoeg ruimte voor heb

[Orphix]

Nou een beetje slim filesystem heeft dat bestandje snel opgezocht. Ik denk dat dit een betere methode is dan met directories gaan werken. En aangezien je geen DB wilt gebruiken is dit de enige optie.
Maar je hebt genoeg ruimte voor 30.000 bestanden, maar niet voor een DB

[muis|IA]

db ruimte is maar 10mb en schijfruimte een heel stuk meer

[ACM]

Voor zoveel files raad ik je wel aan meerdere directories aan te maken.

Een van de weinige filesystemen die hier echt tot zijn recht komt is het reiserfs, bijna alle anderen hebben het niet al te makkelijk met dit soort setup's vermoed ik.

Wat ook nog een optie is, natuurlijk, is om meerdere files ineen te maken.
Dus alles wat bij elkaar kan in 1 file (tenzij dat natuurlijk niet samen kan, maar dat hangt af van wat je precies gebruikt).

[[ti]]

Als die files oplopend genummerd zijn oid, dan zou ik ze per 1000 in 'n dir zetten. Dan krijg je dus bv:

\DATA
\DATA\0 // (file 0 t/m 999)
\DATA\1000 // (file 1000 t/m 1999)
...
\DATA\29000 // (file 29000 t/m 29999)

Al is het alleen maar voor het overzicht. Waarschijnlijk is het stiekem toch nog wel wat sneller ook. Als je met php 30.000 keer 'n lus door moet lopen gaat het ook niet echt sneller van worden.

[eamelink]

Als je 1 bestandje wilt openen, hoef je toch ook niet 30000 keer door een lus heen? Of mis ik iets???

[[ti]]

Nja, beetje ongelukkig voorbeeld inderdaad.

Ik zat in m'n hoofd met de gedachte als je 'n soort findfirst/findnext iets ging doen om de files op te sommen, maar da's hier waarschijnlijk niet echt van toepassing.

[ACM]

Op zaterdag 01 december 2001 19:58 schreef eamelink het volgende:
Als je 1 bestandje wilt openen, hoef je toch ook niet 30000 keer door een lus heen? Of mis ik iets???

Dan nog is het aan te raden niet zoveel files in 1 dir te hebben, er zijn geloof ik zelfs filesystems die niet meer dan 32K of 64K files kwijt kunnen.

[Onno]

Hmm.. mijn grootste directory is 16k bestanden. Dat gaat niet meetbaar langzamer dan eentje met 100 bestanden.

(alleen heb ik vast een ander bestandssysteem )

[ACM]

Op zaterdag 01 december 2001 20:36 schreef Onno het volgende:
Hmm.. mijn grootste directory is 16k bestanden. Dat gaat niet meetbaar langzamer dan eentje met 100 bestanden.

(alleen heb ik vast een ander bestandssysteem )

Het kan ook wel...
Maar ik raad het gewoon af

[Verwijderd]

Op zaterdag 01 december 2001 19:41 schreef muis het volgende:
Ik heb hier voor een site, zo'n 30.000 bestanden die opgevraagd moeten kunnen worden. De bestanden zijn allemaal rond de 2Kb. Is het verstandig om dit in 1 directory te zetten of wordt het super traag als ik met mijn php scrippie een bestand hiervan wil openen en inlezen? Een DB hiervoor gebruiken kan (nog) niet omdat ik tot nu toe niet genoeg ruimte voor heb

Zoals gezegd ligt het heel erg aan je filesystem, ReiserFS kan inderdaag goed omgaan met grote directories, XFS bijvoorbeeld ook.

Het verschil zit hem in de manier waarop de directorystructuren worden opgeslagen, in sommige gevallen is dit gewoon een linked list. Als er 2x zoveel files in een directory komen, wordt de list ook 2x zo lang, waardoor het gemiddeld 2x zo lang duurt.

Ander filesystems slaan een directory op als een zoekboom, normaalgesproken een B-tree (of varianten, zoals B+-tree bij XFS en B*-tree bij ReiserFS). Zo'n zoekboom is heel goed scalable naar veel files, omdat de zoektijd niet zo snel toeneemt naarmate er meer files komen.

Een 2e probleem dat je krijgt is de allocatie overhead. Vrijwel elk filesystem deelt de disk op in blokken van een vaste grootte. De minimale hoeveelheid ruimte die een file gebruikt is dan ook 1 blok. Als je toevallig blokken van 4kB hebt, en je hebt heel veel files van 1kB, dan gaat er op die manier een hoop ruimte verloren. Verder gaat er nog extra ruimte aan metadata verloren, bijvoorbeeld een aantal tijden, permissies etc, deze overhead is in een database veel kleiner.

ReiderFS lost dit probleem gedeeltelijk op door middel van tail packing. hierdoor kunnen meerdere kleine files in 1 blok plaatst worden, waardoor de ruimte overhead afneemt. Het is ook een design goal van ReiserFS om het filesystem bruikbaar te maken voor dit soort toepassingen, dit zal echter pas bij Reiser4 echt gerealiseerd worden.

[Orphix]

Hmmz ja ik ging er dus eigenlijk al vanuit dat een filesystem een binary tree gebruikte om bestanden op te zoeken. Dan is een bestand zoeken in 30.000 bestanden maar 4 of 5 steppen weg. Maar dat schijnt dus niet altijd het geval te zijn
time for OrphixFS merk ik al wel

[cappie]

je kunt gerust 30000 files in 1 dir gooien, zolang je d'r maar geen 'dirlisting' van wil zien/request. gewoon files accessen gaat prima met heel veel files, alleen maak je het jezelf wel lastig als je een file wilt deleten ofzo.

weet je zeker dat 't niet met een database op te lossen is?

[Verwijderd]

met het bestandsysteem NTFS gaat dit prima. Met fat 32 hoef je dit niet te proberen. Volgens mij heb ik ook wel een idee wat er in die 30000 bestandjes zit... Ik heb hetzelfde problem ook gehad

[LauPro]

Allemaal leuk en aardig maar wacht maar totdat je ze allemaal moet verwijderen

[ACM]

Bekijk de opbouw van het filesystem als je een antwoord op die vraag wilt.

Om nou dit topic omhoog te schoppen met een melding 'in ntfs kan het wel' is niet echt iets aan de discussie toevoegen imho