3. 指标数据模型优化：理解高基数（High Cardinality）问题，优化Label设计以减少查询扫描量

3.1 高基数问题的本质

在Prometheus、VictoriaMetrics、Thanos等时序数据库中，基数（Cardinality）指一个Label（标签）或Label组合的唯一取值数量。当某个Label的取值数量超过合理阈值（通常>10,000），即构成高基数（High Cardinality）问题。

3.2 基数等级与性能影响对照

3.3 高基数的三大危害

1. 倒排索引膨胀：每个唯一Label值都需要在倒排索引中建立条目，高基数Label使索引大小超过数据本身数倍。
2. 内存压力激增：时序数据库需要在内存中维护活跃序列的元数据，百万级序列将耗尽堆内存。
3. 查询扫描爆炸：一个包含高基数Label的查询，可能触发全表扫描，导致CPU和磁盘IO飙升。

3.4 Label设计优化原则

以下SVG展示了从错误设计到优化设计的Label重构路径：

3.5 高基数Label识别清单

以下列表帮助SRE快速识别应避免作为指标Label的属性：

• 用户级标识：user_id、account_id、customer_id、email
• 请求级标识：request_id、trace_id、span_id、session_id
• 网络级标识：client_ip、source_ip、hostname（动态）、pod_name（动态）
• 设备级标识：device_id、imei、mac_address、fingerprint
• 业务级标识：order_id、transaction_id、payment_id

3.6 低基数Label推荐设计

3.7 高基数问题的检测与监控

以下PromQL查询可用于实时监控基数状态：

# 检测单个Label的基数（以service为例）
count by (__name__) (
  count by (service, __name__) ({__name__=~".+"})
)

# 检测所有Label组合的序列数（Top 10）
topk(10,
  count by (__name__, job) (
    {__name__=~".+"}
  )
)

# 检测指标总序列数
count({__name__=~".+"})

# 检测最近24小时新增Label值
sum by (__name__) (
  label_replace(
    increase(prometheus_tsdb_head_series_total[24h]),
    "series_count", "$1", "__name__", "(.+)"
  )
)

3.8 高基数问题的修复策略

以下SVG展示了从检测到修复的完整工作流：

3.9 实战：Label重构前后对比

3.10 最佳实践总结