数据保存周期 (TTL) 设置

此设置用于决定采集数据的保存时长。该值同时决定了磁盘容量 —— 请结合数据存储容量估算一起查阅。

唯一标准是属性文件

保存周期由 plantpulse-storage.properties 的 storage.*.ttl 值决定。 单位为 «天»（而非秒）。

无法通过环境变量修改

PP_* 环境变量中不存在决定保存周期的值。在同一文件中，仅连接信息和密码可以通过环境变量开放，TTL 值必须全部直接写入文件。

默认值

以下为 2026-09 出货标准。该值为直接从容器内文件确认的值。

属性	默认值(天)	涉及数据
`storage.tag.point.ttl`	3650 (10年)	标签原始采集值
`storage.tag.point.map.ttl`	1	标签映射
`storage.tag.point.sampling.ttl`	93	采样表 (10秒~1小时)
`storage.tag.point.snapshot.ttl`	93	快照
`storage.tag.point.aggregation.ttl`	93	聚合表 (1分钟~1小时)
`storage.tag.point.archive.ttl`	365	归档 — 迁移至对象存储的源数据
`storage.tag.blob.ttl`	93	标签 blob
`storage.blob.object.ttl`	31	blob 对象
`storage.asset.data.ttl`	10	设备数据
`storage.asset.data.sampling.ttl`	31	设备数据采样
`storage.asset.alarm.timeline.ttl`	30	报警时间轴
`storage.asset.alarm.timeline.rollup.ttl`	90	报警时间轴汇总
`storage.asset.standard.ttl`	0 = 无限	设备标准数据

文档中长期存在的 62 天并非事实

在旧资料中曾记载 «默认 TTL 5356800秒 = 62天」。当前为 3650 天。 62 天这一数值源自一个已明确表示非 SSOT 的旧 Schema 存储库。

计数器和 «当前状态» 系列表没有过期时间 (default_time_to_live = 0)，因为它们没有时间轴，不属于需要过期的对象。

如何生效

服务器在启动时读取一次属性文件。
仅针对«已指定»的表创建 ALTER TABLE … WITH default_time_to_live = <일 × 86400> 语句。
读取当前 Schema 并仅执行其他项。

因此，运行人员无需通过 cqlsh 直接输入 ALTER。相反，如果从属性文件中删除键，该表将被跳过 —— 删除键并不会使其变为无限保存。

已存储的数据不会改变

Aster TSDB 的 default_time_to_live 在写入时嵌入到每个值中。因此，即使修改了设置，也仅适用于之后进入的数据。截至昨日积累的数据过期时间保持不变。

这就是为何 «增加周期是安全的，而减少周期具有风险» 的原因。

修改方法

🔴 在容器安装版本中，目前无法在宿主机上修改此文件。 plantpulse-storage.properties 仅存在于镜像内 (…/webapps/ROOT/WEB-INF/classes/)，虽然存在外部配置目录 (…/plantpulse-server/config/)，但未通过 Bind Mount 挂载到宿主机 (2026-09-08 实测 — 挂载仅限于日志、Offload、安全卷集)。

如果在容器内修改，在更换容器的瞬间将消失。 重新安装或升级即意味着还原。

如需更改保存周期，请与产品团队共同进行。数值修改方式如下：

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

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

不重启无法生效。 目前没有无停机生效路径，也没有在管理控制台中更改 TTL 的界面。

确认是否生效

启动日志中会以表格形式打印应用值。请查找 DATA STORAGE TTL 横幅 — 其中会显示属性名称、保存周期以及该值的来源（文件或代码默认值）。

查看 Schema 中实际生效的值如下：

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

由于显示为秒，除以 86400 即可得出天数。0 为无限保存。

注意事项

缩短周期会导致数据丢失。 新进入数据的过期时间将相应提前。在缩短周期前，请确保执行备份。

缩短周期后数据不会 «立即» 删除。 过期值首先变为 tombstone，在 gc_grace_seconds 之后，compaction 才会实际回收磁盘空间。因此，在缩短设置当天，磁盘占用不会立即下降。

延长周期将导致磁盘线性增长。 从 62 天增加到 3650 天，保存量约增加 59 倍。延长保存周期时，请重新进行容量估算。

TTL = 0(无限)不仅是容量问题。 如果没有过期标准，compaction 将失去整理旧数据段的手段，导致碎片堆积，读取速度下降。

TTL 设置过短可能会导致服务器拒绝 ALTER。 这是因为 compaction 窗口设置与保存周期之间必须维持一定的关系。在这种情况下，该表将保持创建时的设置，因此必须检查日志中的警告。

CEP 死信队列

CEP 无法处理的事件将保留在 Valkey 流 PP:CEP-DEAD-LETTER:{샤드} 中。这是用于调查的临时存储，不通过 TTL 设置，而是通过 plantpulse-cep.properties 决定。

属性	默认值	含义
`cep.stream.max_deliveries`	3	仅在尝试投递三次仍未处理的事件才进入死信队列
`cep.stream.dead_letter.retention_ms`	86400000 (24小时)	每次写入时截断早于此时间的数据
`cep.stream.dead_letter.max_bytes`	268435456 (256 MiB)	总计。超过分片数除后的商时，从最旧数据开始截断

如需调查，必须在 24 小时内 查看。

对象存储端

超过 TTL 的数据并非全部消失。归档表 (storage.tag.point.archive.ttl, 默认 365 天) 的数据将被迁移至对象存储的 Iceberg 表中进行长期保存。

项目	值
Iceberg 快照保留	默认 3 天 (`SNAPSHOT_RETENTION_DAYS`)
仓库审计表	31 天
容量使用量历史	1095 天 (3 年)

快照保留不等于数据保存

Iceberg 快照过期并非删除数据，而是切断返回到过去时间点（time travel · rollback）的能力。默认 3 天过后，将无法回滚到该时间点之前。

Iceberg 表本身没有自动过期机制。如需删除，必须显式执行删除操作。

唯一标准是属性文件​

默认值​

如何生效​

修改方法​

确认是否生效​

注意事项​

CEP 死信队列​

对象存储端​

相关文档​