Die Wahl einer Datenbank: relational, Dokument, Key-Value, Spalten, Graph und Zeitreihen

Warum die Wahl Sorgfalt verdient

Eine Datenbank gehört zu den am schwersten austauschbaren Komponenten. Anwendungen werden um ihre Daten herum neu geschrieben, nicht umgekehrt; Terabytes an Live-Daten zu migrieren, während das Geschäft weiterläuft, kann ein Jahr dauern. Die Wahl des Speichers ist deshalb eine Einwegtür, die eine explizite Entscheidung verdient, während viele Teams sie aus Gewohnheit oder nach Mode treffen.

Kapitel 0 hat relationale Datenbanken und die vier NoSQL-Familien eingeführt. Dieser Abschnitt geht weiter: wofür jede Familie wirklich gut ist, die neueren Kategorien (Zeitreihen, Suche, Vektoren und Distributed SQL), wie man nach Belegen statt nach Begeisterung wählt und was es kostet, mehrere Arten zugleich zu betreiben. Die Antwort ist selten eine Datenbank für alles und fast nie eine andere Datenbank für jeden Service.

Relational: weiterhin der Standard, aus guten Gründen

Eine relationale Datenbank speichert Daten in Tabellen mit deklarierten Typen, Schlüsseln und Constraints und beantwortet deklarative SQL-Abfragen, eine Idee aus Edgar Codds Paper von 1970. Fünfzig Jahre später ist sie aus vier Gründen weiterhin der vernünftige Standard für Geschäftsdaten. Erstens Transaktionen und Constraints: Die Datenbank selbst garantiert, dass eine Zahlung und ihre Hauptbucheinträge gemeinsam committet werden und dass keine Bestellung auf einen fehlenden Kunden verweist, sodass diese Regeln nicht in jedem Service unvollkommen neu implementiert werden müssen. Zweitens Flexibilität bei Abfragen: Sie müssen beim Entwurf des Schemas nicht jede künftige Frage kennen; ein neuer Bericht ist eine neue Abfrage, keine neue Tabelle. Drittens Reife: Jahrzehnte an Werkzeugen für Backup, Replikation, Monitoring, Migration und Performance-Diagnose sowie Fachleute, die sie schon kennen. Viertens Bandbreite: Moderne relationale Systeme speichern und indizieren JSON (jsonb in PostgreSQL), unterstützen Volltextsuche, Geodaten (PostGIS), Zeitpartitionierung und Vektorähnlichkeit (die Erweiterung pgvector), sodass eine gut betriebene Datenbank in moderatem Umfang viele Anforderungen abdecken kann.

Die echten Grenzen sind konkret. Schreibvorgänge auf einem einzelnen Primary sind durch eine Maschine begrenzt; sehr große Tabellen brauchen sorgfältige Partitionierung; Schemaänderungen an riesigen Tabellen brauchen Technik (Schemaevolution); und manche Zugriffsmuster, etwa tiefe Graphtraversierungen oder relevanzbasierte Textsuche, bedienen spezialisierte Engines deutlich besser. Ein einzelner moderner Server mit schnellen SSDs kann Tausende Transaktionen pro Sekunde und Terabytes an Daten bewältigen, was den Bedarf der meisten Organisationen abdeckt.

Die nicht relationalen Familien

Eine Dokumentendatenbank speichert jeden Datensatz als in sich geschlossenes Dokument, meist JSON oder eine binäre Form davon. Sie passt zu Aggregaten im Sinne des Domain-Driven Design: Dingen, die als Ganzes gelesen und geschrieben werden, etwa die Speisekarte eines Restaurants mit ihren Rubriken, Gerichten und Optionsgruppen. Ein Dokument zu lesen ist ein einziger Zugriff ohne Joins. Die Abwägung zeigt sich, wenn dieselben Daten in einer anderen Form abgefragt (alle Gerichte mit Erdnüssen über alle Speisekarten hinweg) oder in vielen Dokumenten zugleich geändert werden müssen; Joins und dokumentübergreifende Transaktionen gibt es in modernen Produkten, aber sie sind teurer und weniger natürlich als in SQL.

Ein Key-Value-Store ist ein verteiltes Wörterbuch: einen Wert unter einem Schlüssel ablegen, ihn wieder abrufen. Weil der Speicher nie in die Werte hineinschaut, kann er extrem schnell und leicht zu partitionieren sein. Redis und sein Open-Source-Fork Valkey halten Daten im Arbeitsspeicher mit optionaler Persistenz und bieten zusätzlich Datenstrukturen (Sorted Sets, Streams, Geo-Indizes) und Ablaufzeiten; Amazon DynamoDB ist ein verwalteter, partitionierter Key-Value- und Dokumentenspeicher. Sie eignen sich für Sessions, Warenkörbe, Zähler für Rate Limiting, Feature-Flags, Caches und die letzte Position jedes Kuriers.

