Welche Arten von Datenbanken gibt es?

Auf dem Weg zum Verzeichnis hält QUERY vor einem dunklen Bereich des Tresors an. Hinter Glas liegt das Register der Archive der alten Erde, die die Große Trennung nicht überlebt haben: Die Cache-Knoten erloschen zuerst, die Dokumentenspeicher kamen nur als zerrissene Fragmente an, die Analyse-Cluster schweigen über ganze Sektoren hinweg. Der relationale Schnappschuss von «Kotomarket» aber blieb vollständig erhalten — mit allen Verbindungen.

Nicht nur relational

Für «Kotomarket» sind relationale Datenbanken besonders naheliegend: Käufer, Bestellungen und Produkte passen gut in Tabellen mit klaren Verbindungen. Genau darum geht es in diesem Kurs. In der Branche — 2024 ebenso wie heute — begegnen dir aber auch andere Ansätze:

• Schlüssel-Wert (Redis) — ein sehr schnelles Format „Schlüssel → Wert“, wenn man einen einfachen Datensatz blitzschnell abrufen will;
• dokumentenorientiert (MongoDB) — speichert flexible JSON-Dokumente, deren Struktur sich von Datensatz zu Datensatz unterscheiden kann;
• spaltenorientiert (ClickHouse) — stark in der Analytik, wenn Kennzahlen über riesige Datenmengen schnell berechnet werden müssen.

Die meisten verbreiteten DBMS für Produktentwicklung bleiben relational: PostgreSQL, MySQL, Oracle, MS SQL. Wenn du hier SQL beherrschst, kannst du in sehr unterschiedlichen Unternehmen sicher Daten lesen.

QUERY: Jedes Archiv hat seine Aufgabe: eines liefert Geschwindigkeit, eines Flexibilität, eines Analytik. Wir hatten Glück: Uns ist das Archiv geblieben, in dem alles miteinander verbunden ist.

Not only relational

For Kotomarket, relational databases suit us especially well: buyers, orders, and products fall naturally into tables with links between them. That’s what this course is about. But across the industry — in 2024 just as today — you’ll meet other approaches too:

• key-value (Redis) — a blazingly fast "key → value" format for when you need to grab a simple record instantly;
• document-oriented (MongoDB) — stores flexible JSON documents whose structure can differ from record to record;
• columnar (ClickHouse) — strong at analytics, when you need to crunch metrics over enormous volumes of data fast.

Most of the popular DBMSs for product development stay relational: PostgreSQL, MySQL, Oracle, MS SQL. Master SQL here and you’ll be able to read data confidently at very different companies.

QUERY: Each archive has its own job: one prizes speed, another flexibility, a third analytics. You and I got lucky: we inherited the one where everything is connected to everything.

Das Register der Familien: sauber geordnet

Das Register hinter dem Glas ist ein guter Anlass, die Datenbankfamilien gründlich durchzugehen: „Welche Datenbanken gibt es, und wann nimmt man welche?“ ist eine der häufigsten Fragen im Vorstellungsgespräch. Wir betrachten fünf Familien nacheinander, jeweils nach demselben Muster: Speicherweise, Stärken und Schwächen, Produkte und typische Einsatzfälle.

Relationale Datenbanken: strenges Schema und Verbindungen

Speicherweise: Zeilen in Tabellen mit einem vorab festgelegten Schema. Jede Spalte hat einen Typ, zwischen Tabellen bestehen Verbindungen über Schlüssel, und das DBMS schützt die Integrität selbst: Eine Bestellung für einen nicht existierenden Käufer lässt sich nicht speichern. Änderungen laufen als Transaktionen mit ACID-Garantien ab — „Bestellung + Bestandsabbuchung“ werden entweder gemeinsam geschrieben oder gar nicht.

• Stärken: ausdrucksstarkes SQL (Filter, Tabellenverknüpfungen, Aggregate), Integrität auf Datenbankebene, Transaktionen.
• Schwächen: Das Schema muss im Voraus durchdacht und bei Änderungen migriert werden; horizontales Skalieren über viele Server ist schwieriger als bei vielen NoSQL-Familien.
• Produkte: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Wann man sie nimmt: Nutzer, Bestellungen, Geld, Lager — überall dort, wo Daten miteinander verbunden sind und fehlerhafte Schreibvorgänge nicht akzeptabel sind. Für ein neues Produkt ist das meist die Standardwahl.

Schlüssel-Wert-Datenbanken: ein Wörterbuch auf Höchstgeschwindigkeit

Speicherweise: ein einziges riesiges Wörterbuch „Schlüssel → Wert“, meist im Arbeitsspeicher. Keine Tabellen, keine Verbindungen: per Schlüssel hineinlegen, per Schlüssel in Bruchteilen einer Millisekunde wieder herausholen.

-- To nie SQL, to polecenia Redis
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Stärken: Geschwindigkeit, Einfachheit, einfache Skalierung.
• Schwächen: Abfragen laufen nur über den exakten Schlüssel. Die Frage „Finde alle Sitzungen von Käufern aus Moskau“ passt nicht zu diesem Modell; das Innere eines Werts bleibt für die Datenbank undurchsichtig.
• Produkte: Redis, Memcached, Amazon DynamoDB.
• Wann man sie nimmt: Cache, Sitzungen, Zähler, Warteschlangen, Bestenlisten — heiße Daten neben der Hauptdatenbank, nicht an ihrer Stelle.

