想象你经营着一家大型连锁便利店。每家门面每一秒都在产生“进货小票”：几点几分、哪个门店、哪种商品、卖了多少。这些小票汇总起来就是“时序数据”——一条按时间排列的数值记录。当店面从十几家扩张到几千家时，你该怎么管理这些越堆越高的账本？ 三条路摆在面前：第一种，自己建一座精密中心仓，所有小票统一入库、真空打包、货架编号清清楚楚——这就是 VictoriaMetrics 的做法，一个高效的全能仓库；第二种，让每家店继续自己记自己的账，在总部搭一套“查账联盟”，需要时通过总机把各家账本调出来统一汇总——这就是 Thanos 的思路，把分散的 Prometheus 数据用统一查询层焊在一起；第三种，干脆把整个仓储外包给云物流巨头，按量付费、全球布点、不用自己维护——这就是 Mimir 提供的托管式服务。 本文用“时序数据库选型”这个话题，带你把这三种仓储模式从架构、存储、查询、扩展到运维逐项逛一遍。看懂它们，你就知道在真实监控系统里，百万条指标到底该交给谁来管。

岗位关联

时序数据库是可观测性体系的地基。掌握 VictoriaMetrics 与 Thanos 的架构差异与选型逻辑，是云架构师与 SRE 构建高性价比监控平台的核心能力，直接影响百万级指标系统的成本与稳定性。

目录
  1. 可视化演示
  2. 时序数据基础
  3. 架构设计对比
  4. 存储引擎差异
  5. 查询性能表现
  6. 扩展与高可用
  7. 运维成本
  8. 选型决策
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示三大时序数据库对比三模式：架构对比（VM单节点AGT-STR-SEL-INS四组件/Thanos PROM-SDC-OBJ-STR-QRY五组件Sidecar架构/Mimir DIST-ING-CMP-STR-QRY五组件分布式架构）、存储性能（WRT写入/CMP压缩/QRY查询/SCL扩展/SIM简易/RES资源六维雷达对比+写入吞吐VM 1M/s vs THN 20k/s vs MMR 200k/s柱状图+关键指标）、选型决策（VM中小规模<100万1C1G/Thanos Prometheus扩展100万-1亿4C8G/Mimir超大规模>1亿8C16G+SCALE/PERF/SIM/COST四决策因子+MON/LOG/TRC/ML四适用场景）。

本节配有交互动效（进入视口后自动加载，约 3KB）。

三大时序数据库架构对比 VM: 单节点架构AGT→STR→SEL→INS，极致性能1C1G起步 Thanos: PROM+SDC Sidecar→OBJ S3→STR→QRY，兼容Prometheus VM(perf) vs Thanos(compat) vs Mimir(scale) VM 50x写入，扩展100%，分布式95%

时序数据基础

便利店每天打烊后，店员会把小票按“哪个门店、哪个货架、哪种商品”分门别类地钉进账本。一张小票对应某个时刻的一笔数值，一年下来，每个类目就形成一条长长的、按时间排序的记录线。这条“记录线”在技术世界里就叫时间序列（Time Series）。

负责存储和管理这些序列的数据库，叫时序数据库（TSDB）。在云原生监控体系里，Prometheus（负责采集指标的监控系统）是“打小票的人”，而 TSDB 是“订账本的仓库”。VictoriaMetrics、Thanos、Mimir 其实都在回答同一个问题：账本怎么订、放哪里、怎么快速查。搞懂它们之前，先看懂账本的两种基本元素——序列和样本。

时序数据库的数据模型只有两个核心概念。序列（series）由指标名（metric name）加一组标签（label）唯一标识；样本（sample）则是这条序列在某个时刻的具体数值。标签相当于小票上的“门店号+商品名”，指标名相当于“销售额”或“库存量”这类量名。保留策略（retention）则决定账本保存多久，超过期限的小票会被定期清走。

理解了序列和样本，相当于看懂了小票的“抬头”和“一行记录”。接下来，我们去看看三个仓库分别用什么方式保存这堆小票。

