[PHP] Files alleen in filesystem of ook in DB?

[PanMan]

Hoi!
Ik heb een DB met items. Nu moeten bij sommige items ook files (vooral plaatjes of PDF's) worden opgeslagen. Ik zal die files vooral nodig hebben bij een item, dus "toon de files die bij item nr 123 horen". Nu zit ik te twijfelen over 2 opties:
1: De file op een filesystem zetten, en het itemnr in de filenaam. Dus iets als 123_foto1.jpg
2: De file in het filesystem zetten, en de info van de file bijhouden in een db. Dus dat ik ze b.v. random namen geef (53245647645.jpg), en in de db opsla dat dat foto.jpg is, die hoort bij item 123.
De 2e optie is waarschijnlijk sneller, maar natuurlijk ook complexer. Vooral als er dingen fout gaan (file wordt wel gewist in DB, maar door foutjes met filesystem bijvoorbeeld niet van disk). Ben bang dat het op een gegevens moment niet meer synchroon loopt.

Nadeel van de eerste optie is dat ik elke keer alle files moet doorlopen. Als er maar 1 file per item was kon je die gewoon naar het item noemen, en dus met if(file_exists($itemnr)) kijken of die bestaat. Maar omdat ik nu dus niet weet hoeveel files er zijn bij een item, moet ik ze allemaal doorlopen, wat dus wellicht traag is. Wat vinden jullie?

[creative8500]

Als jij van jezelf weet dat comlexe scripts schrijven je niet foutloos afgaat, zou ik zo realistisch zijn om de eerste te kiezen. _{Sorry, kon het niet laten}

Als je toch voor optie twee zou gaan is het verstandig een script te schrijven, bedoeld als cron-job, die de logica van je database naloopt, en je op inconsistentie wijst voordat de boel al te erg in de soep loopt...

[ Voor 40% gewijzigd door creative8500 op 25-12-2004 00:01 ]

[Johnny]

Het synchroniseren van een database en filessysteem is niet zo heel moeilijk. Schrijf gewoon een aantal aparte functies die zowel een record als een file toevoegen/verwijderen/wijzigen/ophalen en gebruik alleen deze functies om aan je dingen te zitten, op die manier voorkom je dat je ergens per ongeluk iets vergeet te wijzigen.

Om er helemaal zeker van te zijn kun je in deze functies dan ook nog wat foutcontrole bouwen die controleert of het nog wel goed gaat.

[PanMan]

creative8500 schreef op vrijdag 24 december 2004 @ 23:59:
Als jij van jezelf weet dat comlexe scripts schrijven je niet foutloos afgaat, zou ik zo realistisch zijn om de eerste te kiezen. _{Sorry, kon het niet laten}

Als je toch voor optie twee zou gaan is het verstandig een script te schrijven, bedoeld als cron-job, die de logica van je database naloopt, en je op inconsistentie wijst voordat de boel al te erg in de soep loopt...

Hehe, guess I had that comming.:)
Ik kan beide oplossingen zonder problemen maken, maar de eerste is wel minder werk (en dit is maar een klein onderdeeltje van een grote opdracht).
Ik heb m'n eigen text nog's herlezen, en zal de vraag een beetje herfrasen: Vinden jullie het, performance wise, nodig om van ditsoort files ook gegevens in de DB bij te houden, of vinden jullie het afdoende om de gegevens alleen op de HD op te slaan (waarmee er dus per request de hele dir gescand moet worden)?

[Eärendil]

PanMan schreef op vrijdag 24 december 2004 @ 23:11:
1: De file op een filesystem zetten, en het itemnr in de filenaam. Dus iets als 123_foto1.jpg
2: De file in het filesystem zetten, en de info van de file bijhouden in een db. Dus dat ik ze b.v. random namen geef (53245647645.jpg), en in de db opsla dat dat foto.jpg is, die hoort bij item 123.

Ik zou geen namen als 53245647645.jpg gebruiken, dat is alleen maar irritant als je handmatig iets moet herstellen in je filesystem.

[Verwijderd]

Waarom stop je het volledige plaatje niet gewoon in je database? Dan hoef je niet van die smerige workaround code te schrijven zoals cron-jobs.

[Spider.007]

Volgens mij is een nette oplossing zonder enorme database ook mogelijk; maak een directory /files/ en dan per item een subdirectory waarin je de bestanden plaatst Files in je database stoppen zou ik vanwege performanceredenen en overzichtelijkheid niet doen

[gorgi_19]

Spider.007 schreef op zaterdag 25 december 2004 @ 14:08:
Volgens mij is een nette oplossing zonder enorme database ook mogelijk; maak een directory /files/ en dan per item een subdirectory waarin je de bestanden plaatst Files in je database stoppen zou ik vanwege performanceredenen en overzichtelijkheid niet doen

Wat is dan die performance technische reden? Het lijkt me dat er best (memory) caching modules zijn voor PHP

[PanMan]

Files in DB, daar heb ik ook over gedacht. Heb ik een tijd terug ook wel's gedaan. En het werkt heel fijn. Maar de meeste hostingproviders zijn niet zo blij met een MySQL DB van 1 GB (en met 1000 items van 1 meg zit je daar al op). 1 Gb op disk is een stuk minder probleem, denk ik.

