Eine Zeitreihendatenbank ist die Schicht, mit der jedes ernsthafte IoT-Projekt steht und fällt. Sensoren für Temperatur, Vibration oder Energieverbrauch erzeugen einen Strom von Messpunkten, den eine klassische relationale Datenbank im Produktivmaßstab schlicht nicht bewältigt. Eine gut gewählte Zeitreihendatenbank (TSDB) erlaubt es, Millionen von Messwerten pro Sekunde zu schreiben, sie um eine Größenordnung zu komprimieren und in Millisekunden nach Zeitbereichen abzufragen. In diesem Leitfaden erklären wir, wie eine TSDB funktioniert, welche man wählt und wie man Retention, Downsampling und ein Datenmodell für eine Geräteflotte entwirft.
Kurz gesagt: Eine Zeitreihendatenbank ist ein für zeitgestempelte Daten optimiertes Speichersystem — im IoT übernimmt sie die Aufnahme der Telemetrie von Tausenden Geräten, deren Kompression, Retention und schnelle analytische Abfragen. Am häufigsten gewählt werden InfluxDB, TimescaleDB, Azure Data Explorer und ClickHouse.
Was ist eine Zeitreihendatenbank?
Eine Zeitreihendatenbank ist eine spezialisierte Engine zur Speicherung zeitlich geordneter Messsequenzen, bei denen jeder Datensatz einen Zeitstempel, einen Satz von Tags (z. B. Geräte-ID, Standort) und einen oder mehrere Werte hat. Anders als bei einer relationalen Datenbank werden die Daten fast ausschließlich angehängt (Append-only-Modell) und nicht verändert.
Diese eine Eigenschaft ändert alles. Eine TSDB-Engine kann davon ausgehen, dass neue Datensätze chronologisch eintreffen, und wendet daher differenzielle Kompression an (Delta-of-Delta für Zeitstempel, XOR-Kompression für Gleitkommawerte), zeitbasierte Indizes und Partitionierung in Zeitblöcke. Das Ergebnis ist typischerweise eine 5- bis 15-fache Volumenreduktion und Schreibraten von Hunderttausenden Punkten pro Sekunde auf einem einzelnen Knoten.
Warum braucht IoT eine Zeitreihendatenbank?
IoT ist per Definition ein Zeitreihenproblem: Messung, Zeitstempel, Wiederholung. Eine Flotte von 10.000 Geräten, die 10 Metriken alle 10 Sekunden melden, erzeugt rund 100.000 Punkte pro Sekunde und mehr als 8,6 Milliarden Datensätze pro Tag. Ein relationales Modell mit B-Baum-Index degradiert bei dieser Schreibrate, und die IOPS-Kosten steigen sprunghaft.
Telemetrie erreicht die Datenbank meist über einen Message-Broker. In der Praxis kombinieren wir das MQTT-Protokoll am Edge mit einer Cloud-Ereigniswarteschlange wie Azure Event Hubs, und erst von dort wird der Strom in die TSDB geschrieben. Eine solche Pipeline trennt Ingestion und Speicherung und erlaubt es, Verkehrsspitzen zu puffern. Die Streaming-Schicht beschreiben wir ausführlicher in unserem Beitrag zur IoT-Telemetrie in Echtzeit.
Wie funktioniert eine Zeitreihendatenbank?
Eine Zeitreihendatenbank arbeitet in drei logischen Stufen: Annahme des Schreibvorgangs (Ingest), dauerhafte Speicherung mit Kompression und Lesen nach Zeitbereichen. Das Verständnis dieser Stufen ist entscheidend für den Entwurf einer performanten Umsetzung.
- Ingest — Schreibvorgänge landen zuerst in einer In-Memory-Struktur (WAL + Puffer), werden nach Zeit sortiert und periodisch als unveränderliche Blöcke auf die Festplatte geschrieben.
- Kompression und Partitionierung — Blöcke werden in Zeitfenster unterteilt (z. B. 1–7 Tage); ältere Partitionen lassen sich aggressiver komprimieren oder auf günstigeren Speicher verschieben (Tiering).
- Abfragen — die Engine liest nur die Partitionen, die den Zeitbereich der Abfrage abdecken, und führt Aggregationen (avg, min, max, Perzentile) mit Downsampling on the fly aus.
Welche Zeitreihendatenbank sollte man wählen?
Es gibt keine einzig beste Zeitreihendatenbank — die Wahl hängt von Volumen, Abfragemodell und den Kompetenzen des Teams ab. Nachfolgend die am häufigsten eingesetzten Optionen und ihre Stärken.
- InfluxDB — eine dedizierte TSDB-Engine mit der Sprache Flux/InfluxQL; ein guter Einstiegspunkt für Deployments bis zu einigen Hunderttausend Schreibvorgängen pro Sekunde.
- TimescaleDB — eine PostgreSQL-Erweiterung, also volles SQL, JOINs und das Postgres-Ökosystem; praktisch, wenn das Team das relationale Modell bereits kennt.
- Azure Data Explorer / ClickHouse — spaltenorientierte Analyse-Engines, die bis in den Petabyte-Bereich skalieren; sie glänzen bei schwerer Analytik und langer Historie.
- Prometheus — der Standard für Infrastruktur-Monitoring und operative Metriken, aber nicht für die Langzeitspeicherung von Geschäftsdaten.
In Projekten auf der Azure-Plattform kombinieren wir eine TSDB meist mit fertigen Analysediensten — das haben wir in unserem Beitrag zur Zeitreihenanalytik beschrieben. Die Wahl sollte man mit einem echten Lasttest auf dem eigenen Datenprofil untermauern, nicht nur mit dem Benchmark des Herstellers.
Retention, Downsampling und Kompression — wie man das Budget nicht versenkt
Retention ist die Richtlinie, die festlegt, wie lange die Datenbank Daten in voller Auflösung speichert, bevor sie aggregiert oder gelöscht werden. Ohne sie wächst das Volumen linear und kann nach einem Jahr das Infrastrukturbudget um das Zehnfache übersteigen.
Ein bewährtes Muster ist die Auflösungspyramide: Rohdaten (z. B. im 1-Sekunden-Takt) 7–30 Tage aufbewahren, 1-Minuten-Aggregate 1 Jahr und Stundenaggregate mehrere Jahre. Downsampling — das automatische Berechnen und Speichern von Aggregaten — übernehmen Hintergrundjobs (Continuous Queries, Materialized Views). So liest ein historisches Dashboard leichte Aggregate statt Milliarden von Rohpunkten.
Wie entwirft man Datenmodell und Analytik?
Die Performance einer Zeitreihendatenbank hängt vor allem von der Kardinalität ab — der Zahl eindeutiger Tag-Kombinationen. Werte mit hoher Eindeutigkeit in Tags zu packen (z. B. eine zufällige UUID in jeder Messung) kann den Index sprengen und Abfragen verlangsamen. Tags sollten Dimensionen mit endlich vielen Werten beschreiben: Geräte-ID, Sensortyp, Produktionslinie.
Auf so vorbereiteten Daten lässt sich leicht Analytik höherer Ordnung aufbauen. Die gespeicherten Reihen speisen Echtzeit-Dashboards und Mechanismen zur Anomalieerkennung und Alarmierung, die das Herz der vorausschauenden Wartung sind. Diesen Faden führen wir in unserem Artikel zur Predictive Maintenance im IIoT fort.
Häufig gestellte Fragen (FAQ)
Worin unterscheidet sich eine Zeitreihendatenbank von einer gewöhnlichen SQL-Datenbank?
Eine Zeitreihendatenbank ist auf Append-only-Schreibvorgänge mit Zeitstempel, spaltenorientierte Kompression und Zeitbereichsabfragen optimiert. Eine klassische relationale Datenbank verliert bei Millionen Punkten pro Sekunde an Leistung und hat keine eingebaute Retention oder Downsampling.
Wie viele Daten erzeugt eine typische IoT-Flotte?
Eine Flotte von 10.000 Geräten, die 10 Metriken alle 10 Sekunden senden, ergibt rund 100.000 Punkte pro Sekunde, also mehr als 8,6 Milliarden Datensätze pro Tag. Ohne Kompression (meist 5–15×) und Retention-Richtlinie wächst der Speicherkostenaufwand linear und übersteigt schnell das Projektbudget.
Welche Zeitreihendatenbank sollte man für ein IoT-Projekt wählen?
InfluxDB und TimescaleDB eignen sich für die meisten mittelgroßen Deployments, Azure Data Explorer und ClickHouse für Petabyte-Analytik und Prometheus für Infrastruktur-Monitoring. Die Wahl hängt vom Schreibvolumen, vom Abfragemodell und davon ab, ob das Team SQL oder eine dedizierte Sprache bevorzugt.
Fazit und wichtigste Erkenntnisse
Eine Zeitreihendatenbank ist kein Implementierungsdetail, sondern ein Fundament, das über Kosten, Performance und Skalierbarkeit des gesamten IoT-Systems entscheidet. Die zentralen Entscheidungen sind die Wahl der Engine (InfluxDB, TimescaleDB, Azure Data Explorer), die Retention- und Downsampling-Richtlinie und die Kontrolle der Tag-Kardinalität. Richtig entworfen, bewältigen sie Milliarden von Messwerten pro Tag bei vorhersehbarem Budget.
Bei FSS entwerfen wir die gesamte Kette — von Firmware und Hardware über die Telemetrie-Ingestion bis zu Cloud und Analytik. Wenn Sie Telemetrie für eine Geräteflotte einführen möchten, entdecken Sie unser Angebot für IoT-Analytik und Dashboards und lassen Sie uns über eine auf Ihren Maßstab abgestimmte Zeitreihenarchitektur sprechen.