Konfiguration der Datenaufbewahrungsdauer (TTL)

Dies ist die Einstellung, die festlegt, wie lange erfasste Daten aufbewahrt werden. Da dies auch die Festplattenauslastung bestimmt, lesen Sie dies bitte zusammen mit der Kapazitätsplanung für die Datenspeicherung.

Die einzige Referenz ist eine Eigenschaftsdatei

Die Aufbewahrungsdauer wird durch den Wert von storage.*.ttl in plantpulse-storage.properties festgelegt. Die Einheit ist «Tage» (nicht Sekunden).

Kann nicht über Umgebungsvariablen geändert werden

Es gibt keine Werte in den Umgebungsvariablen von PP_*, die die Aufbewahrungsdauer festlegen. In derselben Datei sind nur Verbindungsinformationen und Passwörter über Umgebungsvariablen zugänglich; alle TTL-Werte sind direkt in der Datei eingetragen.

Standardwerte

Dies gilt für die Auslieferung Stand 2026-09. Es sind Werte, die direkt aus den Dateien im Container geprüft wurden.

Eigenschaft	Standardwert (Tage)	Betroffene Daten
`storage.tag.point.ttl`	3650 (10 Jahre)	Rohwerte der Tag-Erfassung
`storage.tag.point.map.ttl`	1	Tag-Map
`storage.tag.point.sampling.ttl`	93	Sampling-Tabelle (10 Sek. ~ 1 Std.)
`storage.tag.point.snapshot.ttl`	93	Snapshot
`storage.tag.point.aggregation.ttl`	93	Aggregationstabelle (1 Min. ~ 1 Std.)
`storage.tag.point.archive.ttl`	365	Archiv — Originale zum Objektpeicher
`storage.tag.blob.ttl`	93	Tag-Blob
`storage.blob.object.ttl`	31	Blob-Objekt
`storage.asset.data.ttl`	10	Anlagendaten
`storage.asset.data.sampling.ttl`	31	Sampling der Anlagendaten
`storage.asset.alarm.timeline.ttl`	30	Alarm-Timeline
`storage.asset.alarm.timeline.rollup.ttl`	90	Alarm-Timeline Rollup
`storage.asset.standard.ttl`	0 = Unendlich	Standarddaten der Anlage

Die in Dokumenten erwähnten 62 Tage sind nicht korrekt

In älteren Unterlagen ist vermerkt: «Standard-TTL 5356800 Sekunden = 62 Tage». Aktuell sind es 3650 Tage. Der Wert von 62 Tagen stammt aus einem alten Schema-Repository, das explizit nicht als SSOT (Single Source of Truth) gekennzeichnet war.

Zähler und Tabellen der Kategorie «Aktueller Status» haben kein Ablaufdatum (default_time_to_live = 0), da sie keine Zeitachse besitzen und somit nicht ablaufen können.

Funktionsweise der Anwendung

Der Server liest die Eigenschaften einmalig beim Booten.
Er erstellt nur für die «explizit genannten» Tabellen eine ALTER TABLE … WITH default_time_to_live = <일 × 86400>-Anweisung.
Er liest das aktuelle Schema und führt die Anweisung nur für andere Tabellen aus.

Daher muss der Betreiber ALTER nicht manuell via cqlsh eingeben. Umgekehrt gilt: Wenn ein Schlüssel aus den Eigenschaften gelöscht wird, wird diese Tabelle übersprungen — das Löschen führt also nicht zu einer unendlichen Aufbewahrung.

Bereits gespeicherte Daten werden nicht geändert

Die default_time_to_live von Aster TSDB werden beim Schreiben in den jeweiligen Wert eingebettet. Daher gilt eine Änderung der Einstellungen erst für die danach eingehenden Daten. Der Ablaufzeitpunkt für Daten, die bis gestern gespeichert wurden, bleibt unverändert.

Dies ist der Grund, warum «das Erhöhen sicher, das Verringern jedoch riskant» ist.

Änderungsmethode

🔴 In der Container-Installation kann diese Datei derzeit nicht auf dem Host bearbeitet werden. plantpulse-storage.properties existiert nur innerhalb des Images (…/webapps/ROOT/WEB-INF/classes/). Ein externes Verzeichnis für Konfigurationen (…/plantpulse-server/config/) ist zwar vorhanden, wird aber nicht als Bind-Mount auf den Host gemappt (Messung vom 2026-09-08 — Mounts existieren nur für Log-, Offload- und Security-Volumes).

Änderungen innerhalb des Containers gehen beim Ersetzen des Containers verloren. Eine Neuinstallation oder ein Upgrade führt zur ursprünglichen Konfiguration zurück.

Wenn die Aufbewahrungsdauer geändert werden muss, führen Sie dies bitte gemeinsam mit dem Produktteam durch. Die Werte selbst werden wie folgt geändert:

# 외부 설정 디렉터리의 파일을 고친다 (WAR 안의 사본이 아니라 이쪽)
cp plantpulse-storage.properties plantpulse-storage.properties.$(date +%F)
sed -i 's/^storage.tag.point.ttl=.*/storage.tag.point.ttl=1825/' plantpulse-storage.properties

