The release of the VictoriaMetrics 1.94.0 platform is available, which provides a DBMS for storing and processing data in the form of a time series (the record forms time and a set of values corresponding to this time, for example, obtained through periodic polling of the status of sensors or collection of metrics), optimized for solving monitoring problems. The project competes with solutions such as InfluxDB, TimescaleDB, Thanos, Cortex and Uber M3, and has higher performance. The DBMS can be used as a long-term data store connected to Prometheus and Grafana, and also as a transparent replacement for InfluxDB. The code is written in Go and distributed under the Apache 2.0 license.
In performance tests, VictoriaMetrics outperforms InfluxDB and TimescaleDB by up to 20 times faster than InfluxDB and 10 times less RAM than Prometheus, Thanos, and Cortex when processing millions of unique time series. Storing data in compressed form allows you to fit 7 times more records in the same amount of storage compared to Prometheus, Thanos and Cortex, and 7 times more than TimescaleDB. There are specific optimizations for storage with high latency and low I/O intensity (for example, hard drives and cloud storage AWS, Google Cloud and Microsoft Azure).
The DBMS is designed as a single executable file with minimal settings passed through the command line upon startup. All data is stored in one directory, specified at startup using the “-storageDataPath” flag. The query language used is MetricsQL, an extended version of the PromQL language used in the Prometheus monitoring system. In addition to continuous processing of incoming data, VictoriaMetrics also provides the ability to download previously collected historical data.
Tools are provided to protect the integrity of the storage from data corruption, for example, during an emergency power outage (the storage is in the form of a log-structured tree with merging), as well as a simple backup system based on snapshots. It is possible to combine VictoriaMetrics nodes into a horizontally scalable cluster that supports high availability mechanisms.
Among the innovations added in the new release:
- In MetricsQL, for clarity, numbers are separated by underlining (for example, you can specify 1_234_567_890 and 1.234_567_890 instead of 1234567890 and 1.234567890).
- vmbackup now supports leaving on server copies of created backups.
- An option has been added to the vmui interface to show the 25 most recent requests. Added support for exporting data to Prometheus to the Explore cardinality page. Added a button to automatically format PromQL/MetricsQL queries. Improved visibility of diagrams. Request history storage has been added to localStorage.
- vmagent has expanded the management capabilities of cluster nodes, improved error handling, and reduced the load on the Kubernetes control panel during initial service discovery.
- In a cluster, the maximum allowed recovery time for vmselect and vminsert operations has been reduced from 60 to 3 seconds in a situation where some vmstorage nodes are unavailable.
Separately, we can note the holding of a virtual conference today at 19:XNUMX Moscow time, at which VictoriaMetrics developers will introduce new project capabilities and development plans, talk about platform management and anomaly detection, and also share information about the development of an open DBMS for logging VictoriaLogs. The event will conclude with a Q&A session.
Source: opennet.ru