series=(m, {(l1,v1),(l2,v2),… }),sample=(ti,vi)\text{series} = \left( m,\ \{(l_1,v_1), (l_2,v_2), \dots\}\right),\qquad \text{sample} = (t_i, v_i)
  1. 指标名 m表示“记录什么量”，例如 http_requests_total（总请求数），决定小票属于哪个类目。
    m=metric_name\text{m} = \text{metric\_name}
  2. 标签集合每个标签是一个键值对，例如 method="GET"、instance="pod-1"，相当于门店号加货架编号。
    {(l1,v1),(l2,v2),… }\{(l_1,v_1),(l_2,v_2),\dots\}
  3. 样本 (t_i, v_i)给序列追加一个“此刻的数值”，时间戳与数值按时间严格递增写入。
    (ti,vi),ti<ti+1(t_i, v_i),\quad t_i < t_{i+1}
  4. 序列唯一性指标名与全部标签共同决定一条唯一序列，标签不同就是两条不同的小票流水线。
    series=m×∏lj\text{series} = m \times \prod l_j

架构设计对比

三种仓管模式各有各的组织形式。VictoriaMetrics 像一个“全能中心仓”：收货、上架、盘点、出库全由同一个二进制进程搞定，布置简单到可以塞进一台虚机。Thanos 像“加盟联盟”：每家门店（Prometheus）各自的账本不动，总部加装总机，再配几个调度员把各店数据串起来。Mimir 则像“云物流”：整个仓储外包，你只跟平台签合同，它内部是微服务组成的大型配送网络。

架构决定了两件事：运维负担的上限与扩展的天花板。选时序库，本质上是选一种“管账的组织形式”。中心仓一个人管理全部事务，简单直接；加盟联盟分工明确但角色众多；云物流内部最复杂，但复杂度由平台替你承担。

VictoriaMetrics 单机版是 All-in-One，一份二进制内含抓取、存储、查询、告警全部能力。数据量大时可以切成 cluster 模式，由 vminsert（收货台）、vmstorage（货架）、vmselect（柜台）三个角色横向扩容。Thanos 则是典型的组件联邦：Sidecar 伴生在每台 Prometheus 旁，把数据块上传到对象存储；Store Gateway 从对象存储读旧块；Querier 统一执行 PromQL（Prometheus 的查询语言）；Compactor 合并小分块并做下采样；可选 Receive 支持无 Prometheus 的远程写入路径。Mimir 是云原生微服务架构：ingester 接收近实时数据，store-gateway 读取对象存储，querier 负责查询，compactor 维护数据，天然支持多租户。

加盟联盟组织灵活，但每加一个组件，就多一个需要“发工资”（运维盯着）的角色。中心仓一个人管全部，简单，但上限取决于单人的能力——这就是为什么规模一大，大家开始考虑集群模式原因。

NThanos=Nsidecar+Nstore+Nquerier+Ncompactor+NreceiveN_{\text{Thanos}} = N_{\text{sidecar}} + N_{\text{store}} + N_{\text{querier}} + N_{\text{compactor}} + N_{\text{receive}}
  1. Sidecar 伴生容器每台 Prometheus 各配一个，负责把本地 TSDB 数据块上传到对象存储。
    Nsidecar=NPrometheusN_{\text{sidecar}} = N_{\text{Prometheus}}
  2. Store 网关向对象存储发起读取，block 量变大时可按哈希分片成多组并行读写。
    Nstore=按块量分片N_{\text{store}} = \text{按块量分片}
  3. Querier 与 Compactor前者把多个来源的查询结果合并，后者把小分块合并成大分块。
    Nquerier, NcompactorN_{\text{querier}},\ N_{\text{compactor}}
  4. Receive 接入无 Prometheus 时接收远程写入的入口，是可选组件。
    Nreceive≥0N_{\text{receive}} \geq 0

存储引擎差异

假设小票必须在仓库里放 30 天才允许扔掉，怎么放最省地方？普通做法是把小票一张张贴满货架，聪明做法是把同类小票摞起来真空打包，每隔一段时间再合并成“标准箱”。仓库省不省空间，全看打包手艺——这就是存储引擎的压缩与分块能力。

存储引擎决定三件事：磁盘占用、写入吞吐、查询时的读取模式，三件事最终都换算成钱。VictoriaMetrics 使用自研存储格式：时间戳做 delta/delta-delta 编码，浮点数值做 XOR 压缩，整体压缩率常有 8~10 倍；小数据块写入后周期性 merge 成大块；内存中维护倒排索引，大多数查询无需读盘。Thanos 直接复用 Prometheus 的 TSDB 格式：样本按 2 小时切一个 block，block 内同样做 delta + XOR 压缩，压缩率约 3~4 倍；block 上传对象存储后由 Compactor 合并与降采样，block 越多查询要触碰的文件越多。Mimir 的 chunk 格式与 TSDB 兼容，压缩率介于两者之间，但靠对象存储的分布式能力兜底。

