VictoriaMetrics学习

1. VictoriaMetrics将传入的数据缓冲到RAM中，并定期将其刷新到磁盘里的类似sstable的数据结构中，刷新的时间间隔被硬编码为1秒(刷新到内存顺序结构中是1s,从内存刷新到磁盘的间隔是5s)

2. Write-ahead logging 往往要消耗磁盘IO带宽的很大一部分，由于这一缺点，建议将WAL放入一个单独的物理磁盘。直接写SSTable方法需要较少的磁盘IO带宽,因此没有WAL的数据库可以处理更多的数据量

3. WAL可能会因为缓慢的恢复步骤而减缓数据库启动的时间，甚至可能导致OOMS和崩溃循环、

4. prometheus、fluxdb和Cassandra 已经在sstable 中使用了类似lsm的数据结构，所以他们可能会很快转向新的方法，目前还不清楚TimescaleDB是否会使用这种新方法，因为它没有使用LSM

5. VictoriaMetrics的存储使用Clickhouse的MergeTree表引擎的思想从头开始构建；

• 分别存储时间序列名称，时间戳和值（也称为列存储）。通过仅扫描所需的列，可以加快查询速度

• 将每一列存储在类似于日志合并树（LSM)的数据结构中。与类似B树的数据结构相比，当添加/扫描排序的值时，这减少了随机I/O。这样可以加快HDD的存储速度。LSM文件是不可改变的。这样可以简化加速快照和备份的过程。与B树相比，LSM有一个缺点，当较小的文件合并为较大的文件时，存储的数据将被多次重写。这浪费了磁盘的带宽，但ClickHouse的实践表明这是一个很好的权衡。

• 以适合CPU缓存的块形式处理数据。由于它不等待来自慢速RAM的数据，因此可以最大化CPU性能。

最初Prometheus标签的索引已经建立在Go的LevelDB端口之上。后来作者尝试用更有效的替代方法RocksDB代替它。但是由于cgo开销很高，因此无法成功，必须在每个扫描的标签上花费经历。最终LevelDB被一个自定义数据结构代替-mergeset。该数据结构针对Prometheus标签的索引进行了专门优化。

mergeset与LevelDB相比，具有以下差异：

• 它仅针key操作，不用关系values

• 它拥有更小的写放大

• 它对查找有序的key速度更快

• 它可以更好的压缩key，因此他需要较少的存储空间

• 它提供及时的数据快照和轻松的备份

• 它使用了ClickHouse的MergeTree表引擎的想法。

最初VictoriaMetrics是单服务器解决方案。后来它已转化为集群解决方案。转换期间，单个服务已经分为三个服务：

vmstorage-存储从接收的指标值vminsert,返回来自查询的原始指标值vmselect。

• vminsert-通过Prometheus_remote_write api接收指标并将其发送给vmstorage

• vmselect-实现Prometheus查询API。从中获取原始数据vmstorage

拆分有如下好处：

• 每个服务可以独立扩展

• 每个服务都可以再针对服务需求进行了优化的硬件上运行

• 繁重的insert不会干扰到繁重的select

• 错误的vminsert不会中断vmselect,反之亦然

• 更好的vmstorage持久性，因为它将复杂的查询逻辑推到了vmselect

现在，VictoriaMetrics在Google_cloud中运行。我们通过部署管理器将基础结构作为代码方法用户资源管理和供应。