Database-based filesystem

Op dit moment ben ik bezig met het ontwikkelen van een database-based filesystem dat als basis zal gaan dienen voor een aantal andere projecten. Het uitdenken en opzetten van het datamodel dat gebruikt zal worden is geen probleem, maar ik vraag me nu alleen af wat de slimste manier is om de bestanden fysiek op de fileserver op te slaan.

Het plan is nu om dat zo plat mogelijk te doen en daarom bestanden enkel met een bestandsnaam (zonder extensie) op te slaan. Deze bestandsnaam wordt dan afgeleid van het id dat het betreffende bestand in de database krijgt tijdens het uploaden. Alle overige informatie (filename, extensie, mime-type, size, etc) wordt allemaal in de database opgeslagen.

Op de fileserver zou het er dan ongeveer als volgt uit komen te zien:

Mijn kennis met betrekking tot (unix) bestandssystemen is niet bijzonder groot, dus zijn er een aantal dingen die ik me afvraag:

- Heeft het aantal bestanden in een map invloed op de snelheid waarmee een enkel bestand benaderd wordt (dat verwacht ik wel).
- En zo ja, wat is een mooi maximum aantal bestanden dat je per map zou willen opslaan.
- Heeft de bestandsgrootte hier ook invloed op en zo ja, wat zou je als maximum grootte per map aanhouden.

Mocht je zelf een hele andere aanpak gebruiken/aanraden, dan sta ik natuurlijk altijd open voor suggesties!

ps. In de mappen met bestanden zal tevens een xml file komen te staan met de meest belangrijke bestandsgegevens (extensie, eigenaar, etc). Als de link met de database om wat voor reden dan ook verbroken wordt, is op die manier altijd nog de meest basale informatie van de bestanden op het filesystem zelf beschikbaar.

Een goed datamodel en een backup voorkomen dit soort problemen. Ik zou je niet aanraden om een soort van backup in XML te gaan zetten, je bereikt daar weinig mee.

1) 2 stukken code => 2 stukken code die stuk kunnen gaan of bugs kunnen bevatten
2) 2 stukken code => extra bouw- en testtijd
3) Wat is leading in het geval van een crash? De XML of de database? Probleem...
4) Backup heb je toch al nodig, kost dus geen extra tijd om dit bouwen en te testen. Levert dus geen extra risico's op, integendeel.

En ik ben nog wel zo'n liefhebber van XML... Het is niet overal bruikbaar en het is een aanslag op de performance. Nu kost extra geheugen of een extra (snelle) processor niet zo veel, maar toch. XML lijkt mij hier niet op zijn plaats, het is geen goed backup/fallback mechanisme.

Nop, heb ik geen relevante kaas van gegeten.

Thanks, heb even wat dingtjes doorgelezen en hier kan ik zeker wat mee.

Op dit moment is nog onzeker hoe de configuratie van de productie server eruit komt te zien, dus dat is even afwachten. In ieder geval lijkt een aantal van 1000 files/directories een mooi aantal om voor dit moment aan vast te houden.

Wat ik me dan alleen nog afvraag is of de bestandsgrootte nog invloed heeft op de performance. Ik vermoed van niet aangezien ik daar niets over heb kunnen terugvinden in de verschillende documentaties. En als het filesystem net als een database gebruik maakt van een soort indexen zou je helemaal niets te maken hebben met de bestandsgrootte. Of ga ik hier nu de mist in?

Dat van dat ene groot bestand zat ik net ook te bedenken..

Is het niet mogelijk om ook even de mogelijkheid te bekijken om de inhoud van het bestand ook in de DB op te slaan? Had vroeger es gehoord dat dat eig geen goed idee was, maar waarom precies is me ontgaan.

Ik hoor PGfrank altijd zeggen dat grote DB's helemaal geen probleem zijn..

Trouwens als je bestanden gewoon op je server staan, moet je ze ook via fread en php aan de gebruiker leveren. Zal die database connectie de hele boel dan zoveel vertraging opleveren?

Misschien kun je een paar verschillende methoden uitproberen en een paar testcase's uitvoeren?

Mja ik begrijp de argumenten niet echt om niet alles op een groot bestand te gooien. Je kan bijv. dingen bewaren zoals waar begint het en hoe groot is een bestand, een eigen index kun je wel zeggen. Of je kunt het natuurlijk ook je eigen filesystem noemen in de vorm van een bestand.

Het is natuurlijk wel een enorme klus ;)

Edit: @jurgen, op wie reageer je nou? Als het op mij was, zoals je kan zien bedoel ik dus ook de IO. Vraag van blanche was, volgens mij, of dit ook invloed heeft op de index en de rest van de filesystem.

Grote databases zijn inderdaad geen probleem, zolang je op een slimme/goede manier indexen aanbrengt in je tabellen. Hier gaat het echter om heel veel records die de database groot maken, maar de records zelf nemen nauwelijks ruimte in. Met bestanden van 500 mb is dat wel even anders...
Dat is waar, maar de databaseserver is dan net weer een extra tussenstap. En waarom zou ik de databaseserver aan het werk zetten om bestanden aan te bieden die ik ook direct van het bestandssysteem kan plukken. Bovendien bestaat de kans dat in de uiteindelijke productieomgeving de database- en fileserver fysiek verschillende servers zijn. En dan kom je in de problemen als je de bestanden in je database opslaat...

Het is wel interessant om hier eens wat tests mee uit te voeren om te zien wat voor invloed dat nou heeft op de snelheid van het script. Wellicht dat ik daar tijdens dit project nog eens aan toe kom.

@Jurgen: het schrijven en lezen van een bestand gebeurt in principe alleen bij het up- en downloaden van het betreffende bestand. Alle informatie over het bestand staan verder in de database, dus daarvoor hoeft het bestand zelf niet benaderd te worden. Ook zullen deze directories nooit uitgelezen worden, wederom omdat alle gegevens van het (virtuele) filesystem in de database staan. Het fysieke filesystem zal alleen gebruikt worden om 1 specifiek bestand op te zoeken en als download aan te bieden.

ps. Hmm, toch eens wat sneller typen?

@Jurgen: Zo kun je het ongeveer noemen ja..

@Blanche: Ok, ik ga er mee akkoord dat de data in DB zetten niet de beste methode is, maar om alles in 1 groot bestand (evt met compressie) zoals Riemer aanhaalde lijkt mij zeker ook een te overwegen methode.

Ja idd, ik zei ook "te overwegen" hé ;-)

Maar ik ben zeer geïnteresseerd in de verdere ontwikkeling van dit project.

Ik zou toch niet voor de alles-in-een variant gaan, denk hierbij aan fragmentatie. Voor je filesystem (ntfs, ext3) heb je hier allemaal optimalisaties voor in plaats en kan je defragmenteren. Dit zou je bij grote bestanden zelf in moeten bakken. Alles-in-een is alleen echt handig wanneer je data weinig tot niet verandert denk ik.

Ik ben zelf een keer tegen het inode-limiet van ext3 aangelopen. Na 16.000 of 160.000 submappen (ben de details vergeten) kan je geen nieuwe submappen meer aanmaken. Ik heb het op die specifieke website opgelost door het id op te delen in stukjes van 3. Ieder stukje is een submap, met een totale lengte van 9 (dus maximaal 3 submappen) En dat werkt verder wel goed. Ik merkte trouwens niet echt iets van een performance impact toen ik tegen dat limiet was opgelopen.

Verder 1 ding waar ikzelf tegenaan liep bij het uitdenken van een FS in een DB: lege mappen.