Datenbanken

Die Auswahl der Datenbank ist eine architektonische Entscheidung, die einen direkten Einfluss auf die Effizienz des Systems hat. Die Szenarien sind vielfältig: Transaktionen, Analytik, Caching, Dokumentation, Telemetrie. Wir bauen ein mehrschichtiges Ökosystem, in dem jede Datenbank ihre Rolle erfüllt und zwischen den Schichten transparente Verträge bestehen. In der Entwurfsphase legen wir nicht-funktionale Anforderungen fest: Reaktionsgeschwindigkeit, zulässige Latenzen, Volumen der gespeicherten Daten, SLA für Verfügbarkeit. Wir modellieren Lasten, prognostizieren Wachstum und wählen für jedes Szenario eine Kombination von Speicherlösungen aus. Für den Cache verwenden wir separate Konturen, um temporäre Daten und die Hauptquelle der Wahrheit nicht zu vermischen. Dieser Ansatz ermöglicht es, SQL und NoSQL zu kombinieren und die Skalierung im Voraus zu planen.

• Transaktionen: Quelle der Wahrheit (PostgreSQL, MySQL/MariaDB).
• Analytik: schnelle Aggregation und Abfragen (ClickHouse).
• Dokumente und dynamische Strukturen: flexibles Schema (MongoDB).
• Cache/Sitzungen: schneller Zugriff mit begrenzter Lebensdauer (In-Memory-Lösungen).
• Telemetrie/Ereignisse: Streaming-Bus und langlebige Speicherung (Kafka + analytisches Lager).

PostgreSQL verwenden wir dort, wo die Unterstützung von Transaktionen (Zuverlässigkeit der Operationserfassung) und strikte Typisierung kritisch sind. Wir entwerfen Datenmodelle unter Berücksichtigung von Integritätsbeschränkungen und Lebenszyklus von Einträgen. Indizes wählen wir bewusst aus: B‑Tree für exakte Abfragen, GIN für Volltextsuche, BRIN für große, zeitbasierte Tabellen. Um es einfach auszudrücken: das sind verschiedene Möglichkeiten, die Suche zu beschleunigen und die Arbeit mit großen Tabellen zu optimieren. „Partitioning“ — das Aufteilen großer Tabellen in Teile zur Beschleunigung der Verarbeitung. Materialisierte Sichten — gespeicherte Ergebnisse komplexer Abfragen. Die Erweiterungen PostGIS (Arbeit mit Geodaten) und TimescaleDB (Zeitreihen) erweitern die Möglichkeiten.

Um das System zuverlässig zu machen, ist es wichtig, Transaktionen zu verwalten. Isolationsstufen helfen, den parallelen Zugriff zu kontrollieren: Read Committed eignet sich für die meisten Szenarien, Repeatable Read schließt schmutzige Daten und Phantomdaten aus, und Serializable garantiert eine strikte Reihenfolge der Operationen. Um Deadlocks (Situationen, in denen Transaktionen sich gegenseitig behindern und der Prozess feststeckt) zu verhindern, legen wir die Reihenfolge der Operationen fest, begrenzen die Dauer von Transaktionen und verwenden Wiederholungsversuche. In konkurrierenden Systemen setzen wir optimistische Sperren über Zeilenversionen ein, um unnötige Verzögerungen zu vermeiden.

MySQL und MariaDB nutzen wir, wenn hohe Lesegeschwindigkeit, ein reifes Ökosystem von Werkzeugen und Vorhersehbarkeit der Arbeitsweise wichtig sind. Diese Datenbanken eignen sich besonders für Webplattformen, CMS und CRM-Systeme, bei denen schneller Datenzugriff und Skalierbarkeit im Vordergrund stehen. Das Modell „Master-Replikat“ sieht einen Hauptserver für Schreiboperationen und mehrere Kopien für Leseoperationen vor, wodurch die Last verteilt und Daten vor Ausfällen geschützt werden können. Bei wachsenden Datenmengen kommt „Sharding“ zum Einsatz — die Aufteilung der Informationen in Teile nach Geschäftsschlüsseln (z. B. nach Benutzern oder Regionen). Zur Lastenbalancierung implementieren wir eine Proxyschicht, die das Routing der Anfragen verwaltet und den Hauptserver entlastet. Die Schemata modellieren wir für OLTP-Szenarien — einfach gesagt, es handelt sich um Systeme, die eine große Anzahl kurzer Transaktionen verarbeiten, wie z. B. Online-Shops oder CRM-Systeme. Um die Leistung zu erhalten, vermeiden wir schwere Joins auf heißen Pfaden und optimieren im Voraus die Indizes und die Struktur der Abfragen.

