[DB] Performance: 1 grote DB of meerdere kleintjes?

[kmf]

Ik ben bezig een snelgroeiende site aan het opzetten, deze heeft meerdere seperate onderdelen die een database nodig hebben.

Qua performance, is het beter om een grote database met zo'n 200 tabellen te hebben of meerdere "kleintjes" van zo'n 50 tabellen elk? (waarvan een gescharede users-db)


Meerdere databases betekent meestal meerdere MySQL-connecties, maar 1 grote DB, betekent een hele grote cache.

[Verwijderd]

Dat hangt uiteraard ook af van je dbmodel.

[whoami]

Ik zou -als de gegevens op de een of andere manier met elkaar gerelateerd zijn- voor 1 DB kiezen. Ik denk dat dit zowiezo qua onderhoud en consistentie v/d gegevens makkelijker zal zijn.

Een connectie maken met een DB is altijd duur (tenzij je connection pooling gebruikt).

[kmf]

Voor de usersdatabase en de grootste DB zal ik in ieder geval persistent connections gebruiken zodat de overhead van de connectie wordt geminimaliseerd.

[gorgi_19]

athlonkmf schreef op 18 mei 2004 @ 09:49:
Voor de usersdatabase en de grootste DB zal ik in ieder geval persistent connections gebruiken zodat de overhead van de connectie wordt geminimaliseerd.

persistent connection? Waarom maak je geen gebruik van connection pooling? En wat vind je groot? 100.000 records? 1 miljoen records?

[ Voor 9% gewijzigd door gorgi_19 op 18-05-2004 09:51 ]

[Suepahfly]

Een persistent connectie is in de meeste gevallen af te raden.
Een user note van php.net:

Normally you do NOT want to use mysql_pconnect. This function is designed for environments which have a high overhead to connecting to the database. In a typical MySQL / Apache / PHP environment, Apache will create many child processes which lie in idle waiting for a web request to be assigned to them. Each of these child processes will open and hold its own MySQL connection. So if you have a MySQL server which has a limit of 50 connections, but Apache keeps more than 50 child processes running, each of these child processes can hold a connection to your MySQL server, even while they are idle (idle httpd child processes don't lend their MySQL connection to other httpd children, they hold their own). So even if you only have a few pages which actually connect to MySQL on a busy site, you can run out of connections, with all of them not actually being used.

In general use mysql_connect() for connecting to MySQL unless that connection takes a long time to establish.

[whoami]

athlonkmf schreef op 18 mei 2004 @ 09:49:
Voor de usersdatabase en de grootste DB zal ik in ieder geval persistent connections gebruiken zodat de overhead van de connectie wordt geminimaliseerd.

Dat is zeker niet aan te raden. Dit zorgt voor een verminderde schaalbaarheid van je site, aangezien een DBMS meestal slechts een max. aantal concurrente connecties toelaat.
Het is zowiezo beter om je connectie te sluiten van zodra je die een tijdje niet meer nodig hebt. Op die manier kan je dan ook gebruik maken van connection-pooling (als MySQL dat ondersteunt), waardoor de kost om een connectie te maken drastisch verminderd wordt.

Ik denk trouwens niet dat de grootte van je DB (als je die in 'aantal tabellen' meet) zoveel uitmaakt voor de performance van je app.
Het is gewoon zaak dat je een goed DB model hebt, goede keuzes maakt wb indexen, connection-pooling gebruikt, etc....

[ Voor 16% gewijzigd door whoami op 18-05-2004 10:12 ]

[curry684]

Als MySQL geen connection pooling ondersteunt implementeer je het toch lekker zelf

En meerdere DB's voor 1 applicatie is per definitie onoverzichtelijk en functioneel fout. 1 database is juist bedoeld voor de organisatie en security rondom 1 applicatie eenvoudig samen te grijpen, en daar dien je dus al je tabellen in te knikkeren.

200 tabellen is overigens wel knap veel... da's een stuk meer dan ik hier zo snel in de global sales database van een grote elektronicagigant uit ons land kan vinden... Wat ben je in godesnaam aan het opzetten?

[Soultaker]

Hoe kom je trouwens aan 200 tabellen? Dat betekent dat je 200 verschillende entiteiten zou hebben in je database. Dat lijkt me in een praktische situatie wel heel onwaarschijnlijk, dus misschien dat je beter eerst je database kunt normaliseren voordat je je zorgen maakt.

Verder zou ik niet echt weten waarom je databases op zou splitsen. Resources worden toch per tabel gealloceerd, dus in hoeveel databases je tabellen dan onderbrengt maakt niet zoveel uit; het is niet alsof je veel database-globale locks krijgt. Het criterium zou dus moeten zijn of de gegevens onderling gerelateerd zijn en over welke tabellen je tegelijk queries wil uitvoeren. Die tabellen hoor in ieder geval bij dezelfde database.

Ik kan me eventueel voorstellen dat je omwille van de beveiliging of het apart back-up'en van je gegevens aparte databases aanmaakt, maar dat is maar een hypothetisch geval. Als je geen specifieke reden hebt om ze op te splitsen is het integraal backupen natuurlijk veel makkelijker, temeer als de databases bepaalde relaties hebben, want je kunt ze natuurlijk nooit naar hetzelfde punt herstellen.

[kmf]

Die 200 tabellen komen omdat het een netwerk van sites wordt waarvan een aantal van standaard php-pakketten.
Het is dus niet zo dat ik zelf een enorme database ontwerp. (Hoewel, als ik het zelf moet ontwerpen, zal dat ook zoiets worden)

Ik heb dan 1 database met tabellen voor een image gallery, forum, cms, lyrics database, etc, etc en allemaal maken ze gebruik van een gesharede userdb.

qua persistent connections. Ik heb de hele webserver voor mezelf, mysql is zo getweaked dat er maar max aantal pers. connecties gemaakt mag worden, gelijk aan het max aantal connecties -10.

[djluc]

Ik zie misschien wel problemen met de tabelnamen: als je meerdere systemen hebt met standaard tabelnamen is het goed mogelijk dat deze paketten bijvoorbeeld een tabel users hebben.

[hobbit_be]

beetje pakket doet wel:

pakket_tablename...