4. InfluxDB 数据模型设计
InfluxDB 的数据模型看起来只有 measurement、tag、field、timestamp 四个要素，但真正决定写入吞吐、查询延迟和存储成本的，恰恰是 tag 与 field 的划分方式。很多工业场景在初期“能写进去就行”，等到设备数量从几百涨到几万、测点从几千涨到几十万时，才发现查询变慢、内存暴涨、压缩率下降，根源往往不是硬件不够，而是 schema 设计从一开始就埋下了隐患。
一、核心原理：tag 与 field 的本质差异
在 InfluxDB 中，tag 是索引化的字符串键值对，field 是非索引的实际测量值。这个差异决定了它们完全不同的使用方式：
- tag：参与倒排索引，用于 WHERE 条件过滤和 GROUP BY 分组，适合低基数、可枚举、用于筛选的维度，如设备编号、产线、区域、工位。
- field：不建索引，按列式存储并压缩，适合高基数、连续变化、需要聚合计算的数值，如温度、压力、电流、转速。
- timestamp：每个数据点必须携带，是时序数据的天然主键，精度由写入时决定。
关键判断标准是：这个值会不会出现在 WHERE 或 GROUP BY 中？会，就考虑 tag；不会，就放 field。如果把温度值写成 tag，索引会随温度值无限膨胀；如果把设备编号写成 field，则无法按设备高效过滤，只能全表扫描。
二、基数控制：tag 设计的第一红线
基数（cardinality）指某个 measurement 下所有 tag 取值组合的数量。它是 InfluxDB 性能最敏感的指标。基数 = tag1 取值数 × tag2 取值数 × … × tagN 取值数。例如设备编号 10000 个、测点类型 50 个、区域 20 个，组合基数就是 1000 万，这已经远超单机舒适区。
高基数带来的直接后果包括：
- 倒排索引膨胀，内存占用急剧上升；
- 写入时索引更新变慢，写入吞吐下降；
- 查询时需要扫描大量 series，响应时间变长；
- 压缩效率降低，磁盘占用增加。
控制基数的常用手段：
- 不要把连续变化的数值（如温度、时间戳、UUID、订单号）作为 tag；
- 对高基数维度做降维，例如把“设备编号”改为“设备类型 + 区域”组合；
- 使用 measurement 拆分不同设备族，而不是把所有设备塞进一个 measurement；
- 必要时用 field 存储高基数标识，查询时配合其他低基数 tag 缩小范围。
三、Schema 设计对性能的影响路径
Schema 设计不是“字段命名”问题，而是直接影响存储引擎行为。下图展示了 tag/field 选择如何沿着写入、索引、查询、压缩四条路径影响最终性能：
从图中可以看到，tag 选择直接决定倒排索引规模，而索引规模又同时影响写入吞吐和查询延迟；field 选择则主要影响压缩率和聚合计算效率。measurement 拆分和基数控制是两条“调节阀”，可以在不改变业务语义的前提下显著降低 series 数量。
四、工业场景案例：设备监控 schema 设计
假设一个工厂有 500 台设备，每台设备有 20 个测点，采集频率 1 秒。如果设计成：
measurement: device_metrics
tags: device_id=DEV0001, point_id=T001, line=A
fields: value=36.5, status=1
此时 series 数量 = 500 × 20 = 10000，基数可控。但如果把 value 也写成 tag：
tags: device_id=DEV0001, point_id=T001, value=36.5
由于温度值连续变化，series 数量会迅速膨胀到百万级，写入和查询都会明显恶化。正确做法是保持 value 为 field，仅把 device_id、point_id、line 作为 tag。
如果设备数量进一步增长到 5 万台，建议按产线或区域拆分 measurement：
measurement: line_A_device_metrics
measurement: line_B_device_metrics
这样每个 measurement 的 series 数量被限制在可控范围，查询时也能通过 measurement 名称快速定位数据域。
五、常见误区与复盘
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 把连续数值写成 tag | 基数爆炸，内存和写入性能下降 | 数值放 field，仅保留可枚举维度为 tag |
| 所有设备共用一个 measurement | series 过多，查询范围难以收敛 | 按产线、区域或设备族拆分 measurement |
| 用 UUID 或时间戳做 tag | 基数接近无限，索引无法有效压缩 | UUID 放 field，或改用业务编号 |
| tag 命名随意、大小写混用 | 查询条件难以统一，易漏数据 | 建立命名规范，统一小写和下划线 |
| 忽略 tag 组合基数估算 | 上线后才发现内存不足 | 写入前用乘积估算 series 上限 |
总结来说，InfluxDB 数据模型设计的核心不是“把数据存进去”，而是“让数据以正确的结构被索引和计算”。tag 负责定位，field 负责度量，measurement 负责隔离，基数控制负责守住性能底线。把这四件事做好，后续的写入、查询和存储优化才有稳固的基础。