© Sergey Nivens / 123RF.com

Relationale Datenbanken besitzen zweifelsohne ihre Daseinsberechtigung – doch im Markt der hippen Cloud-Lösungen etablieren sich seit einigen Jahren Datenspeicher eines ganz anderen Typs: Key-Value-Stores.

Geht es um das strukturierte Speichern von Daten, gelten relationale Datenbanken wie MySQL oder PostgreSQL seit Jahrzehnten als Königsweg. Mit keinem anderen Werkzeug lassen sich große Mengen an Daten so effizient speichern, kaum eine andere Sprache für den Zugriff auf Datenbanken zeigt sich so zugkräftig und gleichzeitig so vielseitig wie SQL. Zwischenzeitlich erfreuten sich relationale Datenbanken derart großer Beliebtheit, dass ihre Vertreter sich quasi zum Gattungsbegriff für Datenbanken schlechthin entwickelten: Der LAMP-Stack beispielsweise, bestehend aus Linux, Apache, PHP und MySQL zeugt davon bis heute.

So wie LAMP über die Jahre an Bedeutung eingebüßt hat, scheint es aber, als sei der Hype um relationale Datenbanken inzwischen zumindest ein wenig abgeebbt. Das passierte aus nachvollziehbaren Gründen: Längst nicht überall, wo Daten strukturiert zu speichern sind, erweist sich die Komplexität einer relationalen Datenbank als hilfreich oder gar notwendig. Das verdeutlicht sich schnell, wenn Sie genauer hinschauen, wo Datenbanken heute überall zum Einsatz kommen.

Auf der Beliebtheitsskala ganz oben stehen seit vielen Jahren Cloud-Computing-Umgebungen. So dominiert Kubernetes die IT der Gegenwart – zu verlockend scheint aus Sicht vieler Unternehmen die Idee, sämtliche Funktionen eines modernen Rechenzentrums oberhalb der Hardware per API steuerbar und damit automatisierbar zu machen. Kubernetes spuckt auf Wunsch persistente Speicherlaufwerke ebenso aus wie dynamische IP-Adressen innerhalb einer Softwaredefined-Networking-Umgebung (SDN).

OpenStack [1], ein Projekt mit ähnlichen Zielen und in Teilen vergleichbarer Funktionalität, hatte Jahre zuvor noch den klassischen Weg gewählt und setzt bis heute auf eine relationale Datenbank (meist MySQL), um die eigenen, persistenten Metadaten zu speichern. Kubernetes schlug von Anfang an eine andere Richtung ein: Hier liegen die Metadaten zwar genauso in einer Datenbank, die fußt aber nicht auf dem relationalen Ansatz. Stattdessen ist Etcd [2] fixer Bestandteil moderner Kubernetes-Installationen (Abbildung 1).

Abbildung 1: Anders als etwa OpenStack setzte Kubernetes von Anfang an auf Etcd als Key-Value-Store für seine eigenen persistenten Konfigurationsdaten. Quelle: Kubernetes / CNCF

Das Produkt bezeichnen Admins auch als Konsens-Algorithmus – Konsens stellt Etcd nämlich hinsichtlich des konkreten Werts einzelner Konfigurationsparameter für Kubernetes her, und zwar über alle Knoten einer Kubernetes-Installation hinweg. Anders als OpenStack konstruiert Kubernetes dabei nicht große und komplexe Tabellen mit zahllosen Einträgen, etwa für geschaffene Speicherlaufwerke oder angelegte IP-Adressen. Stattdessen folgt Kubernetes dem Ansatz, für jede Kombination aus Speicherlaufwerk und ihrer jeweiligen Bezeichnung einfach einen einzelnen Eintrag in Etcd zu hinterlassen. Komponenten von Kubernetes, die mit diesen Daten arbeiten wollen, iterieren über die Liste der vorhandenen Einträge und fischen sich den passenden Eintrag heraus.

Garantien, die viele nicht brauchen

