[PHP/MySQL] Optimalisatie opbouw database

[iznogood]

Stel ik bouw een website met zo'n 300.000 gebruikers die zo'n 500kbyte aan data per persoon opslaan in een database.

Is het zinvol om ( zo optimaal mogelijk gezien ) de database met 300.000 gebruikers te verdelen over meerdere databases op dezelfde server ? Of maakt dit in de praktijk weinig uit ?

Als nu al deze personen een foto kunnen uploaden ( zeg 2 foto's per persoon ) is het dan verstandig deze in de database te dumpen of de foto op de server in een map te bewaren en alleen de verwijzing naar de foto in de database op te slaan ?

Heb ik te maken met een maximale grote van 1 mysql database of maakt de maximale bestandsgrootte onder xp/linux niet meer uit?

[Not Pingu]

Je database kan ettelijke gigabytes groot worden als het moet. Zorg gewoon dat je server dat ondersteunt.
Het verdelen over meerdere databases zal misschien de opzoektijd wat versnellen omdat de indexen minder groot zijn, maar daar staat tegenover dat je grote moeite zult hebben om die twee databases naadloos met elkaar te laten werken.

De haalbaarheid van zo'n oplossing hangt een beetje af van je datamodel; als bij elkaar horende gegevens de kans lopen over 2 verschillende databases versplinterd te raken, heb je natuurlijk een probleem.

edit:
vertragen moest versnellen zijn

[ Voor 6% gewijzigd door Not Pingu op 02-01-2005 19:49 ]

[iznogood]

Gunp01nt schreef op zondag 02 januari 2005 @ 19:39:
Je database kan ettelijke gigabytes groot worden als het moet. Zorg gewoon dat je server dat ondersteunt.
Het verdelen over meerdere databases zal misschien de opzoektijd wat vertragen omdat de indexen minder groot zijn, maar daar staat tegenover dat je grote moeite zult hebben om die twee databases naadloos met elkaar te laten werken.

De haalbaarheid van zo'n oplossing hangt een beetje af van je datamodel; als bij elkaar horende gegevens de kans lopen over 2 verschillende databases versplinterd te raken, heb je natuurlijk een probleem.

Opzoektijd zal versneld worden verwacht ik ( tenzij de harde schijf het te zwaar krijgt ) Ik wil de gebruikers dumpen in de database op basis van de 1e letter van de gebruikersnaam dus:

Gebruiker : Stefan
Database : Database_S

Bij elkaar horende gegevens zullen in dezelfde database staan. Voor iedere gebruiker wordt een aparte tabel aangemaak :

Gebruiker : Stefan
Database : Database_S
Tabel : Tabel_Stefan

Stel nu dat er 5000 mensen zijn ingelogd waarvan de meesten uiteenlopende voorletters voor hun gebruikersnamen hebben. Hoe zit het dan met de opzoektijd en de serverload?

[ Voor 19% gewijzigd door iznogood op 02-01-2005 19:46 ]

[whoami]

iznogood:
voel je je wel goed, of ben je gewoon gek ?

[Not Pingu]

Ik denk dat de versnelling van de opzoektijd te verwaarlozen is. Met zo'n eenvoudig datamodel moet het zeker lukken om alles over meerdere databases te verspreiden, maar je komt al snel in grote problemen als je dingen wilt gaan toevoegen en bijv. relaties wilt creeeren tussen gebruikers. Nou weet ik niet of dat bij jouw applicatie van toepassing is, maar hou daar wel rekening mee.

[eamelink]

Ik denk dat je beter iemand in kan huren.

Eigenlijk denk ik dat je beter een adviseur kan zoeken en hem vragen om iemand in te huren, want je lijkt me niet capabel genoeg om zelf te zien of iemand die je inhuurt verstand van zaken heeft.

Zo, een mooie flamepost

[gorgi_19]

eamelink schreef op zondag 02 januari 2005 @ 19:51:
Eigenlijk denk ik dat je beter een adviseur kan zoeken en hem vragen om iemand in te huren, want je lijkt me niet capabel genoeg om zelf te zien of iemand die je inhuurt verstand van zaken heeft.

Hoewel ik moet toegeven dat z'n databasemodel en z'n opzet op z'n minst opmerkelijk te noemen zijn, kunnen we het wellicht inhoudelijk houden op het probleem? Het inhuren van adviseurs is een optie, maar in de meeste gevallen ook een erg prijzige optie en in een aantal gevallen niet mogelijk

[iznogood]

eamelink schreef op zondag 02 januari 2005 @ 19:51:
Ik denk dat je beter iemand in kan huren.

Eigenlijk denk ik dat je beter een adviseur kan zoeken en hem vragen om iemand in te huren, want je lijkt me niet capabel genoeg om zelf te zien of iemand die je inhuurt verstand van zaken heeft.

Zo, een mooie flamepost

Als je geen normaal antwoord kan geven, reageer dan niet.

[gorgi_19]

iznogood schreef op zondag 02 januari 2005 @ 19:56:
[...]
Als je geen normaal antwoord kan geven, reageer dan niet.

En als je een reactie ziet die in jouw ogen niet door de beugel kan: . Als mensen op elkaar gaan hakken, kan ik het topic net zo goed dicht knallen, dan wordt het toch kansloos.

Oftewel: ontopic.

[ Voor 14% gewijzigd door gorgi_19 op 02-01-2005 19:59 ]

[iznogood]

gorgi_19 schreef op zondag 02 januari 2005 @ 19:55:
[...]

Hoewel ik moet toegeven dat z'n databasemodel en z'n opzet op z'n minst opmerkelijk te noemen zijn, kunnen we het wellicht inhoudelijk houden op het probleem? Het inhuren van adviseurs is een optie, maar in de meeste gevallen ook een erg prijzige optie en in een aantal gevallen niet mogelijk

In welk opzicht is het dan opmerkelijk? Wat dat betreft ben ik op dit gebied nog niet echt vergevorderd, ik kijk gewoon even verschillende mogelijkheden af waarvan ik denk dat ze relevant zijn.

[Verwijderd]

eamelink schreef op zondag 02 januari 2005 @ 19:51:
Ik denk dat je beter iemand in kan huren.

Eigenlijk denk ik dat je beter een adviseur kan zoeken en hem vragen om iemand in te huren, want je lijkt me niet capabel genoeg om zelf te zien of iemand die je inhuurt verstand van zaken heeft.

Zo, een mooie flamepost

De rillingen lopen mij ook over de rug ;-)

