3. 时序数据特征

时序数据库（TSDB）与关系型数据库最根本的差异，不在于 SQL 语法，而在于它面对的数据形态完全不同。工业场景中的一条数据，通常不是“一行记录”，而是“某个设备在某个时刻产生的一组测量值”。理解时间戳、标签、字段、数据点与时间序列模型这五个概念，是设计采集管道、选择存储引擎、编写查询语句的前提。

3.1 五个核心概念：时间戳、标签、字段、数据点、时间序列

在时序数据模型中，一条数据由三部分构成：时间戳（Timestamp）、标签集（Tags）和字段集（Fields）。时间戳标识数据产生的时刻，精度可以是秒、毫秒、微秒甚至纳秒；标签是描述数据来源的维度信息，如设备编号、产线、工厂、测点类型，通常是字符串且相对稳定；字段是真正的测量值，如温度、压力、电流，通常是数值类型，也可能包含布尔或字符串状态。

一个数据点（Data Point）就是“时间戳 + 一组标签 + 一组字段”的最小写入单元。而时间序列（Time Series）则是由“标签集唯一确定”的一条数据流：同一组标签下，按时间顺序排列的所有数据点构成一条时间序列。换句话说，标签决定“这是哪条序列”，时间戳决定“序列上的位置”，字段决定“这个位置上的值”。

3.2 时间序列模型：标签即索引，时间即主键

时序数据库通常采用“标签索引 + 时间分区”的存储模型。写入时，系统先根据标签集计算序列 ID，再将数据点追加到该序列对应的时间分区中。查询时，先用标签条件筛选出目标序列集合，再在时间范围内做扫描与聚合。这种“先标签、后时间”的两级过滤，正是时间窗口查询高效的根本原因。

下面这张图展示了从原始数据点到时间序列模型的映射关系，以及标签、时间戳、字段在其中的角色。

3.3 高写入吞吐与高压缩比：为什么时序数据“写得快、存得小”

工业现场往往有成千上万个测点，每个测点以秒级甚至毫秒级频率上报。假设一条产线有 5000 个测点，采样周期 1 秒，则每秒写入 5000 个数据点，一天就是 4.32 亿个点。这种“只追加、不更新、按时间递增”的写入模式，使时序数据库可以采用 LSM-Tree 或列式存储，把随机写转化为顺序写，从而获得远高于 OLTP 数据库的写入吞吐。

高压缩比来自两个天然优势：其一，时间戳严格递增，可以用差分编码（Delta）甚至二阶差分（Delta-of-Delta）把 8 字节时间戳压缩到 1～2 字节；其二，同一字段列内的数值变化平缓，浮点数可用 Gorilla 异或压缩、整数可用游程编码。实际工程中，时序数据压缩比达到 5:1 到 20:1 非常常见，这意味着原本需要 1TB 的原始数据，落盘后可能只需 100GB。

3.4 时间窗口查询：时序场景最典型的访问模式

时序查询很少“按主键查单条”，绝大多数是“查某设备最近 1 小时温度曲线”“统计每条产线过去 24 小时的平均压力”。这类查询具有明确的时间范围、明确的标签过滤条件，以及聚合或降采样需求。因此，时序数据库通常提供连续查询（Continuous Query）和物化视图，把高频原始数据预聚合成分钟级、小时级结果，避免每次查询都扫描海量原始点。

-- 典型时间窗口查询：每 5 分钟平均温度，最近 1 小时
SELECT mean(temp) AS avg_temp
FROM sensor_data
WHERE device = 'D01'
  AND time >= now() - 1h
GROUP BY time(5m)
FILL(linear);

-- 标签过滤 + 时间范围 + 聚合，是时序查询的黄金组合
SELECT max(press), min(press)
FROM sensor_data
WHERE line = 'L1' AND time >= '2024-06-01T00:00:00Z'
  AND time < '2024-06-02T00:00:00Z'
GROUP BY device;

3.5 案例与误区：标签基数失控的代价

某工厂在采集数据时，把“每批次产品编号”也写进了标签。结果每生产一批就新增一组标签，时间序列数量从几千条暴涨到数百万条，内存索引被撑爆，写入延迟从毫秒级恶化到秒级。复盘结论是：标签应描述稳定的数据来源维度，而不是高频变化的业务属性。批次号、订单号这类高基数字段，应作为字段值或普通列存储，而不是标签。

总结来看，时序数据的本质是“带标签的有序测量流”。时间戳提供顺序，标签提供身份，字段提供内容，数据点是写入单元，时间序列是管理单元。高写入吞吐、高压缩比、时间窗口查询这三大特征，都是这一模型在存储与查询层面的自然结果。理解它们之间的因果关系，才能在工业数据管道中做出正确的建模与选型决策。