Längst ist "Cloud Ready" vom Hype zum validen Anwendungsfall für Applikationen geworden. Die zunehmen-de Zentralisierung der IT unter fleißiger Mitwirkung der Hyperscaler wie AWS oder Azure wird diesen Trend aller Vo-raussicht nach sogar noch weiter befeu-ern: Wer heute mit den Planungen für ein neues Programm beginnt, denkt regel-mäßig in Containern, skalierbaren Netz-werktools wie Istio mit Rückendeckung durch Kubernetes und einer in Mikro-komponenten aufgeteilten Architektur, die implizit Skalierbarkeit und obendrein Verfügbarkeit garantiert.

Weil heute beinahe jede Anwendung in irgendeiner Form eine Datenbank ver-wendet, liegt auf der Hand, dass auch Da-tenbanken bei den Planungen skalierbarer Anwendungen eine große Rolle spielen. Gerade MariaDB & Co. taten sich über lange Zeit allerdings schwer, das Skalier-barkeitskriterium zu erfüllen. Zwar steht für MariaDB bereits seit Jahren Galera zur Verfügung, das im administrativen Alltag jedoch mit ganz eigenen Heraus-forderungen daherkommt.

Fast noch brenzliger sieht die Situation im PostgreSQL-Lager aus: Hier hat sich bis heute kein Produkt als Quasi-Standard etabliert, der ein PostgreSQL-Frontend anbietet, den Speicher im Hintergrund aber verteilen und mithin die Skalierbar-keit in die Breite ermöglichen kann. Letzt-lich geht es um genau das, wenn vom Ska-lieren in die Breite die Rede ist: Skalierbare Systeme bedingen, anliegende Last und zu speichernde Daten auf beliebig viele Instanzen eines Dients zu verteilen.

Um diese Herausforderung zu meistern, existieren am Markt mehrere Produkte. Yugabyte etwa wählt einen radikalen An-satz und baut gleich eine komplett eigene Storage-Engine, der ein Frontend mit vie-len verschiedenen Datenbanksprachen zur Seite steht. Zwar implementiert Yu-gabyte nicht die gesamte PostgreSQL-Spe-zifikation, für den Alltag reicht es in den meisten Fällen jedoch aus. Einen anderen Weg geht Citus Data: Sein Produkt Citus verspricht, unter der Haube echtes Post-greSQL zu verwenden und mithin alle PostgreSQL-Funktionen zu bieten. Jedoch baut der Anbieter rund um die eigentli-chen PostgreSQL-Instanzen etliches an Zusatzfunktionen ein, um zentral koor-diniertes Sharding und mithin echte Mul-ti-Master-Funktionalität auf Basis von PostgreSQL zu ermöglichen.

Nun ist es mit Versprechungen der Her-steller bekanntlich so eine Sache – und genau deshalb knüpft der folgende Test sich den Kandidaten im Detail anhand von fünf Aspekten vor. Der erste Aspekt ist die Grundfunktionalität des Produkts: Was beherrscht Citus, wie gut implemen-tiert es das klassische PostgreSQL-Proto-koll und wo ergeben sich etwaige Proble-me? In Runde zwei geht es dann um einen der wichtigsten Faktoren im Kon-text von Datenbanken, nämlich die Kon-sistenz der abgelegten Daten und die Si-cherheit von Transaktionen. Schritt drei wirft ein Schlaglicht auf die Art und Weise, wie Citus sich ausrollen lässt – zwar gehören Setup-Fragen eigentlich nicht zum klassischen Umfang unserer Tests. "Infrastructure-as-Code" ist aber gerade im Kontext der Hyperscaler ein wichtiger Faktor, und eine Datenbank, die im Handling hyperkompliziert ist, wird dem Admin den Alltag kaum erleichtern.

Auch die Themen Sicherheit und Compli-ance dürfen natürlich nicht fehlen, also wie sich eine Citus-Installation gegen Angriffe absichern lässt und inwiefern Citus dem Administrator hier unter die Arme greift. Der fünfte und letzte Schritt schließlich geht auf die Performance ein, wobei sowohl die insgesamt verfügbare Bandbreite als auch die Latenz für kleine Schreibopera-tionen eine Rolle spielen.

