VictoriaMetrics 1.146.0 源码专题【左扬精讲】—— 与其他 TSDB 对比——Prometheus/InfluxDB/Thanos/VM

当你需要为监控系统选择存储后端时，是否曾在 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 概述
二、存储引擎对比：TSDB Head vs LSM Tree vs MergeSet
三、内存模型对比：全量 mmap vs 按需缓存
四、水平扩展对比：四种扩展模式的本质差异
五、数据模型与查询语言对比
六、选型指南：根据场景选择合适的 TSDB
七、FAQ：常见疑问
八、Roadmap：后续预告

一、问题的起点：四大 TSDB 概述

思考记忆提示 — 理解四大 TSDB 的定位是选型的基础——它们面向不同的场景

Prometheus = 单机存储的事实标准
InfluxDB = 企业级时序分析平台
Thanos = Prometheus 的扩展方案
VictoriaMetrics = 高性能 Prometheus 替代方案

1.1 四大 TSDB 一览

说明

以下表格中的 GitHub Stars 数量和诞生年份未经验证，可能与实际情况不符。Stars 数量随时间变化，建议直接访问各项目 GitHub 页面核实。

系统	定位	诞生年份	GitHub Stars	主要用户
Prometheus	云原生监控标准	—	—	CNCF 所有项目
InfluxDB	企业级时序分析	—	—	大型企业
Thanos	Prometheus 扩展	—	—	大规模部署
VictoriaMetrics	高性能监控存储	—	—	官方文档列出 Grammarly、Roblox、Wix、Spotify 等为案例

我理解源码的意思是说

VictoriaMetrics 的存储引擎设计，可以直接从源码里读出来。我们不看任何类比，直接看四个关键文件，就能理解 MergeSet 为什么这样设计：

源码视角一：MergeSet 只合并不分层的核心逻辑

读 lib/mergeset/table.go 第 1-80 行，会发现 MergeSet 的核心设计原则：数据只通过合并（merge）操作整理，绝不原地更新或分层。写入路径上，一个 InMemory Part 刷盘后变成 Small Part，若干 Small Part 合并成 Big Part——整个过程是单向的，没有 LSM Tree 的 L0→L1→L2 分层概念。

源码视角二：Part 合并的触发条件

读 lib/storage/partition.go 第 41 行和第 524 行：

const defaultPartsToMerge = 15

if len(rrss.rowssToFlush) >= defaultPartsToMerge {
    // 触发合并
}

当一个分区的 Part 数量达到 15 时，自动触发合并。这就是 MergeSet 控制 Part 数量的机制。

源码视角三：为什么这样设计适合时序数据

时序数据的三个特点决定了 MergeSet 的设计选择：

追加写入为主：几乎不更新和删除，所以不需要 LSM Tree 的更新能力
查询通常是范围查询：MergeSet 的线性扫描路径更简单，没有跨层合并开销
热点数据集中在近期：InMemory Part 和 Small Part 承载热点数据，Big Part 承载冷数据

源码视角总结：2 个设计原则

1 个写入原则：defaultPartsToMerge = 15 触发合并，控制 Part 数量
1 个读取原则：所有 Part 在同一层查询，无跨层合并

避坑提醒（源码视角）：

不要以为 MergeSet 等于没有合并：合并是核心机制，由 defaultPartsToMerge = 15 控制
不要混淆 MergeSet 和 LSM Tree：MergeSet 没有分层，LSM Tree 有分层

二、存储引擎对比：TSDB Head vs LSM Tree vs MergeSet

思考记忆提示 — 存储引擎是 TSDB 的核心——理解它就理解了性能差异的根因

Prometheus TSDB = Head Block + mmap
InfluxDB TSM = LSM Tree 变体 + WAL
VM MergeSet = 只合并不分层

2.1 存储引擎对比表

特性	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 分层）	高（无分层）
空间放大	中等	高	低

2.2 核心差异分析

┌─────────────────────────────────────────────────────────────────────────┐
│                    存储引擎核心差异                                           │
│                                                                          │
│  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 的核心洞察：时序数据的访问模式天然适合只合并不分层的架构。时序数据有三个特点：

