定义
Time Series DB（时序数据库）专为时间序列数据设计，存储设备 Telemetry 遥测数据。支持高并发写入、按时间范围聚合查询，为 Device Monitoring、Predictive Maintenance 提供数据基础。
核心特性与选型
时序数据库针对「时间戳 + 指标值」结构优化，支持高吞吐写入、按时间窗口的降采样与聚合（如 avg、max、percentile）。常见选型包括 InfluxDB、TimescaleDB、OpenTSDB、Prometheus 等。设备管理平台需根据设备规模、采样频率、保留策略及查询模式选型；大规模 IoT 场景通常采用列式存储与压缩，支持冷热数据分层，满足长期存储与实时查询的平衡。
与 DMP 的数据流
设备遥测经 MQTT 或协议网关接入后，由规则引擎或数据管道写入时序库。数据模型通常以设备 ID、物模型属性为 Tag，时间戳与数值为时序点。平台提供聚合查询 API 供 Device Monitoring 监控大屏、Report Analytics 报表及 Grafana 等可视化工具消费；RUL 剩余寿命预测、异常检测等算法也依赖时序数据作为输入。
应用场景
时序数据库支撑能源监控、工业传感器、智能表计、车联网等场景的遥测存储与分析。高并发写入能力满足百万级设备同时上报；降采样与保留策略控制存储成本；按设备、按时间的多维查询支持故障回溯与趋势分析。是设备管理平台数据底座的核心组件。
时序点由标签、时间戳和值构成
时序库里的一个点，是在某条序列上、某个时刻的一个值。序列由少量稳定标签区分，例如设备标识和物模型属性。时间戳用采样时间，值按模型规定的类型存放。平台若把收到时间当成唯一时间，补传数据会挤在恢复连接的时刻，按时间回溯故障时会对错位置。同一个序列、同一个时间戳只应有一个值；冲突要显式处理，不能依赖库的默认覆盖而不留痕迹。
写入适合追加。修改历史、频繁删除中间点，都和这类库的组织方式相反。需要更正时，追加一个更正点并保留原值，或按明确的保留规则整段重建。查询侧常见的是按时间窗取原始点，或按固定窗口做均值、最大、分位。窗口聚合要写明空窗怎么处理：没有点就不要输出零。降采样生成的新序列应换一个保留期限，并注明它不能还原尖峰。规则若要看尖峰，应读原始序列或足够细的降采样，而不是读为了省空间留下的小时均值。
高基数标签会先于磁盘成为瓶颈
标签的组合数就是序列的数量级。设备标识乘以属性数，已经是预期内的规模；再把每一次请求的追踪号、操作者姓名、自由文本备注放进标签，序列数会随事件次数增长，索引和内存会先于磁盘满。使用条件因此是：标签只放会反复出现、用来过滤的维度，一次性的信息放进值、日志或另外的档案库。
查询要带时间范围和至少设备或属性一类选择，避免在所有序列上做无边界扫描。批量导出应走专门的任务，限制并发，而不是让看板的每一次打开都扫全表。保留期限按属性区分：高频振动不必和日电量保存同样久。过期删除应是连续的策略，而不是磁盘告急时手工停写。停写会让规则引擎在无数据时沉默，看起来像现场恢复了正常。
把设备档案字段全部做成标签
站点名、责任人、合同编号、安装地址经常被一次写进每条遥测的标签，方便“直接按地址查曲线”。这些字段会变。责任人一改，同一台设备的新旧点分属不同序列，曲线在变更日断开，按新人过滤又看不到变更前的数据。档案字段应留在设备资料里，查询时先解析出设备标识列表，再按时序过滤。偶尔需要的历史归属，用变更记录在查询层还原，而不是把当时的姓名固化进每一个点。
另一个错误是为每个统计口径复制一整份原始点。在线率、日报、告警回放如果各存一份明细，写入量成倍增加，口径还容易不一致。明细保留一份，各种口径在查询或汇总任务里计算，并保存汇总结果而不是复制明细。时钟错误的点若直接参与聚合，会把远未来或远过去的窗污染。入库前把明显超出合理范围的时间戳标出并隔离，不要为了“不丢数据”而让它们进入默认查询。隔离区仍可人工查看，但默认曲线、规则和报表不读它。
上线新的标签前先估计序列数量：设备数乘以属性数乘以这个标签的可能取值数。估计超出内存预算就改放到档案或值里。定期看最久没有新点的序列和占用最多序列的标签，找出已经拆分过度的维度。修复办法是停止写入该标签并在查询层做转换，而不是立刻删除历史，删除会让正在跑的回溯失去样本。容量告警应早于写入失败，告警后优先缩短高频属性的保留或降低其降采样前的保留份数，并记录这次取舍影响了哪些查询。