Zuvor darf eine kurze Anmerkung zu den Citus-Editionen allerdings nicht fehlen. Der Hersteller vermarktet sein Produkt unter einer freien Lizenz und als quellof-fene Software. Das ist eine relevante Neue-rung der kürzlich erschienenen Version 11, denn vor dieser gab es eine "Enter-prise"-Version und eine Open-Source-Va-riante. Seit Citus 11 steht der gesamte Funktionsumfang unter offener Lizenz. Es steht also jedem Admin frei, das Pro-dukt herunterzuladen und in einer eige-nen Umgebung oder auf einer der großen Plattformen zu betreiben.

Auf Azure ist Letzteres allerdings leichter als anderswo, denn hier bietet Citus selbst entsprechende Appliances an, die der Hersteller aktiv kuratiert. Diese Azure-Edition bietet mehrere Zusatzfeatures und ist im Wesentlichen "Database-as-a-Ser-vice" – natürlich mit den entsprechenden Kosten. Aus Gründen der Vergleichbar-keit geht unser Test jedoch auf die nor-male Edition von Citus ein, denn die lässt sich in jeder Umgebung benutzen.

Skalierbare Datenbanken verhelfen vieler-orts einem technischen Prinzip zu neuen Ehren, das praktisch bereits als vergessen galt. Wer früher Mailserver administriert hat, weiß, worum es geht: Zu einer Zeit, in der von massiv skalierbaren Speichern wie Ceph noch niemand auch nur zu träu-men wagte, behalfen sich Admins auf Mail-servern mit Sharding. Sie verbanden also einen Mailserver mit mehreren Speichern und wiesen einzelne Benutzer den einzel-nen Speichern fest zu. Wurde der vorhan-dene Platz knapp, ließ sich der Speicher erweitern und die IT-Abteilung hatte wie-der Luft nach oben.

So ähnlich funktioniert Citus auch. Es teilt die PostgreSQL-Welt in zwei logische Dienste ein, nämlich den Coordinator und den Worker. Nomen est omen: Der Coor-dinator enthält die Metadaten der Daten-banken in Citus, also Informationen über deren Struktur und ihre einzelnen Tabel-len. Die Daten hingegen residieren auf den Workern. Citus teilt hier aber nicht beliebig auf, sondern folgt dem Ansatz, dass ein Shard eine PostgreSQL-Tabelle ist.

Wer auf vier Tabellen in derselben PostgreSQL-Datenbank zugreift, kommuniziert je nach Größe des Setups also mit vier unterschiedlichen Worker-Knoten. Citus spricht dabei von "Distributed Tables", also von verteilten Tabellen, die obendrein durch den Admin mit einer "Distribution Column" angelegt werden müssen. Anhand jener bestimmt Citus auf Basis eines deterministischen Algorithmus, auf welchem Worker-Knoten eine spezifische Tabelle landet.

Für den Administrator gibt es allerdings Möglichkeiten, die Platzierung unmittelbar zu beeinflussen. Sind einzelne Tabellen in einer Citus-Installation etwa logisch mit-einander verbunden, ergibt es Sinn, diese auf denselben Worker-Knoten zu legen. Denn das erspart dem Coordinator beim Netzwerkzugriff viel Traffic und Zeit, wo-durch spezielle Queries wie etwa JOIN-An-weisungen deutlich effizienter ausfallen.

Neben der Pflege der internen Metadaten sind die Coordinators auch für die Verwaltung der Benutzer einer Citus-Instal-lation zuständig. Sie sind im Regelfall zu-dem die unmittelbare Schnittstelle für Clients: Will eine Anwendung etwas aus einer Datenbank in Citus lesen, schickt sie ihre Anfrage an den Coordinator, der die Daten aus den betroffenen Shards zusammensucht und schließlich als fertige Antwort zurückschickt. Da versteht es sich von selbst, dass der Administrator beim Coordinator nicht auf eine einzelne Instanz angewiesen ist, sondern diese wie die Worker-Knoten auch beliebig in die Breite skalieren kann.

Der Zugriff ist dann allerdings eine Herausforderung, denn wie in konventionellen Umgebungen bedarf es dann ent-weder eines Loadbalancers oder der Admin hinterlegt in den Clients fixe IP-Adressen für die Datenbank. Dann muss er sich allerdings gesondert um das Thema Verfügbarkeit kümmern. Seit Citus 11 besteht für Clients ferner die Möglichkeit, Daten bei einzelnen Worker-Knoten direkt abzugreifen; in der Praxis dürfte das aber nur in sehr wenigen Szenarien tatsächlich zum Einsatz kommen.