追加写入为主：几乎不更新和删除（除非 delete series）
查询通常是范围查询：最近 N 分钟/小时/天
热点数据集中在近期：历史数据查询少

这意味着：分层 LSM Tree 的"更新"能力在时序场景下几乎无用武之地，反而引入了空间放大和读放大。MergeSet 放弃了更新能力，换取了更简单的查询路径和更低的资源消耗。

三、内存模型对比：全量 mmap vs 按需缓存

思考记忆提示 — 内存模型是 VM 的核心优势——理解它就理解了 VM 按需缓存的设计

Prometheus = 全量 mmap（所有索引常驻）
InfluxDB = 分层缓存（可配置）
VictoriaMetrics = 按需缓存（TSIDCache 37%）

3.1 内存模型对比表

特性	Prometheus	InfluxDB	VictoriaMetrics
索引策略	全量 mmap	分层缓存	按需缓存（37%）
数据缓存	依赖 Page Cache	可配置缓存层	blockCache 三层
内存可控性	不可控	可配置	精确控制
内存占用	取决于 mmap 范围	高（Enterprise）	按 memory.Allowed() 配置
省内存能力	基准	~1x	按需缓存（memory.Allowed() 控制）

3.2 核心差异详解

┌─────────────────────────────────────────────────────────────────────────┐
│                    内存模型核心差异                                           │
│                                                                          │
│  Prometheus（mmap）：                                                     │
│  ┌─────────────────────────────────────────────────────────────────┐     │
│  │  所有索引 ──→ mmap ──→ Page Cache ──→ 查询加载                 │     │
│  │                                                                   │     │
│  │  问题：索引全量加载，查询越多内存占用越大                         │     │
│  │  优点：查询一定命中缓存（内核管理）                               │     │
│  └─────────────────────────────────────────────────────────────────┘     │
│                                                                          │
│  VictoriaMetrics（按需缓存）：                                            │
│  ┌─────────────────────────────────────────────────────────────────┐     │
│  │  热点索引 ──→ TSIDCache 37% ──→ 内存                         │     │
│  │  冷数据   ──→ indexDB ──→ 按需加载                            │     │
│  │                                                                   │     │
│  │  优点：内存占用可控，按需加载                                   │     │
│  │  问题：冷数据查询需要读磁盘                                     │     │
│  └─────────────────────────────────────────────────────────────────┘     │
│                                                                          │
│  关键洞察：                                                              │
│  - Prometheus 的 mmap 适合"查询所有数据"场景                            │
│  - VM 的按需缓存适合"查询热点数据"场景                                  │
│  - 监控数据的访问模式天然是热点访问（近期数据查询多）                      │
└─────────────────────────────────────────────────────────────────────────┘

四、水平扩展对比：四种扩展模式的本质差异

思考记忆提示 — 水平扩展能力决定了系统能支持多大——这是选型的关键因素

Prometheus = 不支持水平扩展
InfluxDB = Enterprise 专属
Thanos = Prometheus + Sidecar 代理
VictoriaMetrics = 原生 Cluster 支持

4.1 水平扩展对比表

特性	Prometheus	InfluxDB	Thanos	VictoriaMetrics
扩展模式	不支持	Enterprise 专属	Sidecar + 对象存储	原生 Cluster
数据分片	无	Hash + 时间	Prometheus 本地	一致性哈希
查询聚合	无	内置	Query Layer	vmselect
副本复制	无	Enterprise	对象存储	Enterprise
多租户	Federation	支持	不支持	支持

4.2 核心差异分析

┌─────────────────────────────────────────────────────────────────────────┐
│                    扩展模式核心差异                                           │
│                                                                          │
│  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 是更好的选择                             │
└─────────────────────────────────────────────────────────────────────────┘

小贴士 — 扩展模式选择建议

根据扩展需求选择：

< 100 万 series：Prometheus 足够
100-500 万 series：Thanos 或 VM Single-Node
> 500 万 series：VM Cluster
Enterprise 功能需求：InfluxDB Enterprise 或 VM Enterprise

