VictoriaMetrics 完全指南 / 01 - VictoriaMetrics 特性与对比分析

01 · VictoriaMetrics 特性与对比分析

本章目标

• 了解 VictoriaMetrics 的诞生背景与核心定位
• 掌握其关键特性与技术优势
• 与 Prometheus、InfluxDB 进行系统性对比
• 帮助你在架构选型时做出合理决策

1.1 什么是 VictoriaMetrics

VictoriaMetrics（以下简称 VM）是一款高性能、低成本的时序数据库（Time Series Database, TSDB）和监控解决方案，由 Aliaksandr Valialkin 于 2018 年开源。它同时提供单节点版和集群版，并完全兼容 Prometheus 生态。

设计哲学

┌─────────────────────────────────────────────────┐
│            VictoriaMetrics 设计三角              │
│                                                 │
│              简单 (Simplicity)                   │
│                    ▲                            │
│                   / \                           │
│                  /   \                          │
│                 /     \                         │
│                /       \                        │
│    性能 (Performance)──成本 (Cost Efficiency)    │
└─────────────────────────────────────────────────┘

• 简单：单二进制文件部署，无外部依赖（单节点版）
• 高性能：比 Prometheus 快 10-100 倍的查询速度
• 低成本：高压缩率，磁盘占用降低 7-10 倍

1.2 核心特性

1.2.1 存储引擎

1.2.2 协议兼容性

Prometheus remote_write ──┐
Prometheus remote_read ───┤
Prometheus scrape ────────┤
InfluxDB line protocol ───┼──▶ VictoriaMetrics
OpenTSDB ─────────────────┤
Graphite ─────────────────┤
CSV / JSON ───────────────┘

1.2.3 查询语言 MetricsQL

• 完全兼容 PromQL
• 新增 50+ 实用函数（如 rollup, default_rollup, label_match 等）
• 支持子查询嵌套、多级聚合
• 详见 第 05 章 MetricsQL

1.2.4 运维友好

• 单二进制文件，无需 ZooKeeper / Consul / etcd
• 内置 HTTP API，方便与各种工具集成
• 支持即时快照备份（snapshot）
• 提供丰富的自我监控指标

1.3 与 Prometheus 对比

这是选型中最常遇到的问题。以下是详细对比：

架构差异

Prometheus 架构：
┌──────────┐   pull    ┌──────────┐
│  Target  │ ◀──────── │Prometheus│ ──▶ 本地 TSDB
└──────────┘           └──────────┘
                              │
                        remote_write（可选）
                              ▼
                       ┌──────────────┐
                       │ 远程存储（VM）│
                       └──────────────┘

VictoriaMetrics 单节点架构：
┌──────────┐  remote_write  ┌─────────────────┐
│Prometheus│ ──────────────▶│ VictoriaMetrics │（同时作为远程存储和查询引擎）
└──────────┘                └─────────────────┘
       │                            ▲
       │   scrape（可选）            │
       └────────────────────────────┘

功能对比表

何时选择 Prometheus

• 团队对 Prometheus 生态非常熟悉
• 数据量较小（< 100 万活跃时间序列）
• 不需要长期存储或集群能力
• 希望使用原生 CNCF 生态

何时选择 VictoriaMetrics

• 时间序列数量巨大（> 100 万）
• 对存储成本敏感
• 需要长期数据保留（月/年级）
• 需要多租户支持
• 需要简单运维的集群方案
• 查询性能有较高要求

1.4 与 InfluxDB 对比

架构差异

InfluxDB（单机版）：
┌──────────┐
│ InfluxDB │ ──▶ TSI Index + TSM Engine
└──────────┘

InfluxDB Enterprise：
┌──────────┐    ┌────────────┐
│  Data     │◀──▶│  Meta      │  (需 Raft 共识)
│  Node(s)  │    │  Node(s)   │
└──────────┘    └────────────┘

VictoriaMetrics：
┌──────────┐
│    VM     │ ──▶ Mergetree + Inverted Index
└──────────┘     (单二进制，无需外部依赖)

功能对比表

数据模型对比示例

InfluxDB 风格：

cpu,host=server01,region=cn-north usage_idle=95.2,usage_user=3.1 1699000000000000000

Prometheus / VM 风格：

cpu_usage_idle{host="server01", region="cn-north"} 95.2
cpu_usage_user{host="server01", region="cn-north"} 3.1

注意：InfluxDB 的 field 在 Prometheus 模型中会拆分为独立的 metric name，这意味着从 InfluxDB 迁移时需要重新设计数据模型。

何时选择 InfluxDB

• 数据是事件型的（logs, events, traces 混合）
• 团队熟悉 SQL 语法
• 需要 Flux 的复杂数据转换能力
• 数据量不大，单机版即可满足

何时选择 VictoriaMetrics

• 纯时序指标数据
• 需要开源的集群方案
• 对存储成本和查询性能有更高要求
• 已有 Prometheus 生态，希望平滑迁移

1.5 与其他方案对比速览

1.6 真实案例：从 Prometheus 迁移收益

某互联网公司监控数据概况：

提示：以上数据基于公开社区分享，实际效果因工作负载而异。

1.7 版本演进

1.8 业务场景

场景一：云原生 Kubernetes 监控

• 1000+ 节点 K8s 集群
• 50 万+ Pod，每 Pod 3-5 个指标
• 需要 90 天数据保留
• 推荐方案：VM 集群版 + Prometheus Agent 模式

场景二：IoT 设备数据采集

• 100 万台设备，每 30 秒上报
• 数据量：~300 万 samples/s
• 需要 1 年数据保留
• 推荐方案：VM 单节点（高配）或集群版 + InfluxDB 协议写入

场景三：原有 Prometheus 扩展

• 当前使用 Prometheus，数据增长导致性能下降
• 不希望大幅改动现有配置
• 推荐方案：Prometheus + VM 作为 remote storage，渐进式迁移

本章小结

扩展阅读

• VictoriaMetrics 官方博客：Why VictoriaMetrics
• Prometheus vs VictoriaMetrics 基准测试
• InfluxDB vs VictoriaMetrics 性能对比
• Thanos vs VictoriaMetrics