Dabei stellen die Kubernetes-Entwickler eindrücklich unter Beweis, was manch passioniertem Administrator seit Langem klar war: Der bloße Akt des permanenten Speicherns von Daten setzt nämlich nicht zwangsläufig eine relationale Datenbank mit all ihren Garantien voraus, wie es viele Entwickler beinahe gebetsmühlenartig propagiert haben. MySQL & Co. mit ihren Konsistenzgarantien nach ACID gelten als zweifellos als Segen, wenn sie in einem Setup zum Einsatz kommen, das mit komplexen Datenstrukturen hantiert. Geht es jedoch ausschließlich darum, wie beschrieben einfache Schlüssel-Wert-Pärchen zu speichern und abzurufen, mutieren relationale Datenbanken im schlechtesten Fall zum Hemmschuh. Denn ganz gleich, welche Inhalte darin liegen: Die ACID-Garantien, die ihre Autoren versprechen, müssen relationale Datenbanken auch bei noch so trivialen Datensätzen tatsächlich realisieren.

Häufig lässt sich bei simplen Datenstrukturen in der Konsequenz allerdings nachweisen, dass das Erfüllen der ACID-Garantien zum Beispiel die Ausführdauer von Datenbankabfragen signifikant erhöht. Von verteilten Datenbanken, bei denen etliche Datenbankinstanzen zusätzlich per Netzwerk miteinander kommunizieren müssen, ist dabei noch gar nicht die Rede. Hier tritt der Effekt noch heftiger zutage, denn dann sind die Konsistenzgarantien ja nicht nur für einen Host zu erfüllen, sondern für alle an der Replikation beteiligten Instanzen.

Den allermeisten Key-Value-Stores der Gegenwart hingegen haben die Entwickler die Netzwerkfähigkeit quasi in die Wiege gelegt: Sie ist impliziter Bestandteil des Konzepts, statt wie bei Lösungen wie Vitess (MySQL-kompatible Cloud-Datenbank) angebaut zu sein. Das entpuppt sich in den modernen und verteilten Setups als riesiger Vorteil. Folgerichtig stechen bei eben jenen trivialen Datensätzen Key-Value-Speicher relationale Datenbanken oft gnadenlos aus, ohne dabei wesentlich unsicherer hinsichtlich der Konsistenz von Daten zu sein. Etcd macht es vor und kommt gerade deshalb längst nicht mehr nur für Kubernetes-Metadaten in Kubernetes-Clustern zum Einsatz.

Auch Consul gelingt es zu liefern

Damit an dieser Stelle keine Missverständnisse entstehen: Key-Value-Speicher sind nicht als universeller Ersatz für relationale Datenbanken zu betrachten, die als Drop-in-Ersatz beliebig einzusetzen wären und in jeder denkbaren Konstellation massive Performancegewinne ermöglichen. Vor der Entscheidung für einen Key-Value-Store als Rückgrat zum Speichern persistenter Daten fällt einem Entwickler deshalb die Aufgabe zu, sorgsam zu prüfen, ob sich die einfache Speicherschnittstelle Schlüssel und Wert für den eigenen Einsatzzweck tatsächlich eignet oder ob man doch komplexe Datenstrukturen braucht, die sich mit Key-Value-Stores nicht implementieren lassen.

Hier liefert die Community manch groteskes Beispiel: Software etwa, die Daten erst in einem Key-Value-Store ablegt, dabei jedoch JSON oder andere Konstrukte nutzt, die daraufhin ausgelesen und ausgewertet werden müssen, um die benötigten Daten zu finden. Ein solcher Ansatz ist nicht zwingend falsch, oft aber arbeiten die so entwickelten Konstrukte nicht nur langsamer als eine gut getunte relationale Datenbank, sondern fallen auf der Code-Ebene auch viel komplexer aus. Wer diesen Ansatz wählt, hat Sinn und Nutzen von Key-Value-Speichern lediglich bedingt verstanden. Denn ihre tatsächliche Stärke können Etcd & Co. nur da ausspielen, wo die zu verarbeitenden Daten tatsächlich in Form von Schlüsseln und Werten vorliegen. Eine andere Lösung, seit jeher so was wie der natürliche Erzfeind von Etcd, demonstriert das anschaulich: Consul (Abbildung 2).