五、数据模型与查询语言对比

思考记忆提示 — 数据模型和查询语言决定了系统的表达能力——迁移成本也与此相关

Prometheus/VM = 标签模型 + PromQL
InfluxDB = Tag/Field 模型 + InfluxQL/Flux

5.1 数据模型对比

特性	Prometheus	InfluxDB	VictoriaMetrics
数据模型	Metric + Labels	Measurement + Tag + Field	Metric + Labels
标签类型	字符串	Tag（索引）/Field（不索引）	字符串
字段支持	单一值	多字段	单一值
时间戳精度	毫秒	纳秒（可配置）	纳秒

5.2 查询语言对比

特性	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

思考记忆提示 — 选型是本文的最终目标——理解差异后做出正确决策

小规模 = Prometheus
大规模高性能 = VictoriaMetrics
企业级功能 = InfluxDB Enterprise
已有 Prometheus 扩展 = Thanos

6.1 选型决策树

┌─────────────────────────────────────────────────────────────────────────┐
│                    TSDB 选型决策树                                           │
│                                                                          │
│                          开始                                                │
│                            │                                                │
│                            ▼                                                │
│                    规模是多少？                                             │
│                            │                                                │
│           ┌────────────────┼────────────────┐                              │
│           │                │                │                               │
│           ▼                ▼                ▼                               │
│      < 100万          100-500万        > 500万                            │
│       series           series           series                              │
│           │                │                │                               │
│           ▼                ▼                ▼                               │
│      Prometheus       Thanos或         VM Cluster                         │
│                       VM Single                                         │
│                            │                                              │
│                            ▼                                              │
│                    需要水平扩展吗？                                          │
│                            │                                              │
│           ┌────────────────┴────────────────┐                            │
│           │                              │                                 │
│           ▼                              ▼                                 │
│         是                              否                                  │
│           │                              │                                 │
│           ▼                              ▼                                 │
│      VM Cluster                   Prometheus + Thanos                      │
│           或                              或                                 │
│      Thanos                          VM Single                             │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

6.2 详细选型指南

场景	推荐	原因
小规模监控（<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 原生

设计精髓

选型的核心原则是匹配场景，平衡成本：

Prometheus：简单场景首选，不需要额外组件
VictoriaMetrics：性能和规模优先，Prometheus 的超集
Thanos：已有 Prometheus 基础设施，想扩展长期存储
InfluxDB：需要企业特性或 SQL -like 查询

七、FAQ：常见疑问

思考记忆提示 — FAQ 是全篇的"临考前速背"模块，20 组覆盖全链路

Q1-Q5 围绕存储引擎：TSDB Head vs LSM Tree vs MergeSet
Q6-Q10 围绕内存模型：全量 mmap vs 按需缓存
Q11-Q15 围绕扩展能力：四种扩展模式对比
Q16-Q20 围绕选型建议：场景与系统匹配

Q1. Prometheus 能支持多少时间序列？

官方建议 < 100 万 series，实际取决于可用内存。Prometheus 的 mmap 索引会占用额外内存，具体占用取决于标签数量和数据量。

Q2. VictoriaMetrics 为什么比 Prometheus 省内存？

因为 VM 使用按需缓存策略，不是全量 mmap。Prometheus 的 mmap 会导致所有索引数据被内核加载到 Page Cache，而 VM 使用多个独立缓存（TSID 缓存 37%、MetricID 缓存 6.25%、MetricName 缓存 10%，见 lib/storage/storage.go 第 338-370 行），冷数据按需从磁盘加载。

Q3. Thanos 和 VictoriaMetrics 有什么区别？

Thanos 是 Prometheus 的扩展，VM 是独立的存储引擎。Thanos 通过 Sidecar 代理 Prometheus 的数据，本质上还是依赖 Prometheus 的 TSDB。VictoriaMetrics 自己实现 MergeSet 存储引擎，不依赖 Prometheus。

