101 lines
4.7 KiB
Markdown
101 lines
4.7 KiB
Markdown
# ADR-0005: Polyglotte Persistenz
|
|
|
|
## Status
|
|
|
|
Akzeptiert
|
|
|
|
## Kontext
|
|
|
|
Als Teil unserer Microservices-Architektur ([ADR-0003](0003-microservices-architecture-de.md)) mussten wir die am besten
|
|
geeignete Datenspeicherstrategie bestimmen. Verschiedene Teile unseres Systems haben unterschiedliche Anforderungen an
|
|
die Datenspeicherung:
|
|
|
|
1. Einige Daten erfordern starke Konsistenz und komplexe Beziehungen
|
|
2. Einige Daten müssen mit sehr geringer Latenz abgerufen werden
|
|
3. Einige Daten sind ereignisbasiert und müssen in einem Zeitreihenformat gespeichert werden
|
|
4. Verschiedene Dienste haben unterschiedliche Datenzugriffsmuster
|
|
|
|
Ein Einheitsansatz für die Datenspeicherung würde Kompromisse erzwingen, die die Leistung, Skalierbarkeit oder
|
|
Entwicklungsproduktivität beeinträchtigen könnten.
|
|
|
|
## Entscheidung
|
|
|
|
Wir haben uns entschieden, eine polyglotte Persistenzstrategie zu implementieren, die verschiedene
|
|
Datenspeichertechnologien für verschiedene Anwendungsfälle nutzt:
|
|
|
|
1. **PostgresQL**: Als primäre relationale Datenbank zur Speicherung strukturierter Daten mit komplexen Beziehungen
|
|
|
|
- Wird von allen Domänendiensten für ihre primäre Datenspeicherung verwendet
|
|
- Jeder Dienst hat sein eigenes Datenbankschema, um Isolation zu gewährleisten
|
|
|
|
2. **Redis**: Als verteilter Cache für schnellen Datenzugriff
|
|
|
|
- Wird für das Caching häufig abgerufener Daten verwendet
|
|
- Wird für die Sitzungsspeicherung verwendet
|
|
- Wird für Rate-Limiting verwendet
|
|
|
|
3. **Kafka**: Als Event-Store für Event Sourcing
|
|
|
|
- Wird zur Speicherung von Domänenereignissen für Event Sourcing verwendet
|
|
- Ermöglicht Event-Replay zum Wiederaufbau des Zustands
|
|
|
|
4. **Elasticsearch** (geplant): für Volltextsuchfunktionen
|
|
|
|
- Wird für erweiterte Suchfunktionen über mehrere Domänen hinweg verwendet werden
|
|
|
|
Jeder Dienst ist für die Verwaltung seiner eigenen Datenspeicherung verantwortlich, und Dienste dürfen nicht direkt auf
|
|
die Datenbanken anderer Dienste zugreifen.
|
|
|
|
## Konsequenzen
|
|
|
|
### Positive
|
|
|
|
- **Optimierte Leistung**: Jede Art von Daten wird in der am besten geeigneten Speichertechnologie gespeichert
|
|
- **Skalierbarkeit**: Verschiedene Speichertechnologien können unabhängig voneinander basierend auf ihren spezifischen
|
|
Anforderungen skaliert werden
|
|
- **Flexibilität**: Teams können die beste Speichertechnologie für ihre spezifischen Anwendungsfälle wählen
|
|
- **Resilienz**: Probleme mit einer Speichertechnologie beeinträchtigen nicht unbedingt andere
|
|
|
|
### Negative
|
|
|
|
- **Betriebliche Komplexität**: Mehrere Speichertechnologien müssen bereitgestellt, überwacht und gewartet werden
|
|
- **Herausforderungen bei der Datenkonsistenz**: Die Aufrechterhaltung der Konsistenz über verschiedene
|
|
Speichertechnologien hinweg erfordert sorgfältiges Design
|
|
- **Lernkurve**: Teams müssen mit mehreren Speichertechnologien vertraut sein
|
|
- **Komplexität bei Backup und Wiederherstellung**: Verschiedene Speichertechnologien haben unterschiedliche Backup- und
|
|
Wiederherstellungsverfahren
|
|
|
|
### Neutral
|
|
|
|
- **Daten-Governance**: Umfassende Daten-Governance ist über alle Speichertechnologien hinweg erforderlich
|
|
- **Überwachungsbedarf**: Jede Speichertechnologie erfordert ihren eigenen Überwachungsansatz
|
|
|
|
## Betrachtete Alternativen
|
|
|
|
### Einzelne Datenbank für alle Dienste
|
|
|
|
Wir haben die Verwendung einer einzelnen PostgresQL-Datenbank mit separaten Schemas für jeden Dienst in Betracht
|
|
gezogen. Dies hätte den Betrieb vereinfacht, hätte aber einen Single Point of Failure geschaffen und hätte es uns nicht
|
|
ermöglicht, für verschiedene Datenzugriffsmuster zu optimieren.
|
|
|
|
### Datenbank pro Dienst, gleiche Technologie
|
|
|
|
Wir haben die Verwendung von PostgresQL für alle Dienste, aber mit separaten Datenbanken in Betracht gezogen. Dies hätte
|
|
Dienstisolation geboten und gleichzeitig den Betrieb vereinfacht, hätte es uns aber nicht ermöglicht, für verschiedene
|
|
Datenzugriffsmuster zu optimieren.
|
|
|
|
### Vollständig verteilter NoSQL-Ansatz
|
|
|
|
Wir haben die Verwendung eines vollständig verteilten NoSQL-Ansatzes mit Technologien wie Cassandra oder MongoDB für die
|
|
gesamte Datenspeicherung in Betracht gezogen. Dies hätte eine ausgezeichnete Skalierbarkeit geboten, hätte aber die
|
|
Modellierung komplexer Beziehungen erschwert und hätte signifikante Änderungen an unseren Entwicklungspraktiken
|
|
erfordert.
|
|
|
|
## Referenzen
|
|
|
|
- [Polyglot Persistence von Martin Fowler](https://meldestelle-pro.youtrack.cloud/api/files/526-28?sign=MTc2MjU2MDAwMDAwMHwyLTF8NTI2LTI4fERaVkFWVmlEbVJJbTVZSFE2SWlrbmRydHNaeDdxZUFaRExpdkNxbk9wVEkNCg&updated=1762343428460)
|
|
- [PostgresQL Dokumentation](https://www.postgresql.org/docs/)
|
|
- [Redis Dokumentation](https://redis.io/documentation)
|
|
- [Apache Kafka Dokumentation](https://kafka.apache.org/documentation/)
|
|
- [Elasticsearch Dokumentation](https://www.elastic.co/docs/solutions/search)
|