InfluxDB
Zeitreihen-Datenbank für Messwerte: schreibt sehr schnell, speichert komprimiert und vergisst alte Daten automatisch.
Ein Sensor tickt im Sekundentakt: Jeder Messwert landet mit seinem Zeitstempel in einem Bucket — einem Datenbehälter mit Ablaufdatum.
// Teste dich
Worauf ist InfluxDB spezialisiert?
In 30 Sekunden
InfluxDB ist eine Datenbank, die auf eine einzige Sache spezialisiert ist: Messwerte mit Zeitstempel — sogenannte Zeitreihen. Sensoren, Server oder Maschinen liefern pausenlos Werte, und InfluxDB schreibt sie deutlich schneller und platzsparender weg als eine klassische SQL-Tabelle. Alte Rohdaten räumt sie über Aufbewahrungsregeln (Retention) selbstständig ab, verdichtete Zusammenfassungen bleiben dafür jahrelang erhalten. Zusammen mit Grafana als Dashboard ist sie der Quasi-Standard für Monitoring und IoT-Datenerfassung.
InfluxDB funktioniert wie eine Überwachungskamera mit Ringspeicher: Ständig kommen neue Aufnahmen dazu, und die ältesten werden automatisch überschrieben — niemand muss von Hand löschen. Wer etwas langfristig behalten will, speichert nicht jedes Einzelbild, sondern eine Zusammenfassung, etwa ein Standbild pro Stunde. Genauso behält InfluxDB die frischen Rohdaten nur kurze Zeit und hebt verdichtete Mittelwerte für Jahre auf.
Wo trifft man InfluxDB an?
IoT- und Sensordaten
Der Klassiker: Temperatur, Feuchte, Strom oder Füllstand von vielen Sensoren im Sekundentakt. Beispiel: Eine Wetterstation schickt ihre Werte per MQTT, Telegraf schreibt sie nach InfluxDB, Grafana zeigt den Verlauf.
Server- und Container-Monitoring
CPU, RAM, Disk und Netzwerk von Servern und Docker-Containern als Metriken. Beispiel: Ein Docker-Host meldet alle zehn Sekunden seine Auslastung — Ausreisser fallen im Dashboard sofort auf.
Energie-Monitoring
Photovoltaik, Smart Meter und Wärmepumpe im Blick behalten. Beispiel: Die PV-Anlage schreibt laufend die aktuelle Leistung, das Dashboard zeigt Tagesverlauf und Eigenverbrauch.
Industrie und OT
Maschinen- und Prozessdaten für Trendanalysen und vorausschauende Wartung sammeln. Beispiel: Die Spindeltemperatur einer Fräsmaschine steigt über Wochen leicht an — ein Hinweis auf ein Lagerproblem.
Smart Home
Langzeit-Historie neben der Smart-Home-Zentrale. Beispiel: Home Assistant lagert Messverläufe nach InfluxDB aus, damit sich die Raumtemperatur über ein ganzes Jahr vergleichen lässt.
Netzwerk-Monitoring
Latenz, Bandbreite und Verfügbarkeit über die Zeit verfolgen. Beispiel: Ein Ping-Test alle 30 Sekunden zeigt, dass die Internetleitung jeweils abends einbricht.
Gut geeignet für
- Für Daten, die praktisch nur geschrieben und selten geändert werden, weil die Speicher-Engine genau auf dieses Anhängen (append) optimiert ist.
- Für hohe Schreibraten auf bescheidener Hardware, weil InfluxDB auch auf einem Raspberry Pi viele tausend Punkte pro Sekunde verkraftet.
- Für automatische Datenhygiene, weil Retention-Regeln alte Punkte ohne Skripte und ohne manuelles Aufräumen löschen.
- Für Dashboards mit Grafana, weil Abfragen über Zeitbereiche (letzte Stunde, letzte Woche) extrem schnell beantwortet werden.
- Für den typischen IoT-Stack mit MQTT, Telegraf und Node-RED, weil fertige Anbindungen existieren und kaum Eigenbau nötig ist.
Weniger geeignet für
- Für klassische Geschäftsdaten mit Beziehungen (Kunden, Aufträge, Rechnungen), weil relationale Verknüpfungen und Transaktionen fehlen; besser PostgreSQL oder MySQL.
- Für Daten, die häufig nachträglich geändert oder einzeln gelöscht werden müssen, weil der Speicher aufs Anhängen ausgelegt ist; besser eine relationale Datenbank.
- Für Volltextsuche in Logs und Dokumenten, weil InfluxDB Zahlenreihen speichert, keine Texte; besser Elasticsearch/OpenSearch oder Grafana Loki.
- Für Tags mit sehr vielen unterschiedlichen Werten (hohe Kardinalität, z. B. eine ID pro Anfrage), weil der Index dann stark wächst; hier lohnt sich der Blick auf TimescaleDB.
Fakten
- Zeitreihen-Datenbank (Time Series Database, TSDB)
- InfluxData (USA), erste Version 2013
- Open Source (MIT-Lizenz), daneben Cloud- und Enterprise-Angebote
- Measurement, Tags, Fields und Zeitstempel
- Line Protocol über die HTTP-API (Standard-Port 8086)
- InfluxQL (SQL-ähnlich), Flux (Version 2), SQL (Version 3)
- Buckets mit Retention — alte Daten verfallen automatisch
- Grafana (Dashboards), Telegraf (Sammler), MQTT, Node-RED
Im Detail
Warum keine normale SQL-Tabelle?
Ein einziger Sensor, der jede Sekunde misst, erzeugt über 2,5 Millionen Werte pro Monat. Eine klassische SQL-Datenbank ist für das Lesen und Ändern einzelner Datensätze gebaut — bei Zeitreihen passiert aber fast nur eines: hinten anhängen und ganze Zeitbereiche lesen. Genau darauf ist eine Zeitreihen-Datenbank zugeschnitten: Sie sortiert alles nach Zeit, komprimiert benachbarte, ähnliche Werte sehr effizient und beantwortet Fragen wie «zeig mir die letzte Woche» ohne teure Suchläufe.
Das Datenmodell: vier Teile pro Punkt
Jeder Datenpunkt besteht aus einem Measurement (was gemessen wird, z. B. temperatur), Tags (beschreibende Etiketten wie ort=halle1, nach denen gefiltert wird), Fields (der eigentliche Messwert, z. B. wert=21.7) und dem Zeitstempel. Geschrieben wird das kompakt im sogenannten Line Protocol, einer einfachen Textzeile: temp,ort=halle1 wert=21.7 1720252800. Tags sind indexiert und machen Abfragen schnell, Fields tragen die Nutzdaten.
Buckets und Retention: eingebautes Vergessen
Daten landen in Buckets — Behältern mit Ablaufdatum. Wer einen Bucket mit 30 Tagen Retention anlegt, muss sich um alte Daten nie mehr kümmern: Was älter ist, löscht die Datenbank selbstständig. Das hält den Speicher dauerhaft schlank und ist ein grosser Unterschied zu klassischen Datenbanken, in denen Messwert-Tabellen ohne Pflege einfach immer weiter wachsen.
Downsampling: Rohdaten kurz, Mittelwerte lang
Für Langzeit-Auswertungen braucht niemand jeden Sekundenwert. Ein automatischer Task verdichtet die Rohdaten deshalb regelmässig — etwa zu einem Mittelwert pro Stunde — und schreibt das Ergebnis in einen zweiten Bucket mit langer Retention. So bleiben die Details 30 Tage verfügbar, der grobe Verlauf dagegen über Jahre — bei einem Bruchteil des Speicherplatzes.
Abfragen und Dashboards
Abgefragt wird je nach Version mit InfluxQL, Flux oder SQL — immer nach demselben Muster: Zeitbereich wählen, filtern, verdichten. In der Praxis übernimmt das meist Grafana: Das Dashboard fragt InfluxDB im Hintergrund ab und zeichnet die Kurven. Der typische IoT-Stack sieht darum so aus: Sensor → MQTT → Telegraf → InfluxDB → Grafana.
Zur Einordnung der Versionen: InfluxDB 1.x nutzt InfluxQL, Version 2 setzt auf die eigene Sprache Flux, und die neu geschriebene Version 3 kehrt zu SQL zurück. Wer heute startet, sollte die Versionswahl bewusst treffen — Anleitungen im Netz beziehen sich oft noch auf ältere Versionen und deren Abfragesprachen.