Abbildung 2: Consul ist ein Key-Value-Store mit integriertem Konsensalgorithmus von HashiCorp und fungiert als Datenspeicher unter anderem in der Kubernetes-Alternative Nomad. Quelle: HashiCorp / IBM

Consul [3] stammt aus dem Hause HashiCorp, jener Firma, die neuerdings zu IBM gehört. Seine Entwickler haben Consul als Ergänzung zu anderen Werkzeugen wie Nomad konzipiert. Dahinter steckt ein Werkzeug zur Containerorchestrierung, das sich an eher kleine Setups richtet, für die Admins den Mehraufwand mit Kubernetes scheuen. Schnell wird allerdings klar, wohin die Reise geht: Genauso wie Etcd, das praktisch jeden Kubernetes-Cluster antreibt, ist Consul ein Algorithmus zur Konsensfindung hinsichtlich einzelner Key-Value-Paare in verteilten Umgebungen.

Wie Etcd läuft Consul verteilt auf jedem Knoten der gesamten Installation mit, erlaubt die lokale Abfrage von Key-Value-Paaren und sorgt dabei stets dafür, dass der lokale Inhalt der Datenbank mit dem Inhalt der Datenbanken aller anderen Knoten übereinstimmt. Wie bei Etcd existieren zudem definierte Mittel und Wege, um Key-Value-Paare clusterweit anzulegen oder zu verändern. Zumindest zum Teil ahmen Key-Value-Speicher damit die Konsistenzgarantien klassischer Datenbanken nach, obwohl dabei fundamental andere Werkzeuge zum Einsatz kommen. Etcd beispielsweise implementiert einen eigenen Konsensalgorithmus, der gewisse Ähnlichkeiten mit PAXOS oder Raft aufweist. Wenn Sie sich dabei an Pacemaker [4] erinnert fühlen, liegen Sie goldrichtig: Hier kommt ebenso PAXOS zur Konsensfindung zum Einsatz, und de facto ist jede Pacemaker-Instanz ein – äußerst rudimentärer – Key-Value-Speicher ohne direkte Schnittstelle zur Außenwelt.

Pfiffige Entwicklungen abseits der Stars

Zwar sind Consul und Etcd heute ohne Zweifel die meistverbreiteten Vertreter der Gattung der Key-Value-Speicher, doch keinesfalls die einzigen. Hinter Apache Zookeeper [5] beispielsweise verbirgt sich ebenso ein verteilter Konsensalgorithmus für verteilte Systeme, unter dessen Haube ein einfacher Key-Value-Store werkelt. Anders als Etcd und Consul ist Zookeeper spezifisch dafür entwickelt, als Konfigurationsdatenbank in verteilten Umgebungen zu funktionieren. Zwar finden die Stars Etcd und Consul heute mehrheitlich genauso in dieser Art und Weise Verwendung, lassen sich jedoch anders als Zookeeper auch außerhalb der Themen Diensteerkennung und Ablegen von Dienstmetadaten sinnvoll als Key-Value-Store nutzen.

Obendrein haben die High-Tech-Unternehmen aus dem Silicon Valley die Vorzüge von Key-Value-Speichern längst erkannt. Facebook etwa kennen hierzulande vielen Menschen ausschließlich als Betreiber des gleichnamigen sozialen Netzwerks – tatsächlich agiert Facebook schon geraume Zeit als ein riesiger Technologiekonzern, der Produkte nicht nur für die Verwendung auf der eigenen sozialen Plattform entwickelt und bereitstellt. Vielmehr zeichnet Facebook für eine Reihe von Produkten verantwortlich, die sich in anderen Projekten wiederfinden.