Het opsplitsen van database tabellen over verschillende servers lijkt mij een nachtmerrie. Wat je wel vaak ziet is het mirroren van databases over meerdere servers. Als je applicatie zelden schrijft maar vaak leest (dat is meestal zo) kan dat zeer gunstig zijn. Je zorgt er dan d.m.v. replicatie voor dat de databases synchroon blijven.

Plaatjes en andere bestanden in databases opnemen is meestal ook niet zo'n handig idee. Files kun je het beste in een filesystem onderbrengen. Als je zo'n zware applicatie hebt dat dat problemen op kan leveren (serven van statische bestanden kan natuurlijk door een server met een behoorlijke cache erg efficient gebeuren - of zelfs met de supersnelle Linux tux kernel http server) kun je altijd ook daar een mirror van opzetten.

[gorgi_19]

iznogood schreef op zondag 02 januari 2005 @ 19:59:
[...]

In welk opzicht is het dan opmerkelijk? Wat dat betreft ben ik op dit gebied nog niet echt vergevorderd, ik kijk gewoon even verschillende mogelijkheden af waarvan ik denk dat ze relevant zijn.

300.000 gebruikers vind ik nog geen grote database. 150 MB aan database grootte ook niet GoT heeft een messagetable met miljoenen records. Ik vind dan ook de keuze om nu al een database te gaan splitsen erg opmerkelijk

Sowieso geldt: meten is weten. Maak een testdatabase aan met een hele hoop testdata en simuleer een load, bijvoorbeeld met MACT. Kijk vervolgens naar de performance

[ Voor 14% gewijzigd door gorgi_19 op 02-01-2005 20:02 ]

[Verwijderd]

