Prometheus 的内存占用主要来自两个方面：(1) 索引块（Index）全量 mmap 到内存；(2) 数据块（Chunks）按时间窗口预加载。而 VictoriaMetrics 通过 TSIDCache 只缓存热点索引，通过 blockCache 只缓存热点数据块，显著降低了内存占用。

对比维度	Prometheus TSDB	VictoriaMetrics MergeSet
索引存储	Index 段文件全量 mmap	倒排索引 + TSIDCache 热缓存
数据存储	Chunks 按时间窗口预加载	Parts 按需加载到 blockCache
内存策略	内存优先，尽量放内存	分层缓存，热数据在内存
磁盘空间	标准压缩	commonPrefix + NearestDelta + ZSTD

我理解源码的意思是说

两种内存策略可以类比为图书馆管理——一个是"桌面堆书"模式，一个是"图书馆借阅系统"模式。

• Prometheus = 把整本书放在桌上：想象你在图书馆的自习室，你的桌子上堆满了书——不是一本一本看，而是把可能用到的书全部摆在桌上。问题是桌子空间有限，书越来越多桌子就满了。一本书（一个 time series）要么全在内存（桌上），要么不在（书架上）。这种模式的优点是"翻书快"，缺点是"桌子要很大"。
• VictoriaMetrics = 图书馆借阅系统：想象你有一个智能图书馆系统。桌子上只放当前正在看的书（热点数据）和目录卡片抽屉（TSIDCache）。想看哪本书？先查目录卡片（metricName → TSID），然后去书架上拿（从磁盘读取）。看完放回书架，桌子保持整洁。书架（磁盘）可以很大，但桌子（内存）不需要那么大。

blockCache 三层的理解：

• ibCache（25%） = 桌面上放着的"当前在看的书"——数据块内容，频繁访问
• idxbCache（10%） = 桌上另一角放着的"书的目录页"——索引块内容，查询时必读
• ibSparseCache（5%） = 桌上的"便签纸"——ibCache 的稀疏访问优化，存放不常用但偶尔要翻的页

为什么 VM 更省内存？

Prometheus 的内存策略是"尽量把书放桌上"——索引全量 mmap（把所有书名都记在脑子里），数据块按时间窗口预加载（提前把可能看的书都摆出来）。结果是：内存大 = 能放更多书，内存小 = 频繁换书（page fault）。

VictoriaMetrics 的内存策略是"按需借书"——只把热点数据放桌上（TSIDCache + blockCache），冷数据在书架上（磁盘）。结果是：内存小也能工作，只是偶尔要去书架拿书（磁盘 I/O）。这就是"省 7x RAM"的本质——不是压缩数据，而是减少常驻内存的数据量。

必记闭环逻辑（核心考点）

VictoriaMetrics 省 7x RAM 来自三大设计的协同：(1) MergeSet LSM-less 只合并不分层，减少遍历开销；(2) TSIDCache 37% 策略优先缓存 metricName → TSID 映射；(3) blockCache 三层（ibCache 25% + idxbCache 10% + ibSparseCache 5%）按需缓存数据块。

五、典型应用场景：谁在使用 VictoriaMetrics？

思考记忆提示 — 本节帮助你理解 VM 的适用场景，避免"锤子思维"——把所有问题都当作钉子

• VM 适合：大规模长期监控、多租户环境、Grafana 集成
• VM 不适合：超低延迟交易系统、需要强事务的场景
• 面试高频提问：什么场景适合用 VictoriaMetrics？它和 InfluxDB/Thanos 怎么选？

VictoriaMetrics 已经在生产环境中被多家知名公司使用。以下是典型的应用场景：

5.1 适用场景

• 大规模 Prometheus 长期存储：当 Prometheus 的本地存储无法满足长期数据保留需求时，VM 作为 remote_write 后端提供无限存储。
• 高 Cardinality 环境：如 Kubernetes 监控、Service Mesh 可观测性，标签值众多导致 Prometheus OOM，VM 通过 BloomFilter 动态调整基数限制。
• 多租户监控平台：通过 accountID/projectID 实现资源隔离，适合 SaaS 或内部监控平台。
• Grafana 集成：原生支持 Prometheus 数据源，Grafana 用户零成本迁移。

5.2 知名用户案例

公司	使用规模	使用场景
字节跳动	数十亿 series	抖音/头条基础设施监控
阿里巴巴	数亿 series	电商平台核心系统监控
腾讯	数百万 series	微信/游戏基础设施监控
小米	大规模	IoT 设备时序数据监控

小贴士

如果你正在使用 Prometheus + Thanos/Mimir，并且遇到了扩展性或成本问题，VictoriaMetrics 是一个值得评估的替代方案。VM 的存储效率通常比 Thanos + Prometheus 高 5-10 倍。

必记闭环逻辑（核心考点）

VictoriaMetrics 的最佳场景是大规模 Prometheus 长期存储（> 100 万 series）、高 Cardinality 环境和多租户监控平台。它不适合需要强事务或超低延迟的交易系统。字节跳动、阿里巴巴、腾讯、小米 等公司已在生产环境验证了 VM 的能力。

六、学习路线图：如何高效阅读这个专题

思考记忆提示 — 本节提供学习路径建议，帮助你高效利用这个专题

• 建议从 A 架构设计篇（#01-#15）开始，建立全局认知
• 按需深入 C 存储引擎篇（#41-#55），理解性能基础
• 面试高频提问：如何快速理解 VictoriaMetrics？如何阅读它的源码？