MongoDB wählen wir für dynamische Datenstrukturen und verschachtelte Dokumente. Es eignet sich für IoT, Protokollierung und Speicherung von Signalen, bei denen sich das Format der Ereignisse ändern kann. Wir definieren im Voraus einen Schlüssel, nach dem die Daten verteilt werden, um Überlastung zu vermeiden und Abfragen zu beschleunigen. Die Aggregation Pipeline (ein Toolkit für Analysen innerhalb der Datenbank) ermöglicht es, Analysen direkt im Speicher durchzuführen: zum Beispiel Echtzeitberichte über Ereignisse zu erstellen. „Write Concern“ passen wir den Anforderungen an: von schneller Speicherung ohne strenge Garantien bis hin zu zuverlässiger Bestätigung auf den meisten Servern. Die Replikation entwerfen wir unter Berücksichtigung des CAP-Theorems (Regel, dass Datenbanken zwischen Geschwindigkeit, Konsistenz und Ausfallsicherheit balancieren müssen).

• TTL-Indizes entfernen automatisch veraltete Einträge.
• Archivkollektionen speichern wir getrennt von „heißen“.
• Wir halten die Treiber und Protokollversionen aktuell, damit Updates den Betrieb nicht stören.

ClickHouse verwenden wir in Projekten mit riesigen Datenmengen: Trades, Börsenlogs, Telemetrie. Die spaltenbasierte Struktur ermöglicht schnelle Abfragen und günstige Speicherung. Wir planen das Schema im Voraus: wie die Daten verteilt werden, welche Sortierschlüssel festgelegt werden. „Sortierschlüssel“ sind die Reihenfolge, in der die Daten angeordnet sind, um Anfragen zu beschleunigen. Dies ermöglicht es, Überlastungen zu vermeiden und hohe Geschwindigkeit zu garantieren. In Kombination mit Kafka erhält ClickHouse einen Ereignisstrom direkt: Daten werden in Zwischentabellen geschrieben und dann auf Partitionen verteilt. Dieser Ansatz ermöglicht Echtzeit-Analysen.

• Trades: Aufteilung nach Tagen und Instrumenten, schnelle Abfragen für Risikoanalysen.
• Börsenlogs: Erstellung von Bestenlisten, Berechnung von Verzögerungen und Perzentilen (Bewertung von Verzögerungen nach Benutzergruppen).
• Telemetrie: Speicherung von „rohen“ Daten und Aggregaten für Dashboards.

Wir unterscheiden zwischen „heißen“ und „kalten“ Daten, da dies ermöglicht, sowohl die Geschwindigkeit der Verarbeitung als auch die langfristige Speicherung aufrechtzuerhalten. Die „heiße“ Schicht ist für schnelle Schreibvorgänge und Abfragen optimiert – hier leben Transaktionen, die neuesten Änderungen und häufig verwendete Informationen. Die „kalte“ Schicht ist für kostengünstige und langfristige Speicherung ausgelegt – in ihr befinden sich Archive, historische Daten und Datenmengen für Analysen. Im transaktionalen Kontur erfassen wir die Quelle der Wahrheit (PostgreSQL), daneben nutzen wir MongoDB für Flexibilität im Umgang mit Dokumenten und ClickHouse für Aggregationen und komplexe Berichte. Dieser dreistufige Ansatz gewährleistet sowohl Zuverlässigkeit als auch Flexibilität.

