MySQL Petition

Berthold Cogel cogel at uni-koeln.de
Di Jan 5 09:40:35 CET 2010


Harald Weidner schrieb:
> Hallo,
> 

...

> 
> Das, was man üblicherweise in der Technik damit meint: Wenn eine Anwendung
> statt auf einem auf n Servern betrieben und ihre Performance dadurch um den
> Faktor n erhöht wird.

...

> 
> PostgreSQL kann das von mir beschriebene Szenario definitiv nicht, zum einen
> weil es die dazu nötigen Replikationsmechanismen (noch?) nicht kennt und zum
> anderen die Lockingfreiheit in Read-Mostly Anwendungen prinzipbedingt nicht
> unterstützt.
> 

...


> Die Skalierung von MySQL < 5.4 über mehrere CPU-Kerne ist zwar bedauerlich,
> spielt aber in dem beschriebenen Szenario keine Rolle. In dem typischen
> Setup zur horizontalen Skalierung wird der komplette Ausspielserver mitsamt
> Webserver, Application Server und DBMS auf mehrere Maschinen repliziert. Das
> DBMS kann und darf man dabei gerne lokal an die Menge von CPU Cores binden,
> mit der es optimal läuft. Mit MySQL >= 5.4 ist das Problem ohnehin
> Geschichte.
> 


Das sind genau die Punkte, wo PostgreSQL ein *echtes* Defizit hat. Für
HA- und Loadbalancing-Scenarien ist die Replikation praktisch ein 'Muß'
und die Lösungen, die es hier für PostgreSQL gibt, sind mehr oder
weniger 'geargelt'. Da haben die Entwickler schlicht gepennt. Die HIS
hat das wohl vor einiger Zeit in einer Diplomarbeit für ihr HISinOne
untersuchen lassen. Das Ergebnis war nicht gerade ermutigend.

Bei MySQL kann man, vorausgesetzt man entwickelt seine Anwendung
entsprechend, per Replikation beliebig viele Slaves aufsetzen, die die
lesenden Zugriffe übernehmen, während die schreibenden Zugriffe über den
Master laufen. Das dürfte bei ca. 90% der Hochlast-Webanwendungen der
Fall sein. Und reicht das nicht, dann gibt es noch den MySQL-Cluster.

Die einzige Chance, die man bei PostgreSQL hat ist die Replikation der
Datenbankfiles im Hintergrund mit Lösungen wie Double-Take oder DRBD.
Das Setup ist alles andere als trivial. Dazukommt, daß man man auch hier
seine Anwendung entsprechend entwickeln muß, um Multi-Master-Situationen
zu vermeiden oder sauber abzuwickeln.


Gegen Oracle kommt das alles nicht an. Das ist ein *richtiges* DBMS.
Dafür muß man aber den erhöhten Administrationsaufwand gleich doppelt
bezahlen. Einmal über die Lizenz und zum Anderen über die
Personalkosten. Ein guter Oracle-Admin wird nicht ohne Grund auch heute
noch praktisch mit Gold aufgewogen, verglichen mit anderen Jobs in der
IT-Branche (vom öffentlichen Dienst ganz zu schweigen...).


Gruß
Berthold



Mehr Informationen über die Mailingliste Linux-Users