物联网时序数据保留周期没有统一答案，但行业共识是热数据保留7-30天、温数据保留3-12个月、冷数据按合规要求保留1年以上，这是存储成本与查询体验的最佳平衡点。保留太久，存储成本拖垮预算；删得太早，业务复盘和故障追溯又无从下手，下面把决策逻辑和实操路径拆开讲。
物联网时序数据保留多久合适
先按数据温度分层，再谈保留周期
时序数据的价值随采集时间快速衰减,一台设备昨天产生的运行数据，今天可能还在排查故障时用得上；三个月前的数据，基本只在做趋势分析和报表时被翻出来，虽然你的项目不一定见过真实的温度分层案例，但把数据按“热、温、冷”三档规划保留周期，是几乎所有物联网平台的默认做法。
- 热数据（7-30天）：设备实时状态、告警触发前后的原始采样值，要求毫秒级查询响应，放在SSD或内存缓存里。
- 温数据（3-12个月）：小时级聚合结果、日报周报数据，查询频率明显降低，放SATA盘或标准云盘即可。
- 冷数据（1年以上甚至更久）：用于年度复盘、合规审计、设备生命周期追溯，直接丢对象存储或归档存储，几乎不参与实时查询。
数据特性决定保留策略
不是所有测点都值得一视同仁地保存,以光伏电站为例，逆变器交流侧的电压、电流、功率数据每秒采集一次，一天就是86400条记录；但组件温度每5分钟采一次，一天才288条，前者在故障诊断时价值巨大，后者用聚合值就能覆盖绝大多数分析场景，合理做法是：
- 高频采集的关键工况参数：原始数据保留30天，之后按分钟聚合保留1年。
- 低频环境参数：原始数据直接保留1-3年，体积完全可控。
- 告警事件和操作日志：按合规要求保留2年以上，优先保证完整性。
物联网数据存储成本怎么算
成本不只是硬盘容量
多数人低估了时序数据的存储开销,同样的数据量，时序数据库的物理占用比关系型数据库小得多，但如果你只盯着磁盘单价，忽略计算、带宽和维护成本，预算照样失控，真实账单通常由四块组成：
- 存储介质成本：按容量和性能计费，SSD普遍是对象存储的8-15倍单价。
- 计算资源成本：数据写入时的压缩、降采样、查询时的聚合计算，都消耗CPU，这部分在自建集群时尤其明显。
- 网络带宽成本：设备端采集通道和云端写入通道的流量费用，在边缘网关方案里往往被忽略。
- 运维人力成本：定期清理过期数据、处理存储节点故障、调整保留策略的工单，看似零散实则累积。
一张表看清不同方案的容量账
以某工厂5000个测点、每秒1条采集频率、原始记录约1.3亿条/月的规模举例，存储用量的差异很直观：
| 方案 | 在线热存 | 冷归档 | 月度存储成本量级 |
|---|---|---|---|
| 全量保留原始数据2年 | 约25TB | 不做归档 | 较高 |
| 热存30天+降采样保留 | 约3TB | 约40TB（对象存储） | 中等 |
| 仅保留聚合数据 | 约0.4TB | 视合规要求 | 较低 |
统计显示，采用“热存+降采样+冷归档”三段式方案后，多数项目能节省60%-80%的总存储成本，这个数字来自多家云厂商公开的客户实践，具体比例取决于测点规模和数据波动程度。
时序数据库压缩和降采样技术选型
压缩比对比：选对引擎能省一半空间
时序数据的压缩率主要取决于编码算法和数据类型,行业共识是主流时序数据库的压缩比在10:1到30:1之间，但具体数值差异很大，纯整数计数器（如电表读数）压缩率最高，浮点型传感器数据（如温度、振动）压缩率偏低，乱序写入会进一步恶化压缩效果。
- InfluxDB：采用gorilla压缩变体，对浮点数据的压缩率约为15:1，胜在生态成熟，但写入和压缩的CPU开销偏高。
- TDengine：针对物联网场景做了列式存储和二阶差分编码，多数场景压缩比可达20:1以上，且写入吞吐更高。
- TimescaleDB：基于PostgreSQL的压缩算法，在关系型查询上更友好，但对超高基数（如设备ID非常多）的时序场景支持偏弱。
如果你在建新项目,建议直接用这两个典型方案做对比测试：用同样的数据源分别写入InfluxDB和TDengine，跑48小时后再比较物理文件大小，这个办法看的是压缩算法和索引策略的综合结果，比看任何宣传指标都准。
降采样是省钱的核心手段
压缩解决的是“存多少”的问题，降采样解决的是“存多细”的问题，保留周期越长，粒度越粗，一个典型的分层配置长这样：
- 原始数据（1秒粒度）：保留7天，用于告警和实时监控。
- 分钟级聚合（1分钟均值/最大值/最小值）：保留6个月，用于日常运维报表。
- 小时级聚合（1小时均值）：保留3年，用于年度趋势分析和容量规划。
冷热分层存储架构实操
TDengine多级存储设置步骤
TDengine从2.x版本开始支持多级存储配置，把热数据放SSD、冷数据放HDD或对象存储，具体操作路径：
-- 创建存储级，绑定不同挂载目录 CREATE STORAGE LEVEL 1 SSD '/mnt/ssd_data'; CREATE STORAGE LEVEL 2 HDD '/mnt/hdd_data'; CREATE STORAGE LEVEL 3 S3 'bucket:/mnt/archive'; -- 为数据库设置多级存储参数 CREATE DATABASE factory_data STORAGE LEVELS 3 DURATION 3650d KEEP 3650d;
所有数据先写第一级,超过设定时间后自动迁移到下一级，对查询完全透明。实际运维中，热数据迁移到冷存储后，查询延迟会从毫秒级上升到秒级，但这部分数据本来就用于低频分析，体验影响有限。
InfluxDB的保留策略和连续查询
InfluxDB的经典做法是保留策略（RP）+连续查询（CQ）组合，先建RP控制数据过期时间，再用CQ自动做降采样并写入新的measurement。
-- 保留策略：原始数据保留30天
CREATE RETENTION POLICY "raw_30d" ON "iot_db" DURATION 30d REPLICATION 1 DEFAULT;
-- 连续查询：每30分钟计算一次1分钟均值，存入新表
CREATE CONTINUOUS QUERY "cq_1m_avg" ON "iot_db"
BEGIN
SELECT mean(value) INTO "auto_1m" FROM "raw" GROUP BY time(1m),
END;这个方案的优点是灵活,缺点是CQ任务多了以后会占用额外查询资源，如果你对实时性和资源占用都比较敏感，建议优先评估支持原生降采样功能的数据库，把聚合逻辑下沉到存储引擎内部，避免脱离监控平台后逻辑失效。
时序数据库选型参考：InfluxDB与TDengine对比
自建vs托管：先看团队运维能力
自建集群对你的收益很直观：数据不出内网，安全可控，适合对数据主权要求严格的场景，但时序数据库的运维深度比MySQL复杂得多，节点扩展、数据均衡、备份恢复都是硬骨头，托管服务帮你解决这些问题，代价是单GB单价更高。
业内专家指出，200万点规模以内的项目，托管时序数据库的总拥有成本反而更低；超过这个量级，自建优势才开始显现。
在实际项目中,深圳某工业物联网平台的选型思路值得参考，他们对三种方案做了对比：InfluxDB集群版、TDengine集群版、某云厂商时序数据库托管服务，结论是：InfluxDB上手快但节点间数据分发策略偏简单，写入瓶颈出现后扩容成本高；TDengine对超大测点规模的支撑更平稳，自带的超级表和子表模型贴合设备维度建模，但在复杂分析查询（跨多表关联）上不如InfluxDB灵活。
基数和频率是选型第一指标
时序数据库的选型判断依据,不是品牌知名度，而是三点：
- 数据基数：设备数量乘以每个设备的测点数量，基数超过一亿就要特别关注索引内存占用。
- 写入频率：每秒写入点数（Points/s）决定了数据库的写入引擎能否撑住，峰值往往是均值的5倍以上。
- 查询模式：频繁做跨设备聚合分析，还是持续做单设备时间范围查询？前者要选分布式聚合能力强的，后者对单机性能要求高。
常见问题解答
物联网时序数据保留周期设多少个月才合理？
没有标准答案,但可以参考两个门槛：3个月是业务查询的黄金窗口期，1年以下可能影响年度设备趋势分析，超过3年除非有明确的合规诉求，否则性价比极低，如果项目预算紧张，优先保原始数据30天+聚合数据1年。
冷数据是删除还是归档到对象存储？
除非合规要求明确允许删除,否则建议归档，对象存储的单价通常只有热存储的十分之一，以9000元/年为例，它能帮你多放好几十TB的冷数据，归档后即使需要访问，提前几分钟恢复（如从S3 Glacier回取）也是成本可接受的操作，远比数据被物理删除后追悔莫及要好得多。
时序数据库压缩比达到多少算正常？
正常范围是10:1到20:1，超过20:1说明你的数据模式非常适合列式压缩，低于8:1则要检查写入乱序率和数据精度设置，用真实业务数据压测比看产品文档里的极限值可靠得多，压缩比算错，后续存储容量规划全都会跟着偏差。