Das Muster „Schnell schreiben – später lesen“ hilft dem System, beim Schreiben nicht zu stocken: Ereignisse werden schnell angenommen und aufgezeichnet, während die detaillierte Verarbeitung und Analyse später in spezialisierten Speichern durchgeführt wird. CQRS (Trennung der Logik für Schreiben und Lesen) ermöglicht es, schnelle und leichte Abfragen an die Daten zu entwerfen, ohne das Risiko einzugehen, den transaktionalen Kontur zu beschädigen. Event Sourcing (Speicherung der Änderungs-historie in Form von Ereignissen) ermöglicht nicht nur die Wiederherstellung des aktuellen Zustands, sondern auch die Nachverfolgung des gesamten Änderungsprozesses.

Zusammen machen diese Ansätze die Architektur transparent: Das Geschäft erhält schnelle Rückmeldungen bei Operationen und behält gleichzeitig die Möglichkeit einer tiefen Analyse historischer Daten.

Konsistenz von Daten ist die Garantie für Integrität: Informationen in der Datenbank müssen korrekt und konsistent bleiben, selbst wenn sie gleichzeitig von mehreren Benutzern oder Diensten geändert werden. Einfach gesagt, wenn Sie eine Bestellung aufgegeben haben, sollte diese in allen Teilen des Systems gleich angezeigt werden. Isolationsstufen helfen dabei, zu kontrollieren, wie parallele Transaktionen Änderungen sehen. Row-level locking (Sperren einzelner Zeilen bei gleichzeitigen Änderungen) und optimistische Sperren regulieren konkurrierende Änderungen. Deadlock (eine Situation, in der Transaktionen sich gegenseitig behindern und der Prozess stecken bleibt) wird durch die Reihenfolge der Vorgänge und Zeitüberschreitungen verhindert.

Um es einfacher zu erklären: eventual consistency bedeutet, dass die Daten nicht sofort, sondern durch den Austausch von Ereignissen synchronisiert werden. Zum Beispiel kann eine Bestellung in einem Online-Shop Sekunden nach der Auftragsannahme beim Lieferservice erscheinen. Der endgültige Zustand bei allen Diensten wird übereinstimmen, jedoch nicht sofort. Hierfür werden Wiederholungen von Zustellungen und Vorgänge angewendet, die sicher mehrmals ausgeführt werden können. Dieser Ansatz wird häufig in verteilten und mikroservicebasierten Systemen verwendet, in denen Geschwindigkeit und Skalierbarkeit wichtiger sind als unmittelbare Synchronisation.

Wir entwerfen im Voraus Strategien zur Skalierung, damit das System mit dem Geschäft wachsen kann, ohne „Schmerzpunkte“. Die Replikation entlastet das Lesen und erhöht die Verfügbarkeit: Hauptdaten werden auf einen Server geschrieben, während Kopien die Leseanfragen verarbeiten. Dies reduziert die Belastung des Hauptknotens und schützt vor Ausfällen. Sharding ermöglicht es, Daten in Segmente zu unterteilen und auf verschiedene Server zu verteilen: zum Beispiel bedienen einige Server Kunden aus Europa, andere aus Asien. Dieser Ansatz bietet ein lineares Wachstum der Leistung mit zunehmender Benutzerzahl.

In Master-Slave-Topologien führt ein Server die Schreibvorgänge durch, während die Kopien für das Lesen verantwortlich sind. Dies eignet sich gut für Projekte mit hohem Leseanfragevolumen. In Master-Master können mehrere Server gleichzeitig Daten schreiben und lesen. Dies erhöht die Fehlertoleranz und verringert das Risiko von Ausfallzeiten, erfordert jedoch Abstimmungsmechanismen, um Konflikte beim Schreiben zu vermeiden.

