Le code de VictoriaMetrics, une base de données pour séries temporelles compatible avec Prometheus, est ouvert

Ouvert codes sources VictoriaMetrics — une SGBD rapide et évolutive pour le stockage et le traitement des données sous forme de séries temporelles (une entrée formant un temps et un ensemble de valeurs correspondantes à ce temps, par exemple, obtenues par un sondage périodique de l'état des capteurs ou la collecte de métriques). Le projet concurrence des solutions telles que InfluxDB, TimescaleDB, Thanos, Cortex et Uber M3. Le code est écrit en Go et est distribué sous licence Apache 2.0.

Avantages et caractéristiques de VictoriaMetrics :

• Facile à utiliser. Il s'agit d'un seul fichier exécutable avec des configurations minimales passées par la ligne de commande lors du démarrage. Toutes les données sont stockées dans un seul répertoire, défini au démarrage à l'aide du drapeau « -storageDataPath » ;
• Support du langage de requêtes PromQL, utilisé dans le système de surveillance Prometheus. Les sous-requêtes PromQL et certains fonctionnalités avancées, telles que l'expression « offset », des modèles à l'intérieur de « WIDTH », des opérateurs « if » et « default », des fonctions supplémentaires et la possibilité d'inclure des commentaires ;
• Possibilité d'être utilisé comme un stockage de données à long terme, connecté à Prometheus et Grafana.
• Disponibilité d'un mode de remplissage inverse pour le chargement des données historiques ;
• Support de divers protocoles de transmission de données, y compris Prometheus API, Influx, Graphite et OpenTSDB. VictoriaMetrics peut également être utilisé comme un remplacement transparent d'InfluxDB et peut fonctionner avec des collecteurs compatibles avec InfluxDB tels que Telegraf ;
• Haute performance et faible consommation de ressources comparé à des systèmes concurrents. Dans certains tests, VictoriaMetrics surpasse InfluxDB et TimescaleDB dans l'exécution d'opérations d'insertion et de sélection de données jusqu'à 20 fois. En exécutant des requêtes analytiques, le gain par rapport aux SGBD relationnels PostgreSQL et MySQL peut aller de 10 à 1000 fois.
  
  
  
• Il est possible la possibilité de traiter un très grand nombre de séries temporelles uniques. Lors du traitement de millions de séries temporelles différentes, il consomme jusqu'à 10 fois moins de RAM qu'InfluxDB.
• Un grand taux de compression des données dans le stockage sur disque. Comparé à TimescaleDB, il peut contenir jusqu'à 70 fois plus d'enregistrements dans le même volume de stockage ;
• Dispositions d'optimisation pour les stockages à grande latence et faible nombre d'opérations d'entrée/sortie par seconde (par exemple, disques durs et espaces de stockage Cloud d'AWS, Google Cloud et Microsoft Azure) ;
• Système simple de sauvegarde basé sur des instantanés;
• Disponibilité de moyens pour protéger l'intégrité du stockage contre les dommages aux données, par exemple en cas de coupure de courant (le stockage prend la forme d'un arbre structuré en journaux avec fusion);
• Implémentation en langage Go, ce qui assure un compromis entre performance et complexité du code par rapport à Rust et C++.
• Des codes sources sont fournis versions de cluster, qui prend en charge le dimensionnement horizontal sur plusieurs serveurs et affiche des frais généraux bas. Des moyens pour assurer une haute disponibilité sont disponibles.

Source : opennet.ru