Als je nog niet zo ver gevorderd bent, dan moet je niet aan zulke projecten beginnen. Niet eerlijk tegenover je opdrachtgever en je brengt jezelf alleen in de problemen. Je moet eens wat dingen gaan lezen over database normalisatie. Zoek eens wat tutorials over hoe je een database opzet, bekijk functionele ontwerpen van andere systemen.

[eamelink]

iznogood schreef op zondag 02 januari 2005 @ 19:56:
[...]
Als je geen normaal antwoord kan geven, reageer dan niet.

De eerste regel van dat je het beter aan iemand anders kan overlaten was wel degelijk serieus bedoeld

Als alternatief kan je natuurlijk ook eerst een website met 300k bezoekers uit je hoofd zetten en gewoon een paar boeken kopen over webdevelopment, en een paar over databases.

Want wat je wilt doen is echt BIZAR. Een aparte tabel voor elke user. Het hele concept van databases gaat klaarblijkelijk aan je voorbij.

Dat is niet erg, maar om dan meteen een website met 300k gebruikers te willen maken is tamelijk onverstandig. Omdat je het zo resoluut zegt denk ik dat het maken van die website voor 300k gebruikers voor jou belangrijker is dan het zelf maken. Daarom denk ik dat je het beter door iemand anders kan laten doen.

Als ik het fout ingeschat hebt en je het perse zelf wilt maken, laat dan misschien het idee van zo'n grote website varen

Als je dat ook niet wilt doen en perse een inhoudelijk antwoord wilt op je belachelijke vraag:

"Maak gewoon 1 database, met 1 tabel voor de users, en gooi daar alle users in. Een aparte database per letter is onnodig en onzinnig, een aparte tabel voor elke gebruiker is hopeloos. Dan kan je net zo goed met textfiles werken he? Dat gaat nog veel sneller en als je toch alle voordelen die een database kan bieden meteen al uitsluit met je ontwerp zie ik geen reden om uberhaupt voor een database te kiezen Maak dan directories met de eerste letter en daarin textfiles met de gebruikersnaam als naam. Gaat een stuk vlotter dan een database :)"

[Not Pingu]

iznogood schreef op zondag 02 januari 2005 @ 19:59:
[...]

In welk opzicht is het dan opmerkelijk? Wat dat betreft ben ik op dit gebied nog niet echt vergevorderd, ik kijk gewoon even verschillende mogelijkheden af waarvan ik denk dat ze relevant zijn.

Het is opmerkelijk omdat het een nogal... apart idee is* Het is uiteraard mogelijk, maar je database design wordt er nodeloos ingewikkeld van (heb je ineens 27 databases als we er even vanuit gaan dat een naam alleen met een hoofdletter mag beginnen) maar ook is het helemaal niet zeker dat het daadwerkelijk iets oplevert in snelheidsverschil.

Wbt. het aantal connecties en schijfactiviteit is er weinig verschil, maar je hebt wel wat overhead omdat elke database indexen en execution plans en toegangsrechten en weetikveelwat opslaat.

Als je zeker wilt weten of het iets uithaalt, zou ik zeggen: maak een testcase en werk een simpele applicatie uit die meerdere databases gebruikt.


Verder ben ik het met earnelink eens dat een site met 300k gebruikers wel erg ambitieus klinkt voor iemand die (no offense) zo weinig ervaring met webdevelopment lijkt te hebben. Kun je misschien een beeld geven van wat voor project het is? Dan kunnen wij wat meer zeggen over de haalbaarheid / het nut van je idee.

[ Voor 14% gewijzigd door Not Pingu op 02-01-2005 20:06 ]

[iznogood]

gorgi_19 schreef op zondag 02 januari 2005 @ 20:00:
[...]

300.000 gebruikers vind ik nog geen grote database. 150 MB aan database grootte ook niet GoT heeft een messagetable met miljoenen records. Ik vind dan ook de keuze om nu al een database te gaan splitsen erg opmerkelijk

ah kijk dat wilde ik weten. Het is dus niet interessant om de database te gaan opsplitsen. Als ik nu een simpele query loslaat op die 150 Mb aan database dan is deze nagenoeg meteen klaar met het uitvoeren hiervan.

[ludo]

iznogood schreef op zondag 02 januari 2005 @ 19:59:
[...]

