VictoriaMetrics 存储机制逻辑分析

VictoriaMetrics 是后出的一款面向可观测指标的时序数据存储和查询引擎, 传闻比prometheus 查询性能强,存储成本还低,我们也有做指标数据平台,特来学习下

以下分析基于 v1.45.x 版本

1. 核心结论

VictoriaMetrics 的存储设计可以概括为以下几点:

  • 使用 vminsertvmstoragevmselect 分离写入、存储与查询职责;
  • 采用 Prometheus 风格的单值时序模型,每个数据点由时间戳和浮点数值组成;
  • 根据指标名和标签生成时间序列标识 TSID
  • 将标签索引与原始时序数据分开存储;
  • 原始数据按 TSID 聚合,并将时间戳和值分别进行列式压缩;
  • 数据先写入内存,刷盘后形成不可变的 Part,再通过后台 Merge 合并;
  • 按月建立数据分区,通过 smallbig 两级目录平衡近期数据的读取速度与历史数据的压缩率;
  • 索引和数据均采用分层文件结构,通过元索引缩小读取范围;
  • 不依赖传统 WAL,在异常退出时可能丢失尚未刷盘的数据。

2. 集群架构

VictoriaMetrics 集群由三个核心组件组成。

组件 主要职责
vminsert 接收写入请求,通过一致性哈希将数据分发到不同的 vmstorage 节点
vmstorage 保存标签索引和时序数据,并执行本地检索
vmselect 接收查询请求,从一个或多个 vmstorage 节点读取数据并汇总结果

三个组件可以分别扩容。vmstorage 采用 Shared-Nothing 架构:节点之间不共享数据,也不需要互相通信。这种结构降低了节点间协调成本,使扩容和故障隔离更简单。


VictoriaMetrics 查询性能测试

Vectoria Metrics 查询性能测试用例

原本是测试某款产品和 vm的对比, 某款产品没有对比意义,已经移除相关对比数据, 只看vm的查询性能即可

测试结果

对比项 vectoria metircs
写入吞吐 886k/s(1.66m/s)
压缩率(源json) 0.22%
查询性能(1并发) 6.19
查询性能(10并发, 7个用例同时进行10、50、100个时间段查询,统计总用时) 34.18 s
查询性能(50并发) 560.47
查询性能(100并发) 2040.83
查询性能(50并发,47.5w/s写) 575.19

测试方案

单次查询脚本

  1. 双方准备测试用例sql
  2. 用例均通过双方的query api接口进行查询,均通过response中的执行耗时进行用例耗时统计
  3. 循环测试用例,每个用例连续执行3遍,新用例执行前清除系统cache
  4. 收集所有用例执行时间
  5. 分别统计 冷执行(用例第一次执行) 和 热执行(用例第二次和第三次执行)所耗时间
  6. 进行对比

VictoriaMetrics 写入吞吐和数据压缩比 测试

测试结果

对比项 X2.0 vectoria metircs score
写入吞吐 x 886k/s(1.66m/s)
压缩比(源json) x 0.22%

benchmark 数据源配置

pod 4c6G

数据生成速率

1
2
3
3000*1230 active time series
scrapeInterval 10秒,1230*3K/10 369k samples/sec
每10分钟 更新10% time series

数据协议,prometheus remote write

数据格式(转json 后)

1
2
3
{"metric":{"__name__":"node_scrape_collector_success","job":"node_exporter","instance":"host-2362","collector":"mdadm","replica":"0","revision":"r0","url_replica":"0"},"values":[1],"timestamps":[1724313603243]}
{"metric":{"__name__":"node_textfile_scrape_error","job":"node_exporter","instance":"host-1398","replica":"0","revision":"r5","url_replica":"0"},"values":[0],"timestamps":[1724313609919]}
{"metric":{"__name__":"node_textfile_scrape_error","job":"node_exporter","instance":"host-1902","replica":"0","revision":"r0","url_replica":"0"},"values":[0],"timestamps":[1724313604325]}

指标数据逻辑存储模型

指标数据逻辑存储模型

常见的时序数据库的数据模型,主要分成单值模型和多值模型

单值模型是根据业务指标数据建模,按照单个指标的细粒度进行数据使用和逻辑存储,如下所示,一行数据只有一个指标值,即value列。目前采用单值模型的时序数据库,有OpenTSDB、 KairosDB、Prometheus等。

1
2
3
4
单值模型:
time host metric value
2026-08-08 10:00:00 web01 cpu_usage 72
2026-08-08 10:00:00 web01 io_usage 31

多值的模型则是针对数据源建模,我们每一行数据针对的是一个数据源,它的被测量的多个指标在同一列上,如下所示,一行数据有多个指标值,即有cpu和io两列。目前采用多值模型的时序数据库,有InfluxDB、TimescaleDB等。

1
2
3
多值模型:
time host cpu_usage io_usage
2026-08-08 10:00:00 web01 72 31

可以把两者理解为:

  • 单值模型:一条时序记录只描述一个指标。
  • 多值模型:一条时序记录同时描述同一数据源在同一时刻的多个指标。

严格来说,多值模型中的多个指标是放在同一行的不同列/字段中,而不是同一列。


指标体系的应用场景 - 动态阈值

指标体系的应用场景 - 动态阈值

在指标体系的应用场景中,基于指标的告警也是指标数据的一个重要应用。

基于指标的告警一般有以下几种类型:

  • 静态阈值:大于/小于 某个具体的值则产生告警(对于明细数据,还可以用中位值/分位值进行阈值判断)
  • 同环比: 同比/环比 变化率/变化值 上升/下降超过多少产生告警
  • 动态阈值: 对比历史同时间段的基线值 产生告警
  • 异常检测:基于历史数据检测度量的异常行为。异常检测会检测指标的行为何时与过去不同,并考虑趋势和季节性
  • 离群点异常检测:离群点异常检测组内与其他成员相比异常的成员,主要用于判断指标的分组组合中哪些和其他组合差异过大
  • 预测告警:预测指标在未来的表现。通过在超出阈值之前发出警报

本篇主要介绍动态阈值的实现方案:


Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×