真空打包 vs 普通纸箱：同样囤三年小票，VM 的仓库可能只要 Thanos 一半的面积——省房租是好消息，代价是打包机（CPU）得更卖力。这个交换划不划算，看你的账单结构。

Sstored=Nseries×T×fs×16 BρS_{\text{stored}} = \frac{N_{\text{series}}\times T \times f_s \times 16\,\text{B}}{\rho}
  1. 序列数 N_series有多少条小票流水线，一百万条序列意味着有一百万个类目要分别记账。
    NseriesN_{\text{series}}
  2. 总样本数 T × f_s保留时长（秒）乘以每秒采样次数，得到保留期内产生的总样本数量。
    Ntotal=T×fsN_{\text{total}} = T \times f_s
  3. 原始样本 16 字节时间戳 8 字节加数值 8 字节的朴素编码，是压缩前的“一张小票”大小。
    8 B+8 B8\,\text{B} + 8\,\text{B}
  4. 压缩率 ρ原始大小与磁盘真实占用之比，VictoriaMetrics 约 8~10，TSDB 约 3~4。
    ρ=SrawSstored\rho = \frac{S_{\text{raw}}}{S_{\text{stored}}}

查询性能表现

顾客来查“上周二下午三点，全城所有门店的矿泉水销量”。中心仓（VictoriaMetrics）的货架编号清晰，直接冲向对应货位一口气搬完；加盟联盟（Thanos）得先打电话给各家门店，等他们把照片发来，再拼好答案——电话越多，等得越久。

查询路径一般分四步：解析 PromQL → 定位涉及的序列 → 读取对应数据块 → 聚合计算。三者的差异集中在“定位”和“读取”两步。VictoriaMetrics 的倒排索引常驻内存，定位序列是纯内存操作；最近数据在缓存里，旧数据从压缩块中顺序读取一大片，并行扫描充分压榨 CPU。Thanos 的 Querier 把查询并发扇出到所有 Store 网关与 Sidecar，再由网关从对象存储拉取 block——每个 GET 都有网络往返延迟，block 越多延迟越明显，这正是 Compactor 存在的意义：把无数通小电话合并成几通大电话。Mimir 的查询路径与 Thanos 类似，但调度与缓存更激进，查询结果缓存命中率高。

查询性能的敌人是“把答案拆得太碎”。VM 用内存索引加大块读取胜，Thanos 用 Compactor 与缓存把碎电话合并成几通大电话——理解了这两条路，你就理解了大部分查询调优手段。

Qcost=∑b∈Bseriesseek(b)+∑i=1nmergeiQ_{\text{cost}} = \sum_{b \in B_{\text{series}}} \text{seek}(b) + \sum_{i=1}^{n} \text{merge}_i
  1. 分块集合 B_series一条序列被切成的 block 数量，block 越少越好。
    BseriesB_{\text{series}}
  2. 定位开销 seek(b)访问一个 block 的开销，在对象存储上通常等同一次网络往返。
    seek(b)≈RTT\text{seek}(b) \approx RTT
  3. 合并开销 merge_i多个分片或副本返回后，按时间合并排序与去重的开销。
    mergei=排序+去重\text{merge}_i = \text{排序} + \text{去重}
  4. 下采样加速把老数据粒度从 5 秒拉粗到 1 分钟，需要扫描的 block 数大幅减少。
    B′=Bdownsample_ratioB' = \frac{B}{\text{downsample\_ratio}}

扩展与高可用

生意做到全国，一个仓库不够就要多开。中心仓（VictoriaMetrics）的做法是把仓库拆成收货、货架、柜台三个部门，各部门加人即可；加盟联盟（Thanos）天然是多家店，要做的是“双店同货、总部去重”；云物流（Mimir）则全球布点，哪个区域爆单自动调配。

