2. InfluxDB 核心概念:Measurement、Tag、Field、Timestamp、Series、Retention Policy

在部署厂务时序数据库之前,必须深入理解 InfluxDB 的六大核心概念。这些概念构成了数据模型、存储结构与查询优化的基础。本章将逐一拆解,并通过对比表格与内联 SVG 图帮助建立直观认知。

2.1 核心概念总览

InfluxDB 的数据模型与传统关系型数据库有显著差异。下表从“类比”与“特性”两个维度快速建立映射关系:

InfluxDB 概念 关系型数据库类比 核心特性
Measurement 表(Table) 存储同类时序数据的逻辑容器
Tag 带索引的列 用于过滤与分组,支持字符串类型,自动建立索引
Field 普通列(值) 存储实际数值,不会被索引,是查询与聚合的目标
Timestamp 主键(时间戳) 每条数据记录的唯一时间标识,精度可达纳秒
Series 分区/索引组合 由 Measurement + Tag 集合 + Field 唯一确定的数据流
Retention Policy (RP) TTL 策略 控制数据保留时长、副本数及存储分片策略
运维提示: 在厂务场景中,Tag 通常用于存储“设备ID”、“产线编号”、“区域”等静态元数据;Field 用于存储“温度”、“压力”、“流量”等动态测量值。合理设计 Tag 与 Field 是优化查询性能的第一步。

2.2 数据模型结构图

下图展示了 InfluxDB 一条数据点(Point)在存储层面的完整结构:

InfluxDB 数据点结构图 InfluxDB 数据点(Point)结构 Measurement 厂务_空调_温度 Tags(索引) 设备ID=AHU-01 产线=Line-A 区域=CleanRoom Fields(值) 温度=23.5 湿度=45.2 压力=101.3 Timestamp 2025-03-21T14:30:00Z Series Measurement + Tags 组合 Retention Policy autogen (7d, 1副本) 关键理解 • 一个 Point = 1个 Measurement + N个 Tags + N个 Fields + 1个 Timestamp • Series = Measurement + Tags • RP 控制数据生命周期

2.3 逐概念深度解析

2.3.1 Measurement(测量)

Measurement 是时序数据的逻辑分类,类似于关系型数据库中的表。在厂务场景中,通常按设备类型或测量对象命名,例如:厂务_空调_温度、厂务_纯水_电导率、厂务_空压机_振动。

2.3.2 Tag(标签)

Tag 是带索引的元数据列,用于快速过滤和分组。Tag 只支持字符串类型,且 InfluxDB 会自动为 Tag 建立倒排索引。在查询中,WHERE 子句对 Tag 的过滤效率远高于 Field。

厂务最佳实践: 将设备ID、区域、产线、设备类型等低基数(Low Cardinality)元数据设为 Tag。避免将时间戳、随机ID等高基数数据设为 Tag,否则会导致索引膨胀,写入性能下降。

2.3.3 Field(字段)

Field 存储实际的测量数值,是查询与聚合运算的目标。Field 可以是浮点数、整数、字符串或布尔值。与 Tag 不同,Field 不会被索引,因此对 Field 的过滤会触发全表扫描,性能较差。

特性 Tag Field
是否索引 是(自动建立倒排索引) 否
数据类型 仅字符串 浮点数、整数、字符串、布尔
查询过滤 高效(走索引) 低效(全表扫描)
典型用途 设备ID、区域、产线 温度值、压力值、流量值
基数影响 低基数(<10万) 无限制

2.3.4 Timestamp(时间戳)

Timestamp 是每条数据记录的唯一标识,精度可达纳秒。在 InfluxDB 中,时间戳是主键的一部分(与 Tag 组合)。如果写入时未指定时间戳,InfluxDB 会自动使用服务器当前时间。

注意: 同一 Measurement + Tags 组合下,如果写入两条相同时间戳的数据,后写入的数据会覆盖前一条。在厂务数据采集场景中,建议使用采集设备的时间戳,避免因网络延迟导致时间错乱。

2.3.5 Series(序列)

Series 是 InfluxDB 中最核心的存储单元。一个 Series 由 Measurement + 所有 Tag 的键值对组合 唯一确定。例如:

Measurement: 厂务_空调_温度
Tags: 设备ID=AHU-01, 产线=Line-A, 区域=CleanRoom
→ 构成一个唯一的 Series

Series 的数量 = Measurement 数量 × 每个 Tag 的基数乘积。Series 过多(Series Cardinality 过高)会导致内存占用飙升,是 InfluxDB 性能瓶颈的常见原因。

2.3.6 Retention Policy(保留策略)

Retention Policy 定义了数据在 InfluxDB 中的保留时长、副本数和分片组时长。每个数据库可以有多个 RP,但只有一个默认 RP。

RP 参数 说明 厂务推荐值
DURATION 数据保留时长,超过后自动删除 原始数据 7~30 天,聚合数据 1 年
REPLICATION 副本数(开源版固定为 1) 1(开源版)
SHARD DURATION 每个分片覆盖的时间范围 7 天(与 DURATION 匹配)

2.4 数据写入与查询示例

以下示例展示如何写入一条厂务数据,并验证核心概念:

-- 写入数据(自动创建 Measurement 和 RP)
INSERT 厂务_空调_温度,设备ID=AHU-01,产线=Line-A,区域=CleanRoom 温度=23.5,湿度=45.2 1711012200000000000

-- 查询指定 Series 的数据
SELECT * FROM "厂务_空调_温度"
WHERE "设备ID" = 'AHU-01'
  AND time >= now() - 1h

-- 查看当前数据库的 RP
SHOW RETENTION POLICIES ON "厂务数据库"

2.5 概念关系总结图

下图展示六大概念之间的层级与依赖关系:

InfluxDB 六大概念关系图 InfluxDB 六大概念关系图 Database(数据库) Retention Policy(保留策略) Measurement(测量) Series(序列) 由 Measurement + Tags 组合唯一确定 Tags(索引) Fields(值) Timestamp
运维要点: 在部署 InfluxDB 前,务必先规划好 Measurement 命名规范、Tag 设计策略以及 Retention Policy 的保留时长。这些决策直接影响后续的查询性能与存储成本。建议在厂务系统中,将原始数据保留 7 天,聚合数据保留 1 年,以平衡查询效率与磁盘开销。