Insgesamt schlägt Citus sich bei seiner Grundfunktionalität gut: Tatsächlich lässt sich dank Citus ein mit PostgreSQL völlig protokollkompatibler Datentresor bauen, der je nach Bedarf beliebig zu erweitern ist. Zwar bietet das Produkt damit Funktionalität, die in PostgreSQL fehlt, vorrangig, weil die PostgreSQL-Entwickler ein sol-ches Feature gar nicht unterstützen wollen. Ein Alleinstellungsmerkmal gelingt Citus hier allerdings nicht, denn vergleichbare Funktionalität lässt sich durchaus auch mit anderen Werkzeugen erreichen.

Die schönste Datenbank ist nutzlos, wenn sie die in ihr beheimateten Daten schreddert und bei Transaktionen nicht darauf achtet, konsistent zu bleiben. Das ACID-Prinzip ist genau dafür da: Es legt fest, dass Datenbanken ihre Anfragen "atomic", "consistent", "isolated" und "durable" abhandeln müssen. "Atomic" oder "atomar" meint dabei, dass die Anfragen stets komplett und vollständig ihren Weg in die Datenbank finden müssen – oder gar nicht. Bricht die Verbindung zwischen Client und Datenbank während eines Schreibvorgangs ab, darf in der Datenbank kein Datensalat stehen, sondern diese muss den gesamten Schreibvorgang verwerfen.

In dasselbe Horn stößt das "C", denn Datenbanken müssen garantieren, dass sie vor und nach einem Schreibvorgang in einem konsistenten Zustand sind. "Isolated" bedeutet, dass zwei zeitgleich einset-zende Operationen auf dieselben Daten der Datenbank dieselben sauberen Ausgangsdaten sehen müssen. Kommt es zum Konflikt, muss die Datenbank sich erst beim Commit um diesen kümmern. "Durable" schließlich verweist darauf, dass Daten in der Datenbank sich nicht ohne das passende Query verändern dürfen. Die Einhaltung des ACID-Prinzips ist schon bei einer einzelnen Datenbank eine Herausforderung. Für Citus sind die Hürden hier jedoch ungleich höher, denn hier schreiben verschiedene Clients parallel über verschiedene Coordinators auf die verteilten Shards im Hintergrund.

Die Citus-Entwickler haben das Problem allerdings elegant vermieden. Zwar geben sie an, dass sie im Laufe der Zeit durchaus eigene Strategien entwickelt haben. SoAttribute ihrer persönlichen Accounts im Self-Service ändern und bestimmte existierte zwischenzeitlich ein PAXOS-Modul für PostgreSQL, das die Coordinator-Knoten eingebunden haben. Letztlich verlässt der Anbieter sich mittlerweile aber auf eine Funktionalität, die in Post-greSQL bereits implementiert ist – spezifisch auf die Two-Phase-Commit-Funk-tion ("2PC") der Datenbank.

Das Two-Phase-Commit-Prinzip ist dabei eine Möglichkeit, die beschriebenen Probleme im Hinblick auf Konsistenz in verteilten Umgebungen anzugehen. Andere Ansätze wären Paxos oder Raft, zwei Algorithmen zur Konsensfindung in verteilten Umgebungen. 2PC sowie Raft und Paxos haben dabei spezifische Vor- und Nachteile: 2PC bietet die höchste Performance, ist allerdings darauf angewiesen, dass alle Knoten, die einen Teil der gerade relevanten Daten enthalten, auch tatsächlich online sind. Ist die Anforderung nicht erfüllt, lässt sich die Datenbank im 2PCSystem nicht nutzen.

Paxos und Raft haben weniger strenge Verfügbarkeitsanforderungen, gehen aber mit der Gefahr von Split-Brain-Situationen bei Netzwerkausfällen und weiteren Konsistenzproblemen einher. Die Citus-Entscheidung für 2PC war aus Sicht der Datenkonsistenz und Verfügbarkeit insofern durchaus richtig. Den hohen Verfügbarkeitsanforderungen begegnet Citus dann mit Streaming-Replication für Recovery-Szenarien, damit selbst der Ausfall von Systemen mit einzelnen Shards kein Problem darstellt, zumindest wenn der Admin dieses Feature entsprechend konfiguriert. In Summe schlägt Citus sich hinsichtlich der Konsistenz der ihm anvertrauten Daten also auf Augenhöhe mit dem Markt.

Nach zwei Jahrzehnten in der Informationstechnik kommt es nicht mehr sehr häufig vor, dass wir mit vor Erstaunen offenem Mund vor unserem Bildschirm sitzen. Citus gab genau dafür allerdings –traurigen – Anlass. Denn was der Anbieter hinsichtlich des Deployments liefert, kann eigentlich nur als schlechter Scherz gemeint sein.