扩展（scale-out）解决容量上限，高可用（HA）解决单点故障，两者共同决定系统能不能在凌晨三点出问题时还不惊动你。VictoriaMetrics 集群模式下，vminsert 按一致性哈希把数据分片到各 vmstorage，vmselect 负责聚合查询，任何存储节点挂掉，分片都会自动转移。Thanos 的多 Prometheus 各自抓取天然是分区；要做高可用，就双跑 Prometheus 抓同一批目标，再由 Querier 按副本标签去重。Mimir 原生多租户，每个租户配额独立，数据多副本写入，查询自动去重，节点故障由 Kubernetes 重新调度。

“双店同货”让任何一家店关门都不影响营业，但别忘了总部要去重——否则同一笔账会被算两次。副本数量不是越多越好，每个副本都意味着双倍的抓取带宽和存储成本。

A=1−(1−pnode)nreplicaA = 1 - (1 - p_{\text{node}})^{n_{\text{replica}}}
  1. 单节点故障概率 p_node一台机器硬件损坏或进程崩溃的可能性。
    pnodep_{\text{node}}
  2. 副本数 n_replica同一批数据被几个独立节点抓取或写入，副本越多越稳。
    nreplican_{\text{replica}}
  3. 全部故障概率 (1-p)^n所有副本同时挂掉的概率，副本越多这个值越小。
    (1−pnode)nreplica(1-p_{\text{node}})^{n_{\text{replica}}}
  4. 可用性 A至少一个副本活着的概率，即服务对外的可用性。
    A=1−(1−pnode)nA = 1 - (1-p_{\text{node}})^n

运维成本

选仓库方案，不能只看租金。中心仓一个人能管，加盟联盟要养各区管理员再加总部调度员，云物流看似租金高但省了全部人力。运维成本是“看得见的账单”与“看不见的加班”之和，也是最容易被新手低估的一项。

运维成本可以拆成四件套：资源占用（CPU/内存/磁盘）、自身可观测性、升级维护、迁移代价。VictoriaMetrics 单机版内存占用非常克制，几十万序列用一台 8G 内存的虚机也能跑；升级就是替换一个二进制；它兼容 Prometheus HTTP API，从 Prometheus 迁入只需加一行 remote write 配置。Thanos 组件多，每个组件都要接入监控、日志与告警；升级要按 Sidecar→Store→Querier→Compactor 的顺序编排，版本互相约束；它还依赖对象存储，读流量费用随查询量上涨。Mimir 若用托管版几乎零运维，自托管则要维护 Kubernetes operator、多副本与租户配额，复杂度转移到 K8s 平台本身。

别被“组件越多越牛”骗了——每多一个组件，都是给未来的自己多加一次夜班。选型时把四类成本列成表，你的第一感觉往往和最终账单差距很大。

Ctotal=Ccompute+Cstorage+Cnetwork+CopsC_{\text{total}} = C_{\text{compute}} + C_{\text{storage}} + C_{\text{network}} + C_{\text{ops}}
  1. 计算成本 C_computeCPU 与内存开销，与压缩率正相关，压缩越狠 CPU 越忙。
    CcomputeC_{\text{compute}}
  2. 存储成本 C_storage磁盘或对象存储费用，与压缩率反相关，是压缩最直接的省钱来源。
    CstorageC_{\text{storage}}
  3. 网络成本 C_network对象存储读得多、跨区复制多，流量费就高。
    CnetworkC_{\text{network}}
  4. 人力成本 C_ops每多一个组件，排障与升级的工时随之上涨，是隐性的大头。
    CopsC_{\text{ops}}

选型决策

三家仓库方案摆在面前：小本买卖自建中心仓，连锁网络用联盟，全球巨头全托管。没有最好的仓库，只有最匹配生意规模的方案。选型不是比谁参数好看，而是比谁更贴合你的“货量、人力和预算”。

把选型拆成四个维度打分：规模适应力、运维简单度、总成本、生态成熟度，再按团队真实情况分配权重。推荐边界大致如下：单集群百万级以内序列、资源受限、团队小，选 VictoriaMetrics，极简部署且查询快；已有多个 Prometheus 集群、需要统一全局查询、已有对象存储和专职监控团队，选 Thanos；SaaS 多租户、K8s 原生、预算充足想免运维，选 Mimir（托管版）。无论选谁，先小流量试运行两到三周，重点验证写入是否追平、长跨度查询延迟、磁盘增长曲线、升级流程是否顺手。

架构没有银弹，只有匹配。把“我们到底有多少货、多少人、多少钱”这三个问题想清楚，选型就成了一道送分题。想不清楚的时候，回去看那张评分矩阵，别凭感觉拍板。

