建模的分界线在哪
时序建模围绕一个问题：哪些维度要用来筛选与分组。频繁出现在过滤与分组里的、取值可控的维度放 tag（如主机、地域、服务、状态码），测量值与高变化的值放 field。measurement 表示一批结构相同的数据流，同一个 measurement 的字段集合应尽量固定。
高基数标签的代价
时序库会为每个标签取值组合维护索引序列，高基数标签（请求 ID、用户 ID 这类几乎唯一的值）会让序列数迅速膨胀，内存占用与查询耗时同步上升。判断方法是先把各标签的取值个数相乘估算组合数，再结合写入速率与保留期评估，别等上线后才在监控里发现问题。
基本信息
| 放 tag | host、region、service、status 等可控枚举，支撑过滤与分组 |
|---|---|
| 放 field | 数值测值、消息内容、高变化字符串 |
| measurement | 同结构数据流，字段集合保持稳定 |
| 命名规范 | 小写加下划线，单位写进字段名（latency_ms、size_bytes） |
| 适用版本 | InfluxDB 2.x 行协议 |
示例
示例
# 好：维度可控，字段是测值
http_requests,service=api,region=cn,code=200 count=42i,latency_ms=12.5
# 差：request_id 取值无界，序列数会爆炸
http_requests,request_id=8f3a9c,count=1i
# 类型后缀：i 表示整数，u 表示无符号整数，默认按浮点处理
mem,host=web-1 used=1024i,free=2048i
# 时间戳单位由写入参数的 precision 决定，这里示意纳秒
cpu,host=web-1 usage=0.73 1719792000000000000典型使用场景
- 指标采集：把主机、服务、地域做成标签，把测值做成字段
- 多来源汇总：同类数据用同一 measurement，用标签区分来源
- 查询下推：把最常过滤的维度设为标签，减少需要扫描的序列数
- 容量设计：结合基数与保留期估算内存与磁盘需求
- 规范评审：上线前先估算标签取值组合数
建模决策对照
| 决策 | 判断依据 | 代价 |
|---|---|---|
| 设为 tag | 需要过滤或分组，取值可控 | 基数增长带来索引与内存压力 |
| 设为 field | 测量值或高变化字符串 | 不能用于高效过滤与分组 |
| 拆出 measurement | 字段结构完全不同 | 跨测量查询需要额外合并 |
| 单位写进字段名 | 避免同一字段混用多种单位 | 字段名变长但语义清晰 |
命名保持小写与下划线风格，把单位写进字段名（latency_ms、size_bytes），避免同一个测量里混用多种单位造成误读。
同一 measurement 内字段类型不一致（先写整数后又写浮点）会引发类型冲突，导入前统一数值类型，必要时在行协议里显式加类型后缀。