RocksDB [6] ist dafür ein hervorragendes Beispiel. Fast schon bescheiden bezeichnet der Konzern RocksDB als “persistenten Key-Value-Speicher für die Verwendung in Flash und RAM”. Praktisch gilt RocksDB heute allerdings als eine Art eierlegende Wollmilchsau beim hochperformanten, persistenten Speichern von Daten. Dabei haben die RocksDB-Entwickler einige Grundregeln nicht nur befolgt, sondern ihr Produkt maßgeblich darauf getrimmt: Pate für RocksDB stand eingangs LevelDB [7] von Google, ein Key-Value-Speicher, der sich ebenfalls bereits ausschließlich im RAM betreiben ließ.

RocksDB selbst stellt eine signifikante Weiterentwicklung von LevelDB dar: Es kommt nicht grundsätzlich als eigener Dienst im Sinne eines Daemons daher, sondern lässt sich in Anwendungen als Bibliothek integrieren. Schon das dreht an der Performance-Schraube, weil der oft ressourcenintensive Umweg über das TCP/IP-Protokoll und den gesamten Netzwerkstack beim Abfragen von Datenbanken komplett entfällt.

Hinzu kommt, dass RocksDB darauf ausgelegt ist, seinen gesamten Datenbestand dauerhaft im RAM vorzuhalten. Zwar sind moderne Laufwerke auf Flash-Basis und mit NVMe-Schnittstelle nicht annähernd so träge unterwegs wie ihre rotierenden Gegenstücke aus der Vergangenheit, aber bis heute ist RAM noch immer deutlich flotter. Indem RocksDB die eigenen Daten grundsätzlich im RAM vorhält, schöpft sie die Vorteile von RAM in Sachen Geschwindigkeit gegenüber NVMe-Laufwerken und anderen Flash-Geräten komplett aus und reicht sie an die Nutzerseite weiter. Durchaus bemerkenswert dabei: Die innere Struktur von RocksDB zeigt sich simpel. Denn auch RocksDB lässt sich als beinahe schon banaler Speicher für Pärchen aus Schlüssel und Wert verwenden.

RADOS nutzt RocksDB statt eines Dateisystems

Dass das im Alltag zu ungeahnten Performance-Vorteilen an überraschenden Stellen führen kann, beweist ausgerechnet die Objektspeicherlösung Ceph, die gerade im Hinblick auf Latenz üblicherweise eher als Negativbeispiel dient. In Ceph-Clustern der Gegenwart spielt RocksDB eine zentrale Rolle. Dazu muss man wissen: Als Ceph-Erfinder Sage Weil die ersten Ideen zu Ceph und dem darunterliegenden Objektspeicher RADOS im Rahmen seiner Dissertation zu Papier brachte, wusste er, dass Ceph auf Blocklaufwerke würde zugreifen müssen, um Daten persistent abzulegen. Wie jeder andere Dienst, der auf Blockspeichergeräte zugreift, sind die OSD-Dienste von Ceph darauf angewiesen, dass seine Datenträger den geordneten und strukturierten Zugriff ermöglichen.

Der klassische Ansatz zur Lösung dieses Problems besteht freilich darin, auf ein POSIX-kompatibles Dateisystem zurückzugreifen. Ganz ähnlich wie relationale Datenbanken verspricht POSIX zahlreiche Garantien hinsichtlich des konkurrierenden Zugriffs auf Dateien, ihre Konsistenz und diverse andere Faktoren. Sage Weil wollte für Ceph zunächst Btrfs [8] nutzen. Weil das aber lange nicht fertig erschien – und bis heute als unfertig gilt – begnügte er sich kurzerhand mit XFS. Keine Frage, bei XFS handelt es sich um ein erprobtes, grundsolides Dateisystem für den RZ-Alltag, das sämtliche POSIX-Regeln für Dateisysteme vollumfänglich einhält.