Für die Sicherung implementieren wir die Unterstützung für die Wiederherstellung zu einem bestimmten Zeitpunkt (PITR). Das bedeutet, dass im Falle eines Ausfalls das System in einen Zustand zu einem beliebigen Zeitpunkt vor der Panne zurückversetzt werden kann. Wir testen regelmäßig die Backups und üben Notfallszenarien, um sicherzustellen, dass die Wiederherstellung in einer realen Situation minimale Zeit in Anspruch nimmt. Die Überwachung umfasst Anfragen, Replikation, Latenzen und Lastmetriken. Wir identifizieren „Engpässe“ und beheben sie, bevor sie zu einem Problem werden. Dieser ganzheitliche Ansatz gibt die Sicherheit, dass das System sowohl plötzlichen Lastspitzen als auch Notfällen standhalten kann.

Um die Rolle jeder Technologie anschaulich zu zeigen, haben wir die wichtigsten Erkenntnisse in eine separate Karte zusammengefasst. Sie hilft zu verstehen, welche Aufgaben jede Datenbank und welcher Ansatz in der Architektur erfüllt:

• PostgreSQL / MySQL. Diese relationalen Datenbanken sind das Kernstück transaktionaler Systeme. Sie gewährleisten strenge Datenintegrität, die Verarbeitung von Tausenden von Operationen pro Sekunde, Indizierung und Kontrolle von Sperren. PostgreSQL eignet sich gut für komplexe Beziehungen und Analysen auf SQL-Ebene, MySQL und MariaDB – für Systeme, in denen Lesegeschwindigkeit und einfache Skalierbarkeit entscheidend sind. Ihr Hauptwert liegt in der zuverlässigen Dokumentation von Geschäftsoperationen: Bestellungen, Zahlungen, Buchhaltung.
• MongoDB. Diese Datenbank ist praktisch, wenn sich die Datenstruktur häufig ändert: Benutzerprofile, IoT-Ereignisse, Protokolle. Sie ermöglicht die Speicherung von verschachtelten Dokumenten ohne strikte Schema und horizontale Skalierung. MongoDB bietet dem Unternehmen Flexibilität: Neue Attribute können ohne komplexe Migrationen hinzugefügt werden, was die Einführung neuer Funktionen und die Anpassung des Produkts beschleunigt.
• ClickHouse. Optimiert für Analytik und große Volumen. Seine Spaltenstruktur ermöglicht es, Millionen von Zeilen schnell zu aggregieren und Berichte nahezu in Echtzeit zu erstellen. Wird für Handelsprotokolle, Telemetrie und Analyse des Benutzerverhaltens verwendet. Der Vorteil von ClickHouse liegt in der Fähigkeit, riesige Datenmengen ohne Verluste bei Geschwindigkeit und Speicherkosten zu verarbeiten.
• Speicherarchitektur. Die richtige Trennung von "heißen" und "kalten" Daten, die Verwendung von CQRS (Trennung der Schreib- und Leselogik) und Event Sourcing (Speicherung der Änderungshistorie in Form von Ereignissen) macht das System vorhersehbar und benutzerfreundlich. "Heiße" Daten sind immer griffbereit für schnelle Transaktionen, "kalte" für Analytik und langfristige Speicherung. Dieser Ansatz bietet ein Gleichgewicht zwischen Arbeitsgeschwindigkeit und Analysevertiefung.
• Skalierung und Ausfallsicherheit. Replikation, Sharding, Sicherungskopien und Monitoring bilden die Grundlage einer zuverlässigen Infrastruktur. Dies gewährleistet, dass das System auch bei Ausfällen oder plötzlichem Anstieg der Last funktioniert. Für Unternehmen bedeutet dies Vorhersehbarkeit: Der Dienst wird nicht wegen eines Ausfalls gestoppt und kann Spitzenlasten überstehen.

Diese Karte zeigt, dass die Architektur von Datenbanken kein Satz zufälliger Lösungen ist, sondern ein strukturiertes System, in dem jedes Element seine Aufgabe erfüllt und andere stärkt.

Eine gut gestaltete Datenbankarchitektur gewährleistet Skalierbarkeit und Fehlertoleranz. Wir bauen Systeme so, dass Daten das Wachstum des Unternehmens beschleunigen. Die Kombination von SQL- und NoSQL-Technologien funktioniert wie ein einheitlicher Mechanismus.