In welk opzicht is het dan opmerkelijk? Wat dat betreft ben ik op dit gebied nog niet echt vergevorderd, ik kijk gewoon even verschillende mogelijkheden af waarvan ik denk dat ze relevant zijn.

Nou het idee van een database is dat je een mooie gecentraliseerde opslag van gegevens hebt. Hierdoor kun je makkelijk relaties leggen tussen gegevens en met behulp van queries de database vragen stellen. Als jij nu je database gaat opbreken in meerdere databases haal je het hele idee van de (relationele) database onderuit.

Jouw idee is dus iets wat je in geen enkel geval wilt. Of het nou sneller is of niet. Optimalisaties kan je beter op andere manieren doen, bijvoorbeeld door het aanmaken van goede indexen. En 300.000 gebruikers voor een (goede) database is net niks. Daar moet een beetje database server niet moe van worden.

Dan over het opslaan van die foto's. Het is een persoonlijk iets, maar ik hou er niet van om bestanden op te slaan in een database. Ik zou de foto's altijd gewoon in een directory plaatsen en dan verwijzingen naar die foto's opnemen in je database.

[edit]
Nog even een voorbeeld waarom het waanzin zou zijn:
Stel je programeert een applicatie waarin de orders van gebruikers zitten. Als je één database hebt met een tabel gebruikers en een tabel orders kun je orders mooi koppelen aan een gebruiker d.m.v. bijvoorbeeld een gebruikersnummer. Dit is heel eenvoudig te programmeren, ook het opvragen van bijvoorbeeld alle orders van gebruiker Jan is eenvoudig. Een simpele SQL query levert je zo de juiste gegevens op.

Als we dit nu op de manier gaan doen zoals jij het wilt doen moet je eerst in je applicatie zelf gaan kijken waarmee de gebruikersnaam zou beginnen. Dat is in het geval van Jan dus een J. Dan moet jij een verbinding gaan maken met de database waarin alle mensen met een J staan. Hierin vraag je het gebruikersnummer van Jan op. Vervolgens moet je met een andere database gaan verbinden waarin de orders staan en hier weer alle orders opvragen met het gebruikersnummer van Jan. Zo ben je dus eigenlijk alle kracht van SQL kwijt... In feite ben je nu van al je tabellen een database aan het maken. Dan is het einde zoek, want waarom zou je dan niet voor ieder record een database aanmaken? Ik hoop dat je nu een beetje duidelijk is dat jouw idee redelijke waanzin is

[ Voor 35% gewijzigd door ludo op 02-01-2005 20:13 ]

[Verwijderd]

iznogood schreef op zondag 02 januari 2005 @ 19:42:
[...]

hier stond tekst...

Stel nu dat er 5000 mensen zijn ingelogd waarvan de meesten uiteenlopende voorletters voor hun gebruikersnamen hebben. Hoe zit het dan met de opzoektijd en de serverload?

Opeens schoot de welbekende kaartenbak analogie door mijn hoofd. Een database heeft veel weg van een kaartenbak die men vroeger had. Op elk kaartje stonden de gegevens van een persoon.
Een tabel kan je zien als zo'n kaartenbak, waaruit je snel gegevens op kan zoeken.
Wat jij nu eigenlijk voorstelt, is voor elke gebruiker/klant een aparte kaartenbak op te stellen. Snap je nu waarom jou idee gewoon krankzinnig is?
Hoe wou je uberhaupt op die manier alle gebruikers met de naam beginnend met de letter "Q" ophalen?

[whoami]

iznogood schreef op zondag 02 januari 2005 @ 20:04:
[...]

ah kijk dat wilde ik weten. Het is dus niet interessant om de database te gaan opsplitsen.

Eigenlijk niet nee...

Wanneer zie je 'opgesplitste DB's': als je een DB hebt van een (hele) grote organisatie, en als die organisatie verschillende vestigingen heeft.
Dan is het nuttig om je DB te gaan partitionieren door ervoor te zorgen dat vestiging A bv enkel maar aan klanten kan van vestiging A. Dit kan je tewerkstellen dmv views bv.
Om de data dan nog synchroon te houden tussen verschillende sites, kan je een merge - replication gaan opzetten tussen die verschillende vestigingen.