[Spider.007]

gorgi_19 schreef op zaterdag 25 december 2004 @ 14:10:
[...]

Wat is dan die performance technische reden? Het lijkt me dat er best (memory) caching modules zijn voor PHP

Ik heb zelf nogal wat performanceverlies geconstateerd bij het opslaan van bestanden in een populaire database; nadat ik over ben gegaan naar filenames in de database en files op het fs liep het allemaal een stuk beter

[gorgi_19]

Spider.007 schreef op zaterdag 25 december 2004 @ 14:13:
[...]


Ik heb zelf nogal wat performanceverlies geconstateerd bij het opslaan van bestanden in een populaire database; nadat ik over ben gegaan naar filenames in de database en files op het fs liep het allemaal een stuk beter

Vandaar ook cachen Iedere keer de boel uit de database trekken is idd enorm traag Een cache opbouwen in het geheugen is snel; meestal ook sneller dan vanaf het filesystem af halen

[Spider.007]

gorgi_19 schreef op zaterdag 25 december 2004 @ 14:18:
[...]

Vandaar ook cachen Iedere keer de boel uit de database trekken is idd enorm traag Een cache opbouwen in het geheugen is snel; meestal ook sneller dan vanaf het filesystem af halen

Dan zou ik toch voor het fs gaan; in plaats van het in het geheugen cachen van je files uit de database. Krijg je waarschijnlijk last van een vol geheugen; of wil je de cache juist weer op filesystem zetten?

[Eelke Spaak]

Spider.007 schreef op zaterdag 25 december 2004 @ 14:13:
[...]


Ik heb zelf nogal wat performanceverlies geconstateerd bij het opslaan van bestanden in een populaire database; nadat ik over ben gegaan naar filenames in de database en files op het fs liep het allemaal een stuk beter

Ik weet dat MS SQL Server 2000 BLOBs (en dus ook (N)TEXT) opslaat los van de tabel. In elk record zit dan simpelweg een pointer naar de informatie op de speciale 'BLOB'-pages van de SQL Server. Op deze manier zou een dergelijke kolom niet van meer of minder performance-impact moeten zijn dan een INT (of misschien BIGINT).

[The Lord]

Spider.007 schreef op zaterdag 25 december 2004 @ 14:22:
Dan zou ik toch voor het fs gaan; in plaats van het in het geheugen cachen van je files uit de database. Krijg je waarschijnlijk last van een vol geheugen; of wil je de cache juist weer op filesystem zetten?

En wat ik dan graag doe is de memory caching logica uitbreidden met een diskcache.

Bijvoorbeeld 1000 laatst opgevraagde objecten onder 25KB in geheugen cachen en 'de rest' in een caching directory op schijf tot een limiet van bijvoorbeeld 1GB. In zo een situatie is het caching mechanisme makkelijk te tweaken naar belasting, hoeven alleen de applicatie en de db in de backup, kunnen mensen je systeem niet vernaggelen door bestanden te wijzigen en kun je heel makkelijk meerdere front-end nodes toevoegen of front-end node 'verplaatsen' of migreren.

[Verwijderd]

Spider.007 schreef op zaterdag 25 december 2004 @ 14:22:
Dan zou ik toch voor het fs gaan; in plaats van het in het geheugen cachen van je files uit de database. Krijg je waarschijnlijk last van een vol geheugen; of wil je de cache juist weer op filesystem zetten?

Dan ben je niet handig bezig. Een (degelijke) database heeft standaard caching wat de performance bevorderd. En juist dat was je argument om niet voor een volledige database oplossing te gaan.

[Spider.007]

Verwijderd schreef op zaterdag 25 december 2004 @ 21:45:
[...]
Dan ben je niet handig bezig. Een (degelijke) database heeft standaard caching wat de performance bevorderd. En juist dat was je argument om niet voor een volledige database oplossing te gaan.

Maar is het echt een goed idee om voor een database te gaan die door middel van caching de prestaties op een gelijk niveau zou brengen met files op het filesysteem? Je gaat toch geen systeem gebruiken waarbij je uitgaat van caching van je applicatie? Je gebruikt toch de snelste/beste oplossing en probeert deze door middel van caching eventueel nog sneller te maken?

[Verwijderd]

Nee je schrijft een systeem die zo correct als mogelijk werkt zonder versnippering van data.

[Verwijderd]

PanMan schreef op zaterdag 25 december 2004 @ 02:03:

of vinden jullie het afdoende om de gegevens alleen op de HD op te slaan (waarmee er dus per request de hele dir gescand moet worden)?

Als we het toch over cachen hebben, deze lijst kan natuurlijk ook gecachet worden

Even zonder gekkigheid:
Het beste is wat mij betreft toch echt het best om de lijst in een database op te slaan. Immers, dan heb je een veel beter overzicht, en is het generenen van informatie gemakkelijker (lijst van alle bestanden die bij een item horen? Halen we uit de database, zonder ook nog 's het filesystem extra aan te moeten spreken). Waarom zou het moeilijk zijn dit synchroon te houden?