[MySQL] Snelheid met veel tabellen

[Verwijderd]

Ik zit een beetje met een probleem. Ik wil een groot systeem gaan gebruiken om daarin verschillende sites bij te houden in de toekomst. Het is een beetje een lang verhaal, dus om het kort te houden.

Dit systeem maakt gebruik van 1 MySQL database, met daarin redelijk wat tabellen, zijn er nu al 200 maar kunnen er makkelijk 500 worden. Zou dit een probleem kunnen worden met het oog op de snelheid van deze database. Anders kies ik er liever voor om bijvoorbeeld 10 databases van 20 tabellen te maken.

Ik heb al gezocht maar kom nog niet echt tot een goed antwoord.

[Taro]

Ik denk dat het zeker voor het overzicht aan te raden is meerdere databases te gebruiken. Voor de snelheid lijkt het mij weinig uit te maken, maarja, dat weet ik ook niet zeker.

[Varienaja]

Ik heb een tegenvraag: Waarom denk je dat het uit zou maken in snelheid als je maar 10 of wel 500 tabellen in je database hebt staan?

[Verwijderd]

Ik denk ook zeker wel dat het iets uitmaakt in snelheid maar vraag is of je het zal merken, het gaat gewoon om nieuws tabellen etc. Geen tabellen met duizenden records of iets dergelijks.

En voor het overzicht maakt het me niet zo veel uit, de naamgeving is namelijk goed en duidelijk.

[T-MOB]

Of het iets uitmaakt in snelheid kun je natuurijk benchmarken. Maak een testdatabase waarin je één van de 200 tabellen kopieert en test of het wat uitmaakt.

Verder kan ik niet helemaal bij de gedachte achter een database met 200 tabellen. Een database gebruik je om tabellen die bij elkaar horen/gerelateerd zijn in onder te brengen. Ik kan me zo geen voorstelling maken van een DB met 200 tabellen die niet bestaat uit een samenraapsel van meerdere logische eenheden die bij elkaar gedumpt zijn. Maar dat kan aan mijn voorstellingsvermogen liggen...

[Gomez12]

Een systeem om verschillende sites bij te houden, dan denk ik dus dat al deze sites op dezelfde basis draaien dus gewoon in dezelfde tabellen kunnen ( met 1 extra veld genaamd site ). Maar het feit dat je veel tabellen hebt is niet hinderlijk bij een gewone site ( totdat je in phpmyadmin etc alle tabelgegevens gaat opvragen ) voor je applicatie mag dit geen hinder zijn.

Ik werk op dit moment met 1098 tabellen is een dump van een k*t erp systeem wat 's nachts gemaakt wordt en wat even leuk 1021 tabellen bevat, hier hangen dus nog een 77 extra tabellen aanvast ( sommige performancewijs, sommige extra info ) maar in de web-applicatie zelf merk je hier niets van. Alleen gebruik ik tegenwoordig bijna alleen maar mysql cli ipv phpmyadmin want phpmyadmin geeft een output die mijn server en browser niet leuk vinden.

Maar ideaal gezegd zou ik zeggen kies voor zo weinig mogelijk tabellen vanwege overzichtelijkheid en onderhoudbaarheid. Maar performancegewijs is er als je het goed opzet weinig op tegen.

Let wel op, dit verhaal gaat niet op als jij een join over 30 tabellen heen gaat maken, dan denk ik dat mysql compleet in elkaar crasht. Maar als jij per query het beperkt tot een stuk of 10 tabellen dan gaat het allemaal goed denk ik. Alhoewel ik query's met 20 tabellen toch performancegewijs bijna altijd gedeeltelijk via php doet omdat mysql hier op een gegeven moment slechter in gaat presteren ( let op subquery's zijn in mysql 4.x branch wel werkend, maar niet altijd performant misschien in 5.x wel, maar hier werk ik niet mee )

[ Voor 33% gewijzigd door Gomez12 op 07-06-2005 22:02 ]

[NMe]