250 篇源码专题内容很多，如何高效学习？以下是推荐的学习路径：

6.1 第一阶段：建立全局认知（#01-#15，约 1 周）

这一阶段的目标是理解 VictoriaMetrics 是什么、整体架构是怎样的、为什么能省 7x RAM。重点文章：

• #01 设计哲学：理解 VM 的核心优势来源
• #02 全局架构：Single-Node vs Cluster 模式
• #04 整体数据流：数据从写入到存储的全链路
• #05 版本演进：了解 1.146.0 LTS 的重大变化
• #09 性能模型：理解性能常数的来源

6.2 第二阶段：深入核心原理（#41-#70，约 2 周）

这一阶段的目标是理解 MergeSet 存储引擎和查询引擎的内部原理。重点文章：

• #41 MergeSet vs LSM Tree：理解 VM 的核心存储设计
• #47 commonPrefix 压缩：存储空间减少 30-50% 的原理
• #51 6 种压缩算法：NearestDelta 是核心
• #56 PromQL 执行引擎：查询如何执行
• #64 并发控制：concurrencyLimitCh 令牌桶

6.3 第三阶段：进阶专题与运维实践（#116-#145，约 2 周）

这一阶段的目标是具备生产环境的故障诊断和运维能力。重点文章：

• #117 bytesutil 零拷贝：unsafe.Pointer 高性能编程
• #122 persistentqueue：磁盘可靠消息队列
• #127 histogram_quantile：P99 分位数计算原理
• #104 Cardinality 爆炸：最常见的 OOM 原因
• #107 内存调优：memory.Allowed() 计算
• #131 从 Prometheus 迁移：vmctl 使用
• #135 容量规划：硬件选型参考

6.4 第四阶段：源码追踪（#161-#175，约 2 周）

这一阶段的目标是具备独立阅读和理解源码的能力。重点文章：

• #161 HTTP 到 Part 文件：完整写入链路追踪
• #162 PromQL 到结果：完整查询链路追踪
• #163 Part 四文件结构：二进制格式详解
• #165 indexDB 8 种索引前缀：Tag 查询完整路径
• #170 TSIDCache 37% 计算：内存分配逻辑

我理解源码的意思是说

学习 VictoriaMetrics 就像学习一门武功——有内功、有招式、有实战、有闭关修炼。四个阶段，层层递进，不可跳级。

• 第一阶段（#01-#15） = 看武功秘籍的"总纲 + 概述"。这套武功叫什么名字（VictoriaMetrics）、能做什么（高性能时序数据库）、核心原理是什么（MergeSet 存储引擎）。目标：建立全局认知，知道 VM 的轮廓，不要纠结细节。读完这个阶段，你应该在纸上能画出 VM 的三层架构图（vminsert/vmstorage/vmselect）。
• 第二阶段（#41-#70） = 修炼"内功心法 + 基本招式"。内功心法是"存储引擎"（MergeSet 原理、LSM-less 设计、压缩算法）——告诉你 VM 为什么能省 7x RAM；基本招式是"查询引擎"（PromQL 执行、并行归并）——告诉你查询是怎么执行的。目标：理解性能基础，能回答"为什么 VM 这么快"。这个阶段需要配合源码阅读，边看边调试。
• 第三阶段（#116-#145） = 修炼"进阶招式 + 下山历练"。进阶招式是"bytesutil/persistentqueue/histogram_quantile"——深入理解核心库的原理；下山历练是"排障调优 + 运维实践"——学会在实际环境中部署、监控、故障诊断。目标：具备生产环境的实战能力，能解决实际问题。这个阶段需要动手操作，搭建测试环境，模拟故障场景。
• 第四阶段（#161-#175） = 回山闭关，亲手推导武功秘籍。完整追踪一条数据的旅程：从 HTTP 入口到 Part 文件，从 PromQL 解析到结果返回。目标：具备独立阅读和理解源码的能力。前面三个阶段是"看别人写的秘籍"，这个阶段是"自己推导秘籍的原理"。

避坑提醒：

• 不要跳阶段！武功要一层层练，心急吃不了热豆腐。没有全局认知，直接看源码会迷失；没有实战经验，直接追踪源码会缺乏上下文。
• 每个阶段都要配合动手。只看不动手 = 纸上谈兵。建议每篇都 clone 源码，边看边调试。
• 遇到不懂的名词不要慌。先记下来，继续往下看。有时候后面的内容会帮你理解前面的概念。
• 附录是工具书，不是必读内容。遇到问题时再查，不需要提前背下来。

学习时间参考：

• 快速入门（#01-#15）：约 1 周，每天 1-2 小时
• 深度理解（#41-#70）：约 2 周，每天 2-3 小时
• 实战进阶（#101-#145）：约 2 周，每天 2-3 小时 + 动手实践
• 源码追踪（#161-#175）：约 2 周，每天 3-4 小时 + 阅读源码

必记闭环逻辑（核心考点）

高效学习路径：先用 A 架构设计篇建立全局认知（#01-#15），再用 C 存储引擎篇 + D 查询引擎篇理解性能基础（#41-#70），接着通过 H 进阶专题（#116-#130）和 G/I 排障调优和运维实践培养实战能力（#101-#145），最后用 K 源码追踪深入理解内部原理（#161-#175）。