ClickHouse für Energie-Zeitreihen: Warum wir Milliarden Zeilen darin halten
Wir speichern die Messwerte aus Zählern, Wechselrichtern und Marktdaten in ClickHouse, weil eine spaltenorientierte Datenbank genau für hohe Schreibraten und schnelle Auswertungen über riesige Zeitreihen gebaut ist. Hier bekommst du direkt die Gründe, die Grenzen und die konkreten Einstellungen – ohne Umweg.
ClickHouse legt jede Spalte getrennt ab, nicht jede Zeile. Wenn du bei einer Lastgang-Auswertung nur Zeitstempel und Leistung brauchst, liest die Datenbank auch nur diese zwei Spalten – nicht die kompletten Datensätze. Weil in einer Spalte lauter ähnliche Werte stehen (etwa aufsteigende Zeitstempel, ähnliche kW-Werte), lassen sie sich stark komprimieren. Genau das macht Milliarden Zeilen handhabbar: weniger gelesene Bytes, schnellere Aggregate.
Rechne selbst: Ein Viertelstunden-Lastgang erzeugt rund 35.000 Messwerte pro Zähler und Jahr, ein Sekunden- oder Minutentakt aus Wechselrichtern ein Vielfaches. Multipliziere das mit vielen Zählern, Filialen oder Anlagen über mehrere Jahre – und du bist schnell bei Milliarden Zeilen. Eine Zeile pro Messpunkt ist das ehrliche Rohformat; du willst es nicht vorzeitig aggregieren und dir damit Detailfragen für später verbauen.
Nutze die MergeTree-Engine und wähle als Sortierschlüssel typisch (geraet_id, zeitstempel). Danach ist eine Abfrage 'ein Zähler, ein Zeitraum' ein gezielter Bereichs-Scan statt Volltablesuche. Partitioniere sinnvoll grob, meist nach Monat (toYYYYMM(zeitstempel)) – so kannst du alte Zeiträume als ganze Partition löschen oder auslagern. Übertreib die Partitionierung nicht: zu viele kleine Partitionen bremsen die Merges.
Halte die Rohauflösung so lange, wie du sie fachlich brauchst, und lege parallel verdichtete Ebenen an. Mit Materialized Views und AggregatingMergeTree berechnest du Stunden- oder Tagesmittel, Min/Max und Summen automatisch beim Schreiben. Dashboards fragen dann die kleine Aggregat-Tabelle ab (schnell), Detail-Analysen greifen bei Bedarf auf die Rohdaten zu. Für das Ausdünnen alter Rohdaten nutzt du TTL-Regeln direkt in der Tabelle.
ClickHouse ist eine analytische Datenbank, keine Transaktions-DB. Wenn du einzelne Zeilen häufig gezielt änderst oder löschst, Fremdschlüssel-Constraints und echte Transaktionen brauchst, gehört das in Postgres. Auch für Stammdaten (Kunden, Anlagen, Verträge) bleibst du besser bei einer klassischen relationalen DB. ClickHouse spielt seine Stärke bei genau einem Muster aus: viel einfügen, selten ändern, riesig auswerten – also bei den Messwerten selbst.
Schreibe in Batches, nicht Zeile für Zeile: sammle Messwerte und füge sie in Blöcken von einigen zehntausend Zeilen ein. Viele winzige Inserts erzeugen viele kleine Datenteile, die ClickHouse erst mühsam zusammenführen muss. Für Live-Datenströme aus Zählern eignet sich eine Puffer-Schicht (etwa Kafka-Anbindung oder Buffer-Tabelle), die den Takt glättet. So bleibt die Schreibrate hoch, ohne die Merge-Prozesse zu überlasten.
→ Vertiefung: Scheinleistung: Warum verbraucht sie mehr Strom?
→ Vertiefung: Was ist Blindleistung? Einfach erklärt (var & cosφ)
→ Vertiefung: Lastspitzen reduzieren: So kappst du teure Peaks