📚 课程目录第2章时序数据库基础

2. 时序数据库基础

时序数据库（Time Series Database，TSDB）是专门为“带时间戳、按时间顺序到达、写多读少”的数据而设计的存储系统。在工业场景中，设备传感器、PLC、DCS、SCADA 等系统会持续产生温度、压力、流量、振动、电流等测点数据，这些数据天然具有时间属性。理解时序数据模型、写入与查询特征，以及它与传统关系数据库的差异，是后续使用 InfluxDB 建模和优化的基础。

一、时序数据模型：测量、标签、字段与时间戳

InfluxDB 的核心数据模型可以概括为四个要素：measurement（测量）、tag（标签）、field（字段）和timestamp（时间戳）。measurement 相当于一类数据的逻辑表名，例如 motor_sensor；tag 是用于索引和分组的维度，通常是设备编号、产线、区域等离散值；field 是实际采集的数值，如温度、转速、电流；timestamp 则标识数据点发生的精确时间。

与关系数据库不同，InfluxDB 不要求预先定义严格的表结构。同一个 measurement 下可以写入不同字段组合的数据点，字段类型在首次写入时确定。标签会被建立索引，适合用于过滤和分组；字段不会被索引，适合存储高基数或连续变化的数值。理解这一点，对后续查询性能影响极大。

一个典型工业测点的行协议（Line Protocol）写入示例如下：

motor_sensor,line=A1,device=MTR-001 temperature=68.5,current=12.3,vibration=0.42 1710000000000000000
motor_sensor,line=A1,device=MTR-002 temperature=71.2,current=11.8,vibration=0.39 1710000000000000000

其中 motor_sensor 是 measurement，line 和 device 是 tag，temperature、current、vibration 是 field，末尾是纳秒时间戳。

二、写入与查询特征：高吞吐写入与时间窗口聚合

时序数据库的写入模式具有明显特征：数据按时间顺序持续到达，写入量远大于读取量，且通常为追加写，很少更新或删除。InfluxDB 通过 LSM-Tree 类似的存储结构、时间分区和列式压缩，实现高吞吐写入。工业现场可能有数千甚至数万个测点，每秒产生数万条数据，因此写入路径必须高效且稳定。

查询方面，时序数据库的典型操作不是“按主键查单条记录”，而是“按时间范围 + 标签条件 + 聚合函数”进行查询。例如查询某设备过去 24 小时每 5 分钟的平均温度。InfluxDB 提供类 SQL 的 Flux 和 InfluxQL 查询语言，支持 GROUP BY time()、mean()、max()、derivative() 等时间窗口聚合和变换函数。

SELECT mean("temperature") AS "avg_temp"
FROM "motor_sensor"
WHERE "device" = 'MTR-001' AND time >= now() - 24h
GROUP BY time(5m)
FILL(previous)

这类查询在关系数据库中往往需要扫描大量行并做分组计算，而在时序数据库中，数据按时间组织并压缩存储，聚合效率更高。此外，时序数据库通常内置数据保留策略（Retention Policy）和连续查询（Continuous Query）或任务（Task），可自动降采样和过期删除。

三、与传统关系数据库的差异

传统关系数据库强调事务一致性、复杂关联查询和结构化约束，适合业务系统；时序数据库则针对时间序列数据做了专门优化。二者并非替代关系，而是互补关系。下表从多个维度进行对比：

对比维度	传统关系数据库	时序数据库（InfluxDB）
数据模型	表、行、列，强 Schema	measurement、tag、field、timestamp，弱 Schema
写入模式	随机读写，支持频繁更新	追加写为主，极少更新删除
索引方式	B+ 树索引，主键/二级索引	时间分区 + tag 倒排索引
查询重点	多表关联、事务查询	时间范围过滤、窗口聚合、降采样
扩展方式	垂直扩展为主，分库分表复杂	水平扩展，按时间和标签分片
典型场景	ERP、CRM、订单系统	设备监控、能耗分析、预测性维护

需要特别注意的是，时序数据库不适合做复杂事务和频繁更新的业务数据存储；关系数据库也不适合承载每秒数万点的传感器写入。选型时应根据数据特征和访问模式决定。

四、典型工业场景与常见误区

在工业领域，时序数据库的典型应用包括：设备状态监控与告警、能耗与排放分析、生产过程追溯、预测性维护、边缘计算数据缓存等。例如在汽车焊装车间，数千台机器人关节的电流、温度、振动数据被持续写入 InfluxDB，通过时间窗口聚合计算均值、峰值和变化率，再结合阈值规则触发告警。

工业场景建模建议：将设备编号、产线、区域、工位等离散维度设计为 tag；将温度、压力、电流、转速等连续测量值设计为 field。避免将高基数且频繁变化的值（如时间戳、序列号）作为 tag，否则会导致索引膨胀和写入性能下降。

常见误区一：把时序数据库当关系数据库用，频繁执行 UPDATE 和 DELETE。时序数据库的更新删除代价高，应通过保留策略和降采样管理数据生命周期。
常见误区二：tag 设计过多或基数过高，导致内存和索引压力过大。
常见误区三：忽略时间精度和时区问题，工业现场跨时区部署时容易造成查询偏差。

下面用一张图概括时序数据从采集、写入、存储到查询的整体链路，以及各环节的关键特征。

掌握上述基础后，在实际工程中还需要结合数据保留周期、写入批量大小、标签基数、查询频率等因素进行综合设计。时序数据库的价值不在于替代关系数据库，而在于用更合适的存储和计算方式，解决工业场景中高频、海量、时间相关数据的采集、存储与分析问题。