TSDB - VictoriaMetrics 技术原理浅析

一、前言

     在监控领域，通常需要指标存储组件TSDB，目前开源的TSDB组件比较多，各个组件性能、高可用性、维护成本等等各有差异。本文不分析选型问题，重点讲解VictoriaMetrics（后面简称为vm）。

     有兴趣的朋友建议结合源码进行分析，由于源码不断变更，此分析基于 v1.80.0，后续版本变化理论上不会很大。

二、架构与能力

   vm开源版本分为single-server（all in one）的单节点模式和cluster模式，单点模式合适本地调试或测试使用，生产使用的cluster模式分为vmselect、vminsert、vmstorage三个主要模块：  

    （1）vmselect：查询模块，可无状态部署，客户端发送请求到查询模块后，查询模块会把请求分发到所有storage模块（由于没有元数据中心节点，固数据存储在哪无法感知，类似clickhouse的设计模式），得到原始的block数据后在select模块进行合并，再得到一个总结果。

    （2）vminsert：写入模块，可无状态部署，写入数据的请求发到此模块后，根据labels通过一定的hash计算出一个值，根据这个值确定此条数据发往哪个storage节点。因此相同的时间线会往同一个点节点发送，如果有某个时间线数据量特别大则会出现数据倾斜问题后某个storage写入和查询压力都会增大。在扩容货缩容后，由于节点的列表变更，固计算出的hash发往的storage节点也会变更。

    （3）vmstorage：存储模块，有状态，存储模块的移除须先从select和insert的配置中移除才不会有异常，此模块压力最大，非常消耗内存和IO，固推荐使用SSD和比较大的内存，宁愿用大规格的机器也不用量多但规格较小的机器（缓存不命中则会造成较多的IO，性能下降严重）。

三、vmstorage 存储模块

  本文重点讲难度最高的 storage 模块，也只是属于个人理解，如有错误或偏差，望指正。

1、存储目录结构

/data 数据目录的逻辑结构如下：

 （1）每个block只包括一个时间线，内部根据时间排序。

   (2) 每个block最大容纳8000个sample，不同block可并发处理。

2、 写入流程与风险点

3、查询流程与风险点

 

4、数据过期机制

    开源的cluster版本只能针对租户使用全局的统一过期时间，收费的企业版才能支持租户单独设置过期时间。

 

5、数据安全性保障

  （1）VictoriaMetrics 并未使用WAL，而是直接写入类似SSTable的内存结构中，定时刷写磁盘，这是此模块能表现出极高的写入性能的一个原因，如果是单副本则宕机时有可能照成最近的少量数据丢失，如果是数据安全性要求极高的场景，则建议开启双副本模式。

  （2）双副本状态下，写入性能有一定的下降。即使在双副本模式下，不能同时下线两台主机，如果同时下掉两台主机则数据会丢失，为保证数据安全，建议对存储层配置RAID1、RAID5或RAID10保证数据安全性，迁移时将数据从data目录直接迁移走即可在另一主机运行。

四、运维&监控能力、Downsample

  （1）vm配置有grafana的监控模板，安装即可观测各个模块的性能，需要结合代码才能比较深入的了解各个指标的作用含义（不过最前面部分的CPU/内存总量的计算貌似不正确，未深究，有兴趣可以看看什么问题）。

  （2）vm写入由于没有WAL，如果出现大量缓存失效则容易出现慢写入，甚至大量超时，所以写入建议前置一个MQ（如kafka）缓解写入异常放大，写入模块做一定的异常限流防止查询也出现大量超时。

  （3）vm很吃内存和磁盘，磁盘随机IO很多，建议配置SSD。

  （4）vm开源版不支持存储层的downsample（企业版才支持），故会查询原始数据后通过promQL配置采样减少输出点，但总的来说不是存储层的downsample查询时间范围过大时会有很大的压力（比如一个月以上），建议上报的数据1分钟一个点位减少数据量。

五、性能见解与总结

  官方写了一些英文博文对比influxdb的性能，vm的表现优异，但建议实测（官方提供的总有一些趋向性）。从个人的测试数据上看表现确实很不错，数据不方便公开，建议自测。

  总之，此款基于golang的开源TSDB性能表现很好，要能驾驭这组件需要比较多的功力，不能单纯从表层去把它当做一个黑盒来运维，以免后续出现慢写入慢查询会变得手足无措。

  源码层面的分析可以搜索下其他文章，在此就不再分析代码段。