-
VictoriaMetrics将传入的数据缓冲到RAM中,并定期将其刷新到磁盘里的类似sstable的数据结构中,刷新的时间间隔被硬编码为1秒(刷新到内存顺序结构中是1s,从内存刷新到磁盘的间隔是5s)
-
Write-ahead logging 往往要消耗磁盘IO带宽的很大一部分,由于这一缺点,建议将WAL放入一个单独的物理磁盘。直接写SSTable方法需要较少的磁盘IO带宽,因此没有WAL的数据库可以处理更多的数据量
-
WAL可能会因为缓慢的恢复步骤而减缓数据库启动的时间,甚至可能导致OOMS和崩溃循环、
-
prometheus、fluxdb和Cassandra 已经在sstable 中使用了类似lsm的数据结构,所以他们可能会很快转向新的方法,目前还不清楚TimescaleDB是否会使用这种新方法,因为它没有使用LSM
-
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中运行。我们通过部署管理器将基础结构作为代码方法用户资源管理和供应。