[PHP] MySQL multi database connectie..

Ik heb een script dat queries draait naar db server A.
Maar uiteindelijk zullen de queries verdeeld zijn over server A en server B (soort van replicatie, maar dan anders ).

Hoe kan ik dit met PHP regelen dat ik met meerdere db's kan connecten?
Of moet ik iedere keer opnieuw bij iedere query opnieuw toegang maken dmw mysql_connect?

Gewoon je result van mysql_connect opslaan in twee verschillende variabelen? Als je tenminste weet welke queries je op welke server wilt uitvoeren.

eddie schreef op 13-04-2005 @ 21:54 :
Gewoon je result van mysql_connect opslaan in twee verschillende variabelen? Als je tenminste weet welke queries je op welke server wilt uitvoeren.

Logisch

Bedankt

mysql_query($query); werkt als je een database_connect($database, $..); hebt gedaan, maar je kan dus ook mysql_query($query, $db1); en mysql_query($query, $db2); doen type ik met mijn brakke hoofd.

Zoiets heb ik dus ook egdaan..
$db1 = mysql_connect();
$db2 = mysql_connect();

mysql_query("", $db1);
mysql_query("", $db2);

Server A voert het script uit over de database servers B en C.
Heb als test even een kleinere database gepakt van 11 MB..
Duurt 2 minuten om uit te voeren ofzo

Ah.




Is dat goed of slecht?

Het is een eenmalige conversie, dus het is verder niet erg..

Maar een script dat 2,5 minuut doet om 'wat' queries te parsen...
(Ok, heeeel veel queries in dit geval )

2 minuten is ganz schnell!

********** schreef op 14-04-2005 @ 21:19 :
Het is een eenmalige conversie, dus het is verder niet erg..

Maar een script dat 2,5 minuut doet om 'wat' queries te parsen...
(Ok, heeeel veel queries in dit geval )

Hmm... ik weet niet of MySQL het kan, maar misschien een idee om de queries pre-compiled in de database te zetten?

Of werken met 'parameterized queries' wanneer de query hetzelfde is alleen de voorwaarde veranderd (x = 1 -> x = 2 -> x = 3; niet x = 1 -> y = 2 -> z = 3) zodat de optimizer de query in cache kan bewaren, het executie plan in opnieuw hoeft uit te rekenen en de query niet opnieuw hoeft te compileren. (jaaaaa, ik ben ook eens bezig geweest met database)

Ulfheðin schreef op 14-04-2005 @ 21:20 :
2 minuten is ganz schnell!

Ja, heb er niet ingebouwt dat hij bijhoud hoeveel queries hij draait.. wel jammer...

Maar reken op een stuk of 1000 (wat makkelijk kan oplopen tot 10000).

eddie schreef op 14-04-2005 @ 21:28 :
Hmm... ik weet niet of MySQL het kan, maar misschien een idee om de queries pre-compiled in de database te zetten?

Of werken met 'parameterized queries' wanneer de query hetzelfde is alleen de voorwaarde veranderd (x = 1 -> x = 2 -> x = 3; niet x = 1 -> y = 2 -> z = 3) zodat de optimizer de query in cache kan bewaren, het executie plan in opnieuw hoeft uit te rekenen en de query niet opnieuw hoeft te compileren. (jaaaaa, ik ben ook eens bezig geweest met database)

Ja, dit kan wel...
Alleen ik moet voor een hoop queries de auto_inc id terug hebben omdat de id's veranderen en dus opnieuw verwerkt moeten worden...
Dan gaat dat helaas niet op...

********** schreef op 14-04-2005 @ 21:29 :
Ja, dit kan wel...
Alleen ik moet voor een hoop queries de auto_inc id terug hebben omdat de id's veranderen en dus opnieuw verwerkt moeten worden...
Dan gaat dat helaas niet op...

Als jij het zegt

Daar ik je queries niet ken en je conversiescript kan ik er verder weinig over zeggen

Ik laat wel weten als het resultaat er is...
(En waar het nou eigenlijk allemaal over ging)


Bijkoemdn nadeel is trouwens dat het om een MySQL3 servers gaat, en niet MySQL4...

Nog een tip om het geheel wat sneller te maken:
haal alle indexen, constraints e.d. eraf en maak auto inc velden niet auto inc.

Dit maakt de conversie wel een stukje complexer (aangezien je nu zelf allemaal dingen moet controleren) maar de database hoeft minder bij te houden. Zeker bij veel records zal je dit goed merken.

klein voorbeeldje bij een index op een kolom

bij/na een insert moet de database:

• de index bijwerken
• indien nodig de 'pages' (waaruit de index is opgebouwd) opnieuw gaan rangschikken
• indien het een 'clustered index' (heeft MySQL dat?) is, ook de records fysiek gaan rangschikken
• eventueel statistieken bijwerken

(bovenstaande is niet een een specifieke volgorde en kan incompleet zijn)
En dat voor iedere insert. Sneller is dus de index eraf halen, dan alles inserten en daarna de index er op zetten. Dan kan de database namelijk de hele tabel in één keer door.