这是 VictoriaMetrics 深度技术系列的开篇索引文章。如果你正在寻找一个高性能、节省资源的时序数据库（TSDB）解决方案；如果你想知道 Prometheus 的"增强版"到底强在哪里；如果你渴望深入理解 MergeSet 存储引擎、LSM-less 设计、7x RAM 节省背后的工程原理——那么这个系列将带你从源码层面彻底读懂 VictoriaMetrics。
本系列基于 VictoriaMetrics v1.146.0 LTS 版本（Long-Term Support），共规划 200 篇正文 + 10 篇附录，覆盖架构设计、组件原理、存储引擎、查询引擎、工具链、运维实践、排障调优等 14 个维度。每一篇都从源码出发，兼顾理论深度和实战落地。
VictoriaMetrics 时序数据库 Prometheus MergeSet 云原生监控 Go 存储引擎 v1.146.0 LTS
学习重点提示
系列核心价值（必须掌握）
- 架构设计哲学：理解 VM 为什么能做到比 Prometheus 省 7x RAM（MergeSet vs TSDB、LSM-less 设计）
- 存储引擎原理：MergeSet 只合并不分层的 LSM-less 设计，commonPrefix 压缩，NearestDelta 编码
- 完整组件体系：vminsert/vmselect/vmstorage 三层架构，12 种协议接入，Cluster 模式
- 性能优化方法论：TSIDCache 37% 策略、blockCache 三层设计、rawItemsShards 分片
系列扩展知识（了解即可）
- VictoriaLogs 日志一体化监控
- Enterprise vs OpenSource 功能差异
- vmagent/vmalert/vmauth/vmbackup 工具链
- 与其他 TSDB（InfluxDB/Thanos/Mimir）的对比
文章目录
思考记忆提示 — 本节是系列的"入口"——弄清楚 VM 是什么、解决了什么问题，才能理解后面每篇的定位
VictoriaMetrics（简称 VM）是一个开源的时序数据库（Time Series Database, TSDB），专门为云原生监控场景设计。它与 Prometheus 完全兼容，支持 Prometheus remote_write 协议、Grafana 数据源、以及 PromQL 查询语言。但 VM 的野心不止于"兼容"——它要做的是在保持兼容性的同时，大幅超越 Prometheus 的性能和资源效率。
我的理解的意思是说
可以把 VictoriaMetrics 想象成一个超级版 Prometheus：
VictoriaMetrics 由 Aliaksandr Valialkin 于 2019 年创建，最初是为了解决 Promscale（InfluxDB on PostgreSQL）的性能和存储成本问题。经过多年发展，VM 已经成为 CNCF 生态中最受欢迎的时序数据库之一，GitHub 超过 15k stars，被 Spotify、Roblox、Grammarly、DoorDash 等知名公司采用。
为什么选择 VictoriaMetrics 而不是 Prometheus 原生？以下四个优势是 VM 脱颖而出的关键：
设计精髓
VictoriaMetrics 的设计哲学是：在不牺牲兼容性的前提下，用更少的资源做更多的事。这体现在四个维度：存储效率（MergeSet 压缩）、内存效率（LSM-less + 缓存策略）、查询性能（并行 k-way 归并）、扩展性（Cluster 模式）。
| 维度 | Prometheus | VictoriaMetrics | 提升幅度 |
|---|---|---|---|
| RAM 占用 | 全量数据常驻内存 | TSIDCache 37% + blockCache 分层 | 省 7x |
| 水平扩展 | 不支持（单机） | Cluster 模式支持 | 无限扩展 |
| 长期存储 | 需要 Thanos/Mimir | 内置 retention | 原生支持 |
| Cardinality | 有限制 | BloomFilter 动态调整 | 更高上限 |
理解 VictoriaMetrics 和 Prometheus 的关系非常重要：VM 不是要替代 Prometheus，而是要解决 Prometheus 的局限性。Prometheus 仍然是一个优秀的抓取和告警工具，但它的本地存储不适合大规模长期存储。VictoriaMetrics 提供了两种集成方式：
注意
VictoriaMetrics 不是 Prometheus 的 fork，而是一个完全独立的实现。VM 使用了完全不同的存储引擎（MergeSet vs Prometheus TSDB），但通过完整实现 Prometheus 的 API（/api/v1/*）和协议（remote_write）来实现兼容性。
必记闭环逻辑（核心考点）
VictoriaMetrics 是一个与 Prometheus 完全兼容的时序数据库，通过 MergeSet 存储引擎和 LSM-less 设计实现比 Prometheus 省 7x RAM，同时支持 Cluster 模式无限水平扩展。它不是 Prometheus 的替代品，而是 Prometheus 的"超级增强版后端"。
思考记忆提示 — 本节是系列的"地图"——快速定位你需要的文章，避免迷失在 200 篇的海洋里
200 篇听起来很多，但通过 14 个维度的组织，每一篇都有清晰的定位。以下是每个维度的定位和推荐阅读顺序：
| 维度 | 篇数 | 定位 | 推荐阅读 |
|---|---|---|---|
| A. 架构设计篇 | 15 | 全局架构、设计哲学、组件关系 | #01-#15 必读（建立全局认知） |
| B. 组件深潜篇 | 25 | 按组件垂直深挖源码实现 | #16-#40（深入理解核心组件） |
| C. 存储引擎篇 | 15 | storage/mergeset/encoding/cache | #41-#55 核心（理解性能基础） |
| D. 查询引擎篇 | 15 | promql/metricsql/netstorage | #56-#70（查询优化必读） |
| E. 工具链篇 | 20 | vmagent/vmalert/vmauth/vmbackup | #71-#90（运维必备） |
| F. 集成生态篇 | 10 | Grafana/k8s/Prometheus Operator | #91-#100（快速上手） |
| G. 排障调优篇 | 15 | 慢查询/cardinality/OOM/写入瓶颈 | #101-#115 实操（问题诊断） |
| H. 进阶专题篇 | 15 | decimal/bytesutil/fastcache/fs | #116-#130（深入理解） |
| I. 运维实践篇 | 15 | 迁移/k8s 部署/容量规划 | #131-#145（生产环境） |
| J. 生产极限篇 | 15 | 10 亿 series/百万 samples-s | #146-#160（大规模场景） |
| K. 源码追踪篇 | 15 | 完整链路追踪：HTTP 到 Part 文件 | #161-#175 硬核（源码阅读） |
| L. VictoriaLogs 协同篇 | 10 | LogQL/指标日志关联 | #176-#185（一体化可观测性） |
| M. 压轴总结篇 | 15 | PromQL 深潜/性能极限/工程哲学 | #186-#200（收尾升华） |
| N. 附录篇 | 10 | 速查地图/API 端点/错误码 | A1-A10 工具书（日常参考） |
我的理解的意思是说
200 篇系列就像一本《VictoriaMetrics 源代码专题研究》：
建议先读 A 架构设计篇（建立全局认知），再按需深入其他章节。
根据不同的学习目标，这里提供三条推荐阅读路径：
必记闭环逻辑（核心考点）
200 篇系列按 14 个维度组织，覆盖理论深度（A-M）和实战落地（G/I）。推荐从 A 架构设计篇开始（建立全局认知），按需深入组件原理（#16-#55）和源码追踪（#161-#175），附录（A1-A10）作为日常工具书参考。
思考记忆提示 — 本节是系列的"骨架"——理解组件体系，后续各篇才有上下文
VictoriaMetrics 的组件体系非常清晰。无论你是使用 Single-Node 模式还是 Cluster 模式，理解这三级架构都是理解 VM 的基础。
VictoriaMetrics 架构分层
│
├── [1] 应用层 (app/)
│ ├── vminsert — 写入接入层（Prometheus/InfluxDB/DataDog/OTel 等 12+ 协议）
│ ├── vmselect — 查询执行层（PromQL/MetricsQL/GraphiteQL + 查询调度）
│ └── vmstorage — 数据存储层（Cluster 模式核心）
│
├── [2] 存储核心层 (lib/storage/)
│ ├── Storage — 全局协调器：分区/缓存/基数限制
│ ├── Table — 表级抽象：按月分区生命周期
│ ├── Partition — 分区级抽象：In-Memory/Small/Big Parts + indexDB
│ └── indexDB — 倒排索引引擎：8 种索引前缀
│
├── [3] MergeSet 存储引擎 (lib/mergeset/)
│ ├── Table — 分片/合并调度/刷盘策略
│ ├── Part — metaindex + index + items + lens 四文件
│ └── InmemoryPart — 内存未排序 Part，1 秒刷新
│
└── [4] 压缩编码层 (lib/encoding/)
├── MarshalType — 6 种压缩类型
└── NearestDelta 算法 — Counter/Gauge 自适应差分编码 + ZSTD
设计精髓
VictoriaMetrics 的核心设计哲学之一是简洁性：Single-Node 模式用同一个进程处理写入、存储、查询三种职责，适合中小规模场景；Cluster 模式将三种职责分离到独立进程，支持水平扩展。这种"单进程可工作，分布式更强大"的设计让 VM 既能简单起步，又能随业务增长平滑升级。
| 特性 | Single-Node | Cluster |
|---|---|---|
| 进程数 | 1 个进程 | 3 种角色：vminsert、vmstorage、vmselect |
| 扩展方式 | 垂直扩展（加 CPU/内存/磁盘） | 水平扩展（增加 vmstorage/vmselect 节点） |
| 适用规模 | < 100 万 series | 100 万 ~ 10 亿 series |
| 部署复杂度 | 极简（一行命令启动） | 中等（需要配置负载均衡） |
| 多租户 | 不支持 | 支持（accountID/projectID 隔离） |
小贴士
如果你的监控规模在 100 万 series 以内，Single-Node 模式通常是最佳选择——部署简单、资源占用低、维护成本小。随着规模增长，再考虑迁移到 Cluster 模式。
一条监控数据从 HTTP 入口到永久存储，需要经过以下步骤：
┌─────────────────────────────────────────────────────────────────────────┐
│ VictoriaMetrics 数据写入流程 │
│ │
│ ┌──────────────┐ Remote Write ┌──────────────┐ │
│ │ Prometheus │ ─────────────────► │ vminsert │ │
│ │ (或 vmagent) │ /api/v1/write │ (写入接入层) │ │
│ └──────────────┘ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Storage │ │
│ │ .addRows() │ │
│ └──────┬───────┘ │
│ │ │
│ ┌────────────────────────┼────────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ │ InMemoryPart │ │ InMemoryPart│ │ InMemoryPart│
│ │ (1秒刷新) │ │ (1秒刷新) │ │ (1秒刷新) │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ rawItemsShards │ rawItemsShards │ │
│ │ (CPU 分片并行) │ (CPU 分片并行) │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ │ Part │ │ Part │ │ Part │
│ │ (四文件结构) │ │ (四文件结构) │ │ (四文件结构) │
│ │ metaindex │ │ metaindex │ │ metaindex │
│ │ index │ │ index │ │ index │
│ │ items │ │ items │ │ items │
│ │ lens │ │ lens │ │ lens │
│ └──────────────┘ └──────────────┘ └──────────────┘
│ │
└─────────────────────────────────────────────────────────────────────────┘
我的理解的意思是说
写入流程可以想象成快递分拣中心：
关键是：分拣台（rawItemsShards）是按 CPU 核心数分片的，所以 VM 的写入性能可以随 CPU 核心数线性扩展。
必记闭环逻辑（核心考点）
VictoriaMetrics 的三层架构（vminsert/vmstorage/vmselect）可以分离部署（Cluster 模式）也可以合一（Single-Node 模式）。数据写入经过：HTTP 入口 → Storage.addRows() → rawItemsShards CPU 分片 → InMemoryPart 1秒刷新 → Part 四文件持久化。
思考记忆提示 — 本节是系列的"亮点"——理解 VM 的核心优势，为后续深入理解存储引擎做铺垫
"比 Prometheus 省 7x RAM"是 VictoriaMetrics 最广为人知的优势。但这不是单一优化点，而是多个设计决策协同工作的结果。
设计精髓
VictoriaMetrics 省 RAM 的核心哲学是：数据按需加载，而非全量常驻。Prometheus 把所有数据块加载到内存（mmap），而 VM 只把热点数据（通过 TSIDCache 和 blockCache）保留在内存，冷数据放在磁盘按需读取。这是典型的"内存-磁盘分层"设计，比 Prometheus 的"内存优先"更节省资源。
设计一：MergeSet vs LSM Tree（LSM-less 设计）
传统的 LSM Tree（如 RocksDB）采用分层合并策略：L0 → L1 → L2 → ... 每层大小呈指数增长，合并时需要同时读取多层数据，内存压力大。VictoriaMetrics 的 MergeSet 采用了只合并不分层的 LSM-less 设计：
设计二：TSIDCache 37% 策略
VictoriaMetrics 把 -memory.allowedDataPointers 的 37% 用于 TSIDCache。TSIDCache 是 metricName → TSID 的映射缓存：
设计三：blockCache 三层设计
blockCache 分为三层，每层缓存不同类型的数据：
| 层级 | 缓存内容 | 内存占比 |
|---|---|---|
| ibCache | 数据块内容（items.bin） | 25% |
| idxbCache | 索引块内容（index.bin） | 10% |
| ibSparseCache | ibCache 的稀疏访问优化 | 5% |
注意
Prometheus 的内存占用主要来自两个方面：(1) 索引块（Index）全量 mmap 到内存；(2) 数据块（Chunks）按时间窗口预加载。而 VictoriaMetrics 通过 TSIDCache 只缓存热点索引，通过 blockCache 只缓存热点数据块，显著降低了内存占用。
| 对比维度 | Prometheus TSDB | VictoriaMetrics MergeSet |
|---|---|---|
| 索引存储 | Index 段文件全量 mmap | 倒排索引 + TSIDCache 热缓存 |
| 数据存储 | Chunks 按时间窗口预加载 | Parts 按需加载到 blockCache |
| 内存策略 | 内存优先，尽量放内存 | 分层缓存，热数据在内存 |
| 磁盘空间 | 标准压缩 | commonPrefix + NearestDelta + ZSTD |
我的理解的意思是说
两种内存策略可以类比为图书馆管理：
TSIDCache 37% 就像是"书的目录卡片抽屉"——虽然书不在桌上，但根据卡片（metricName → TSID）可以快速找到书在哪。
必记闭环逻辑（核心考点）
VictoriaMetrics 省 7x RAM 来自三大设计的协同：(1) MergeSet LSM-less 只合并不分层，减少遍历开销；(2) TSIDCache 37% 策略优先缓存 metricName → TSID 映射；(3) blockCache 三层（ibCache 25% + idxbCache 10% + ibSparseCache 5%）按需缓存数据块。
思考记忆提示 — 本节帮助你理解 VM 的适用场景，避免"锤子思维"——把所有问题都当作钉子
VictoriaMetrics 已经在生产环境中被多家知名公司使用。以下是典型的应用场景：
| 公司 | 使用规模 | 使用场景 |
|---|---|---|
| Spotify | 数十亿 series | 音频流媒体基础设施监控 |
| Roblox | 数百万 series | 游戏平台实时监控 |
| Grammarly | 中等规模 | 写作工具基础设施监控 |
| DoorDash | 大规模 | 外卖平台配送监控 |
小贴士
如果你正在使用 Prometheus + Thanos/Mimir，并且遇到了扩展性或成本问题，VictoriaMetrics 是一个值得评估的替代方案。VM 的存储效率通常比 Thanos + Prometheus 高 5-10 倍。
必记闭环逻辑（核心考点）
VictoriaMetrics 的最佳场景是大规模 Prometheus 长期存储（> 100 万 series）、高 Cardinality 环境和多租户监控平台。它不适合需要强事务或超低延迟的交易系统。Spotify、Roblox、Grammarly、DoorDash 等公司已在生产环境验证了 VM 的能力。
思考记忆提示 — 本节提供学习路径建议，帮助你高效利用这个系列
200 篇系列内容很多，如何高效学习？以下是推荐的学习路径：
这一阶段的目标是理解 VictoriaMetrics 是什么、整体架构是怎样的、为什么能省 7x RAM。重点文章：
这一阶段的目标是理解 MergeSet 存储引擎和查询引擎的内部原理。重点文章：
这一阶段的目标是具备生产环境的故障诊断和运维能力。重点文章：
这一阶段的目标是具备独立阅读和理解源码的能力。重点文章：
我的理解的意思是说
学习 VictoriaMetrics 就像学习一门武功：
不要跳阶段！没有全局认知，直接看源码会迷失；没有实战经验，直接追踪源码会缺乏上下文。
必记闭环逻辑（核心考点）
高效学习路径：先用 A 架构设计篇建立全局认知（#01-#15），再用 C 存储引擎篇理解性能基础（#41-#55），接着通过 G/I 排障调优和运维实践培养实战能力（#101-#145），最后用 K 源码追踪深入理解内部原理（#161-#175）。
思考记忆提示 — FAQ 是全系列的"临考前速背"模块，覆盖最常见的问题
VM 是 Prometheus 的长期存储后端，不是替代品。Prometheus 仍然负责抓取（scraping）和告警评估（alerting），数据通过 remote_write 协议写入 VictoriaMetrics。VM 提供了比 Prometheus 原生存储更高的扩展性和更低的资源占用。
来自三大设计的协同：MergeSet LSM-less + TSIDCache 37% + blockCache 三层。Prometheus 把所有索引和数据块 mmap 到内存，而 VM 只把热点数据（TSIDCache + blockCache）保留在内存，冷数据放在磁盘按需读取。
Single-Node 适合 < 100 万 series，Cluster 适合 100 万 ~ 10 亿 series。Single-Node 是单进程，部署简单；Cluster 模式把 vminsert/vmstorage/vmselect 分离部署，支持水平扩展。
Cluster 模式原生支持多租户，通过 accountID/projectID 实现隔离。每个租户的数据在存储层完全隔离，适合 SaaS 或内部多业务线监控平台。
MergeSet 采用 LSM-less 设计：只合并不分层。LSM Tree（如 RocksDB）有 L0→L1→L2→... 多层合并，开销大；MergeSet 只有 Small Parts 和 Big Parts 两类，查询时只需读最新的 Big Part + 最近的 Small Parts。
commonPrefix 压缩利用标签值的共同前缀来减少存储。例如：metric{job="prometheus",instance="localhost:9090"} 和 metric{job="prometheus",instance="localhost:9091"} 共享 metric{job="prometheus",instance="localhost:909"} 前缀，只需存储一次。
37% 是经验值，经过大量测试发现这个比例能最大化缓存命中率。TSIDCache 缓存 metricName → TSID 映射，是写入和查询的关键路径。37% 的比例在 cache hit rate 和 memory usage 之间取得了最优平衡。
BloomFilter 用于基数限制（cardinality limiting），防止高 cardinality 数据打爆 VM。每个小时和每天的 BloomFilter 会记录见过的 metricIDs，如果某小时 metricID 数量超过限制，会拒绝写入。
没有！这是 VM 的设计选择。Prometheus TSDB 使用 WAL 来保证崩溃恢复，但 WAL 会增加写入延迟。VM 通过 InMemoryPart 每秒刷盘的设计，在保证数据安全的同时避免了 WAL 的开销。
正常情况下不会丢数据。InMemoryPart 在内存中维护多个副本，刷盘时会先写临时文件再原子重命名。如果进程崩溃，正在刷盘的数据可能丢失，但这是 Prometheus remote_write 协议允许的"最多一次"语义范围内。
高 cardinality 来自标签值组合过多。例如：metric{job="foo",instance="ip-1"}、metric{job="foo",instance="ip-2"}... 每个 instance 都是一个唯一的 time series。如果有 1 万个 instance，就是 1 万个 series。
使用 QueryTracer 分析查询各阶段耗时。VM 的 QueryTracer 会在查询的每个阶段记录耗时：parse → plan → execution → merge。打开 debug 日志可以看到详细的阶段信息。
ibCache 缓存数据块（items.bin），idxbCache 缓存索引块（index.bin），ibSparseCache 是 ibCache 的稀疏访问优化。三者合计占用 memory.allowedDataPointers 的 40%。
内存规划公式：TSIDCache(37%) + blockCache(40%) + 工作内存(23%) ≈ memory.allowed。对于 100 万 series，建议预留 4GB+ 内存；500 万 series 建议 16GB+；1000 万 series 建议 32GB+。
不会立即删除，数据会在后台慢慢清理。VM 每小时检查一次是否有过期数据，清理过程是异步的。磁盘空间释放可能有延迟，这是正常行为。
使用 vmctl prometheus 命令迁移。vmctl 可以从 Prometheus 的 TSDB 快照中读取数据，批量写入 VictoriaMetrics。迁移过程中 Prometheus 可以继续运行，迁移完成后切换 remote_write 目标。
vmagent 更轻量、更高效，但功能比 Prometheus 少。vmagent 是 VM 官方推荐的抓取代理，支持 relabel 和 service discovery，但不支持告警评估（那是 vmalert 的职责）。
重点关注：vm_rows_inserted_total、vm_cache_size_bytes、vm_merges_total、vm_parts_automerge。这些指标可以监控写入吞吐、缓存效率和合并状态。
vmalert 执行告警评估，AlertManager 处理告警路由和通知。vmalert 评估规则后生成告警，发送给配置的 AlertManager（可以是 Prometheus AlertManager 或 vmalert 内置的通知器）。
推荐使用 Helm Chart 或 VictoriaMetrics Operator。官方 Helm Chart 提供了完整的配置选项；VictoriaMetrics Operator 可以通过 CRD 管理 VM 资源，与 Prometheus Operator 配合使用。
全篇必记总纲
VictoriaMetrics 是 Prometheus 的超级增强版：通过 MergeSet LSM-less 设计、TSIDCache 37% 策略、blockCache 三层缓存实现比 Prometheus 省 7x RAM。Single-Node 适合中小规模，Cluster 支持无限水平扩展和多租户。200 篇系列覆盖架构设计、存储引擎、查询引擎、运维实践全维度。
思考记忆提示 — 后续预告帮助读者规划学习路径
本篇是 VictoriaMetrics 深度技术系列的开篇索引，接下来我们将按以下顺序展开：
本文参考与源码链接：
• VictoriaMetrics 官方 GitHub 仓库
• VictoriaMetrics 官方文档
• VictoriaMetrics 架构设计文章
• CHANGELOG v1.146.0
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。