Echter, de manier waaraan jij dacht is gewoon van de pot gerukt. Als jij verschillende DB's hebt, hoe ga je dan gaan bepalen met welke DB je moet gaan connecteren ? En hoe ga je snel de juiste DB vinden ?

Ff een sidenote: ik ben op m'n werk bezig met een project dat een centrale DB behelst voor een hele hoop medische informatie. Die database is op dit moment ongeveer 4 GB groot, en nog lang niet alle informatie zit erin.
Het opvragen van data gaat nog steeds snel (omdat we goeie indexen geplaatst hebben, een goed data-model hebben, en de DB access components gewoon goed zijn).
Die databank is ook verspreid over 3 sites, en wordt ook synchroon gehouden dmv replication, maar een verdere partitionering is zelfs nog niet in ons opgekomen.

[ Voor 6% gewijzigd door whoami op 02-01-2005 20:12 ]

[iznogood]

eamelink schreef op zondag 02 januari 2005 @ 20:02:
[...]


De eerste regel van dat je het beter aan iemand anders kan overlaten was wel degelijk serieus bedoeld

Als alternatief kan je natuurlijk ook eerst een website met 300k bezoekers uit je hoofd zetten en gewoon een paar boeken kopen over webdevelopment, en een paar over databases.

Want wat je wilt doen is echt BIZAR. Een aparte tabel voor elke user. Het hele concept van databases gaat klaarblijkelijk aan je voorbij.

Dat is niet erg, maar om dan meteen een website met 300k gebruikers te willen maken is tamelijk onverstandig. Omdat je het zo resoluut zegt denk ik dat het maken van die website voor 300k gebruikers voor jou belangrijker is dan het zelf maken. Daarom denk ik dat je het beter door iemand anders kan laten doen.

Als ik het fout ingeschat hebt en je het perse zelf wilt maken, laat dan misschien het idee van zo'n grote website varen

Als je dat ook niet wilt doen en perse een inhoudelijk antwoord wilt op je belachelijke vraag:

"Maak gewoon 1 database, met 1 tabel voor de users, en gooi daar alle users in. Een aparte database per letter is onnodig en onzinnig, een aparte tabel voor elke gebruiker is hopeloos. Dan kan je net zo goed met textfiles werken he? Dat gaat nog veel sneller en als je toch alle voordelen die een database kan bieden meteen al uitsluit met je ontwerp zie ik geen reden om uberhaupt voor een database te kiezen Maak dan directories met de eerste letter en daarin textfiles met de gebruikersnaam als naam. Gaat een stuk vlotter dan een database :)"

Excuus.. ik zie waarom jij het idioot vindt om voor iedere gebruiker een aparte tabel aan te maken:

IPV :
Database: foo
Tabel: Profile_userid
FIELDS:
fullname, age, enz

Kan ik ook:
Database foo
Tabel: Profiles
FIELDS:
userid, fullname, age, enz

Geen idee hoe ik bij dat eerste idee kwam..

[ Voor 1% gewijzigd door iznogood op 02-01-2005 20:20 . Reden: databasenaam gewijzigd... was onduidelijk ]

[ludo]

iznogood schreef op zondag 02 januari 2005 @ 20:13:Excuus.. ik zie waarom jij het idioot vindt om voor iedere gebruiker een aparte tabel aan te maken:

IPV :
Database: a
Tabel: Profile_userid
FIELDS:
fullname, age, enz

Kan ik ook:
Database a
Tabel: Profiles
FIELDS:
userid, fullname, age, enz

Geen idee hoe ik bij dat eerste idee kwam..

Maar je wil hier nog steeds voor elke beginletter een aparte database gaan maken Ik hoop dat ik dat verkeerd lees Heb je mijn edit bij m'n vorige post al gezien?

[iznogood]

ludo schreef op zondag 02 januari 2005 @ 20:17:
[...]
Maar je wil hier nog steeds voor elke beginletter een aparte database gaan maken Ik hoop dat ik dat verkeerd lees Heb je mijn edit bij m'n vorige post al gezien?

Nee die a staat er voor de fun bij ... nu worden gewoon alle gebruikersnamen in 1 tabel gedumpt.

[eamelink]