# 서버를 재시작한다 — 프로퍼티는 부팅 때 한 번만 읽는다

Ohne Neustart werden die Änderungen nicht übernommen. Es gibt weder einen Pfad zur unterbrechungsfreien Anwendung noch eine Maske in der Verwaltungskonsole zum Ändern der TTL.

Überprüfung der Anwendung

Die angewendeten Werte werden beim Booten als Tabelle in den Logdateien ausgegeben. Suchen Sie nach dem DATA STORAGE TTL-Banner — dort werden der Name der Eigenschaft, die Aufbewahrungsdauer und die Herkunft des Wertes (Datei oder Standardwert im Code) aufgeführt.

Die im Schema tatsächlich hinterlegten Werte lassen sich wie folgt einsehen:

SELECT table_name, default_time_to_live, gc_grace_seconds
FROM system_schema.tables
WHERE keyspace_name = 'pp';

Da die Ausgabe in Sekunden erfolgt, ergibt die Division durch 86400 die Anzahl der Tage. 0 bedeutet unendliche Aufbewahrung.

Fallstricke

Bei einer Verringerung verschwinden Daten. Der Ablaufzeitpunkt für neu eingehende Daten wird entsprechend vorgezogen. Sichern Sie vor einer Verringerung ein Backup.

Daten werden bei einer Verringerung nicht «sofort» gelöscht. Abgelaufene Werte werden zunächst zu Tombstones; erst nach Ablauf von gc_grace_seconds gibt die Compaction den Speicherplatz auf der Festplatte tatsächlich frei. Daher sinkt der Festplattenverbrauch nicht unmittelbar am Tag der Einstellungsänderung.

Bei einer Erhöhung steigt der Festplattenbedarf linear an. Eine Änderung von 62 Tagen auf 3650 Tage entspricht einer etwa 59-fachen Speichermenge. Führen Sie bei einer Erhöhung der Aufbewahrungsdauer die Kapazitätsplanung erneut durch.

TTL = 0 (Unendlich) ist nicht nur ein Problem der Kapazität. Ohne Ablaufkriterium verliert die Compaction das Mittel, alte Bereiche zu bereinigen. Dies führt zu einer Anhäufung von Fragmenten und verlangsamt die Lesezugriffe.

Wenn die TTL zu kurz gesetzt wird, kann der Server ALTER ablehnen. Dies liegt an einer notwendigen Beziehung zwischen der Compaction-Window-Einstellung und der Aufbewahrungsdauer. In diesem Fall behält die Tabelle die ursprünglichen Einstellungen bei; prüfen Sie die Warnmeldungen im Log.

CEP Dead Letter

Events, die vom CEP nicht verarbeitet werden konnten, bleiben im Valkey-Stream PP:CEP-DEAD-LETTER:{샤드}. Dies dient der temporären Aufbewahrung zu Untersuchungszwecken und wird nicht über die TTL-Einstellungen, sondern über plantpulse-cep.properties geregelt.

Eigenschaft	Standardwert	Bedeutung
`cep.stream.max_deliveries`	3	Nur Events, die nach drei Zustellversuchen nicht verarbeitet wurden, gehen in den Dead Letter
`cep.stream.dead_letter.retention_ms`	86400000 (24 Std.)	Bei jedem Schreibvorgang werden ältere Einträge gekappt
`cep.stream.dead_letter.max_bytes`	268435456 (256 MiB)	Gesamtlimit. Wenn der Wert pro Shard überschritten wird, werden die ältesten Einträge gelöscht

Für eine Untersuchung müssen die Daten innerhalb von 24 Stunden geprüft werden.

Objektpeicher

Daten, deren TTL abgelaufen ist, verschwinden nicht einfach. Daten der Archivtabelle (storage.tag.point.archive.ttl, Standard 365 Tage) werden in Iceberg-Tabellen im Objektpeicher zur Langzeitarchivierung verschoben.

Punkt	Wert
Iceberg-Snapshot-Aufbewahrung	Standard 3 Tage (`SNAPSHOT_RETENTION_DAYS`)
Warehouse-Audit-Tabelle	31 Tage
Verlauf der Kapazitätsauslastung	1095 Tage (3 Jahre)

Snapshot-Aufbewahrung ist keine Datenaufbewahrung

Das Ablaufdatum eines Iceberg-Snapshots löscht keine Daten, sondern beendet die Fähigkeit, zu einem früheren Zeitpunkt zurückzukehren (Time Travel · Rollback). Nach Ablauf der standardmäßigen 3 Tage ist ein Zurücksetzen auf einen früheren Zeitpunkt nicht mehr möglich.

Iceberg-Tabellen selbst verfügen über keinen automatischen Ablaufmechanismus. Zum Löschen müssen diese explizit entfernt werden.

Die einzige Referenz ist eine Eigenschaftsdatei​

Standardwerte​

Funktionsweise der Anwendung​

Änderungsmethode​

Überprüfung der Anwendung​

Fallstricke​

CEP Dead Letter​

Objektpeicher​

Verwandte Dokumente​