Q4. 从 Prometheus 迁移到 VictoriaMetrics 容易吗？

非常容易，PromQL 完全兼容。VictoriaMetrics 兼容 Prometheus 的所有协议和数据格式。使用 vmagent 或 Remote Write 代理新数据，使用 vmctl 迁移历史数据，Grafana 数据源无缝切换。

Q5. InfluxDB 和 VictoriaMetrics 哪个性能更好？

Benchmark 显示，在相同硬件下 VM 的写入吞吐和查询延迟都优于 InfluxDB。具体倍数取决于数据特征和测试场景，建议参考官方或第三方实测数据。

Q6. 什么场景下应该选择 Thanos？

已有 Prometheus 基础设施，需要扩展长期存储和全局视图。Thanos 的优势是可以复用现有的 Prometheus 配置，不需要迁移。

Q7. 什么场景下应该选择 InfluxDB？

需要企业级特性（RBAC、审计、连续查询）或 SQL-like 查询。InfluxDB Enterprise 提供完整的企业功能，但成本较高。

Q8. VictoriaMetrics 支持高可用吗？

支持，Enterprise 版本提供副本复制和故障转移。Cluster 模式下可以将数据复制到多个 vmstorage 节点，实现高可用。

Q9. MergeSet 和 LSM Tree 哪个更好？

取决于场景：时序数据更适合 MergeSet，事务型数据更适合 LSM Tree。时序数据的特点是追加写入为主、很少更新，MergeSet 的只合并不分层设计更匹配这个访问模式。

Q10. VictoriaMetrics 的压缩率是多少？

压缩率取决于数据特征。Counter 类型（平滑变化）压缩率高，Histogram 类型压缩率低。具体压缩率建议通过实测获取。

Q11. Prometheus 的 Federation 和 VictoriaMetrics 的 Cluster 有什么区别？

Prometheus Federation 只是视图聚合，VM Cluster 是真正的数据分片。Federation 只是将多个 Prometheus 实例的查询结果聚合起来，每个实例仍然是完整的数据副本。VM Cluster 将数据按 tenant 分片到不同节点。

Q12. 哪个系统运维最简单？

Prometheus 最简单，VictoriaMetrics 次之，InfluxDB/Thanos 最复杂。Prometheus 是单一二进制，不需要额外组件。VictoriaMetrics 也是单一二进制，但需要 Cluster 时组件较多。InfluxDB Enterprise 架构复杂，需要专人维护。

Q13. 哪个系统生态最好？

VictoriaMetrics 在 CNCF Landscape 中处于 Observability 分类。Prometheus 是 CNCF 毕业项目，Grafana 原生支持。VictoriaMetrics 完全兼容 Prometheus 生态，具体 CNCF 会员状态请参考 CNCF Landscape 官方页面。

Q14. VictoriaMetrics 的缺点是什么？

主要缺点：1）相对较新；2）Enterprise 版本需要付费；3）文档相对较少。Prometheus 生态更成熟。

Q15. 如何从 InfluxDB 迁移到 VictoriaMetrics？

使用 vmctl influx 命令迁移数据。vmctl 支持从 InfluxDB 导出数据，然后导入到 VictoriaMetrics。需要将 InfluxQL 转换为 PromQL。

Q16. 存储成本对比如何？

VictoriaMetrics 的高压缩率和按需缓存设计降低了存储成本。具体数字取决于数据特征，建议通过实测获取。

Q17. 可以同时使用 Prometheus 和 VictoriaMetrics 吗？

可以，Prometheus Remote Write 支持多目的地。可以配置 Prometheus 同时写入 Prometheus 本地存储和 VictoriaMetrics。

Q18. VictoriaMetrics 支持哪些协议？

VictoriaMetrics 支持多种协议。包括 Prometheus remote_write、InfluxDB line protocol 等，具体支持的协议数量请参考官方文档 docs.victoriametrics.com。

Q19. 迁移到 VictoriaMetrics 需要停机吗？

不需要，可以热迁移。配置 Prometheus Remote Write 同时写入旧系统和 VM，切换 Grafana 数据源到 VM，然后停止旧系统。

