时序数据模型长什么样
时序库按「测量对象 + 标签集 + 字段集 + 时间戳」组织数据：measurement 是逻辑上的测量对象，tag 是用于检索与分组的维度键值，field 是真正的测值，timestamp 标记时刻。同一 measurement 与同一组 tag 取值构成一个 series，序列数量决定了内存与索引压力。
基本信息
| measurement | 逻辑测量对象，如 cpu、http_requests |
|---|---|
| tag | 字符串键值，会建索引，用于筛选与分组；组合决定序列基数 |
| field | 实际测值，不建索引，是聚合计算的目标 |
| timestamp | 纳秒精度的时刻，写入与查询都以时间范围为主轴 |
| series | measurement 与 tag 组合的唯一实例，构成一条独立时间线 |
典型使用场景
- 指标建模：先确定哪些维度是可检索的 tag
- 容量评估：估算 tag 组合数量，判断序列基数是否可控
- 查询设计：先用 tag 缩小范围，再对 field 做聚合计算
- 数据核对：按 measurement 与 tag 检查数据完整性
- 排查高基数问题：定位把序列数推高的那个 tag
行协议与对照
行协议与对照
# InfluxDB 行协议：measurement,tag=值 field=值 时间戳
cpu,host=web-1,region=cn usage=0.73,idle=0.21 1719792000000000000
# 结构化对照
# |cpu| |---- tags ----| |------- fields -------| |--- timestamp ---|
# 测量对象 检索与分组维度 实际测值（聚合目标） 纳秒时刻
# 先用 tag 缩小范围，再对 field 聚合
SELECT mean("usage") FROM "cpu" WHERE "host" = 'web-1' AND time > now() - 1h GROUP BY time(5m)四要素对照
| 要素 | 是否建索引 | 典型内容 | 放错的影响 |
|---|---|---|---|
| measurement | — | cpu、http_requests | 粒度混乱会让查询跨对象 |
| tag | 是 | host、region、status | 高变化值当 tag 会瞬间推高序列基数 |
| field | 否 | usage、latency、count | 把维度放进 field 就无法按它分组 |
| timestamp | 时间索引 | 纳秒时间戳 | 精度不一致会造成时间点对齐困难 |
建模的核心只有两个问题：哪些维度放 tag（可检索、影响基数），哪些放 field（只做统计）。放错会同时影响写入性能与查询体验，事后调整模型基本等于重写历史数据。
写入时 tag 的顺序不影响序列归属，但同一条序列的字段集应保持一致；前后写入的 field 不一致会在查询结果里产生空值列，聚合前先用过滤条件固定字段，结果才可比。