Aus Sicht der Ceph-Entwickler verwandelte sich XFS allerdings bald vom Segen zum Fluch. Immerhin kann der Objektspeicher RADOS als Herz von Ceph mit vielen der Garantien, die ein POSIX-kompatibles Dateisystem geben muss, nichts anfangen. Überschreibt ein Benutzer beispielsweise ein binäres Objekt in RADOS, ersetzt RADOS das schon bestehende Objekt im Hintergrund nicht durch die neuen Daten. Es legt stattdessen ein neues Objekt an und ändert in seinen internen Metadaten den Verweis, der vom Namen des Objekts auf die konkreten Daten im Dateisystem verweist. Das nun verwaiste Objekt löscht RADOS im Rahmen seiner Hausmeistertätigkeiten später selbstständig und ohne weiteren Eingriff durch den Nutzer.

Noch offensichtlicher zeigt sich das Problem, wenn es um den bloßen Zugriff auf binäre Objekte geht, die irgendwo im Hintergrund von RADOS auf einem OSD liegen. Weil XFS POSIX-Garantien bietet, muss es etwa beim Zugriff auf eine Datei verschiedene Tests anstellen, um den unkoordinierten konkurrierenden Zugriff auf eine Datei zu unterbinden. Ein solches Szenario kann in RADOS seiner interner Implementierung wegen praktisch jedoch gar nicht entstehen – ein Szenario also, in dem mehrere Benutzer ohne Absprache auf dasselbe Objekt eines OSDs zugreifen.

Trotzdem kostete das Einhalten der POSIX-Garantien bei jedem Zugriff auf ein RADOS-OSD viel wertvolle Zeit. Bald wuchs der Unmut in der Entwicklergemeinde, und schließlich wagte man einen radikalen Schnitt: Kurzerhand entwickelte Sage Weil für RADOS-OSDs eine Art minimales Rumpfdateisystem namens BlueFS [9]. Wer im Kontext von RADOS schon mal den Begriff BlueStore gehört hat, findet hier die Erklärung. BlueFS funktioniert unter der Haube einfach: Viel mehr als die Information, an welcher physischen Adresse auf einem Datenträger RADOS ein bestimmtes Objekt findet, muss ein einzelnes OSD gar nicht besitzen, um den Zugriff umzusetzen. Die Kombination aus Objektname und Speicheradresse indes ist, Sie ahnen es vermutlich, ein typisches Key-Value-Paar, das sich hervorragend in einer Key-Value-Datenbank speichern lässt. Hier entschied Sage Weil sich für RocksDB, und folgerichtig besteht die einzige echte Aufgabe von BlueFS darin, alle nötige Funktionen zu bieten, die das Speichern von Daten per RocksDB und eines Write-Ahead-Logs für das jeweilige OSD ermöglichen (Abbildung 3).

Nach exakt diesem Prinzip funktioniert BlueStore bis heute. Es hat die konventionelle Methode, die man im Nachhinein auf den sperrigen Namen Filestore getauft hat, nicht nur längst verdrängt, sondern liefert zudem erhebliche Geschwindigkeitsvorteile im direkten Vergleich (Abbildung 3). Nicht zuletzt auf das neue On-Disk-Format mit BlueFS und RocksDB ist zurückzuführen, dass RADOS heute wesentlich geringere Latenzen in High-Performance-Umgebungen ermöglicht, als es noch vor ein paar Jahren der Fall war.

Abbildung 3: Weil es die POSIX-Garantien von XFS nicht brauchte, ersetzte Red Hat XFS bei Ceph durch ein Rumpfdateisystem und die Key-Value-Datenbank RocksDB. Das hat zu erheblichen Geschwindigkeitsgewinnen geführt. Quelle: Red Hat / IBM

Sämtliche Möglichkeiten evaluieren

Apropos RADOS: Hält man sich die Funktion des verbreiteten Objektspeichers vor Augen, merkt man schnell, dass hinter RADOS im Grunde ebenso ein Key-Value-Store steckt. Nutzen Sie RADOS nicht durch eines der drei Front-Ends hindurch, verzichten also auf das RADOS Gateway, auf RBD und auf CephFS, können Sie direkt auf der Programmierebene beliebige Informationen in RADOS unter einem spezifischen, clusterweit einzigartigen Namen anlegen. Zugegeben, darin liegt eine sehr spezielle Art der Nutzung eines Key-Value-Stores. Sie ist aber nicht zwingend unsinnig – denn als Key-Value-Speicher eröffnet RADOS Möglichkeiten, die sich mit klassischen und insbesondere relationalen Datenbanken gar nicht abbilden lassen.