iznogood schreef op zondag 02 januari 2005 @ 20:13:
[...]

Excuus.. ik zie waarom jij het idioot vindt om voor iedere gebruiker een aparte tabel aan te maken:

IPV :
Database: a
Tabel: Profile_userid
FIELDS:
fullname, age, enz

Kan ik ook:
Database a
Tabel: Profiles
FIELDS:
userid, fullname, age, enz

Geen idee hoe ik bij dat eerste idee kwam..

Dat tweede idee is een stuk beter inderdaad Toch houd je daarbij nog steeds problemen. Stel het fictieve geval dat je een "Wie is er vandaag jarig" pagina wilt maken. Dat kan niet? Je kan geen select doen daarop. Je moet er dan 26 doen.

Als je iemand wilt bannen op ip-adres, dan moet je ook in alle 26 tabellen zoeken.

Je zou natuurlijk wrapperfuncties kunnen maken die een normale query opsplitsen in 26 queries, maar dan is je performancewinst waarschijnlijk alweer ver in het negatieve omgeslagen

En zoals gorgi al zei, kunnen databases de hoeveelheden data die jij noemt gemakkelijk aan, dus het opsplitsen lijkt me niet handig.

Wat betreft de plaatjes, die kan je het beste ergens los neerdumpen. Eventueel kan je ze nog wel opdelen in wat mappen, ik meen ergens te hebben gelezen dat sommige filesystems traag worden bij veeel files in een dir, maar dat weet ik niet zeker, dat zou je even moeten benchen misschien.

edit:
Of betekent die a niet dat je ook een b, een c enzovoorts wilt maken?

[ Voor 4% gewijzigd door eamelink op 02-01-2005 20:21 ]

[iznogood]

Thanks for the input mensen. Het is helemaal duidelijk voor mij. Ik zal in het vervolg alles gewoon in 1 db dumpen en niet voor ieder klein ding een tabel aanmaken. Ook zal ik eens beginnen met het gebruiken van de index

De fotobestanden ga ik wel verdelen over meerdere mappen. Ik ben persoonlijk tot de conclusie gekomen dat als je meer dan een paar duizend bestanden hebt dat dat toch niet zo heel lekker loopt.

Excuus voor de onkundigheid, maar het is voor mij een langlopend en zelfontwikkelend project dus alles komt goed!!

[ludo]

iznogood schreef op zondag 02 januari 2005 @ 20:19:
[...]

Nee die a staat er voor de fun bij ... nu worden gewoon alle gebruikersnamen in 1 tabel gedumpt.

Ow gelukkig Maar je hebt daar ook nog 'age' staan. Dat is ook niet handig om zo in een database op te nemen. In een database moet je nooit zulke gegevens opslaan. Je zou wel de geboortedatum op kunnen nemen in je database. Wanneer je dan wilt weten hoe oud iemand is, kun je dat vanuit die geboortedatum berekenen.
Want als je een leeftijd opneemt in een database, hoe weet je dan wanneer iemand een jaar ouder is?

Kennis moet groeien Succes! Ik hoop dat we je in ieder geval alweer iets wijzer hebben kunnen maken

[ Voor 10% gewijzigd door ludo op 02-01-2005 20:26 ]

[Jrz]

Best een leuk topic

Ik denk dat je beter wat meer in zal moeten lezen..

[iznogood]

ludo schreef op zondag 02 januari 2005 @ 20:25:
[...]
Ow gelukkig Maar je hebt daar ook nog 'age' staan. Dat is ook niet handig om zo in een database op te nemen. In een database moet je nooit zulke gegevens opslaan. Je zou wel de geboortedatum op kunnen nemen in je database. Wanneer je dan wilt weten hoe oud iemand is, kun je dat vanuit die geboortedatum berekenen.
Want als je een leeftijd opneemt in een database, hoe weet je dan wanneer iemand een jaar ouder is?

Kennis moet groeien Succes! Ik hoop dat we je in ieder geval alweer iets wijzer hebben kunnen maken

Taking notes

[Johnny]