Q20. VictoriaMetrics 的未来发展如何？

VictoriaMetrics 持续更新中，路线图包括 VictoriaLogs 集成等。更多路线图信息请参考官方文档。

全篇必记总纲

四大 TSDB 的选择核心是匹配场景：小规模用 Prometheus（简单成熟），大规模高性能用 VictoriaMetrics（按需缓存 + 原生 Cluster），已有 Prometheus 扩展用 Thanos（复用配置），企业级功能用 InfluxDB Enterprise。VM 是 Prometheus 的超集，PromQL 完全兼容，迁移成本最低，推荐作为 Prometheus 的长期替代方案。

八、Roadmap：后续预告

本篇覆盖了四大 TSDB 的对比分析，后续将深入各个专题：

#11 开源生态：VM 在 CNCF 生态中的位置——理解 VM 的生态位
#12 源码阅读路线图：如何高效阅读 VM 源码——最佳实践
#192 Prometheus TSDB vs VM：Benchmarks 数字真相——深度对比
#41 MergeSet vs LSM Tree：存储引擎专题——MergeSet 源码深度解析
#146 10 亿 Series 规模：超大规模 VM 部署架构——生产极限专题

本文参考与源码链接：
  • VictoriaMetrics 官方对比文档
  • Prometheus 官网
  • InfluxDB 官网
  • Thanos 官网

posted @ 2026-06-29 01:24 左扬阅读(35) 评论(0) 收藏举报

刷新页面返回顶部

左扬(你们的胃叫胃，孤的叫胃PLUS)

深耕云原生全栈架构，只为成为更好的自己 —— 知命不惧，日日维新

VictoriaMetrics 1.146.0 源码专题【左扬精讲】—— 与其他 TSDB 对比——Prometheus/InfluxDB/Thanos/VM

VictoriaMetrics 1.146.0 源码专题【左扬精讲】—— 与其他 TSDB 对比——Prometheus/InfluxDB/Thanos/VM

一、问题的起点：四大 TSDB 概述

1.1 四大 TSDB 一览

二、存储引擎对比：TSDB Head vs LSM Tree vs MergeSet

2.1 存储引擎对比表

2.2 核心差异分析

三、内存模型对比：全量 mmap vs 按需缓存

3.1 内存模型对比表

3.2 核心差异详解

四、水平扩展对比：四种扩展模式的本质差异

4.1 水平扩展对比表

4.2 核心差异分析

五、数据模型与查询语言对比

5.1 数据模型对比

5.2 查询语言对比

六、选型指南：根据场景选择合适的 TSDB

6.1 选型决策树

6.2 详细选型指南

七、FAQ：常见疑问

Q1. Prometheus 能支持多少时间序列？

Q2. VictoriaMetrics 为什么比 Prometheus 省内存？

Q3. Thanos 和 VictoriaMetrics 有什么区别？

Q4. 从 Prometheus 迁移到 VictoriaMetrics 容易吗？

Q5. InfluxDB 和 VictoriaMetrics 哪个性能更好？

Q6. 什么场景下应该选择 Thanos？

Q7. 什么场景下应该选择 InfluxDB？

Q8. VictoriaMetrics 支持高可用吗？

Q9. MergeSet 和 LSM Tree 哪个更好？

Q10. VictoriaMetrics 的压缩率是多少？

Q11. Prometheus 的 Federation 和 VictoriaMetrics 的 Cluster 有什么区别？

Q12. 哪个系统运维最简单？

Q13. 哪个系统生态最好？

Q14. VictoriaMetrics 的缺点是什么？

Q15. 如何从 InfluxDB 迁移到 VictoriaMetrics？

Q16. 存储成本对比如何？

Q17. 可以同时使用 Prometheus 和 VictoriaMetrics 吗？

Q18. VictoriaMetrics 支持哪些协议？

Q19. 迁移到 VictoriaMetrics 需要停机吗？

Q20. VictoriaMetrics 的未来发展如何？

八、Roadmap：后续预告

公告