Database snel houden met veel data
- Ricardo -
23/08/2010 14:57:20Ha iedereen,
Ik ben druk bezig om een site te maken waar mensen berichten e.d. kunnen posten. Nu kan dit oplopen tot enkele 10.000 den berichten per maand. Hoe houd je dus de (MySQL) database snel, ook al zitten er honderdduizenden rows in? Ik dacht aan misschien voor elke maand een aparte tabel laten genereren en daar de berichten van die maand in zetten ?
Hoe doen jullie zoiets ?
Alvast bedankt!
Ricardo
Ik ben druk bezig om een site te maken waar mensen berichten e.d. kunnen posten. Nu kan dit oplopen tot enkele 10.000 den berichten per maand. Hoe houd je dus de (MySQL) database snel, ook al zitten er honderdduizenden rows in? Ik dacht aan misschien voor elke maand een aparte tabel laten genereren en daar de berichten van die maand in zetten ?
Hoe doen jullie zoiets ?
Alvast bedankt!
Ricardo
PHP hulp
22/12/2024 04:44:22Chris -
23/08/2010 14:59:31Normaliseren! Dat is alles ;-) database normaliseren
- Ricardo -
23/08/2010 15:07:39Ja maar dan nog houd je bepaalde tabellen met miljoenen rijen, hoe weinig data er ook in die rijen staat ? Het lijkt me niet dat hij daar erg snel van blijft ? Bijv. twitter ?
Remco van Arkelen
23/08/2010 16:26:50MySQL kan heel snel zijn, ook met honderduizenden of miljoenen records. Zorg voor een goed datamodel, niet alleen normaliseren maar ook het kiezen van de juiste datatypes en indices scheelt enorm in performance.
Data verplaatsen naar andere tabellen is fout...niet alleen werkt het fouten in de hand, je krijgt ook een wildgroei aan dynamisch aangemaakte tabellen die allemaal dezelfde structuur hebben. Wat nu als je door al die berichten gaat zoeken? Na een jaar zou je een union krijgen met 12 tabellen, na 2 jaar zit je op 24 tabellen etc...dat wordt traag, heel traag.
Als je daadwerkelijk zoveel records verwacht te gaan verwerken zou ik iets meer onderzoek doen naar het schalen van database-systemen. Als straks blijkt dat je 2 of meer servers nodig hebt voor je database is het wel van belang dat je begrijpt hoe je database omgaat met clusters/replicatie etc.
Data verplaatsen naar andere tabellen is fout...niet alleen werkt het fouten in de hand, je krijgt ook een wildgroei aan dynamisch aangemaakte tabellen die allemaal dezelfde structuur hebben. Wat nu als je door al die berichten gaat zoeken? Na een jaar zou je een union krijgen met 12 tabellen, na 2 jaar zit je op 24 tabellen etc...dat wordt traag, heel traag.
Als je daadwerkelijk zoveel records verwacht te gaan verwerken zou ik iets meer onderzoek doen naar het schalen van database-systemen. Als straks blijkt dat je 2 of meer servers nodig hebt voor je database is het wel van belang dat je begrijpt hoe je database omgaat met clusters/replicatie etc.
- Ricardo -
23/08/2010 18:21:26Ok, dankjewel! Ik ga er achteraan. Eerst maar gewoon met normaal normaliseren, en later zal ik me dan eens gaan verdiepen in database schaling en loadbalancing en dergelijke.