先看看VictoriaMetrics官网网站上是如何作(tree)宣(new)传(bee)的：

官方广告

• 为高性能而设计

• 便于安装

• 支持单机和群集版本

• 最小的sample size

• 数据去重能力(deduplication)

• high churn rate support

  • （防止？）高流失率
  • 识别和消除具有频繁更改值的标签

如果旧时间序列不断被新时间序列以高速率取代，那么这种状态称为高流失率。 高流失率有以下负面影响：

• 增加了存储在数据库中的时间序列总数。

• 增加了存储在 <-storageDataPath>/indexdb 中的倒排索引的大小，因为倒排索引包含每个时间序列的每个标签的条目，并且至少有一个摄取的样本。

• 在多天内减慢查询速度。

  针对高流失率的解决方案是识别和消除具有频繁更改值的标签。 /api/v1/status/tsdb 页面可以帮助确定这些标签。

• 优化过的存储系统带来低延迟和低IOPS占用

• 高查询性能

• 基于模板：可以很简单的编写和管理复杂查询

• 支持并改进PromQL的函数

• 新增超过100个函数（后面还会加更多）

• 支持的PUSH协议

  • Graphite
  • OpenTSDB
  • Influx

• 通过vmagent支持prometheus协议的pull

• 协议对等

  • (啥意思？)

• 支持复制

• 支持增量备份

  • 到本地磁盘
  • 到对象存储

• 从中断点自动恢复流

• 支持prometheus的alterting rules

• 内置alert manager

• 就算重启也会保留alert状态

• 数据导入支持

  • JSON
  • CSV
  • prometheus暴露的数据
  • 其他流行的格式

• 数据导出支持

  • JSON
  • CSV
  • 其他流行的格式

• 备份协议支持

  • Graphite
  • OpenTSDB
  • Influx

• 支持remote write协议

• 支持并改进promql函数

• 支持联邦部署模式

• metric加密

• 端口鉴权

• 多租户支持

---

特点

1.可以用于prometheus的长期存储

2.可以代替grafana后端的prometheus

• 因为支持prometheus query API

3.可以替代grafana后端的Graphite

• 因为支持Graphite API

4.安装和运营很简单

• 单一的小小的二进制文件

• 所有的配置项都通过命令行参数

• 所有数据都存储在单一目录

• 又简单又快的备份能力

5.PromQL-based query language - MetricsQL

6.提供全局查询视图

• 可通过单个query查询多个 prometheus实例

7.高性能

• 在数据摄入和数据查询方面都具备很好的水平和垂直扩容能力

• 相比InfluxDB和TimescaleDB，性能有20倍提升

8.内存占得少

• 在对比100万不同的时间序列下：

• 比InfluxDB少10倍

• 比prometheus少7倍

9.优化时间序列达到高流失率

10.高数据压缩率

• 对比data point:

• 比TimescaleDB少70倍

• 比prometheus少7倍

11.低延迟，低IOPS占用

12.一个打十个

• 单个节点就能替代thanos的中等规模集群

13.它可以保护存储免受非正常关机时的数据损坏

14.支持多种方式灌入数据

• 方式包括：抓取、摄入、备份恢复

• 协议有10种以上

15.支持标签重定义

• relabeling

16.series limiter能力

• 解决有大量相同label值的time series

• 解决大量短暂出现的time series

17.其他

• time series删除能力

• 后台数据合并机制

  • 每月一个数据分区

  • 可以让过去月份的分区进行强制合并

• time series导出能力

• time series导入能力

• 联邦部署