Wat betreft die performance hoef ik al niets meer te zeggen, dan hebben de mensen boven me al gedaan. Maar mag ik vragen wat je kwijt wil in 500 tabellen? Eerlijk gezegd ruikt dat naar een brak datamodel of een heel gecompliceerde/gedetailleerde applicatie. Helaas zie ik dat eerste vaker dan het laatste.

[Verwijderd]

Inderdaad ruikt dit naar een brak datamodel en is het eigenlijk totaal onlogisch en klopt het van geen kanten. Dat weet ik, maar zolang ik het overzicht kan houden, en geloof me dat lukt nog makkelijk en de performance er niet op achteruit gaat (wat jullie zeggen en ik al dacht) dan is het goed.

Kortom bedankt voor de reacties, ik denk dat ik hier nog wel even mee door kan gaan.

[Webgnome]

Inderdaad ruikt dit naar een brak datamodel en is het eigenlijk totaal onlogisch en klopt het van geen kanten

Als het onlogisch is, brak en van geen kanten klopt waarom niet een redesign? Het is toch veel logischer om diverse databases te gebruiken waarbij je elke database zijn eigen user toewijst hierdoor is het ook niet meer mogelijk dat een website de ander zou kunnen gaan beïnvloeden. Denk aan dat iemand in jou servertje zit te pielen met die user/ww en ineens alles kan zien. Je kan dan beter zeker zijn dat iedereen zijn eigen usertje heeft en ik durf te wedden dat 500 tabellen echt niet meer overzichtelijk is. Zeker niet als je er ff niks meer mee doet en dan ineens weer iets moet aanpassen... mmmmm welke tabel zal ik eens pakken

over de snelheid.. is al gezegd

[napel25]

Een mooi data model hoeft niet altijd snel te zijn. Soms moet je de-normaliseren om performance te winnen.
Wanneer bijvoorbeeld veel sessies tegelijk op één tabel werken kan er 'file vorming' ontstaan. Met name wanneer er gebruik wordt gemaakt van een grof locking systeem. MySQL heeft enkele storage engines met een grof locking systeem.
In zo'n geval kun je beter voor veel kleine tabellen kiezen. De sessies hoeven dan i.i.g. niet op elkaar te wachten.

[ Voor 3% gewijzigd door napel25 op 08-06-2005 10:27 ]

[djluc]

Je kan dan beter voor een ander tabeltype kiezen dan voor meerdere tabellen met vergelijkbare data.

[Guru Evi]

Ik kan er wel inkomen in dat soort model daar ik er dagelijks mee werk.

Je maakt x-aantal sites op 1 server en geeft die allemaal een aparte databank. Daar elke site een aparte user heeft geef je elke site een databank want je wilt niet dat ze in andermans databank gaan zitten. Als je op elke site dan standaard een PHPbb voorinstalleert kom je ongeveer aan die situatie.

Als je natuurlijk in dezelfde site gebruik maakt van meerdere verschillende databanken dan ben je wel verkeerd bezig. Dan combineer je ze best, anders moet je constant mysql_select_db doen of meerdere connecties open hebben en dat wil je natuurlijk niet.

De snelheid gaat niet veel verschil geven in het eerste geval. In het tweede geval ga je gewoon veel overhead hebben welke performance issues kan geven waardoor je best gewoon in het begin goed uitdenkt anders zit je later in de puree met een live site.

[Verwijderd]

Ik heb nog nooit echt een case gezien waar de snelheid belangrijker werd geacht dan onderhoudbaarheid, integriteit van data en schaalbaarheid.

Voor de kosten die je in een later stadium kwijt bent met wijzigingen in je applicatie kun je straks bij wijze een heel cluster aan machines neerzetten.

[Tjeemp]

zouden er voor die verschillende websites niet een hoop tabellen zijn die voor meerdere websites gebruikt worden? dan geef je iedere website een id mee of zoiets, en dat is ook een veld in de tabel, en je opent per website gewoon alle records uit een tabel met de website id...

maar soms staat de host het trouwens niet toe om meerdere databases aan te maken, dus dan zit je vast aan die ene, dat is bij mij het geval, al zit ik er niet mee, mja