Scorei=∑j=14wj×rij,∑j=14wj=1\text{Score}_i = \sum_{j=1}^{4} w_j \times r_{ij},\quad \sum_{j=1}^{4} w_j = 1
  1. 方案下标 iVictoriaMetrics、Thanos、Mimir 各占一行。
    i∈{VM,Thanos,Mimir}i \in \{\text{VM}, \text{Thanos}, \text{Mimir}\}
  2. 维度下标 j规模适应、运维简单、总成本、生态成熟四个维度。
    j∈{1,2,3,4}j \in \{1,2,3,4\}
  3. 权重 w_j团队最在意什么就给谁更大的权重，所有权重加起来为 1。
    ∑j=14wj=1\sum_{j=1}^{4} w_j = 1
  4. 单项得分 r_ij方案 i 在维度 j 上的 1~5 分打分，例如“运维极简”给 VM 打 5 分。
    rij∈[1,5]r_{ij} \in [1,5]

AI 应用场景

万人规模 Kubernetes 集群监控存储

阶段：指标采集与存储（可观测性数据底座）

解决的问题：上万 Pod 每 15 秒上报一次指标，Prometheus 单机内存吃紧、历史数据查询超时。传统方案堆多套 Prometheus 导致告警规则重复、查询入口分散。引入 VictoriaMetrics 统一存储，Prometheus 通过 remote write（远程写入）把数据推给它，十万级序列单机即可承载，查询从分钟级降到秒级。

具体案例：某互联网公司 3000 节点 K8s 集群，原先 6 套 Prometheus 各自为政；改造成 2 个 Prometheus 抓取 + VictoriaMetrics 单机存储后，Grafana 全链路统一查询，磁盘占用降为原来的约 1/6，SRE 值班电话明显减少。

多集群、多云统一可观测性查询

阶段：全局统一查询与长期历史分析（跨数据源联邦）

解决的问题：公司在三个公有云加自建机房各有一套 Prometheus，业务方要求“一个 Grafana 看全球”。传统做法是人肉切换数据源、跨区导出数据，效率低且容易漏。采用 Thanos 联邦后，各集群 Prometheus 配 Sidecar，历史数据块进对象存储，Querier 提供单一 PromQL 入口。

具体案例：某出海电商在 5 个 region 部署 Prometheus + Thanos，全局面板统一查询，跨 region 的容量规划与故障排查基于同一份数据完成，季度大促前的容量评估从一周缩短到半天。

SaaS 化可观测性平台的多租户底座

阶段：多租户托管存储与隔离（平台即服务）

解决的问题：对外输出监控能力时，每个客户一套 Prometheus 不可持续：成本爆炸、租户互相干扰。Mimir 原生多租户加对象存储，租户间配额隔离，查询互不感知，计费也能按租户维度拆分。

具体案例：某监控 SaaS 厂商用 Grafana Mimir 支撑上千租户，每个租户独立指标配额与保留策略，平台统一账单与容量规划，新租户开通从半天缩短到分钟级。

Python 演示