So haben Generationen von Datenbankadministratoren sich den Kopf darüber zerbrochen, wie sich typische Assetdaten wie Bilder oder andere Binärdaten sinnvoll in relationalen Datenbanken ablegen lassen. Das geschah vor allem, um nicht in die Verlegenheit zu kommen, einer Anwendung zusätzlich zu ihrer Datenbankschnittstelle eine Schnittstelle etwa für den Zugriff auf ein POSIX-kompatibles Dateisystem spendieren zu müssen. Wirklich elegant waren Lösungen dieser Art allerdings nie – und tatsächlich widersprechen sie zudem der Art und Weise, wie die Macher von MySQL & Co. ihre Datenbanken gern genutzt sähen. Die heutige Datenbankvielfalt setzt solchen Krückenlösungen beispielsweise in Form von RADOS ein Ende.

Von verschwimmenden Trennlinien

Es wäre übrigens aus meiner Sicht unredlich, am Ende eines Artikels über Key-Value-Stores nicht noch zu erwähnen, dass im Kontext mancher Projekte die Grenzen zwischen den Ansätzen längst zu verschwimmen begonnen haben. Ein perfektes Beispiel dafür bietet Yugabyte [10]. Es ist dem Wesen nach zunächst ein klassischer Key-Value-Speicher. Das Produkt hat alle Vorteile im Gepäck, die ein Key-Value-Store grundsätzlich bietet: schnelle Abfragen für triviale Datensätze, ein ab Werk vorhandener Konsensmechanismus für den Betrieb in verteilten Infrastrukturen und dadurch praktisch beliebige Skalierbarkeit in die Breite. Die wiederum ermöglicht ein Drehen an der Performanceschraube, gerade was Lesevorgänge angeht, die in den meisten Setups bis heute den größten Teil der Datenbankabfragen ausmachen.

Yugabyte kann allerdings noch viel mehr: Über eine Kompatibilitätsschnittstelle haben die Entwickler ihr nämlich den SQL-Dialekt von PostgreSQL beigebracht (Abbildung 4). Anders formuliert, lässt sich mittels einer Übersetzerkomponente auf eine Yugabyte-Instanz so zugreifen wie auf ein PostgreSQL. Dabei räumen die Yugabyte-Autoren durchaus ein, dass ihre PostgreSQL-Schnittstelle nicht alle Befehle zu 100 Prozent so implementiert wie das Original. Für die allermeisten Anwendungen aber, so der Tenor, sei die Kompatibilität von PostgreSQL mit Yugabyte völlig ausreichend.

Abbildung 4: Yugabyte ist unter der Haube ein Key-Value-Store auf Basis des Raft-Protokolls, exponiert zur Außenwelt hin aber auch eine PostgreSQL-Schnittstelle. Quelle: Yugabyte

Der Betrieb einer für PostgreSQL entwickelten Webanwendung wird Yugabyte und sein SQL-Interface im Normalfall dementsprechend nicht vor allzu große Herausforderungen stellen. Anders als klassisches PostgreSQL verspricht Yugabyte dafür im Gegenzug echte Skalierbarkeit in die Breite und ACID-ähnliche Konsistenzgarantien, sogar für geo-redundante Setups (Abbildung 5).

Abbildung 5: Weil Yugabyte auf komplexe Datenstrukturen verzichtet, lässt sich selbst eine standortübergreifende Replikation mit dem Werkzeug deutlich einfacher bewerkstelligen als mit echtem PostgreSQL. Quelle: Yugabyte