Dokumentendatenbanken: flexibles JSON

Speicherweise: Die Datensätze sind JSON-Dokumente, gruppiert in Sammlungen. Das Schema wird nicht im Voraus festgelegt: Eine Smartwatch hat ein Feld „Akkulaufzeit“, ein Hoodie eine „Größentabelle“, und beide Dokumente können problemlos in derselben Sammlung liegen. Verschachtelte Strukturen werden direkt im Dokument gespeichert, ohne separate Tabellen.

• Stärken: flexible Struktur, ein Dokument wird mit einem einzigen Zugriff vollständig gelesen, praktisch für Kataloge mit uneinheitlichen Attributen und für schnelle Prototypen.
• Schwächen: Verbindungen zwischen Dokumenten muss die Anwendung verwalten, echte JOINs gibt es kaum; ohne Disziplin wird eine Sammlung schnell zu einem Sammelsurium unvereinbarer Formate.
• Produkte: MongoDB, Couchbase, Firestore.
• Wann man sie nimmt: Inhalte, Kataloge mit stark unterschiedlichen Feldern, Profile und Einstellungen.

Die Grenze zwischen den Familien ist übrigens fließend: PostgreSQL kann Dokumente in einer Spalte vom Typ jsonb speichern und darüber Indizes bilden — oft deckt das einen „dokumentenartigen“ Bedarf ab, ohne dass eine zweite Datenbank nötig wird:

-- Przykład spoza naszej migawki: attrs — kolumna typu jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Spaltenorientierte Datenbanken: Analytik über Milliarden Zeilen

Speicherweise: Die Werte liegen nicht zeilenweise, sondern spaltenweise: alle Preise beieinander, alle Datumswerte beieinander. Die Abfrage „durchschnittlicher Bestellwert pro Monat“ liest von der Platte nur zwei Spalten statt der ganzen Tabelle, und gleichartige Werte lassen sich hervorragend komprimieren. Daher kommt die hohe Geschwindigkeit bei Aggregaten.

-- Ulubiony gatunek bazy kolumnowej (dialekt ClickHouse: toYYYYMM to jego funkcja)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Stärken: Aggregate und Scans über Milliarden Zeilen, starke Kompression.
• Schwächen: punktuelle Aktualisierungen und Löschungen sind teuer; eine einzelne Zeile vollständig zu lesen ist langsamer als in einer zeilenorientierten Datenbank; für transaktionale Last sind diese Systeme schlicht nicht gebaut.
• Produkte: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Wann man sie nimmt: Analytik, Berichte, Ereignisse, Logs, Metriken — meist neben der „produktiven“ relationalen Datenbank.

Hier passen ein paar Begriffe, die in Vorstellungsgesprächen beliebt sind: OLTP (online transaction processing — viele kurze Schreib- und Leseoperationen, die Welt von PostgreSQL) und OLAP (online analytical processing — schwere analytische Lesevorgänge über die gesamte Historie, die Welt von ClickHouse). Das Produkt schreibt in die OLTP-Datenbank, die Analytik liest aus einer OLAP-Kopie.

Und die letzte Familie: Graphdatenbanken

Wenn die Verbindungen wichtiger sind als die Datensätze selbst — „Freunde von Freunden“, Lieferrouten, Empfehlungsketten — greift man zu Graph-Datenbanken (Neo4j, Memgraph). Die Daten bestehen dort aus Knoten (den Datensätzen) und Kanten (den Verbindungen zwischen ihnen). Verbindungen beliebiger Tiefe zu durchlaufen, ist eine native Operation. In einer relationalen Datenbank wird so ein Durchlauf zu einer Kette von Tabellenverknüpfungen, die mit jeder Ebene schwerer wird.

Mini-Leitfaden: Wie man eine Datenbank für ein Projekt auswählt

1. Beginne mit den Fragen, nicht mit den Daten. Welche Abfragen wird das Produkt stellen: punktuell „nach Schlüssel“, verknüpft „wer hat was gekauft“, analytisch „wie viel pro Monat“?
2. Standardmäßig: relational. Verbundene Daten plus hohe Fehlerkosten (Bestellungen, Zahlungen, Bestände) — das ist PostgreSQL. Für fast jedes Produkt ist es der sicherste Start.
3. Spezialisierte Datenbanken: für konkrete Aufgaben, nicht „auf Vorrat“. Lesezugriffe laufen heiß — füge einen Redis-Cache hinzu. Die Analytik ist gewachsen — repliziere Ereignisse nach ClickHouse. Felder variieren stark — versuche zuerst jsonb in PostgreSQL, und erst wenn das nicht reicht, eine Dokumentendatenbank.
4. Rechne die Kosten einer zweiten Datenbank mit ein. Jedes neue DBMS bedeutet Datensynchronisation, Backups, Monitoring und eine weitere Technologie, die das Team beherrschen und pflegen muss.