Argumente für die Nutzung von PostgreSQL

Martin Langhoff spricht sich für PostgreSQL aus (Quelle: Moodle überholt WebCT und LNLS an der Athabasca University? Forum Eintrag)

Es gibt mehrere Gründe, sich auf Postgres einzulassen, ich werde versuchen, diese kurz zu skizzieren. Wir betreiben bei Catalyst eine Reihe von relationalen Datenbanksystemen und haben damit eine Menge eigener Erfahrungen gesammelt: Oracle, Postgres, MySQL und Progress sowie einige andere. Wir haben auch Erfahrung mit replizierenden Datenbanken, Clustering und weiteren Tricks, die wir als Backend der .nz root domain server sowie für einige andere erfolgskritische Systeme einsetzen.

Für die Performance ist bei Postgres ein wenig mehr Aufwand für die anfängliche Konfiguration notwendig als bei MySQL. Eine gut getunte Portgres-DB kommt in der Performance eines SELECT-Statements in etwa an die von kleinen MySQL-Datenbanken heran. Bei großen Tabellen hat man bei MySQL große Performance-Probleme und Postgres verhält sich hier viel besser.

Die Performance beim Schreiben ist bei MySQL auch eine Frage -- bei hoher Last gibt es ernsthafte Probleme mit gleichzeitigen Zugriffen. Auch hier verhält sich Postgres besser.

Aber, um die Wahrheit zu sagen, der Hauptgrund für die Wahl von Postgres ist die Ausfallsicherheit. Wir betreiben eine Menge an Datenbanken und Postgres ist absolut zuverlässig mit dem Fokus auf korrekte ACID (Anm. d. Ü. Atomarität, Konsistenz, Isoliertheit und Dauerhaftigkeit). Wenn ein COMMIT beendet wurde, sind die Daten auch wirklich im Speicher hinterlegt und gehen nicht mehr verloren -- ausgenommen aktuelle Hardwareprobleme, die wir mit einem RAID-1 beseitigen.

Was auch immer wir versucht haben, bei MySQL-Datenbanken unter hoher Last traten wiederholt korrumpierte Indizes auf. Wenn man sich einmal die Startup Scripts für MySQL auf den meisten Linux-Installationen anschaut: sie prüfen bei jedem Hochfahren zuerst nach korrumpierten Daten -- damit wird die Tatsache verschleiert, dass das häufig vorkommt.

Bei kleinen Installationen, die keine erfolgskritischen Daten enthalten mag das ja noch angehen, aber es ist fraglich, ob eine derartige Lösung vertrauenswürdig ist. Und bei großen Datenmengen kann es Stunden dauern, bis die Routinen isamchk/myisamchk durchgeführt wurden -- das können wir uns nicht leisten.

Über die Clustering Lösung von MySQL wird viel gesprochen. Ich glaube, dass sie eine Luftnummer ist. Hauptsächlich irritiert es mich, dass asynchron geschrieben wird -- d.h. es gibt keine Garantie dafür, dass die Daten auch wirklich korrekt im Speicher landen. Manchmal klappt es, manchmal kommen sie beim Slave an. Hmmm.

Unter der Voraussetzung, dass das MySQL Cluster asynchron schreibt, werden Lese/Schreibvorgänge zwischen Master und Slave unterbrochen, wenn wir Daten schreiben und sie sofort (oder sehr schnell darauf folgend) wieder auslesen. Und das kommt doch häufiger vor, als man denkt.

Dann ist auch noch die Erhöhung der Performance beim asychronen Schreiben zu beachten: wenn das in einer autonomen Postgres- oder MySQL-DB geschieht, wird sie viel besser skalieren (es sollten 3-4 mal mehr gleichzeitige Schreibzugriffe erreicht werden). Aber in einem MySQL-Cluster geht dieser Vorteil verloren. Es kann immer noch einigermaßen reagieren, wenn der Master ausfällt, aber Postgres ebenso, nimmt dafür Slony und mit einer besseren Garantie für die Datenkonsistenz.

Kurz gesagt, MySQL ist in der Regel nicht sehr zuverlässig, wenn es um die sichere Speicherung meiner Daten geht, sogar wenn theoretisch garantiert wird, dass alles abgespeichert wurde. Und vom MySQL Cluster wird diese Garantie von vorne herein schon gar nicht abgegeben. Guuuuuuter Hinweis.

Michael spricht davon, UPS (Anm. d. Ü.: Unterbrechungsfreie Stromversorgung) aufzustellen. Wir haben eine UPS-Einheit so groß wie ein PKW und einen Generator dazu, groß wie ein Container, der automatisch startet. Und doch würde ich mich darauf bei einer großen Datenbank-Installation nicht verlassen, wenn es um die Konsistenz der Datenbank geht. So viele andere Dinge als ein Stromausfall können schief gehen (und tun das auch). Wenn ein Prozess ein Problem bei der Datenspeicherung bekommt, sollte der Nutzer das erfahren. Mit asynchronen Schreibvorgängen stehen noch eine Reihe von nicht abgespeicherten Daten in der Warteschlange, aber der Nutzer hat schon eine positive Rückmeldung bekommen.

So sollte eine Datenbank nicht arbeiten.

Ich untersuche gerade einige Techniken ähnliche wie diejenigen, die in livejournal und slashdot benutzt werden. Wir sollten die Skalierbarkeit von Moodle verbessern, indem wir die Last auf der DB um etwa 50% verringern. Das machen wir so nach und nach in Lücken zwischen dringenderen Projekten. Richard und ich sind die richtigen Ansprechpartner, wenn das für jemand von Interesse ist.

Siehe auch

   * Installation von Postgres auf Ubuntu(Debian)
   * MySQL vs. Postgres in Mahara (Mahara ist eine Webapplikation, die ganz ähnlich wie Moodle aufgebaut ist, alle dort vorgebrachten Argumente treffen auch auf Moodle zu). 

Quelle: "https://docs.moodle.org/en/Arguments_in_favour_of_PostgreSQL"

Categories: Administrator | Performance