Unsere AWS Datenbank-Strategie Trading steht vor der wichtigsten Architektur-Entscheidung: Nach den ersten Schritten mit AWS Lambda und EventBridge in Woche 37 evaluieren wir jetzt drei grundsätzlich verschiedene Datenbank-Optionen. DynamoDB (NoSQL), TimescaleDB (Time-Series) und Aurora PostgreSQL mit pgvector (Relational + Vector) stehen zur Auswahl.
Die richtige AWS Datenbank-Strategie Trading ist entscheidend für Performance, Kosten und Skalierbarkeit. In dieser Woche beginnt ein mehrwöchiger Evaluations-Prozess. Jede Option hat spezifische Vor- und Nachteile für Trading-Use-Cases.
AWS Datenbank-Strategie Trading: Warum die Wahl jetzt wichtig wird
Nach unseren ersten AWS-Schritten mit Lambda und EventBridge in den letzten Wochen ist die Datenbank-Wahl der nächste logische Schritt. Trading-Daten haben spezifische Charakteristika: Sie sind Time-Series-orientiert (OHLCV-Daten), haben hohe Schreiblasten und benötigen schnelle Query-Performance für Backtesting.
Drei grundsätzlich verschiedene Ansätze sind möglich. Die Entscheidung beeinflusst Performance, Kosten, Skalierbarkeit und Entwicklungsgeschwindigkeit. Ähnlich wie bei unserer PostgreSQL-Evaluation in Woche 22, geht es nicht um „entweder/oder“, sondern um „welche Datenbank für welchen Use Case“.
Unsere Performance-Requirements aus Trading: Weniger als 100ms Latency für OHLCV-Abfragen, kosteneffiziente Speicherung (Referenz zu unserem Cost-Efficiency-Vergleich in CW37) und einfache Skalierbarkeit. Die Evaluation wird mehrere Wochen dauern.
Option 1: TimescaleDB – Time-Series-optimiert
TimescaleDB ist eine PostgreSQL-Extension, die speziell für Time-Series-Daten entwickelt wurde. Für Trading ist das relevant, weil OHLCV-Daten (Open, High, Low, Close, Volume) klassische Time-Series sind. Der große Vorteil: Volle SQL-Kompatibilität mit allen PostgreSQL-Features.
Die technischen Highlights sind Hypertables (automatische Partitionierung nach Zeit) und Continuous Aggregates – Real-Time-Berechnungen ohne ständige Recalculation. Wir haben bereits in Woche 21 erste TimescaleDB-Erfahrungen gesammelt, die jetzt relevant werden.
Die Benchmarks aus unserer Konzept-Evaluation zeigen beeindruckende Zahlen bei 50 Millionen Datenpunkten:
- 6.000x schnellere Inserts im Vergleich zu AWS Timestream
- 175x schnellere Queries bei komplexen Abfragen
- 220x günstiger im Betrieb
- 94% Compression für historische Trading-Daten
Die Vorteile liegen auf der Hand: Beste Performance für Time-Series-Queries, SQL-Kompatibilität für einfachen Einstieg und RDS-Deployment als Managed Service möglich. Die Nachteile: Kein Serverless-Modus (Server läuft 24/7), höhere Setup-Komplexität als DynamoDB und Vector-Support nur via pgvector-Extension.
Option 2: DynamoDB – Serverless NoSQL
DynamoDB ist AWS-managed NoSQL, serverless und perfekt für Event-Driven-Architecture. Das passt gut zu unserem EventBridge-Lambda-Pattern aus den letzten Wochen. DynamoDB Streams ermöglichen Event-Sourcing und das Single-Table-Design flexible Queries.
Zero-Administration ist der Hauptvorteil – kein Server-Management nötig. Das Partition-Key-Design ist allerdings kritisch, um Hot Partitions zu vermeiden. Global Secondary Indexes (GSI) ermöglichen flexible Queries trotz NoSQL. Das On-Demand-Pricing-Modell bedeutet: Pay per Request. Die Latency liegt im Single-Digit-Milliseconds-Bereich.
Die Vorteile von DynamoDB: Serverless ohne Server-Verwaltung, Auto-Scaling ohne Konfiguration und perfekte Integration mit DynamoDB Streams und EventBridge. Die Nachteile: NoSQL bedeutet komplexere Queries ohne SQL, das Kostenmodell kann bei hoher Last teurer werden als RDS, Aggregationen sind schwieriger (kein GROUP BY) und Time-Series-Queries sind nicht optimiert.
Weitere Details zur DynamoDB-Architektur finden sich in der offiziellen AWS-Dokumentation.
Option 3: Aurora PostgreSQL mit pgvector
Aurora PostgreSQL kombiniert Managed PostgreSQL mit Vector-Embeddings über pgvector. Das ist relevant für Trading, weil es SQL-Transaktionen mit Vector-Search für ML-basierte Pattern-Recognition verbindet. Die Learnings aus unserer Intelligence-Migration sind hier übertragbar.
Die technischen Highlights: pgvector HNSW-Index ermöglicht 20x schnellere Vector-Queries, Schema-Design-Patterns für komplexe Beziehungen sind möglich, Aurora Multi-Master bietet hohe Verfügbarkeit und die Kosten sind 75% günstiger als Pinecone für Vector-Storage.
Die Vorteile: Vollständiges SQL mit komplexen Joins und Aggregationen, integrierter Vector-Search für ML-Features, Aurora Serverless v2 verfügbar mit Auto-Scaling und ACID-Transaktionen. Die Nachteile: Time-Series nicht so optimiert wie TimescaleDB, pgvector-Extension benötigt Extra-Setup, teurer als TimescaleDB on RDS und komplexer als DynamoDB.
Details zu Aurora PostgreSQL gibt es in der AWS Aurora-Dokumentation, pgvector ist auf GitHub verfügbar.
Multi-Database-Strategy als möglicher Ansatz
Unsere aktuelle Arbeits-Hypothese für die AWS Datenbank-Strategie Trading: Verschiedene Daten-Typen könnten verschiedene Datenbanken brauchen. Eine mögliche Aufteilung wäre TimescaleDB für Market Data (OHLCV, Indicators) wegen Time-Series-Optimierung, DynamoDB für Events, Logs und State wegen Event-Driven-Architecture und Aurora pgvector für Transaktionen und Intelligence-Daten wegen Relational + Vector.
Die Rationale für Multi-DB: „Right tool for the right job“ statt Eine-Lösung-für-alles. Unsere Konzept-Recherche zeigt, dass Hybrid-Architektur Production-Standard ist. Die Komplexität ist managebar, weil das AWS SDK einheitlich ist.
Aber: Diese Strategie erhöht die Komplexität. Die Alternative wäre ein Single-DB-Ansatz mit nur TimescaleDB oder nur Aurora. Die Evaluation läuft noch mehrere Wochen, welcher Weg besser passt. Weitere Informationen zu AWS-Datenbank-Optionen gibt es in der AWS Database-Übersicht.
🎯 Datenbank-Entscheidungsbaum für Trading-Daten
START: Was ist der primäre Use Case? ├─ TIME-SERIES-DATEN (OHLCV, Indicators) │ └─ Performance > Kosten? │ ├─ JA → TimescaleDB (6.000x schneller) │ └─ NEIN → DynamoDB (günstiger bei niedrigem Volumen) │ ├─ EVENT-DRIVEN-ARCHITECTURE (Logs, State-Changes) │ └─ Serverless bevorzugt? │ ├─ JA → DynamoDB (mit Streams) │ └─ NEIN → PostgreSQL + Triggers │ ├─ KOMPLEXE QUERIES (Joins, Aggregationen, Reports) │ └─ ML-Integration geplant? │ ├─ JA → Aurora pgvector (SQL + Vectors) │ └─ NEIN → Aurora PostgreSQL (nur SQL) │ └─ ALLE USE CASES → Multi-DB-Strategy (Arbeits-Hypothese) - TimescaleDB: Market Data - DynamoDB: Events - Aurora: Transactions
📊 Performance-Benchmarks (50M Datenpunkte)
| Metrik | DynamoDB | TimescaleDB | Aurora |
|---|---|---|---|
| Insert-Latency | 5-10ms | 0.8ms ⭐ | 2-5ms |
| Query-Latency (1d) | 50-100ms | 8ms ⭐ | 15-30ms |
| Query-Latency (30d) | 200-500ms | 47ms ⭐ | 80-150ms |
| Aggregation (GROUP) | Nicht nativ | 187ms ⭐ | 250ms |
| Storage/Monat | €23 | €2.30 ⭐ | €11.50 |
| Compression | Keine | 94% ⭐ | ~50% |
| SQL-Kompatibilität | ❌ | ✅ ⭐ | ✅ ⭐ |
| Serverless | ✅ ⭐ | ❌ | ✅ (v2) |
| Vector-Search | ❌ | Via pgvector | ✅ ⭐ |
Quelle: Interne Konzept-Benchmarks mit AWS-Services
Nächste Schritte: Evaluation geht weiter
Status aktuell: Die Evaluation läuft, erste Erkenntnisse aus Benchmarks liegen vor. In den nächsten Wochen folgen Cost-Simulationen mit realistischen Trading-Volumes, Migration-Analyse von unserer lokalen Lösung und Performance-Tests mit Prototypen.
Die Timeline ist realistisch: Mehrere Wochen Evaluation, bevor wir mit der AWS-Implementation starten. Offene Fragen sind die genaue Kostenprognose bei hohen Volumina, der Migrations-Aufwand von unserer lokalen PostgreSQL-Lösung, die Backup-Strategy über mehrere Datenbanken hinweg und praktische Performance-Tests mit Prototypen.
Community-Input ist erwünscht: Welche Erfahrungen habt ihr mit diesen Datenbank-Optionen gemacht? Was würdet ihr für Trading-Daten wählen? Hinterlasst Kommentare oder teilt eure Gedanken mit uns.
Kommentar verfassen