随着云原生普及和快速发展，可观测能力也成为云原生平台的重要能力。 可观测对TSDB的依赖非常重要，因为它是可观测所使用的核心技术之一，可观测存储、查询、检测和可视化指标数据都依赖TSDB。本文主要通过VictoriaMetrics来了解TSDB的一些常用特性及存储。
VictoriaMetrics是一款基于Go语言开发的开源时序数据库。它提供高性能、低延迟和可扩展的时序数据存储和查询服务。本文主要简单介绍下VictoriaMetrics的特性、架构及存储。
VictoriaMetrics特性
- 可作为prometheus的远程存储，内置实现了prometheus remote writer接口协议
- 兼容主流promQL语法
- 集群版方案提供了高性能和良好的横向可扩展性
- 在处理高基数的场景下内存消耗只有prometheus的几分之一，高流失率的时间序列进行了优化
- 提供高效的数据压缩算法
- 单节点VictoriaMetrics可支持百万时间序列的监控产品，可作为prometheus、Thanos的替代品，并且具有更优秀的性能表现
VictoriaMetrics 的架构
VictoriaMetrics支持单节点和集群两种模式。VictoriaMetrics的集群主要由vmstorage、vminsert、vmselect等三个核心组件组成，vmstorage 提供数据存储; vminsert 负责数据插入，使用一致性hash算法写入分片； vmselect 负责数据查询，可以通用promQL从 vmstorage 中查询数据，进行去重和运算。
VictoriaMetrics三个核心组件可以单独进行扩展。vmstorage采用shared-nothing架构，优点是 vmstorage的节点相互之间无感知，相互无需通信，不共享数据，增加了集群可用性、简化集群的运维和集群的扩展的成本。缺点是没有元数据模块，在集群规模、数据均衡迁移、完整分布式能力方面有缺失。
VictoriaMetrics 集群架构的图示：
VictoriaMetrics 的数据模型
VictoriaMetrics 的数据模型主要由以下几个要素构成：
metric：代表一个指标，例如 CPU 利用率、内存使用率等
label：用于区分不同的 Metric。一个 Metric 可以有多个 Label，"__name__"作为一个特殊的label
timestamp：代表指标采集时间
value：代表指标的数值
这些要素共同构成了时序数据，例如以下的示例：
{"metric":{"__name__":"temperature","sensor_id":"12345"},"values":123,"timestamps":1680000058000}
VictoriaMetrics 的存储目录介绍
我们先测试导入数据
curl -X POST http://localhost:8428/api/v1/import -d '{"metric":{"__name__":"temperature","sensor_id":"12345"},"values":[123],"timestamps":[1680000058000]}'
磁盘目录
根目录下主要包括data、indexdb、metadata、snapshots、tmp目录
Data:数据目录
Indexdb:索引目录
Metadata:元数据目录，新版本增加
Snapshots:快照
Tmp:临时（查询中间结果等）
数据目录
数据目录具体结构如图data所示，主要分为big，small目录，两个目录结构类似，数据目录下的part主要存储timestamps,values字段的数据
两个目录之间有什么关联，如何工作的呢。VictoriaMetrics写数据时，会先写入到small目录下的partition下，同时VictoriaMetrics会周期性检查，small目录和big目录，检查partition目录下的part是否需要做merge。如果检查有满足merge条件的parts，则这些parts合并为一个大的part，且small目录下的part超过设定阈值时会转入到big目录下。small目录和big目录中的数据压缩算法也有些差别。
索引目录
索引目录下的part主要存储item（labels、metric）索引文件
总结
本文简单介绍了VictoriaMetrics的特性、集群版架构以及VictoriaMetrics的存储目录。VictoriaMetrics可以用来作为Prometheus远程存储或者替代方案，值得大家尝试使用。关于VictoriaMetrics的存储原理需要进一步探究。
