4. 设备时序标签的存储与索引
设备时序标签（如设备编号、产线、工位、型号、批次、区域）在写入时序数据时，往往比测点值本身更影响查询性能。原因在于：时序数据的值列（温度、电流、转速）是高频写入、低频按值过滤的；而标签列是低频写入、高频作为过滤条件的。因此，标签的存储模式与索引方式，直接决定了"按设备+时间范围查曲线"这类典型查询是毫秒级还是分钟级。本节围绕存储选型、标签存储模式、索引优化和实战建库写入四个层面展开。
一、时序数据库与数据湖的选型对比
设备时序数据常见的落点有三类：专用时序数据库（InfluxDB、TimescaleDB、TDengine）、通用关系库扩展、以及数据湖（Parquet/Iceberg/Delta Lake on 对象存储）。它们并非互相替代，而是处于数据链路的不同位置。
| 维度 | InfluxDB | TimescaleDB | TDengine | 数据湖（Parquet/Iceberg） |
|---|---|---|---|---|
| 数据模型 | measurement + tag + field | 标准表 + hypertable 分区 | 超级表 + 子表（标签建子表） | 文件 + 分区目录 + 元数据表 |
| 标签存储 | tag 列，字典编码 | 普通列，可建 B-tree/GIN 索引 | 标签列，一设备一子表 | 列式文件中的列，靠分区裁剪 |
| 写入吞吐 | 高（批量行协议） | 中高（COPY/批量 INSERT） | 极高（列式+乱序处理） | 高（批量追加文件） |
| 标签过滤性能 | 优（倒排索引） | 优（索引+分区） | 优（子表裁剪） | 中（依赖分区与谓词下推） |
| 更新/删除 | 弱 | 强（标准 SQL） | 中 | 弱（需重写文件） |
| 典型定位 | 监控实时查询 | 时序+关系混合分析 | 海量设备高压缩存储 | 长期归档与离线分析 |
选型判断可以归纳为三条：实时监控与告警优先选时序库；需要与业务表 JOIN、复杂 SQL 分析优先选 TimescaleDB；设备量极大、写入压力高、以压缩比和成本为第一目标优先选 TDengine。数据湖则承担"冷数据归档 + 离线训练/报表"的角色，通常与时序库形成热冷分层，而不是二选一。
二、标签在时序库中的三种存储模式
标签的存储模式决定了索引能否生效，常见有三种：
- tag 列模式：标签作为独立列存储，写入时做字典编码，相同标签值只存一次，查询时通过倒排索引快速定位序列。InfluxDB 与 TDengine 属于此类。优点是过滤快、压缩好；缺点是标签基数过高（如把时间戳、随机 UUID 当标签）会导致索引膨胀。
- JSON 字段模式：把标签打包成一个 JSON 字段存入。优点是 schema 灵活、新增标签无需改表；缺点是过滤需要解析 JSON，除非数据库支持 JSON 路径索引（如 PostgreSQL 的 GIN 索引），否则全表扫描。适合标签种类多变但查询不频繁的场景。
- 宽表模式：每个标签一列，直接建普通索引。优点是 SQL 友好、JOIN 方便；缺点是标签数量变化需要 DDL，列数过多时行宽膨胀。TimescaleDB 常用这种模式。
核心原则是：会被 WHERE 过滤的标签，必须是独立列并建索引；只是随数据一起展示、从不参与过滤的元信息，才考虑塞进 JSON。
三、标签索引与查询优化
索引优化的核心是控制标签基数与查询选择性。标签基数指某标签列不同取值的数量：产线可能只有 10 个值（低基数），设备编号可能有 10 万个值（高基数）。低基数标签适合做倒排索引，高基数标签适合做分区键或子表键。
几条可落地的优化规则：
- 标签顺序影响索引效率。在 InfluxDB 中，tag 的排列顺序会影响序列键的生成，把选择性高的标签（device_id）放在前面，能让索引更快缩小范围。
- 避免把时间戳、随机数、递增 ID 当标签。这类值基数无限增长，会让索引和序列数爆炸。它们应作为 field 或直接作为时间列。
- 用连续查询或物化视图预聚合。设备秒级数据查一天曲线时，先降采样到分钟级再返回，可减少 60 倍数据量。
- 查询时显式限定时间范围。没有时间条件的标签查询会跨所有分区，性能急剧下降。
- TimescaleDB 中用 hypertable 按时间分区，并对标签列建 B-tree 索引；若标签组合查询多，可考虑复合索引 (line, model, ts)。
四、实战建库与写入
以 TDengine 为例，建立"产线—设备—测点"三层标签模型。先建超级表，标签为 line、model、device_id，子表按设备自动创建：
CREATE DATABASE IF NOT EXISTS dev_ts
KEEP 365 DURATION 10 BUFFER 256 WAL_LEVEL 1;
USE dev_ts;
CREATE STABLE IF NOT EXISTS sensor_data (
ts TIMESTAMP,
temp FLOAT,
current FLOAT,
rpm INT
) TAGS (
line BINARY(16),
model BINARY(16),
device_id BINARY(32)
);
-- 为每台设备创建子表，标签值写入子表
CREATE TABLE IF NOT EXISTS d_101 USING sensor_data
TAGS ('L1', 'X200', 'D-101');
CREATE TABLE IF NOT EXISTS d_102 USING sensor_data
TAGS ('L1', 'X200', 'D-102');写入时按子表插入，TDengine 会自动按标签路由：
INSERT INTO d_101 VALUES
(NOW, 36.5, 12.3, 1450),
(NOW + 1s, 36.7, 12.4, 1452);
-- 查询 L1 产线 X200 型号近 1 小时温度
SELECT ts, temp FROM sensor_data
WHERE line='L1' AND model='X200'
AND ts >= NOW - 1h;若使用 InfluxDB，则用行协议写入，标签写在等号前、字段写在等号后：
sensor_data,line=L1,model=X200,device_id=D-101
temp=36.5,current=12.3,rpm=1450i 1718000000000000000写入后应验证三件事：一是序列数是否与设备数一致（TDengine 查 SHOW STABLES 与子表数，InfluxDB 查 SHOW SERIES CARDINALITY）；二是查询计划是否命中索引（TimescaleDB 用 EXPLAIN ANALYZE 看是否走 Index Scan 而非 Seq Scan）；三是压缩比是否合理（TDengine 查 SHOW TABLE DISTRIBUTED，正常设备时序数据压缩比可达 5～10 倍）。