python39 行
# 时序数据库选型助手: 存储估算 + 决策矩阵 def estimate_disk(series_count, scrape_interval, retention_days,                  compression_ratio, bytes_per_sample=16):    samples_per_second = series_count / scrape_interval    seconds_total = retention_days * 86400    raw_bytes = samples_per_second * seconds_total * bytes_per_sample    stored_bytes = raw_bytes / compression_ratio    return raw_bytes / 1024**3, stored_bytes / 1024**3 def show_estimate():    print("== 场景: 10万序列, 15s抓取, 保留30天 ==")    for name, ratio in [("VictoriaMetrics", 8.0),                        ("Thanos(TSDB块)", 3.5),                        ("原始不压缩", 1.0)]:        raw, stored = estimate_disk(100000, 15, 30, ratio)        print("%s: 原始 %.1f GB -> 存储 %.1f GB" % (name, raw, stored)) def decision_matrix(weights, scores):    print("\n== 选型评分矩阵(权重之和应为1) ==")    best_name, best_score = None, -1.0    for name, row in scores.items():        total = sum(w * s for w, s in zip(weights, row))        print("%s: %.2f 分" % (name, total))        if total > best_score:            best_name, best_score = name, total    print("推荐方案:", best_name)    return best_name if __name__ == "__main__":    show_estimate()    # 维度顺序: 规模适应, 运维简单, 总成本, 生态成熟    weights = [0.35, 0.30, 0.20, 0.15]    scores = {        "VictoriaMetrics": [5, 5, 4, 3],        "Thanos":          [3, 3, 3, 5],        "Mimir":           [4, 4, 2, 4],    }    decision_matrix(weights, scores)
目的：根据序列数、抓取周期、保留时长估算三种方案的磁盘占用，并用加权评分矩阵辅助选型决策。
  1. samples_per_second = series_count / scrape_interval每秒产出的样本数，是存储估算的起点。
  2. raw_bytes = samples_per_second * seconds_total * bytes_per_sample样本数乘 16 字节，得到未压缩的理论容量。
  3. stored_bytes = raw_bytes / compression_ratio除以压缩率就是真实磁盘占用，对应正文的存储公式。
  4. for name, ratio in [("VictoriaMetrics", 8.0), ...]压缩率字典：VM 最高（8），TSDB 块约 3.5，不压缩为 1 作为对照组。
  5. total = sum(w * s for w, s in zip(weights, row))权重与评分逐维相乘再求和，实现选型评分矩阵。
  6. if __name__ == "__main__":保证脚本既可被 import 也能直接运行，方便接入选型流程。

常见误区

误区“Thanos 就像 Prometheus 的替代品，装上它就能直接存数据，Prometheus 可以扔掉了。”

正解Thanos 更像加盟总部的“调度中心”而不是仓库本身。它不负责抓取，也不直接落地存储；数据仍旧由 Prometheus TSDB 写成 block，再经 Sidecar 上传对象存储。Thanos 补的是“统一查询 + 长期保留”这两个 Prometheus 单机给不了的能力。把 Thanos 当存储引擎用，会漏掉它真正的价值。

为何常见：名字带“数据库”后缀、文档又与 Prometheus 深度绑定，初学者容易把它等同于存储层。

误区“VM 只有一个二进制，所以数据量一大就只能换 Thanos 或 Mimir。”

正解单机版确实主打极简，但 VM 也有 cluster 模式：vminsert 分片写入、vmstorage 分布式存储、vmselect 并行查询，三者都能横向扩。而且单机版本身就能扛几十万到上百万序列，对多数团队来说单机已是天花板。先测数据量再谈扩展，别被“单机”两个字劝退。

为何常见：官方长期把单机版当默认推荐，集群模式藏在文档深处，存在感极低。

误区“选型时磁盘占用越小的方案越优，压缩率是硬指标。”

正解压缩是用 CPU 换磁盘：写路径要编码、读路径要解码，压缩率开到极限，查询延迟和 CPU 账单都会上来。VM 之所以快，不是单纯因为压缩狠，而是“内存索引 + 高压缩 + 顺序读大块”三者配合。评估压缩率一定要连同查询延迟一起测，不能只看数字。

为何常见：磁盘账单直观可见，CPU 与延迟成本隐藏在监控曲线里，人天然被显性数字吸引。

误区“Thanos / Mimir 把 block 放 S3，S3 有三副本，所以服务一定高可用。”

正解对象存储解决的是“数据不丢”，不等于“查询可用”。查询链路仍依赖 Store 网关、Querier、Compactor 等无状态服务的冗余部署；跨区域复制、副本去重、租户配额都要主动设计。把数据托付给云，不等于把架构责任也托付给云。

为何常见：云厂商"99.999999999%"持久性宣传深入人心，容易把持久性误当成整个系统的可用性。

面试题

Q1. 在时序数据库中，一条时间序列（series）由什么唯一确定？

单选题 · easy

  • A.指标名加全部标签← 正确答案
  • B.只由指标名决定
  • C.只由标签集合决定
  • D.由采样时间戳决定

答案：A。指标名加全部标签共同决定一条唯一序列；即使指标名相同，标签值不同也是不同的序列。就像同一家店卖的同一商品，不同门店的小票必须分开记账。只靠指标名或只靠标签都会串线。

Q2. Thanos 在整个监控体系中的核心定位是什么？

单选题 · easy

  • A.独立的存储引擎
  • B.Prometheus 的查询扩展层← 正确答案
  • C.替代数据的采集器
  • D.云上的对象存储

