3、标签索引设计：倒排索引在时序场景下的应用，标签基数对性能的影响
标签索引，说白了就是时序数据库的「门牌号系统」。没有它，你查数据就得把整栋楼翻一遍。我最早接触时序数据库时，觉得这玩意儿不就是个 key-value 嘛，后来被线上事故狠狠教育了一顿——嗯，标签设计不好，再牛的硬件也扛不住。
3.1 倒排索引：时序场景下的「快速查找手册」
倒排索引不是新概念，搜索引擎早就用烂了。但在时序场景下，它的角色有点不一样。
传统数据库的索引，是「记录 → 关键词」的映射。倒排索引反过来，是「关键词 → 记录列表」。你想想看，时序查询最常干的事是什么？
- 查某个
host过去 1 小时的所有 CPU 数据 - 查
region=us-east且service=api的所有指标
这些查询条件都是标签（Tag）。倒排索引正好擅长这个——它把每个标签值作为 key，后面挂一串满足条件的时序数据 ID 列表。
核心逻辑：写入时构建「标签值 → 数据 ID 集合」的映射；查询时通过标签值快速定位到数据 ID，再按 ID 去取数据。
举个例子。假设你有 3 条时序数据：
数据ID: T001, 标签: host=web01, region=us-east
数据ID: T002, 标签: host=web02, region=us-east
数据ID: T003, 标签: host=web01, region=eu-west倒排索引长这样：
| 标签键 | 标签值 | 数据 ID 列表 |
|---|---|---|
| host | web01 | T001, T003 |
| host | web02 | T002 |
| region | us-east | T001, T002 |
| region | eu-west | T003 |
查 host=web01 AND region=us-east 时，先拿两个 ID 列表做交集，得到 T001，再去取数据。整个过程 O(1) 级别，比全表扫描快几个数量级。
3.2 标签基数：那个让你又爱又恨的家伙
标签基数（Cardinality），指的是某个标签键下不同值的数量。比如 host 标签有 1000 台机器，基数就是 1000。
基数低的时候，倒排索引很舒服。基数高了……我见过一个案例，某团队把 request_id 这种 UUID 级别的字段当标签存，基数直接冲到几千万。结果呢？写入变慢，内存爆了，查询也卡成幻灯片。
高基数的三大危害：
- 内存膨胀：每个标签值都要在倒排索引里占一个 entry，几千万个 entry 直接撑爆内存
- 写入放大：每写入一条数据，要更新 N 个倒排索引，基数越高，更新开销越大
- 查询退化：高基数标签的 ID 列表极长，做交集/并集时 CPU 和 IO 都扛不住
为什么会这样？你想想看，倒排索引本质上是「用空间换时间」。每个唯一的标签值，都要在内存里维护一个指针或位图。基数 100 时，这点开销可以忽略；基数 1000 万时，光指针数组就能吃掉几个 GB。
3.3 实战：如何设计「恰到好处」的标签
我在项目中踩过不少坑，总结了几条铁律：
- 区分标签和字段：标签用于过滤和聚合，字段用于存储数值。别把
trace_id、request_id这种高基数唯一标识符放标签里，放字段里用全文检索去查。 - 控制基数上限：我个人习惯，单个标签键的基数不要超过 10 万。超过这个数，就要考虑拆分或降维。
- 避免多标签组合爆炸：3 个标签各 1000 基数，组合起来就是 10 亿种可能。虽然倒排索引不直接存组合，但查询时的多标签联合计算会指数级变慢。
- 利用标签前缀压缩：有些数据库（如 InfluxDB）支持标签前缀索引，可以把
host=web-001、host=web-002压缩成一个前缀节点，减少内存占用。
避坑指南：我曾经帮一个客户排查写入性能问题。他们的时序数据库每秒只能写 5000 点，但硬件配置很高。查了半天，发现他们把 user_id（基数 500 万）当成了标签。改成字段后，写入性能直接飙到 8 万点/秒。嗯，有时候问题不在代码，在模型设计。
3.4 倒排索引的存储结构：B+ 树还是跳表？
不同时序数据库的实现不一样。我简单列一下主流方案：
| 数据库 | 倒排索引实现 | 特点 |
|---|---|---|
| Prometheus | 内存中的倒排列表 + 位图 | 查询快，但内存开销大，基数高时容易 OOM |
| InfluxDB | TSI（Time Series Index）基于 LSM 树 | 支持高基数，但写入时有合并开销 |
| VictoriaMetrics | 内存倒排 + 按时间分片 | 兼顾性能和内存，适合大规模部署 |
| TDengine | 标签单独存储，按表聚合 | 适合超级表模式，标签基数受限于表数量 |
选哪个？看你的基数预期。如果基数稳定在几千以内，Prometheus 的方案最爽。如果基数可能冲到百万级，建议上 InfluxDB 或 VictoriaMetrics。
3.5 一张图看懂标签索引设计
下面这张图，我把标签索引的核心流程和基数影响画出来了。建议你保存下来，设计标签模型时对照着看。
3.6 标签设计的「黄金法则」
最后，我把自己多年总结的几条法则分享给你。照着做，至少能避免 80% 的标签性能问题。
黄金法则清单：
- 法则一：标签值必须是有限的、可枚举的。像
host、region、service这种，没问题。像request_id、timestamp这种，放字段。 - 法则二：单个标签键的基数不要超过 10 万。如果超过，考虑加一层 hash 或前缀。
- 法则三：标签总数（所有标签键 × 值的组合）不要超过 1000 万。这是大多数时序数据库的内存安全线。
- 法则四：查询时尽量用标签过滤，少用字段过滤。字段过滤走不了倒排索引，性能差很多。
- 法则五：定期监控标签基数。我习惯在监控面板上加一个「Top 10 高基数标签」的图表，一旦发现异常，马上处理。
嗯，标签索引设计这块，说白了就是「权衡的艺术」。你给标签的自由度越大，系统付出的代价就越高。想清楚你的查询模式，再决定哪些字段做标签、哪些做字段。别等到线上出问题了才回头改模型——那时候改起来，可比设计时痛苦多了。