4. InfluxDB数据模型：设计合理的measurement和tag，避免高基数问题，field类型选择
好，咱们今天聊聊InfluxDB的数据模型设计。说实话，这是整个时序数据库对接中最容易踩坑的地方。我见过太多项目，前期图省事随便设计，结果数据量一上来，查询慢得像蜗牛，甚至直接OOM。嗯，咱们今天就把这块彻底讲透。
4.1 理解InfluxDB的核心概念
先快速过一下基础。InfluxDB里主要有四个概念：measurement、tag、field和time。
- measurement：相当于关系数据库里的表名。比如你采集设备温度，可以叫
device_temperature。 - tag：带索引的元数据，用于快速过滤和分组。比如设备ID、区域、型号。
- field：实际存储的数值。比如温度值、电压值。
- time：时间戳，每条记录的核心。
说白了，tag是用来查的，field是用来算的。这个区分很重要，你想想看，如果搞反了，性能会差很多。
4.2 设计合理的measurement
我个人习惯，一个measurement只放一类数据。比如温度数据放一个，湿度数据放另一个。别把所有东西塞到一个大表里。
推荐做法：
measurement: temperature
tags: device_id, region, model
fields: value (float), quality (int)
time: 2024-01-15T10:00:00Z
measurement: humidity
tags: device_id, region, model
fields: value (float), quality (int)
time: 2024-01-15T10:00:00Z我在项目中遇到过有人把温度、湿度、气压全塞进一个measurement，然后用一个叫type的tag区分。结果查询时每次都要过滤，索引效率极低。分开后，查询速度提升了3倍以上。
4.3 tag设计：避免高基数问题
这是最要命的坑。高基数（High Cardinality）指的是tag的取值数量过多。比如你用device_id做tag，如果有100万台设备，那这个tag的基数就是100万。InfluxDB的索引是基于tag构建的，基数太高会导致内存爆炸。
高基数的典型表现：
- 写入速度越来越慢
- 内存占用持续增长
- 查询时OOM（内存溢出）
- 压缩率下降，磁盘占用飙升
为什么会这样？因为InfluxDB的TSI（Time Series Index）索引结构，每个唯一的tag组合都会创建一个时间序列。100万台设备，每个设备有10个tag组合，那就是1000万个序列。你想想看，内存能扛得住吗？
我的建议：
- tag的基数控制在10万以内，最好在1万以下
- 不要用设备ID、用户ID这种高基数字段做tag
- 可以用
设备类型、区域、固件版本这种有限取值的字段 - 如果必须用设备ID，考虑用
field存储，或者用哈希分桶
避坑指南：我曾经有个项目，把request_id当成了tag。每个请求都不同，基数直接爆炸。后来改成field存储，问题解决。记住：tag是用于过滤的，不是用于存储唯一标识的。
4.4 field类型选择
field支持四种类型：float、integer、string和boolean。选错了类型，要么浪费空间，要么精度丢失。
| 数据类型 | 适用场景 | 注意事项 |
|---|---|---|
| float | 温度、电压、百分比等连续值 | 注意精度，64位浮点够用 |
| integer | 计数、状态码、版本号 | 比float省空间，查询更快 |
| string | 日志、错误信息、设备名称 | 不能做聚合运算，尽量少用 |
| boolean | 开关状态、告警标志 | 存储为0/1，效率高 |
我个人习惯，能用integer绝不用float。比如设备状态码，0表示正常，1表示告警，2表示故障。用integer存储，查询时用=或!=过滤，速度飞快。
另外，string类型的field要慎用。InfluxDB对string的压缩率不高，而且不能做SUM、MEAN这类聚合。如果你要存日志，建议单独用Elasticsearch，别混在一起。
4.5 实战案例：一个完整的设备数据模型
咱们来看一个实际例子。假设你要采集智能电表的数据，包括电压、电流、功率、累计用电量，还有设备状态和告警信息。
-- 测量：电表实时数据
measurement: meter_realtime
tags:
meter_type: "single_phase" | "three_phase" -- 基数：2
region: "north" | "south" | "east" | "west" -- 基数：4
firmware_version: "v1.0" | "v2.0" | "v2.1" -- 基数：3
fields:
voltage: float -- 电压值，单位V
current: float -- 电流值，单位A
power: float -- 功率值，单位W
energy: float -- 累计用电量，单位kWh
status: integer -- 0=正常, 1=过压, 2=欠压, 3=过流
alarm: boolean -- true=有告警, false=无告警
time: 纳秒级时间戳你看，这里我把设备ID去掉了，因为它是高基数。那怎么区分设备呢？可以在field里加一个device_id的string字段，或者干脆在应用层通过其他方式关联。实际查询时，我们通常按区域、设备类型来聚合，很少按单个设备查。
关键点总结：
- tag的基数乘积不要超过10万
- field类型选对，integer优先于float
- string类型的field尽量少用
- 高基数字段（如设备ID）用field存储
- 一个measurement只放一类数据
嗯，到这里数据模型这块就差不多了。你想想看，设计好了模型，后面的写入和查询才能顺畅。我见过太多人一开始图省事，后面花几倍的时间来重构。所以，花点时间把模型设计好，绝对值得。
下一节咱们聊聊如何用InfluxDB的写入API和SDK，把设备数据高效地写进去。到时候会讲批量写入、压缩、重试策略这些实战技巧。