答案：B。Thanos 不采集也不直接存储，它的 Querier 把多个 Prometheus 与对象存储统一成全局查询入口。这类似加盟总部的调度中心，各门店账本还是各店自己记，总部只负责统一查账和对账。

Q3. VictoriaMetrics 单机版最典型的优势是？

单选题 · easy

  • A.单二进制部署极简← 正确答案
  • B.组件越多扩容越强
  • C.必须依赖对象存储
  • D.只能接收远程写入

答案：A。一个二进制搞定抓取、存储、查询、告警，中规模监控几十分钟就能搭好。B 说反了，组件多是 Thanos 的特征；C 与 D 都是错误特征。VM 不强制依赖对象存储，也支持抓取与远写两种写入方式。

Q4. Thanos Store Gateway 的主要职责是什么？

单选题 · mid

  • A.读取对象存储中历史数据块← 正确答案
  • B.负责抓取指标数据的采集
  • C.合并副本数据并去重
  • D.替代网关执行全部查询

答案：A。Store Gateway 是“历史档案管理员”，从 S3/GCS 读旧数据块提供给 Querier。抓取是 Prometheus 的职责，去重是 Querier 的功能，D 的“全部查询”也夸大了它的职责。

Q5. 关于时序数据压缩的正确理解是？

单选题 · mid

  • A.压缩率越高查询一定越快
  • B.用 CPU 开销换取磁盘空间← 正确答案
  • C.压缩不影响任何查询性能
  • D.高压缩必须依赖对象存储

答案：B。压缩能大幅降低磁盘占用，但写入要编码、读取要解码，CPU 开销上升，因此“越高越快”和“不影响性能”都不成立。高压缩是存储格式设计的事，与是否用对象存储无关。

Q6. VictoriaMetrics 集群模式下承担数据存储的组件是？

单选题 · mid

  • A.vmstorage 存储节点← 正确答案
  • B.vminsert 写入节点
  • C.vmselect 查询节点
  • D.vmagent 采集节点

答案：A。vminsert 是收货台（分片写入），vmstorage 是货架（实际存储），vmselect 是柜台（聚合查询），vmagent 是采集器。类比仓库就很好记：货架 vmstorage 才是放小票的地方。

Q7. 10 万条序列、抓取周期 15 秒、保留 30 天，每样本 16 字节，按 8 倍压缩，需要存储约多少？

单选题 · hard

  • A.约 35 GB← 正确答案
  • B.约 280 GB
  • C.约 1.1 TB
  • D.约 6 TB

答案：A。每秒样本数 100000/15≈6667 个；30 天共 6667×86400×30≈1.73×10^10 个样本；原始 16 字节约 276 GB；除以压缩率 8 得约 34.5 GB。B 是未压缩的原始量，属于常见计算错误。

Q8. 下列哪些场景更适合选择 VictoriaMetrics？（多选）

多选题 · mid

  • A.单集群上百万序列监控← 正确答案
  • B.资源受限且要低内存← 正确答案
  • C.多集群统一全局查询
  • D.追求极简单体运维← 正确答案

答案：ABD。大序列量、低内存、简单运维都是 VM 的强项。C 的“多集群统一全局查询”更偏向 Thanos 或 Mimir 的联邦与多租户能力——单机形态的 VM 很难跨集群汇聚数据。

Q9. 下列属于 Thanos 核心组件的有哪些？（多选）

多选题 · mid

  • A.Sidecar 上传数据块到对象存储← 正确答案
  • B.Store 网关读取历史数据块← 正确答案
  • C.Compactor 合并块与下采样← 正确答案
  • D.Grafana 负责指标采集

答案：ABC。Thanos 核心组件包括 Sidecar、Store 网关、Querier、Compactor 以及可选的 Receive。Grafana 是可视化工具，不负责采集，也不属于 Thanos 组件体系，因此 D 错误。

Q10. 实现高可用时序监控的正确设计包括哪些？（多选）

多选题 · hard

  • A.双采集副本加查询去重← 正确答案
  • B.合并小分块加下采样← 正确答案
  • C.单节点单副本存储
  • D.多租户配额与隔离← 正确答案

答案：ABD。双跑 Prometheus 加 Querier 按副本标签去重，保证数据一致；Compactor 合并分块与降采样，降低查询开销；多租户配额防止租户互相干扰。C 的单节点单副本正是高可用要避免的反模式。