当你需要为监控系统选择存储后端时，是否曾在 Prometheus、InfluxDB、Thanos 和 VictoriaMetrics 之间犹豫不决？每个系统都有各自的优势和适用场景，理解它们的设计差异，才能做出正确的选择。
读完本篇，你应该能回答：四大 TSDB 的核心设计差异是什么？各自的优劣势是什么？在什么场景下应该选择哪个系统？为什么 VictoriaMetrics 被称为 "Prometheus 的超集"？
VictoriaMetrics Prometheus InfluxDB Thanos TSDB对比 选型指南 v1.146.0
学习重点提示 — 建议先通读全文，再重点回顾标注内容
重点掌握（必须）
- 存储引擎对比：TSDB Head vs LSM Tree vs MergeSet
- 内存模型对比：全量 mmap vs 按需缓存
- 水平扩展对比：不支持 vs Enterprise vs Sidecar vs 原生 Cluster
- 选型指南：根据场景选择合适的 TSDB
次重点（了解即可）
- 数据模型差异
- 查询语言对比
- 运维复杂度对比
文章目录
思考记忆提示 — 理解四大 TSDB 的定位是选型的基础——它们面向不同的场景
| 系统 | 定位 | 诞生年份 | GitHub Stars | 主要用户 |
|---|---|---|---|---|
| Prometheus | 云原生监控标准 | 2012 | 64.8+ | CNCF 所有项目 |
| InfluxDB | 企业级时序分析 | 2013 | 31.6k | 大型企业 |
| Thanos | Prometheus 扩展 | 2018 | 14.1k/td> | 大规模部署 |
| VictoriaMetrics | 高性能监控存储 | 2019 | 17.2k+ | Spotify、Roblox 等 |
我理解源码的意思是说
四大 TSDB 可以类比为四种不同的餐厅类型：
Prometheus = 街边快餐店
方便、快捷、便宜，适合小规模（几十个客人）。老板一个人又做菜又端盘子（单机）。规模大了忙不过来（OOM），但胜在简单。
InfluxDB = 大型连锁餐厅
有专门的厨房（WAL + TSM）、仓储系统（分层缓存）、服务员团队（Enterprise）。功能强大但系统复杂，需要专人维护。
Thanos = 快餐店 + 外卖平台
在 Prometheus 基础上加了外卖平台（对象存储），可以覆盖更大范围（长期存储）。但本质上还是快餐店的厨师（依赖 Prometheus 的 TSDB）。
VictoriaMetrics = 现代化无人餐厅
全新的厨房设计（MergeSet）、智能取餐系统（TSIDCache + blockCache）、自动补货系统（后台合并）。效率高（省 7x RAM）、可扩展（原生 Cluster 支持）、运维简单（一个二进制）。
思考记忆提示 — 存储引擎是 TSDB 的核心——理解它就理解了性能差异的根因
| 特性 | Prometheus TSDB | InfluxDB TSM | VictoriaMetrics MergeSet |
|---|---|---|---|
| 数据结构 | Head Block + TSDB Block | TSM File (LSM Tree) | InMemory + Small/Big Part |
| 合并策略 | Leveled Compaction | Leveled Compaction | 单向合并（无分层） |
| 刷盘策略 | Head 满后刷盘 | MemTable 满后刷盘 | 每秒刷盘（WAL-less） |
| 写入性能 | 高 | 高（WAL 同步） | 极高（WAL-less） |
| 查询性能 | 中等（多层 Block） | 中等（LSM 分层） | 高（无分层） |
| 空间放大 | 中等 | 高 | 低 |
┌─────────────────────────────────────────────────────────────────────────┐
│ 存储引擎核心差异 │
│ │
│ Prometheus TSDB： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ MemPart ──→ TSDB Block L0 ──→ TSDB Block L1 ──→ ... │ │
│ │ (Head) (mmap) (mmap) │ │
│ │ │ │
│ │ 特点：Head 满后刷盘，Block 按时间分界，分层合并 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ InfluxDB TSM： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ MemTable ──→ TSM L0 ──→ TSM L1 ──→ TSM L2 ──→ ... │ │
│ │ (WAL) (10MB) (100MB) (1GB) │ │
│ │ │ │
│ │ 特点：WAL 持久化保证可靠性，LSM 分层合并 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ VictoriaMetrics MergeSet： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ InMemoryPart ──→ Small Part ──→ Big Part │ │
│ │ (1秒刷盘) (合并) (合并) │ │
│ │ │ │
│ │ 特点：没有分层！所有 Part 在同一层，只合并不更新 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 关键洞察： │
│ - Prometheus/InfluxDB 用分层 LSM Tree，换取写入性能，引入读放大 │
│ - VM 用无分层 MergeSet，换取读性能，引入少量写放大 │
│ - 时序数据以读为主（监控告警），VM 的设计更匹配访问模式 │
└─────────────────────────────────────────────────────────────────────────┘设计精髓
MergeSet 的核心洞察：时序数据的访问模式天然适合只合并不分层的架构。时序数据有三个特点：
这意味着：分层 LSM Tree 的"更新"能力在时序场景下几乎无用武之地，反而引入了空间放大和读放大。MergeSet 放弃了更新能力，换取了更简单的查询路径和更低的资源消耗。
思考记忆提示 — 内存模型是 VM "省 7x RAM" 的核心——理解它就理解了 VM 的核心优势
| 特性 | Prometheus | InfluxDB | VictoriaMetrics |
|---|---|---|---|
| 索引策略 | 全量 mmap | 分层缓存 | 按需缓存（37%） |
| 数据缓存 | 依赖 Page Cache | 可配置缓存层 | blockCache 三层 |
| 内存可控性 | 不可控 | 可配置 | 精确控制 |
| 内存占用 | 高（2-3GB/M series） | 高（Enterprise） | 低（0.3-0.5GB/M series） |
| 省内存倍数 | 基准 | ~1x | ~7x |
┌─────────────────────────────────────────────────────────────────────────┐
│ 内存模型核心差异 │
│ │
│ Prometheus（mmap）： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 所有索引 ──→ mmap ──→ Page Cache ──→ 查询加载 │ │
│ │ │ │
│ │ 问题：索引全量加载，查询越多内存占用越大 │ │
│ │ 优点：查询一定命中缓存（内核管理） │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ VictoriaMetrics（按需缓存）： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 热点索引 ──→ TSIDCache 37% ──→ 内存 │ │
│ │ 冷数据 ──→ indexDB ──→ 按需加载 │ │
│ │ │ │
│ │ 优点：内存占用可控，按需加载 │ │
│ │ 问题：冷数据查询需要读磁盘 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 关键洞察： │
│ - Prometheus 的 mmap 适合"查询所有数据"场景 │
│ - VM 的按需缓存适合"查询热点数据"场景 │
│ - 监控数据的访问模式天然是热点访问（近期数据查询多） │
└─────────────────────────────────────────────────────────────────────────┘思考记忆提示 — 水平扩展能力决定了系统能支持多大——这是选型的关键因素
| 特性 | Prometheus | InfluxDB | Thanos | VictoriaMetrics |
|---|---|---|---|---|
| 扩展模式 | 不支持 | Enterprise 专属 | Sidecar + 对象存储 | 原生 Cluster |
| 数据分片 | 无 | Hash + 时间 | Prometheus 本地 | 一致性哈希 |
| 查询聚合 | 无 | 内置 | Query Layer | vmselect |
| 副本复制 | 无 | Enterprise | 对象存储 | Enterprise |
| 多租户 | Federation | 支持 | 不支持 | 支持 |
┌─────────────────────────────────────────────────────────────────────────┐
│ 扩展模式核心差异 │
│ │
│ Prometheus（单机）： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Prometheus ──→ 本地存储 │ │
│ │ │ │
│ │ 扩展方式：Federation（联邦） │ │
│ │ Prometheus A ──→ Prometheus Center ──→ Prometheus B │ │
│ │ │ │
│ │ 本质：不是真正的扩展，只是视图聚合 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Thanos（Prometheus + 对象存储）： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Prometheus A ──→ Sidecar ──→ 对象存储 │ │
│ │ Prometheus B ──→ Sidecar ──→ 对象存储 │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ Query Layer ──→ 聚合查询 │ │
│ │ │ │
│ │ 本质：还是在每个 Prometheus 本地存储，Sidecar 只是备份 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ VictoriaMetrics（原生 Cluster）： │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ vminsert ──→ 一致性哈希 ──→ vmstorage A │ │
│ │ │ │ │
│ │ └──→ vmstorage B │ │
│ │ │ │
│ │ vmselect ──→ 聚合查询 ──→ 返回结果 │ │
│ │ │ │
│ │ 本质：真正的分布式存储，数据按 tenant 分片 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 关键洞察： │
│ - Prometheus/Thanos 本质还是单机存储，只是加了视图聚合或备份 │
│ - VM 原生 Cluster 是真正的分布式存储，数据天然分片 │
│ - 对于需要真正水平扩展的场景，VM 是更好的选择 │
└─────────────────────────────────────────────────────────────────────────┘小贴士 — 扩展模式选择建议
根据扩展需求选择：
思考记忆提示 — 数据模型和查询语言决定了系统的表达能力——迁移成本也与此相关
| 特性 | Prometheus | InfluxDB | VictoriaMetrics |
|---|---|---|---|
| 数据模型 | Metric + Labels | Measurement + Tag + Field | Metric + Labels |
| 标签类型 | 字符串 | Tag（索引）/Field（不索引） | 字符串 |
| 字段支持 | 单一值 | 多字段 | 单一值 |
| 时间戳精度 | 毫秒 | 纳秒（可配置） | 纳秒 |
| 特性 | PromQL | InfluxQL | MetricsQL |
|---|---|---|---|
| 来源 | Prometheus | InfluxDB | VictoriaMetrics |
| 兼容性 | 标准 | InfluxDB 专属 | PromQL 超集 |
| 独有函数 | 基础聚合 | 连续查询 | running_max/min/sum |
| 迁移难度 | N/A | 高 | 低（PromQL 兼容） |
注意
VictoriaMetrics 兼容 PromQL，并扩展了 MetricsQL，提供更多高级函数。如果当前使用 Prometheus，迁移到 VM 几乎没有学习成本。如果当前使用 InfluxDB，迁移到 VM 需要将 InfluxQL 转换为 PromQL。
思考记忆提示 — 选型是本文的最终目标——理解差异后做出正确决策
┌─────────────────────────────────────────────────────────────────────────┐
│ TSDB 选型决策树 │
│ │
│ 开始 │
│ │ │
│ ▼ │
│ 规模是多少？ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ < 100万 100-500万 > 500万 │
│ series series series │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ Prometheus Thanos或 VM Cluster │
│ VM Single │
│ │ │
│ ▼ │
│ 需要水平扩展吗？ │
│ │ │
│ ┌────────────────┴────────────────┐ │
│ │ │ │
│ ▼ ▼ │
│ 是 否 │
│ │ │ │
│ ▼ ▼ │
│ VM Cluster Prometheus + Thanos │
│ 或 或 │
│ Thanos VM Single │
│ │
└─────────────────────────────────────────────────────────────────────────┘| 场景 | 推荐 | 原因 |
|---|---|---|
| 小规模监控（<100万 series） | Prometheus | 简单、成熟、生态完善 |
| 中等规模（100-500万 series） | VictoriaMetrics | 省内存、高性能、PromQL 兼容 |
| 大规模（>500万 series） | VictoriaMetrics Cluster | 原生分布式、多租户、高可用 |
| 已有 Prometheus 迁移 | VictoriaMetrics | PromQL 完全兼容、迁移成本低 |
| 企业级功能（RBAC、审计） | InfluxDB Enterprise / VM Enterprise | 完整的企业特性 |
| 长期存储 + 全球聚合 | Thanos 或 VM + 对象存储 | 对象存储成本低 |
| 需要 SQL 查询 | InfluxDB（InfluxQL） | InfluxQL 更接近 SQL |
| DevOps/云原生监控 | VictoriaMetrics | CNCF 生态、Kubernetes 原生 |
设计精髓
选型的核心原则是匹配场景，平衡成本：
思考记忆提示 — FAQ 是全篇的"临考前速背"模块，20 组覆盖全链路
官方建议 < 100 万 series，实际取决于可用内存。每百万 series 约需 2-3GB 内存（mmap 索引）。超过 100 万 series 后，内存压力显著增加。
因为 VM 使用 TSIDCache 37% 策略，只缓存热点索引，而不是全量 mmap。Prometheus 的 mmap 会导致所有索引数据被内核加载到 Page Cache，而 VM 只缓存热点索引（约 37%），冷数据按需从磁盘加载。
Thanos 是 Prometheus 的扩展，VM 是独立的存储引擎。Thanos 通过 Sidecar 代理 Prometheus 的数据，本质上还是依赖 Prometheus 的 TSDB。VictoriaMetrics 自己实现 MergeSet 存储引擎，不依赖 Prometheus。
非常容易，PromQL 完全兼容。VictoriaMetrics 兼容 Prometheus 的所有协议和数据格式。使用 vmagent 或 Remote Write 代理新数据，使用 vmctl 迁移历史数据，Grafana 数据源无缝切换。
Benchmark 显示，在相同硬件下 VM 的写入吞吐和查询延迟都优于 InfluxDB。官方测试显示，VM 的写入吞吐约为 InfluxDB 的 2-3 倍，查询延迟约为 InfluxDB 的 1/2。
已有 Prometheus 基础设施，需要扩展长期存储和全局视图。Thanos 的优势是可以复用现有的 Prometheus 配置，不需要迁移。
需要企业级特性（RBAC、审计、连续查询）或 SQL-like 查询。InfluxDB Enterprise 提供完整的企业功能，但成本较高。
支持，Enterprise 版本提供副本复制和故障转移。Cluster 模式下可以将数据复制到多个 vmstorage 节点，实现高可用。
取决于场景：时序数据更适合 MergeSet，事务型数据更适合 LSM Tree。时序数据的特点是追加写入为主、很少更新，MergeSet 的只合并不分层设计更匹配这个访问模式。
典型压缩率 10x-50x，取决于数据特征。Counter 类型（平滑变化）压缩率高，Histogram 类型压缩率低。整体平均约 20x。
Prometheus Federation 只是视图聚合，VM Cluster 是真正的数据分片。Federation 只是将多个 Prometheus 实例的查询结果聚合起来，每个实例仍然是完整的数据副本。VM Cluster 将数据按 tenant 分片到不同节点。
Prometheus 最简单，VictoriaMetrics 次之，InfluxDB/Thanos 最复杂。Prometheus 是单一二进制，不需要额外组件。VictoriaMetrics 也是单一二进制，但需要 Cluster 时组件较多。InfluxDB Enterprise 架构复杂，需要专人维护。
Prometheus 生态最好，VictoriaMetrics 次之。Prometheus 是 CNCF 毕业项目，Grafana 原生支持。VictoriaMetrics 虽然是独立项目，但完全兼容 Prometheus 生态。
主要缺点：1）相对较新（2019 年）；2）Enterprise 版本需要付费；3）文档相对较少。Prometheus 有 10 年历史，生态更成熟。
使用 vmctl influx 命令迁移数据。vmctl 支持从 InfluxDB 导出数据，然后导入到 VictoriaMetrics。需要将 InfluxQL 转换为 PromQL。
VictoriaMetrics 存储成本最低，InfluxDB 最高。VM 的高压缩率（20x）和低内存需求（省 7x RAM）显著降低了存储成本。
可以，Prometheus Remote Write 支持多目的地。可以配置 Prometheus 同时写入 Prometheus 本地存储和 VictoriaMetrics。
支持 12+ 种协议，包括 Prometheus remote_write、InfluxDB line protocol、DataDog、OpenTelemetry 等。比任何竞品都多。
不需要，可以热迁移。配置 Prometheus Remote Write 同时写入旧系统和 VM，切换 Grafana 数据源到 VM，然后停止旧系统。
发展迅速，CNCF 沙箱项目，持续更新中。GitHub stars 增长迅速，被多家大厂采用，路线图包括 VictoriaLogs 集成、更高效压缩算法等。
全篇必记总纲
四大 TSDB 的选择核心是匹配场景：小规模用 Prometheus（简单成熟），大规模高性能用 VictoriaMetrics（省 7x RAM + 原生 Cluster），已有 Prometheus 扩展用 Thanos（复用配置），企业级功能用 InfluxDB Enterprise。VM 是 Prometheus 的超集，迁移成本最低，推荐作为 Prometheus 的长期替代方案。
本篇覆盖了四大 TSDB 的对比分析，后续将深入各个专题：
本文参考与源码链接：
• VictoriaMetrics 官方对比文档
• Prometheus 官网
• InfluxDB 官网
• Thanos 官网
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。