1. 时序数据库概述
1.1 时序数据特点
时序数据（Time Series Data）是按时间顺序记录的系统、设备或业务指标变化的数据集合。在厂务场景中，温度、湿度、电压、流量、振动频率等传感器数据都是典型的时序数据。理解时序数据的特点，是正确选型与部署数据库的前提。
核心特征：时序数据具有“写多读少、按时间追加、极少更新、按时间窗口聚合”的天然属性，与传统 OLTP 数据有本质区别。
| 特征 | 说明 | 厂务示例 |
|---|---|---|
| 时间戳唯一性 | 每条数据都带有精确的时间标记，时间戳是主键的一部分 | 2025-06-10T14:30:00Z 的空调回风温度 |
| 结构化写多 | 写入频率高，每秒可能数万点，但单条数据量小 | PLC 每 100ms 上报一次电流值 |
| 不可变性 | 数据一旦写入，极少修改或删除 | 历史温度记录不会回退修改 |
| 时间范围查询 | 查询通常按时间窗口（最近1小时、昨天、上周）进行 | 查询今日 8:00-9:00 的洁净室压差 |
| 聚合优先 | 用户更关心平均值、最大值、百分位数等聚合结果 | 过去24小时的平均湿度 |
下图展示了时序数据在厂务监控系统中的典型写入与查询流程：
1.2 InfluxDB 简介
InfluxDB 是由 InfluxData 公司开发的开源时序数据库，专为处理大规模时序数据而设计。它使用 Go 语言编写，提供类 SQL 的查询语言 Flux（以及 InfluxQL），支持高写入吞吐、自动数据保留策略（Retention Policy, RP）和连续查询（Continuous Query, CQ），非常适合厂务监控、IoT 设备数据采集、运维监控等场景。
厂务选型提示：InfluxDB 对“写多读少、按时间窗口聚合”的场景做了深度优化。在厂务系统中，通常使用 InfluxDB 存储原始传感器数据，再通过保留策略自动清理过期数据，避免磁盘空间爆炸。
InfluxDB 核心概念：
- Measurement：类似传统数据库的表，用于描述一类数据（如 temperature、humidity）。
- Tag：带索引的元数据，用于快速过滤（如 sensor_id、location）。
- Field：实际存储的数值（如 value=25.3）。
- Timestamp：每条记录的时间戳，精度可达纳秒。
- Retention Policy (RP)：定义数据保留时长和副本数，自动删除过期数据。
- Continuous Query (CQ)：自动对原始数据做降采样聚合，存入新表。
下图展示了 InfluxDB 的数据模型结构：
1.3 InfluxDB vs 传统数据库
传统关系型数据库（如 MySQL、PostgreSQL）在设计上针对事务处理（OLTP）做了大量优化，但在处理海量时序数据时存在明显短板。InfluxDB 则从底层存储引擎到查询语言都围绕时序场景重新设计。下表从多个维度进行对比：
| 对比维度 | InfluxDB | 传统数据库（MySQL/PostgreSQL） |
|---|---|---|
| 数据模型 | Measurement + Tag + Field + Timestamp | 表 + 行 + 列 + 主键 |
| 写入优化 | LSM-Tree 存储引擎，批量写入，高吞吐 | B+Tree 存储引擎，事务开销大，写入瓶颈明显 |
| 数据保留 | 原生 Retention Policy，自动删除过期数据 | 需手动编写定时任务 DELETE，性能差 |
| 聚合查询 | 内置 downsampling、continuous query，窗口聚合极快 | GROUP BY + 聚合函数，大表性能急剧下降 |
| 存储压缩 | 列式压缩，针对时间戳和浮点数优化，压缩比 5:1~15:1 | 行式存储，压缩比低，通常 2:1~3:1 |
| 查询语言 | Flux / InfluxQL，专为时间范围、降采样设计 | SQL，缺乏时间窗口原生语法 |
| 典型场景 | IoT 监控、厂务数据、APM、日志指标 | 订单系统、用户管理、内容管理 |
选型避坑：不要试图用传统数据库存储高频时序数据。某厂务项目曾用 MySQL 存储 10 万点/秒的传感器数据，3 个月后单表超过 50 亿行，查询响应时间从毫秒级退化到分钟级，最终不得不迁移至 InfluxDB。时序场景请使用时序数据库。
下图从架构层面对比 InfluxDB 与传统数据库的存储与查询路径差异：