Zum Hintergrund: Produkte wie Citus, die ihre eigene Skalierbarkeit hervorheben und sich an verteilte Umgebungen richten, müssen gerade in skalierbaren Umgebungen schnell und leicht aufzusetzen sein. "Infrastructure-as-Code" haben wir bereits erwähnt, jenes Prinzip, bei dem der Administrator seine gesamte virtuelle Infrastruktur in einem versionsverwaltbaren Template beschreibt und das Anlegen der Ressourcen einem Werkzeug wie Kubernetes überlässt.

Wie das in der Praxis aussehen kann, zeigt die Konkurrenz von Yugabyte eindrücklich: Der Anbieter liefert fertige, kuratierte Container-Abbilder seiner Software inklusive Helm-Charts ebenso an wie einen eigenen Operator für Kubernetes. Mit diesem lassen sich etliche Yugabyte-Features nativ und direkt in Form einer Ressource in Kubernetes steuern. Und das wiederum öffnet riesige Möglichkeiten im Hinblick auf fast alle denkbaren Cloud- und Container- Plattformen. In den verschiedenen Kubernetes-Varianten von Azure, AWS oder Googles Cloudumgebung ist das Setup einer Yugabyte-Datenbank eine Frage weniger Handgriffe und Minuten. Und selbst wer lieber "richtiges" Infrastructure- as-a-Service (IaaS) machen möchte, kommt schnell ans Ziel.

Beim Blättern durch die Installationsanweisungen von Citus fühlten wir uns hingegen in die 2000er-Jahre versetzt: Fertige Pakete für Debian, Ubuntu und RHEL bietet der Anbieter an, zusammen mit einer klassischen Installationsanleitung. Das Setup von Coordinator- und Worker- Nodes beschreibt Citus dabei "zu Fuß", von Automation ist also erst gar keine Rede. Eine kurze Recherche ergab, dass es für das Produkt lediglich inoffizielle Integrationen für Ansible oder Puppet gibt. Diese haben ihre jeweiligen Autoren allerdings zum Teil jahrelang nicht mehr gepflegt, sodass unklar ist, ob sie überhaupt funktionieren. Und keine einzige Spur findet sich in der gesamten Installationsanleitung von Kubernetes.

Ein Bugreport im Citus-GitHub-Account erklärt, warum das so ist. Bereits 2016 fragten erste Anwender nach fertig paketierten Citus-Containern, doch bis heute stellt der Anbieter diese schlicht nicht zur Verfügung. Entsprechend mau sieht es auch mit der restlichen Integration in Kubernetes aus, die ebenfalls nicht vorhanden ist. Immerhin: Einzelne Anwender haben Container gebaut und in Kubernetes ausgerollt.

Das setzt allerdings einiges an spezifischem Fachwissen voraus und genießt am Ende trotzdem nicht den offiziellen Support des Herstellers. In Summe ist das gesamte Kubernetes- Thema bei Citus ein kompletter Fehlgriff, was gerade vor dem Hintergrund der Zielgruppe des Produkts eigenartig grotesk anmutet. Hier liefert die Konkurrenz sehr viel mehr und für Citus besteht dringender Handlungsbedarf.

Wenig daneben geht bei Citus erfreulicherweise bei den Themen Security und Compliance. Der Anbieter wartet hier mit einigen sinnvollen Funktionen auf. Die Benutzerverwaltung ist auf der Ebene der Coordinators verankert. Sie bietet etliche Möglichkeiten, etwa das Anlegen von Benutzern, die lediglich auf spezifische Shards Zugriff erhalten, nicht aber auf ganze Datenbanken. Der Anschluss an eine zentrale Benutzerverwaltung ist in Citus hingegen nicht möglich, in der Praxis hätte ein solches Feature allerdings nur begrenzte Relevanz. Clients verbinden sich bei Bedarf über eine mittels SSL verschlüsselte Verbindung mit den Coordinators, und auch die Verbindung zwischen diesen und ihren Worker-Nodes ist mit SSL abgesichert.

Wer es noch sicherer braucht, setzt auf Encryption at Rest. Citus bietet diese Funktionalität für seine gehostete Cloudvariante standardmäßig an; die Daten liegen in Citus dann nicht unverschlüsselt, sondern verschlüsselt auf den Speichergeräten der jeweiligen Worker Nodes und Coordinators. Citus implementiert diese Funktion jedoch nicht selbst, sondern setzt bei seinem gehosteten Produkt Features aus Azure. Ähnliches lässt sich in lokalen Implementierungen ebenfalls erreichen, doch ist der Administrator hier weitgehend auf sich allein gestellt.

