[PHP/MySQL] globale database: remote of lokaal+mirroring?

[SvMp]

Voor mijn werk heb ik een aantal websites ontwikkeld.
Platform: Ubuntu, Apache 2.2, PHP 5.3, MySQL 5.1

Deze websites gebruiken zowel een eigen database als een algemene database die voor alle websites wordt gebruikt. Die algemene database wordt niet rechtstreeks benaderd vanuit code van de sites zelf, maar door een verzameling classes die door alle websites gemeenschappelijk wordt gebruikt.

Huidige situatie: Alles draait op één machine. De MySQL-server bevat dus een database voor elke website én de algemene database. Welke website gebruikt één MySQL-connectie (MySQLi-extension). Standaard database is de eigen database. Omdat het gebruikte account ook rechten heeft op de algemene database, wordt het onderscheid uitsluitend gemaakt in de queries: "SELECT * FROM tabel_in_lokaal" vs. "SELECT * FROM algemeneDB.tabel_in_algemeneDB".

Dit kan niet zo blijven, omdat de websites niet op één server blijven draaien.

Ik heb ruwweg 2 mogelijkheden in gedachten om flexibiliteit door te voeren:

1. De algemene database komt op een eigen server. De eigen database van de websites draait op dezelfde server als de betreffende website. Er worden twee verbindingen gelegd: Eentje met de algemene database en eentje met de eigen database. Queries zijn inmiddels al gescheiden, er zijn geen gecombineerde queries die zowel de algemene als de eigen database benaderen.

2. Elke webserver draait de (kopie van) algemene database. Op een of andere manier worden die databases synchroon gehouden.


Zelf vind ik mogelijkheid 1 het meest aantrekkelijk. Simpel en gestructureerd. Punt van zorg is performance, omdat er verbinding wordt gelegd met een externe machine. Wel bij dezelfde provider in hetzelfde netwerk, dus lokaal. Hoe denken jullie over deze opties? Zijn er nog andere opties?

[RobIII]

Als je voor 1 gaat zou ik eens zien of je de DB niet kunt ontsluiten als webservice ofzo; een rechtstreekse connectie met MySQL maken op een andere server lijkt me niet zo'n goed idee. Ook voor eventuele latere wijzigingen in de centrale DB is het handig als je een laag abstractie ertussen hebt zitten zodat je niet (snel) wijzigingen in de afhankelijke projecten zult hoeven maken.

Als je voor 2 gaat moet je eens gaan kijken naar replicatie.

[SvMp]

@RobIII: Het is wel binnen één netwerk bij de hostingprovider waar we een aantal eigen servers hebben staan, dus geen verbindingen naar MySQL over internet.

Ik heb de mogelijkheid om met een aantal servers te doen wat ik wil, als die websites maar goed gaan functioneren.

[ Voor 91% gewijzigd door SvMp op 09-02-2011 10:23 ]

[eamelink]

RobIII schreef op woensdag 09 februari 2011 @ 10:11:
Als je voor 1 gaat zou ik eens zien of je de DB niet kunt ontsluiten als webservice ofzo; een rechtstreekse connectie met MySQL maken op een andere server lijkt me niet zo'n goed idee.

Waarom niet?

[RobIII]

eamelink schreef op woensdag 09 februari 2011 @ 10:25:
[...]

Waarom niet?

1) Ik wist (nog) niet of had eroverheen gelezen dat 't binnen dezelfde hoster/netwerk bleef; je MySQL publiek met z'n kont aan het web hangen kan maar is IMHO niet zo heel erg veilig.
2) Zoals ik al zei: met een (desnoods "dun") abstractielaagje ben je vrijer in het aanpassen van de centrale DB zonder dat alle 'client applicaties' er meteen last van hoeven hebben.

[ Voor 10% gewijzigd door RobIII op 09-02-2011 13:36 ]

[SvMp]

@RobIII: Dat is ook de reden dat ik een aantal gemeenschappelijke classes heb die de algemene database benaderen. Door de code van websites zelf geen enkele rechtstreekse toegang.

[RobIII]

SvMp schreef op woensdag 09 februari 2011 @ 14:45:
@RobIII: Dat is ook de reden dat ik een aantal gemeenschappelijke classes heb die de algemene database benaderen.

Ja, maar die rol je nu uit naar elke "client" (lees: website die (ook) gebruik maakt van de algemene DB) zoals ik je begrijp? Als je dan een aanpassing maakt in de algemene DB moet je alle websites nalopen om de gemeenschappelijke classes te updaten. Maak je er een klein smeerlaagje abstractie tussen en gebruik je dus (bijv.!) een webservice dan heb je wat meer flexibiliteit aan de andere kant zonder steeds alle websites na te moeten lopen. Het is overigens zeer zeker geen wondermiddel, bij drastische aanpassingen zul je natuurlijk alsnog de gemeenschappelijke classes moeten updaten en die websites bij moeten gaan werken met de nieuwere gemeenschappelijke classes.

[ Voor 14% gewijzigd door RobIII op 09-02-2011 14:51 ]

[Verwijderd]

Wij gebruiken een zelfde opzet waarbij de centrale DB aangesproken wordt via een set models / DAO's die shared zijn. Dat is in principe een redelijk dunne abstractielaag die erg prettig werkt en waarbij niet te grote wijzigingen in het datamodel weinig tot geen impact hebben op de client code.

Daarnaast is er ook een manier om eventueel het connectieobject naar de hoofddatabase op te vragen.