ludo schreef op zondag 02 januari 2005 @ 20:25:
[...]
Ow gelukkig Maar je hebt daar ook nog 'age' staan. Dat is ook niet handig om zo in een database op te nemen. In een database moet je nooit zulke gegevens opslaan. Je zou wel de geboortedatum op kunnen nemen in je database. Wanneer je dan wilt weten hoe oud iemand is, kun je dat vanuit die geboortedatum berekenen.
Want als je een leeftijd opneemt in een database, hoe weet je dan wanneer iemand een jaar ouder is?

Datum registreren waarop de leeftijd werdt ingevoerd

Als je er dan ieder jaar eentje bij optelt heb je gemiddeld van 50% van de gebruikers de juiste leeftijd, en bij de andere 50% zit je er dan een jaar onder, of boven.

[JHS]

Verwijderd schreef op zondag 02 januari 2005 @ 20:07:
[...]


Opeens schoot de welbekende kaartenbak analogie door mijn hoofd.

Niet echt terzake, maar volgens mij is dat juist een compleet verkeerde analogie . Als het een simpele kaartenbak was, kan je het juist makkelijk opsplitsen. Dat doen ze in de bieb in het echt ook . Je weet dan namelijk iemand zijn primaire gegeven altijd, zoals de naam, zodat je ze makkelijk kan opzoeken. Als je de naam weet, weet je ook gelijk in welke kaartenbak moet zoeken. Houd de kaartenbakken overzichtelijk, zoekt dus sneller.

Punt met database's echter, is dat je lang niet altijd iemand zijn primaire gegeven weet. Je wil soms het primaire gegeven van meerdere mensen opzoeken, bijvoorbeeld met het verjaardagsvoorbeeld. Het mooie van een database is dat hij de relatie zo mooi weergeeft. Waardoor je snel alle mensen die jarig zijn kan opzoeken, waarna je hun naam, of idnr hebt, en eventuele andere gegevens, of ze man of vrouw zijn bijvoorbeeld, zodat je dat alles mooi weer kan geven .

Ik kom zo snel niet op een andere analogie, maar het is geen kaartenbak iig, een kaartenbak heeft ook altijd maximaal 1 index .

[JayVee]

Over het opslaan van foto's in de database. Zoek daar eens over. Daar zijn genoeg topics over langsgeweest. Het grootste probleem was volgens mij dat de plaatjes niet gecached kunnen worden. En voor iemand die niet zo thuis is in databases is het ook nog eens makkelijker om gewoon de filename (met pad) in de db te zetten. Suc6!

[Verwijderd]

Ik los het meestal zo op dat ik entries in een DB tabel heb en daarmee corresponderend bestanden die ik een numerieke naam geef. Dus tabel entry met pimary key 127 heeft als bijbehorend bestand /pix/127.gif. Het voordeel is dat je dan de lokatie van de files nog eens kunt wijzigen zonder dat je alle tabel entries hoeft aan te passen. Het tweede voordeel is dat de filenamen automatisch uniek zijn...

[Janoz]

JayVee schreef op zondag 02 januari 2005 @ 22:26:
Over het opslaan van foto's in de database. Zoek daar eens over. Daar zijn genoeg topics over langsgeweest. Het grootste probleem was volgens mij dat de plaatjes niet gecached kunnen worden. En voor iemand die niet zo thuis is in databases is het ook nog eens makkelijker om gewoon de filename (met pad) in de db te zetten. Suc6!

Het cachen van plaatjes heeft weinig te maken met of het plaatje uit de database of van een filesystem komt. Zodra je het via een scriptje ophaalt (een script dat het plaatje dus opleverd ipv dat blaat.gif als src in een img tag word gezet) is het van belang dat je de juiste headers opneemt. Zolang dat goed is wordt het plaatje ook juist gecached.

Plaatjes uit de DB zijn over het algemeen ietsje langzamer, maar vaak is het verschil verwaarloosbaar. Een voordeel van plaatjes in de db is dat je beter de integriteit van je data af kunt dwingen. In een bakcup worden dan immers ook de plaatjes binnen de db meegenomen. Waneer deze ergens in een mapje staan kan het voorkomen dat ze niet juist meegebackuped worden (doordat het vergeten wordt of doordat het op verschillende momenten gebeurt waardoor een verandering in de db wel gebackuped is terwijl de plaatjes dir gebackuped is voordat deze verandering gebeurt was.)

