PostgreSQL und MariaDB im Cluster
Wimmelbild
Datenbanken zu clustern, ist keine einfache Aufgabe. Für PostgreSQL und MariaDB existieren Erweiterungen, die dafür Sharding verwenden. Ihr Einsatz lohnt jedoch nur in bestimmten Fällen.
Stößt man an die vertikalen Skalierungsgrenzen einer relationalen Datenbank, kommt schnell die Forderung nach einem Cluster. Die meisten Systeme bieten diese Fähigkeit nicht von Haus aus, sie benötigen dafür Zusatzsoftware. Dass dies keineswegs einen linearen Speed-up garantiert und oft alte Probleme durch neue ersetzt, ist vielen nicht bekannt. iX hat Clustering-Lösungen für PostgreSQL und MariaDB untersucht und gibt Hinweise, wofür sich ein Einsatz lohnt. Zahlen hierfür liefern Benchmarks des Transaction Processing Performance Council (TPC).
Relationale Datenbanken lassen sich auf verschiedene Arten auf mehrere Rechenknoten verteilen. Bei ausreichendem Storage kann man die gesamten Daten auf mehreren Knoten ablegen und die Leseanfragen darauf verteilen. Schreibanfragen landen üblicherweise auf einem Master. Alle anderen Rechner im Cluster sind Replikations-Slaves. Dies funktioniert so lange, bis entweder die Schreiblast auf dem Master oder die (sequenzielle) Replikation zum Flaschenhals wird. Außerdem muss die Applikation wissen, dass auf einem Knoten geschrieben wird und die Daten beim nächsten Lesen vom Slave möglicherweise noch nicht aktuell sind. PostgreSQL erlaubt tatsächlich auch synchrone Replikation, allerdings nur mit einem einzigen Slave.
Verteilt man die Daten, spricht man von Sharding. Dafür sollte es inhaltlich sinnvolle Sollbruchstellen geben, zum Beispiel einen Shard pro Land, Abteilung oder Kundengruppe. Eine typische Lösung, wenn dies nicht möglich ist, besteht darin, die Daten per Hashverfahren auf die Knoten zu verteilen. Hier beginnen die Herausforderungen: Quasi alle relationalen Datenbanken unterstützen Joins, die dazu führen können, dass Datensätze von unterschiedlichen Knoten miteinander verknüpft werden müssen. Dies ist über ein Netzwerk viel teurer als lokal. Außerdem werden aus lokalen Transaktionen nun verteilte Transaktionen, die eine Reihe neuer Probleme mit sich bringen.
Für die beliebten Open-Source-Datenbanken PostgreSQL und MariaDB existieren Erweiterungen, die mit geshardeten Tabellen hantieren können. Die Autoren haben CitusDB und Postgres-XL für PostgreSQL und ColumnStore für MariaDB unter die Lupe genommen. Als Maß, wie gut diese Datenbank-Cluster die Performance steigern können, dienen die Benchmarks TPC-H und TPC-DS. Beide befüllen die Datenbanken mit Musterdaten und führen dann eine Reihe beispielhafter Querys zum Decision Support durch. Sie treten gegen Amazons Redshift an, um ein spezialisiertes System als Benchmark zu haben.
CitusDB
CitusDB ist eine Erweiterung für PostgreSQL. Sie verteilt Daten per Hashing auf die Knoten und schreibt Anfragen entsprechend um. Der Client spricht immer mit einem Master, der die Verteilung der Daten und Querys an die Worker und den Zusammenbau des Ergebnisses übernimmt. Aus Redundanzgründen kann der Master repliziert werden, da er die Metadaten über den Cluster enthält. Die Worker-Nodes wissen nicht einmal, dass sie Teil eines Clusters sind.
Fällt ein Worker aus, kann er nach dem Reboot wieder in den Cluster integriert werden. Im Falle eines permanenten Ausfalls verteilt CitusDB die Shards dieses Knotens über den Cluster, um den Replikationsfaktor wiederherzustellen. Letzteres muss bei der Community Edition manuell angestoßen werden. Die Enterprise Edition enthält einen Shard Rebalancer, der dies automatisch erledigt.
CitusDB ist kein Fork von PostgreSQL, sondern eine Erweiterung, die mit jedem „normalen“ PostgreSQL 9.6 (oder höher) zusammenspielt. Dies unterscheidet CitusDB von seinem Konkurrenten Postgres-XL. Laut Hersteller-Website ist ein Einsatzgebiet die Skalierung von operationalen Reporting-Systemen, also von relativ einfachen Leseanfragen auf möglicherweise voraggregierten Daten in Stern-Schemata. Weniger empfohlen wird das Produkt für komplexe Ad-hoc-Querys.