Ein Wide-Column-Store (Bigtable, Apache Cassandra, ScyllaDB, HBase) gruppiert Zeilen nach einem Partition Key und speichert sie innerhalb jeder Partition nach einem Clustering Key sortiert. Er ist für massive Schreibvolumina ausgelegt, verteilt über viele Knoten und Rechenzentren. Die Disziplin, die er verlangt, ist Query-First-Modellierung: Sie entwerfen eine Tabelle pro Abfrage und duplizieren Daten großzügig, weil Abfragen, die nicht beim Partition Key ansetzen, teuer oder unmöglich sind. Cassandra stammt zum Teil von Amazons Dynamo-Paper von 2007 ab, dessen Replikationsideen im übernächsten Abschnitt vorkommen.

Eine Graphdatenbank speichert Knoten und Beziehungen als vollwertige Datensätze und beantwortet Traversierungsabfragen wie Kunden innerhalb von drei Schritten von diesem Betrugsring ohne die kaskadierenden Joins, die solche Abfragen in SQL langsam machen. Cypher von Neo4j ist die bekannteste Abfragesprache, und die ISO hat 2024 eine standardisierte Graphabfragesprache veröffentlicht, GQL (ISO/IEC 39075). Graphen eignen sich hervorragend für Betrugserkennung, Empfehlungen und Netzwerkanalyse und sind meist ein schlechter Primärspeicher für transaktionale Geschäftsdaten.

Zeitreihen-, Such- und Vektorspeicher

Eine Zeitreihendatenbank ist für Messwerte mit Zeitstempel optimiert, die der Reihe nach eintreffen und selten aktualisiert werden: Metriken, Sensorwerte, Preise, Standortverläufe. Sie komprimiert stark, partitioniert nach Zeit, verdichtet alte Daten (jeden Punkt eine Woche lang behalten, Minutenmittelwerte ein Jahr lang) und löscht abgelaufene Daten günstig, indem sie ganze Zeitpartitionen verwirft. Beispiele sind InfluxDB, Prometheus (für Monitoring) und TimescaleDB, eine PostgreSQL-Erweiterung, die zeigt, wie oft sich eine relationale Datenbank passend dehnen lässt.

Eine Suchmaschine wie Elasticsearch, OpenSearch oder Apache Solr (alle auf der Bibliothek Apache Lucene aufgebaut) pflegt einen invertierten Index von Wörtern zu den Dokumenten, die sie enthalten, mit Textanalyse (Stammformreduktion, Synonyme, Tippfehlertoleranz) und Relevanzranking. Sie beantwortet veganes Ramen in meiner Nähe in Millisekunden. Sie sollte fast nie ein System of Record sein: Indizes werden nahezu in Echtzeit statt transaktional aufgefrischt, und das übliche Design speist die Suchmaschine aus der besitzenden Datenbank und baut den Index bei Bedarf daraus neu auf.

Eine Vektordatenbank speichert Embeddings, Zahlenlisten, die die Bedeutung von Texten, Bildern oder Produkten darstellen, und findet die Elemente, die einem Abfragevektor am nächsten liegen. Eine exakte Suche vergleicht die Abfrage mit jedem Vektor, deshalb nutzen diese Speicher Indizes für approximative Nächste-Nachbarn-Suche wie HNSW-Graphen und tauschen ein wenig Trefferquote gegen Geschwindigkeit. Sie treiben semantische Suche, Empfehlungen und das Retrieval für große Sprachmodelle an, behandelt in Retrieval-Augmented Generation. Es gibt eigene Produkte (Milvus, Qdrant, Pinecone, Weaviate), aber für Millionen statt Milliarden von Vektoren genügt oft eine Erweiterung einer bestehenden Datenbank wie pgvector.

Distributed SQL

Distributed-SQL-Datenbanken, manchmal NewSQL genannt (ein Begriff, den der Analyst Matthew Aslett 2011 prägte), behalten das relationale Modell, SQL und ACID-Transaktionen bei, partitionieren und replizieren Daten aber automatisch über viele Knoten, oft über Regionen hinweg. Google Spanner, beschrieben in einem OSDI-Paper von 2012, nutzt eng synchronisierte Uhren (seine TrueTime-API, gestützt auf GPS und Atomuhren), um global konsistente Transaktionen zu bieten. CockroachDB, YugabyteDB und TiDB bieten ähnliche Modelle auf gewöhnlicher Hardware; CockroachDB nutzt standardmäßig serialisierbare Isolation.

Der Preis sind Physik und Betrieb. Eine Transaktion, der Replikas in mehreren Regionen zustimmen müssen, wartet auf einen Konsens-Roundtrip, sodass einzelne Zeilenschreibvorgänge Millisekunden bis zu Dutzenden oder Hunderten Millisekunden dauern statt deutlich unter einer Millisekunde. Abfrageplanung über Partitionen hinweg ist subtiler, die Kosten sind höher, und weniger Fachleute kennen die Fehlerbilder. Distributed SQL ist das richtige Werkzeug, wenn Sie wirklich relationale Transaktionen jenseits der Kapazität eines Servers oder über Regionen hinweg brauchen (ein globales Zahlungshauptbuch, eine Bank in mehreren Regionen), und ein teures, wenn ein einzelner PostgreSQL-Primary mit Replikas genügen würde.