Kortom, voor beiden is wat te zeggen.

[Verwijderd]

Janoz schreef op maandag 03 januari 2005 @ 10:57:
Het cachen van plaatjes heeft weinig te maken met of het plaatje uit de database of van een filesystem komt. Zodra je het via een scriptje ophaalt (een script dat het plaatje dus opleverd ipv dat blaat.gif als src in een img tag word gezet) is het van belang dat je de juiste headers opneemt. Zolang dat goed is wordt het plaatje ook juist gecached.

Gecachet in de browser of proxyserver van de gebruiker bedoel je. Inderdaad dat is ook heel belangrijk. Maar ik denk dat de poster het hier over de disk cache had.

Disk en filesystem caches zijn ook heel belangrijk voor webservers. Je hebt natuurlijk ook weer de mogelijkheid om dbqueries te cachen en ook dbservers hebben voordeel van disk en filesystem caches dus de vraag over wat efficienter is is i.d.d. niet zo heel eenvoudig te beantwoorden.

Mijn instinct zou toch kiezen voor de filesystem oplossing...

[gorgi_19]

Je kan ook in memory cachen van plaatjes.

[Olaf van der Spek]

Janoz schreef op maandag 03 januari 2005 @ 10:57:
Het cachen van plaatjes heeft weinig te maken met of het plaatje uit de database of van een filesystem komt. Zodra je het via een scriptje ophaalt (een script dat het plaatje dus opleverd ipv dat blaat.gif als src in een img tag word gezet) is het van belang dat je de juiste headers opneemt. Zolang dat goed is wordt het plaatje ook juist gecached.

Het nadeel van blobs (of plaatjes) in MySQL is dat de blob eerst van MySQL naar PHP moet en dan van PHP naar het OS.
Als de blobs gewone files zijn, kun je de eerste twee stappen overslaan, wat een redelijke CPU besparing betekent.

[Janoz]

Deze acties zijn voornamelijk IO acties en deze kosten sowieso erg weinig cpu. Natuurlijk is een plaatje rechtstreeks laten opvragen door de webserver (en niet het os) sneller, maar heel vaak is die winst te verwaarlozen, zeker ten opzichte van andere wensen. Daarnaast kan een DB ook erg goed cachen (deze is immers speciaal ontwikkeld om data goed en snel aan te leveren )

Bij veel applicaties die ik nu maak houd ik het liefst de programatuur en de data gescheiden. Waneer ik tussen de php bestanden (om maar even bij deze omgeving te blijven, in mijn geval gaat het om java webapps) ook nog een mapje op moet nemen met daarin de upgeloade afbeeldingen moet ik de webapplicatie twee kanten op backuppen.

In mijn huidige structuur staat alle content in een database. Deze database wordt elke dag gebackuped. De code van de site zelf staat hier locaal in cvs. De release die inline staat is getagged. Bij een verwijderde webapp hoef ik alleen maar ene nieuwe release vanuit cvs te draaien en dat online te gooien en eventueel de database terug zetten.

Waneer ik een mapje had gehad met daarin content dan had ik deze telkens ook moeten backuppen wat weer een nieuw radartje is dat fout kan gaan.

Conclusie is dat er geen duidelijke winnaar is. Beide methoden hebben zo hun voordelen en nadelen.

[Olaf van der Spek]

Janoz schreef op maandag 03 januari 2005 @ 13:12:
Deze acties zijn voornamelijk IO acties en deze kosten sowieso erg weinig cpu.

Van disk naar MySQL is IO. Van MySQL naar Apache/PHP is CPU, tenzij de servers op verschillende systemen staan, dan komt er nog IO bij. Van Apache/PHP naar OS is ook CPU.

Natuurlijk is een plaatje rechtstreeks laten opvragen door de webserver (en niet het os) sneller,

Met Linux sendfile (of OS equivalent) komt het plaatje zelf nooit in de webserver.

maar heel vaak is die winst te verwaarlozen, zeker ten opzichte van andere wensen.

Als performance nauwelijks een issue is wel ja.

Daarnaast kan een DB ook erg goed cachen (deze is immers speciaal ontwikkeld om data goed en snel aan te leveren )