Obendrein enthalten die Installationsanweisungen für Citus viele Tipps und Tricks, die die Sicherheit der Umgebung erhöhen sollen. Manche dieser Tipps wirken jedoch etwas aus der Zeit gefallen, etwa jener, für die Datenbank ein "sicheres, lokales" Netz zu definieren, aus dem der Zugriff ohne Einschränkungen erlaubt ist. Letztlich wird sich der Admin viele eigenen Gedanken bezüglich der Sicherheit seiner Umgebung machen müssen. Das ist allerdings nicht Citus-spezifisch, sondern bei den meisten anderen DBs ähnlich.

Schließlich stellt sich noch die Frage, ob Citus in Sachen Performance liefern kann, was skalierbare Umgebungen der Gegenwart benötigen. Grundsätzlich gilt: Obwohl es sich um einen verteilten Aufbau handelt, ist Citus unter der Haube recht leicht gestrickt. Allzu komplizierte Algorithmen, die vor allem die Latenz nach oben treiben, suchten wir in der Software vergebens.

Solange also ein Citus-Cluster mit hinreichend viel Bandbreite im Backend ausgestattet ist, werden die allermeisten alltäglichen Aufgaben die Datenbank vor keine Probleme stellen. Das gilt umso mehr, weil Admins unmittelbaren Einfluss auf die Performance mittels weniger Stellschrauben nehmen können. Wer etwa in seine Datenbankknoten flotten Flash- Speicher einbaut und die Citus-Instanzen auf diesem laufen lässt, reduziert die Latenz dramatisch und erhöht die verfügbare Bandbreite zur selben Zeit extrem.

Zusätzlich bietet Citus dem Admin mehrere Möglichkeiten, die verfügbare Performance zu steigern. Shards lassen sich etwa mittels eines eigenen Werkzeugs neu ausbalancieren oder verschieben. Davon profitieren manche Workloads erheblich, gerade dann, wenn wie beschrieben zusammenhängende Daten auf denselben Knoten liegen.

Obendrein statten die Entwickler Administratoren mit einem ewig langen Kapitel in ihrer Dokumentation aus, die verschiedene Tuning-Maßnahmen ebenso umfasst wie Hinweise zu "guten" und "schlechten" Queries im Citus-Kontext. Von großem Vorteil gerade in Sachen Performance stellt sich natürlich das Skalieren in die Breite heraus, das effektiv nahezu beliebig viel Bandbreite ermöglicht.

CitusDB geht einen weniger radikalen Ansatz als andere Mitbewerber wie Yugabyte, liefert in Sachen Datenbank aber solide Arbeit ab. Wer ein performantes, verteiltes PostgreSQL sucht, ist hier grundsätzlich richtig. Bei den Grundfunktionen präsentiert Citus sich ebenso auf der Höhe der Zeit wie bei den Themen Security und Compliance. Angst um ihre Daten brauchen Administratoren ebenfalls nicht zu haben – der aus PostgreSQL übernommene 2-Phase-Commit sorgt dafür, dass Citus die ACID-Kriterien einhält.

Dass das zugleich mit hohen Anforderungen an die Verfügbarkeit einzelner Shards verbunden ist, muss dem Administrator allerdings klar sein. Hier empfiehlt es sich unbedingt, die implizit über PostgreSQL enthaltenen Replikationsfeatures zu verwenden, um ausgefallene Shards so flott wie möglich zu ersetzen. Um die entsprechende Konfiguration muss der Admin sich allerdings selbst kümmern.

Was zum einzigen Kriterium im Test führt, bei dem Citus versagt, nämlich der Art und Weise, wie Admins mit dem Produkt an den Start gehen. RPM- und DEB-Pakete sind als exklusive Darreichungsform heute bei fast jeder Anwendung zu wenig. Dass ausgerechnet eine Datenbank, die sich nahtlose Skalierbarkeit auf die Fahnen geschrieben hat, jedoch weder irgendeine Automation hat noch mit Kubernetes-Integration daherkommt, ist beinahe grotesk und inakzeptabel. Wer diese Mühen nicht scheut, findet in Citus eine zuverlässige, mit PostgreSQL vollständig kompatible Datenbank. Wer auf einfache Setups oder Kubernetes Wert legt, schaut sich hingegen besser bei der Konkurrenz um.