Skip to main content

Setting Data Retention Period (TTL)

This setting determines how long collected data is retained. It is also the value that determines disk capacity — see this along with Data Storage Capacity Planning.

The Single Source of Truth is One Property File​

The retention period is determined by the storage.*.ttl value in plantpulse-storage.properties. The unit is «days» (not seconds).

Cannot be changed via environment variables

There is no value to set the retention period in the PP_* environment variables. Only connection information and passwords in the same file are exposed as environment variables; all TTL values are written directly in the file.

Default Values​

Based on the September 2026 shipment. These values were verified directly from files within the container.

PropertyDefault (Days)Targeted Data
storage.tag.point.ttl3650 (10 years)Raw tag collection values
storage.tag.point.map.ttl1Tag maps
storage.tag.point.sampling.ttl93Sampling tables (10s to 1h)
storage.tag.point.snapshot.ttl93Snapshots
storage.tag.point.aggregation.ttl93Aggregation tables (1m to 1h)
storage.tag.point.archive.ttl365Archives — originals moving to object storage
storage.tag.blob.ttl93Tag blobs
storage.blob.object.ttl31Blob objects
storage.asset.data.ttl10Equipment data
storage.asset.data.sampling.ttl31Equipment data sampling
storage.asset.alarm.timeline.ttl30Alarm timelines
storage.asset.alarm.timeline.rollup.ttl90Alarm timeline rollups
storage.asset.standard.ttl0 = InfiniteEquipment standard data
The 62-day value previously in documents is incorrect

Older materials mentioned «Default TTL 5356800 seconds = 62 days». It is now 3650 days. The 62-day value originated from an old schema repository that explicitly stated it was not the SSOT.

Counters and «Current State» series tables have no expiration (default_time_to_live = 0) because they lack a time axis and are not subjects for expiration.

How It Is Applied​

  1. The server reads the properties once during boot.
  2. For tables where values are «specified», it creates ALTER TABLE … WITH default_time_to_live = <일 × 86400> statements.
  3. It reads the current schema and executes only the differences.

Therefore, operators do not need to manually enter ALTER via cqlsh. Conversely, if a key is removed from the properties, that table is skipped — removing it does not result in infinite retention.

Already stored data will not change

The default_time_to_live of Aster TSDB is embedded into each value at the time of writing. Therefore, even if settings are changed, it applies only to data arriving after the change. The expiration point for data accumulated up until yesterday remains the same.

This is why «increasing is safe, but decreasing is risky».

How to Change​

🔴 In container installations, this file cannot currently be modified from the host. plantpulse-storage.properties exists only inside the image (…/webapps/ROOT/WEB-INF/classes/), and while an external configuration directory (…/plantpulse-server/config/) exists, it is not bind-mounted to the host (measured 2026-09-08 — only log, offload, and security volumes are mounted).

If modified inside the container, the changes will disappear as soon as the container is replaced. Reinstallation or upgrades will revert the settings.

If the retention period must be changed, proceed with the product team. The values themselves are changed as follows.

# 외부 설정 디렉터리의 파일을 고친다 (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

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

Changes will not take effect without a restart. There is no zero-downtime application path or screen to change TTL in the management console.

Verifying Application​

The applied values are printed as a table in the boot log. Look for the DATA STORAGE TTL banner — it displays the property name, retention period, and where the value originated (from the file or a code default).

Actual values applied to the schema can be viewed as follows.

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

Since the output is in seconds, divide by 86400 to get the number of days. 0 indicates infinite retention.

Pitfalls​

Decreasing the value will cause data to disappear. The expiration of newly arriving data will be moved forward. Ensure you have a backup before decreasing.

Data is not deleted «immediately» after decreasing. Expired values first become tombstones, and only after gc_grace_seconds does compaction actually reclaim the disk. Therefore, disk usage will not decrease immediately on the day the setting is reduced.

Increasing the value increases disk usage linearly. Moving from 62 days to 3650 days increases the retention volume by approximately 59 times. Re-calculate capacity planning when increasing the retention period.

TTL = 0 (Infinite) is not just a capacity issue. Without an expiration criterion, compaction loses the means to clean up old segments. Fragments accumulate, and read performance degrades.

Setting the TTL too short may cause the server to reject ALTER. This is because there is a required relationship between the compaction window setting and the retention period. In such cases, the table silently maintains the setting it received during creation, so you must check the log warnings.

CEP Dead Letter​

Events that CEP fails to process remain in the Valkey stream PP:CEP-DEAD-LETTER:{샤드}. This is temporary storage for investigation and is determined by plantpulse-cep.properties rather than TTL settings.

PropertyDefaultMeaning
cep.stream.max_deliveries3Only events not processed after three deliveries go to the dead letter
cep.stream.dead_letter.retention_ms86400000 (24 hours)Cuts data older than this whenever writing
cep.stream.dead_letter.max_bytes268435456 (256 MiB)Total aggregate. If the quotient divided by the number of shards is exceeded, the oldest data is cut first

If investigation is required, it must be done within 24 hours.

Object Storage Side​

Data exceeding the TTL does not simply disappear. Data from archive tables (storage.tag.point.archive.ttl, default 365 days) is moved to Iceberg tables in object storage for long-term retention.

ItemValue
Iceberg Snapshot RetentionDefault 3 days (SNAPSHOT_RETENTION_DAYS)
Warehouse Audit Table31 days
Capacity Usage History1095 days (3 years)
Snapshot retention is not data retention

Iceberg snapshot expiration does not delete data; rather, it cuts the ability to return to a past point in time (time travel · rollback). Once the default 3 days pass, you cannot roll back to a point prior to that.

Iceberg tables themselves have no automatic expiration mechanism. They must be explicitly deleted to be removed.