Davon profitieren vor allem – wie sollte es anders sein – Mikroarchitekturanwendungen, die selbst ebenso in die Breite skalieren. In einem komplizierten Mesh-Konstrukt innerhalb einer Kubernetes-Umgebung etwa, in der Yugabyte sich beispielsweise per Helm problemlos ausrollen lässt, realisieren Sie dank der Software verteilte Datenbanken mit MySQL-Interface. Wer noch einen draufsetzen möchte, greift zu Lösungen wie Istio [11] und erreicht damit zudem umfassendes Load-Balancing.

Durch seine PostgreSQL-Kompatibilität etabliert Yugabyte sich freilich außerdem als Alternative zu Lösungen, die relationale Datenbanken selbst skalierbar machen sollen, etwa Vitess [12] für MySQL. Die technischen Unterschiede zwischen den hergebrachten Skalierbarkeitsaufsätzen für MySQL oder PostgreSQL und Yugabyte könnten jedoch kaum eklatanter ausfallen. Vitess beispielsweise erweitert MySQL um Sharding, behält die eigentliche Datenbank im Hintergrund aber bei. Das führt zu einigen Kompromissen und zu deutlich verringerter Performance im Gegensatz zu klassischem MySQL. Die Yugabyte-Entwickler hingegen geben als Ziel Parität in Sachen Geschwindigkeit mit PostgreSQL an. Bis zu eine Million Schreibanfragen soll das Produkt verarbeiten können, wenn der Admin es auf entsprechend leistungsfähiger Hardware betreibt.

Fazit: Die Konkurrenz schläft nicht

Key-Value-Stores sind als valide Alternative zu relationalen Datenbanken im IT-Alltag längst angekommen. Was Skalierbarkeit und Geschwindigkeit angeht, waren sie relationalen Datenbanken ohnehin von Anfang an überlegen. Mittlerweile schicken sie sich darüber hinaus an, über den Umweg des Speicherns von Schlüsseln und den dazugehörigen Werten ihren konventionellen Vorgängern den Schneid bei klassischen Anwendungsfällen für RDBMS abzukaufen.

Unstrittig ist dabei, dass es weiterhin spezielle Einsatzbereiche geben wird, die zwingend klassisches MySQL oder PostgreSQL verlangen. Dass Lösungen wie Yugabyte auf Grundlage eines einfachen Key-Value-Stores künftig im etablierten Marktsegment der relationalen Datenbanken wildern werden, gilt als sicher. Entwickler wie Administratoren können davon letztlich nur profitieren: Weniger Aufwand bei der Administration, bessere Skalierbarkeit und ein Plus bei der Performance zählen eben als schlagende Argumente.

Gerade für die Entwickler von Anwendungen bedeutet der Aufstieg von Key-Value-Speichern gleichzeitig aber mehr Entwicklungsaufwand. Nicht jeder Anwendungsfall passt zu Key-Value-Speichern. Wenn Sie sich also am Beginn der Entwicklung zu früh auf einen Key-Value-Store fixieren, handeln Sie sich möglicherweise Probleme ein, die Sie später auf der Programmierebene durch krude Hacks ausbügeln müssen. Möchten Sie Daten in Ihrer Anwendung persistent speichern, sollten sich deshalb zunächst sehr genau mit dem Layout der zu speichernden Daten befassen. Wenn sie sich sinnvoll in eine Struktur aus Schlüssel und zugeordnetem Wert bringen lassen, spricht nichts gegen den Einsatz eines Key-Value-Stores. Braucht es hingegen komplexere Strukturen, fahren Sie mit einer relationalen Datenbank vermutlich besser. Das gilt gerade deswegen, weil MySQL & Co. eben klassische ACID-Garantien liefern, wo Key-Value-Speicher lediglich Konsens-Algorithmen implementieren. Reduziert auf die Ebene einzelner Transaktionen bieten sie damit nicht dieselben Konsistenzgarantien wie ACID-kompatible Datenbanken. In nahezu allen Anwendungsfällen für Key-Value-Speicher ist das aber auch nicht nötig. Wie immer gilt: Gut geplant ist in Sachen Datenhaltung schon halb gewonnen.