Die Wahl: Kriterien, die zählen

Wählen Sie pro Datenbestand, nicht pro System. Sammeln Sie für jeden wichtigen Datenbestand Belege zu sechs Kriterien und halten Sie die Entscheidung in einem ADR fest.

Datenform. Sind die Daten von Natur aus tabellarisch mit vielen Beziehungen, ein in sich geschlossenes Aggregat, ein Netzwerk, eine Zeitreihe, freier Text oder Vektoren? Zugriffsmuster. Welche Abfragen laufen, wie oft, mit welchen Latenzzielen, und wie viele davon sind ad hoc? Überwiegend lesend oder schreibend? Immer per Schlüssel oder nach vielen Attributen? Konsistenzbedarf. Brauchen die Daten Transaktionen über mehrere Elemente und Constraints (Kontostände, Lagerbestand, Buchungen), oder sind ein paar Sekunden Veralterung harmlos (Likes, Empfehlungen)? Siehe Konsistenzmodelle. Größenordnung. Aktuelle und prognostizierte Datenmenge, Schreibvorgänge pro Sekunde und Wachstum, gemessen, nicht geraten; ein Speicher, der auf Petabytes skaliert, ist bei 50 Gigabyte kein Vorteil. Betrieb. Wer wird ihn betreiben: Backups, Upgrades, Failover, Monitoring, Sicherheitspatches? Gibt es einen Managed Service in Ihrer Cloud, und was kostet er bei Ihren Volumina? Teamkenntnisse. Was kennt das Team schon gut genug, um es um 3 Uhr nachts zu debuggen? Unvertraute Technologie bringt unbekannte Fehlerbilder mit sich.

Zwei Gewohnheiten verbessern die Wahl. Schreiben Sie die fünf oder zehn wichtigsten Abfragen mit ihren Ziellatenzen vor der Wahl auf, und testen Sie den Kandidaten mit realistischen Datenmengen; viele Enttäuschungen stammen von einem Speicher, der auf einem Laptop mit tausend Zeilen getestet wurde. Und trennen Sie das System of Record von abgeleiteten Speichern: Das System of Record braucht die stärksten Garantien und die konservativste Technologie, während abgeleitete Speicher (Suchindizes, Caches, Read Models) gerade deshalb spezialisiert sein können, weil sie sich neu aufbauen lassen.

Polyglotte Persistenz und ihre Kosten

Polyglotte Persistenz bedeutet, innerhalb eines Systems unterschiedliche Speichertechnologien für unterschiedliche Daten zu nutzen, gewählt danach, wie die Daten verwendet werden. Martin Fowler machte den Begriff 2011 bekannt und schrieb seine erste Verwendung Scott Leberknight zu. Er folgt natürlich aus Datenbank pro Service: Jeder Eigentümer kann das richtige Werkzeug wählen.

Die Kosten werden leicht unterschätzt. Jeder zusätzliche Datenbanktyp braucht eigene Expertise, eigene Verfahren für Backup und Wiederherstellung, Monitoring, Kapazitätsplanung, Sicherheitshärtung, einen eigenen Upgrade-Zyklus und Wissen in der Rufbereitschaft. Daten bewegen sich nun zwischen Speichern, also brauchen Sie Pipelines (CDC, Events) und müssen Verzögerung und Ausfall jeder einzelnen bedenken. Konsistenz zwischen Speichern ist bestenfalls eventual. Für ein kleines Team können fünf Datenbanken mehr Aufwand verschlingen als das Produkt. Eine vernünftige Regel ist, jeden neuen Speicher durch eine Anforderung zu begründen, die die bestehenden nachweislich nicht erfüllen können, und für die spezialisierten Managed Services zu bevorzugen.

Häufige Fehler

Lebenslaufgetriebene Entscheidungen: einen Speicher wählen, weil er neu ist oder weil ein großes Unternehmen ihn nutzt, ohne die Anforderung, die ihn dort rechtfertigte. Für eingebildete Größenordnungen wählen: für eine Milliarde Nutzer entwerfen bei einem Produkt mit tausend und vom ersten Tag an die Komplexitätssteuer zahlen. Einen abgeleiteten Speicher als System of Record nutzen: ein Suchindex oder Cache, der zur einzigen Kopie von Daten wird, mit schwächerer Dauerhaftigkeit, als irgendjemand ahnte. Die Abfrageseite ignorieren: einen Key-Value- oder Wide-Column-Store wählen und dann feststellen, dass das Geschäft Ad-hoc-Berichte und Filter braucht, die er nicht bedienen kann. Den Betrieb unterschätzen: vergessen, dass jemand ihn aus dem Backup wiederherstellen, ohne Ausfallzeit upgraden und unter Last diagnostizieren muss. Und schließlich die Wahl als endgültige Wahrheit behandeln: Halten Sie die Annahmen fest (Volumina, Abfragen, Teamkenntnisse), damit die Entscheidung neu geprüft werden kann, wenn sie sich ändern.