Zeitreihendaten

Warum Zeitreihendatenbanken

• Erfassung von Ereignissen, die in hoher Frequenz auftreten
• Hohe Schreibrate, Millionen Punkte/Sekunde möglich
• Append-only: neue Daten werden angehängt, nicht geändert
• Effizientes Speichermanagement notwendig, Kompression
• Abfrage einer sehr großen Anzahl von Zeitreihen
• Zeit als primärer Schlüssel
• Optimiert für sequentielle Daten
• Neueste Daten werden am häufigsten gelesen (Hot Data)
• Automatische Löschung/Komprimierung alter Daten, Downsampling
• Optimiert für zeitbasierte Abfragen

Anwendungsfälle

Hohe Kardinalität

Kardinalität

• Kardinalität = Anzahl eindeutiger Werte in einer Kennung
• Jede Kennungs-Kombination = eine eigene Zeitreihe

Beispiel IOT

• 10.000 Smarthomes (Kennung = Smarthome-ID)
• 10 Sensoren pro Smarthome (Kennung = Sensor-ID)
• 10.000 × 10 = 100.000 Zeitreihen

Möglichst vermeiden

• User-ID, Session-ID, Request-ID als Kennung → Millionen Zeitreihen
• Präzise GPS-Koordinaten als Kennung → ∞ Zeitreihen
• Faustregel: < 10.000 eindeutige Werte je Kennung

Typen von Zeitreihendaten

Metrics (Regular)

• Gleichmäßige Zeitabstände (z.B. alle 15 s)
• Polling-/Scraping-Modell (Pull)
• Beispiele: CPU-Auslastung, Temperatur, Netzwerkdurchsatz
• Einfach zu speichern und zu aggregieren

Events (Irregular)

• Ungleichmäßige, ereignisgesteuerte Abstände
• Push-Modell: Datenpunkt bei jedem Ereignis
• Beispiele: HTTP-Anfragen, Transaktionen, Fehler
• Erfordern Interpolation oder Bucketing für Aggregationen

Zeitreihendatenbanken

InfluxDB

• Speziell für Zeitreihendaten entwickelt, sehr effizient bei hoher Schreiblast
• Version 3 basiert auf Apache Datafusion, SQL
• Integrierte Funktionen für Retention Policies und Downsampling

Prometheus

• Open-Source Monitoring- und Alerting-System, stark im DevOps-Umfeld
• Pull-basiertes Modell (scraped Metriken über HTTP)
• Eigene Query-Sprache (PromQL) für flexible Auswertungen

kdb+

• Hochperformante, spaltenorientierte Zeitreihendatenbank, oft im Finanzbereich eingesetzt
• Sehr schnelle In-Memory-Analysen großer Datenmengen
• Verwendet die kompakte Programmiersprache q für Abfragen und Analysen

TimescaleDB

• Erweiterung für PostgreSQL, kombiniert SQL mit Zeitreihenfunktionen
• Automatische Partitionierung (Hypertables) für skalierbare Speicherung
• Gut integrierbar in bestehende SQL-Ökosysteme und Tools

Zeitbasierte Abfragen

• Zeitbereichsabfragen: WHERE time >= now() - 1h
• Aggregationen über Zeitfenster, Bucketing
• Fensterarten
• Tumbling Window
• Hopping Window
• Sliding Window
• Session Window

Tumbling Window

• Feste Größe: gleichlange, nicht-überlappende Zeitfenster
• Jedes Ereignis gehört zu genau einem Fenster
• Lückenlose Abdeckung: kein Ereignis wird übersprungen
• Pro Fenster wird genau ein Ergebnis ausgegeben
• Typische Anwendung: Zählen, Summieren, Durchschnitt je Periode

Hopping Window

• Fenstergröße und Hop-Größe sind unabhängig
• Hop < Fenstergröße → überlappende Fenster
• Ereignisse im Überlappungsbereich werden in mehreren Fenstern gezählt
• Hop = Fenstergröße → entspricht Tumbling Window
• Anwendung: gleitende Statistiken mit fester Auflösung

Sliding Window

• Fenster gleitet über den Ereignisstrom
• Neuberechnung Fensterinhalt nur, wenn ein neues Ereignis eintritt oder ein altes Ereignis das Fenster verlässt
• Ausgabe bei Beispiel, wenn 3 Einheiten im Fenster sind
• Kein fixes Raster – Ausgabe ereignisgesteuert
• Jedes Ereignis kann in vielen Fenstern enthalten sein
• Anwendung: Anomalieerkennung, gleitende Schwellwerte

Session Window

• Keine feste Größe: das Fenster passt sich der Aktivität an
• Fenster öffnet sich beim ersten Ereignis einer Aktivitätsserie
• Fenster schließt, wenn für ≥ Timeout kein Ereignis eintrifft
• Optional: maximale Fensterdauer (max. duration)
• Anwendung: Benutzer-Sessions, Geräteaktivität, Log-Cluster

Retention Policies & Downsampling

Retention Policy

• Automatisches Löschen nach definierter Zeitdauer
• Mehrere Policies pro Datenbank möglich
• Beispiel: Raw 7 Tage, Aggregiert 1 Jahr

Downsampling

Horizontale Skalierung

Strategien

• Sharding nach Zeit: jeder Knoten verwaltet Zeitbereich
• Sharding nach Metrik: Metriken aufgeteilt auf Knoten
• Replikation: Faktor 2–3 für Ausfallsicherheit
• Object Storage: Langzeitarchiv in S3 / GCS / Azure

Zeitreihen-Komprimierung

Methoden

• Delta-Encoding: Differenz zum Vorgänger speichern
• Delta-of-Delta: bei gleichmäßigen Zeitstempeln
• Gorilla XOR: XOR aufeinanderfolgender Floats
• Simple8b: Bit-Packing für Integer-Werte
• Run-Length Encoding: für Duplikate

Kompressionsrate: 10–100× je nach Datenmuste