Database efficientste oplossing voor veel kleine bestanden?*

[ReLight]

Ten behoeve van een intern project moeten wij duizenden kleinen bestandjes (40 Byte) per dag opslaan op een server. Nu moeten daar allemaal externe connectie en ophaal methodes op los gelaten worden die die bestandjes beschikbaar maken via b/v FTP of file manipulatie.

Doordat het zo veel bestanden zijn kwamen we al snel uit op een database als beste opslag voor deze kleine bestanden (byte velden).

Nu zou het het aller simpelste zijn als we de opgeslagen bestanden in de database konden benaderen net alsof het op een harddisk stond. (dbname:\kolom1\bestand.txt Daarmee een normale toegang via FTP bij voorbeeld mogelijk makend.

Google hielp niet zo veel, maar ik kan me iets herinneren van een jaar of wat geleden dat bepaalde database platformen zulke interfaces toestonden onder voorwaarden.

Iemand enig idee ?

[Bierkameel]

Wat had je zelf al gevonden?

[djluc]

Heb je niet het idee dat je nu een beetje een hele vage oplossing aan het maken bent? Je hebt bestandjes welke je wilt tonen zoals in een filesystem. Sla ze daar dan ook gewoon op?

[ReLight]

Ja, maar het zijn er +- 70.000 per dag met een opslag van 14 dagen, met 40Byte per bestandje.
Aangezien een Filesysteem met clusters werkt kost dat veelste te veel I/O en ruimte.

Ik heb niet direct iets kunnen vinden, Oracle heeft niet zo'n interface, en mogelijk is het 3rd party software. MSSQL doet het native ook niet.

[cool0]

Wat ik uit zijn verhaal begrijp is het volgende: Hij wil bestanden opslaan in een database en dan vervolgens deze benaderen als een filesysteem (WINFS ) De bestandjes zijn vrij klein het probleem als je die opslaat in windows linux etc gebruikt een bestandje van bv. 40 bytes wel een gehele cluster! Dit is dus heel inefficient en als je het op die manier zou doen heb je een gigantische hoeveelheid aan opslag nodig voor eigenlijk niks! Zijn vraag simpel:

Hoe sla ik bestanden op in een database en kan ik die dan benaderen als een filesystem?

Antwoord weet ik niet maar hoop dat mensen het hierdoor iets beter begrijpen anders krijgen we straks weer van die UTFS slotje mededelingen.

[mkleinman]

Is toch oracle niet wat voor jullie? Je kan met IFS ( internet file system ) volgens mij een heel eind komen.

Overigens zou je de bestandjes gewoon een in BLOB kunnen opslaan en daarna een interface kunnen faken IMHO.

[TrailBlazer]

worden die files door mensen opgehaald of door een ander proces.

[wica]

Ik heb hier een tijd geleden ook naar gezocht. Ben op iets terecht gekomen. icm. met postgresql.
Heb het niet in gebru8ik genomen. Maar misschien dat het in de tussen tijd verbeterd is
Zal eens zoeken

@KoeNijn
Dank je voor het zoeken

[ Voor 9% gewijzigd door wica op 06-12-2004 13:08 ]

[Verwijderd]

ReLight schreef op maandag 06 december 2004 @ 12:51:
Ja, maar het zijn er +- 70.000 per dag met een opslag van 14 dagen, met 40Byte per bestandje.
Aangezien een Filesysteem met clusters werkt kost dat veelste te veel I/O en ruimte.

Ik heb niet direct iets kunnen vinden, Oracle heeft niet zo'n interface, en mogelijk is het 3rd party software. MSSQL doet het native ook niet.

Ik neem dus aan dat je een kant en klaar project wil en dat noem je niet native

Even op google gezocht op mysql fs en er kwam het volgende uit gerolle:

http://no.spam.ee/~tonu/m...php?name=News&new_topic=2

Helaas is deze in pre-alpha stadium en voor MySQL.

[Wirehead]

Kan je niet op een apache-server een soort "filemanager" nabouwen, met PHP.

Zoiets als een directory listing bij een apache server, maar dan omgebouwd zodat het op een explorer-venster ofzo lijkt?

Lijkt me niet zo moeilijk i.c.m. MySQL

[ Voor 6% gewijzigd door Wirehead op 06-12-2004 13:08 ]

[ReLight]

TrailBlazer schreef op maandag 06 december 2004 @ 12:56:
worden die files door mensen opgehaald of door een ander proces.

De files wordn opgehaald / ge-mirrored dmv processes, maar manueel erdoorheen gaan mag geen probleem zijn.
Ik heb al wat termen gezien hierboven waarmee ik verder kan zoeken. Maar meer= beter.

[heuveltje]

ReLight schreef op maandag 06 december 2004 @ 12:51:
Ja, maar het zijn er +- 70.000 per dag met een opslag van 14 dagen, met 40Byte per bestandje.
Aangezien een Filesysteem met clusters werkt kost dat veelste te veel I/O en ruimte.

Ik heb niet direct iets kunnen vinden, Oracle heeft niet zo'n interface, en mogelijk is het 3rd party software. MSSQL doet het native ook niet.

als ik even reken :

40(byt(e X 75.000(per dag) X 14(dagen) = 42.000.000bytes = +/- 40MB
Kun je misschien niet aan iets van een ramdisk gaan denken?
* heuveltje heeft er niet zoveel ervaring mee.
maar io is geen probleem meer, clustering is imho niet meer nodig, en je zou om de minuut alles kunnen backuppen naar een zip file oid.

of nog beter laat alles appenden aan een groot file dat je vervolgens kan expanden naar een ramdisk

[The Eagle]

Oracle kan standaard bestanden in zijn DB opslaan, dus daar zit je al goed
Wat je zou kunnen doen is in bijv PHP oid een windows-verkenner nabouwen, waarbij je de DB-objecten kunt benaderen als ware het een filesystem. Ziet er uit als een verkenner, werkt ook zo voor de eindgebruiker - alleen de onderhuidse werking is anders

[Verwijderd]

Move PNS > SA

[Verwijderd]

heuveltje schreef op maandag 06 december 2004 @ 13:14:
[...]


als ik even reken :

40(byt(e X 75.000(per dag) X 14(dagen) = 42.000.000bytes = +/- 40MB
Kun je misschien niet aan iets van een ramdisk gaan denken?
* heuveltje heeft er niet zoveel ervaring mee.
maar io is geen probleem meer, clustering is imho niet meer nodig, en je zou om de minuut alles kunnen backuppen naar een zip file oid.

of nog beter laat alles appenden aan een groot file dat je vervolgens kan expanden naar een ramdisk

Je vergeet de clustergrootte:

bij een clustergrootte van 4kb:

4096(clustergrootte) x 75.000(per dag) x 14(dagen) = 4300800000bytes ~4GB!!!

De ramdisk werkt ook met een clustergrootte volgens mij.

Als je het op een gewoon bestandssysteem wil opslaan zonder veel ruimte te verkwitsen moet je een bestandssysteem vinden met een zeeeeeer kleine clustergrootte.

[ Voor 11% gewijzigd door Verwijderd op 06-12-2004 13:31 ]

[Verwijderd]

ReLight schreef op maandag 06 december 2004 @ 12:51:
Ja, maar het zijn er +- 70.000 per dag met een opslag van 14 dagen, met 40Byte per bestandje.
Aangezien een Filesysteem met clusters werkt kost dat veelste te veel I/O en ruimte.

Ik heb niet direct iets kunnen vinden, Oracle heeft niet zo'n interface, en mogelijk is het 3rd party software. MSSQL doet het native ook niet.

Een database slaat zijn gegevens ook gewoon op in een bestand hoor.

[heuveltje]

Verwijderd schreef op maandag 06 december 2004 @ 13:29:
[...]

Je vergeet de clustergrootte:

bij een clustergrootte van 4kb:

4096(clustergrootte) x 75.000(per dag) x 14(dagen) = 4300800000bytes ~4GB!!!

De ramdisk werkt ook met een clustergrootte volgens mij.

lijkt me dat een ramdisk geen clustergroote nodig heeft, geen koppen die bewegen enzo.
en anders zou het nog kunnen met kleinere klusters, (ntfs heeft 512b clusters als minimum binnen w2k, maar misschien dat dat met een simpele hack al minder is)

btw schiet me opeens binnen, als je compression aanvinkt bij een ntfs drive, zou hij zelf dan niet op een of andere manier werken ?

[heuveltje]

Verwijderd schreef op maandag 06 december 2004 @ 13:31:
[...]


Een database slaat zijn gegevens ook gewoon op in een bestand hoor.

Ja maar wel allemaal in 1 bestand. dus dan heb je geen 200M clusters nodig.

[ReLight]

Verwijderd schreef op maandag 06 december 2004 @ 13:31:
[...]


Een database slaat zijn gegevens ook gewoon op in een bestand hoor.

Maar wel aan 1 stuk & dat is een stuk beter te managen.

[Verwijderd]

heuveltje schreef op maandag 06 december 2004 @ 13:37:
[...]


Ja maar wel allemaal in 1 bestand. dus dan heb je geen 200M clusters nodig.

Databases gaat ook niet na elke transactie "defragmenteren" denk dat als ze gewoon met NTFS opstaat je minder ruimte kwijt bent dat met een database.

Daarnaast is binary niet tot op de byte variabel volgens mij. Dus heb je ook nog steeds "overhead".

Daarnaast is het onzin omdat de bestanden nog steeds minimaal even veel I/O nodig hebben als een FS. Bestand moet eerst geconverteerd worden naar database, en later weer terug naar bestand.

Dus ipv 2x één actie. Heb je dan 2x twee acties.

[JeroenE]

ReLight schreef op maandag 06 december 2004 @ 12:51:
Ja, maar het zijn er +- 70.000 per dag met een opslag van 14 dagen, met 40Byte per bestandje.
Aangezien een Filesysteem met clusters werkt kost dat veelste te veel I/O en ruimte

De I/O blijf je toch wel houden (je moet het toch lezen).

Je kan eens kijken naar ReiserFs, die kan meerdere bestanden in 1 block zetten.

[Verwijderd]

heuveltje schreef op maandag 06 december 2004 @ 13:36:
[...]

lijkt me dat een ramdisk geen clustergroote nodig heeft, geen koppen die bewegen enzo.
en anders zou het nog kunnen met kleinere klusters, (ntfs heeft 512b clusters als minimum binnen w2k, maar misschien dat dat met een simpele hack al minder is)

btw schiet me opeens binnen, als je compression aanvinkt bij een ntfs drive, zou hij zelf dan niet op een of andere manier werken ?

Op een ramdisk heb je ook een bestandssysteem nodig en dus het moet adresseerbaar zijn dus heb je ook clusters. Clusters hebben niets met koppen ofzo te maken maar met adressering.

Als er een mogelijkheid is om de clustergrootte enorm te verkleinen zou het nuttig worden voor de TS. Helaas vindt ik zo 1-2-3 geen hack.

[F_J_K]

Clusters verkleinen zou op een gegeven moment zorgen voor veel te veel overhead bij bestandssystemen die niet zijn gebouwd op clusters van pak-em-beet 50b. Een DB oid. is inderdaad veel makkelijker. _{niet dat ik er een ken die dit doet, ik hoop iemand anders wel.}

Welke clients? Alternatief is misschien een zipfile zonder compressie. Maar dat zal ws. ook niet goed zijn voor de performance.

[Spider.007]

Ik pas de topictitel even aan; aangezien je ook geinteresseerd bent naar alternatieve oplossingen

Database data benaderen alsof een File Systeem > Database efficientste oplossing voor veel kleine bestanden?*

[ReLight]

Bedankt, maar de bestanden moeten toch echt via FTP, en dus denk ik als echt FS, te benaderen, op te halen zijn !

Maar dit is idd wel een deel discussie die eerst gevoerd moet worden. Is een db wel de beste manier ? Of FS ?

[ Voor 34% gewijzigd door ReLight op 06-12-2004 22:23 . Reden: change of hart ]

[Wirehead]

Kijk eens op http://www.namesys.com/v4/v4.html

Het reiserFS is echt iets voor je.

Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down). This makes Reiser4 more space efficient than other filesystems because we squish small files together rather than wasting space due to block alignment like they do. It also means that Reiser4 scales better than any other filesystem. Do you want a million files in a directory, and want to create them fast? No problem.

[orca]

Met 40 bytes heb je toch records nodig van 40 characters? en misschien hetzelfde aantal voor de omschrijving van het bestandje?

dan heb je toch een progje nodig dat de bestandjes uitleest en als record toevoegd aan de database?

met 28800 seconden per werkdag en 70.000 bestandjes zou je elke seconde 2,4 bestanden moeten inlezen of bijna 146 per minuut, een tooltje dat elke minuut alle nieuwe bestanden inleest en de ingelezen wist mag eigenlijk geen probleem zijn..

[McFreak]

kan je niet gewoon een service bouwen met .NET ofzo.
Die laten draaien door je OS en als koppeling laten dienen tussen je filesystem en de clients.
Een soort Distributed Computing (SETI, RC5) -achtig iets.
Je hebt uiteraard veel overhead door de schrijf en lees fileacties.
Daarom is een DB wel sneller hierin.

[ Voor 21% gewijzigd door McFreak op 06-12-2004 23:26 ]

[TheBorg]

Clustersize instellen op 512bytes = 500MB per dag. Paar dikke schijven nemen, verlies voor lief nemen, klaar.

[ Voor 4% gewijzigd door TheBorg op 06-12-2004 23:31 ]

[Verwijderd]

ReLight schreef op maandag 06 december 2004 @ 20:23:
Bedankt, maar de bestanden moeten toch echt via FTP, en dus denk ik als echt FS, te benaderen, op te halen zijn !

Maar dit is idd wel een deel discussie die eerst gevoerd moet worden. Is een db wel de beste manier ? Of FS ?

Is een sql dump niet mogelijk, of werken de clientprogramma's alleen maar met ftp?

[ReLight]

Verwijderd schreef op dinsdag 07 december 2004 @ 10:41:
[...]

Is een sql dump niet mogelijk, of werken de clientprogramma's alleen maar met ftp?

Ze willen ook werken ook met ouderwetse dial-up met zelfs x-modem.....Daar hebben we al modules voor, maar we willen naar FTP, en liever Secure FTP, SFTP.

[sverzijl]

TheBorg schreef op maandag 06 december 2004 @ 23:31:
Clustersize instellen op 512bytes = 500MB per dag. Paar dikke schijven nemen, verlies voor lief nemen, klaar.

Precies mijn gedachte toen ik dit topic doorlas. Waar hebben we het eigenlijk over! 75000*14*512= +/- 512MB in totaal. De tijd die je hier op dit forum hebt doorgebracht heeft al een veelvoud gekost dan die schijf van maarliefst 512MB
Om hier een database voor in te schakelen is m.i. gekkenwerk.

[ReLight]

Okey, ik heb genoeg stof tot nadenken. Bedankt alle tweakertjes voor het meedenken.

[Spider.007]

Laat nog even horen hoe je het hebt opgelost; en wat de resultaten zijn Vinden we wel interessant