时序数据怎么存：写入放大、降采样与保留策略

一千台设备每十秒上报一次，一天就是八百多万条记录。这个量级本身不算大，问题出在它每天都会增加同样多，而且查询模式高度集中在「某台设备最近一段时间的曲线」和「某个指标的跨设备聚合」上 —— 这两类查询在通用关系库上会随数据量增长迅速变慢。

关系库的瓶颈在哪

主要是索引维护。按时间与设备建复合索引后，每次插入都要更新索引，写入吞吐随数据量下降。同时，时序数据有非常强的规律性 —— 同一设备相邻时刻的数值通常接近 —— 关系库不会利用这一点，而专用的时序存储会按列压缩，同样的数据占用的空间可能小一个数量级。

这不意味着小项目必须上专用存储。设备数量在几十台、上报间隔在分钟级的项目，关系库配合合理的分区完全够用，而且省掉一套组件的运维成本。判断依据是估算三年后的数据量和查询模式，而不是当前的。这一步属于物联网平台解决方案里的容量规划。

降采样：越早决定越省事

原始数据的价值随时间下降得很快。三年前某一秒的精确温度几乎没人会查，但那一天的平均值、最高值可能还有用。降采样就是按时间粒度逐级聚合：原始数据保留一段时间，之后保留分钟级聚合，再之后保留小时级、天级。

• 聚合时要同时保留平均、最大、最小，只存平均会丢掉尖峰，而尖峰往往正是排障要看的；
• 计数类指标聚合方式不同于测量类，要分别处理，把累计量当瞬时值平均是常见错误；
• 降采样作业本身要能重跑，补传数据到达后对应时间段的聚合值需要重新计算。

保留策略要写进合同

数据保留多久是业务决定，不是技术决定，但它直接决定存储成本。这件事在项目初期谈清楚，比上线一年后因为存储费用上涨再回头讨论要容易得多。需要明确的是各级粒度各保留多久、过期数据是删除还是归档到冷存储、以及客户是否有导出全量原始数据的权利。

一个容易忽略的点：写入的尖峰

平均写入量不是容量规划的依据，峰值才是。大量设备在整点同时上报是很常见的情况 —— 设备固件里写的是「每小时上报一次」，而它们大多在同一时刻开机或对时，于是上报时刻高度集中。解决办法是在设备侧给上报时刻加一个随机偏移，把负载摊平。这个改动在固件里只有几行，但要在设计阶段就想到，上线后再改需要一轮 OTA。存储选型与上报策略最好和硬件选型在同一轮合作流程里确认。