Dostępna jest wersja platformy VictoriaMetrics 1.94.0, która oferuje system zarządzania bazą danych do przechowywania i przetwarzania danych w formie szeregów czasowych (zapisy składają się z czasu i zestawu odpowiadających temu czasowi wartości, np. uzyskanych w wyniku okresowego odpytywania stanu czujników lub zbierania metryk), zoptymalizowaną do rozwiązywania zadań monitorowania. Projekt konkuruje z takimi rozwiązaniami jak InfluxDB, TimescaleDB, Thanos, Cortex i Uber M3, wyróżniając się wyższą wydajnością. System zarządzania bazą danych może być używany jako długoterminowe magazynowanie danych, podłączone do Prometheus i Grafana, a także jako przezroczysta alternatywa dla InfluxDB. Kod napisany jest w języku Go i jest dystrybuowany na licencji Apache 2.0.
W testach wydajności VictoriaMetrics przewyższa InfluxDB i TimescaleDB przy wykonywaniu operacji wstawiania i pobierania danych nawet do 20 razy, zużywając przy tym 10 razy mniej pamięci RAM niż InfluxDB i 7 razy mniej niż Prometheus, Thanos i Cortex przy przetwarzaniu milionów unikalnych szeregów czasowych. Przechowywanie danych w skompresowanej formie pozwala pomieścić w tej samej wielkości magazynie 7 razy więcej zapisów w porównaniu do Prometheus, Thanos i Cortex, a 70 razy więcej w porównaniu z TimescaleDB. Istnieją specyficzne optymalizacje dla magazynów o dużych opóźnieniach i niskiej intensywności operacji wejścia/wyjścia (np. dyski twarde i chmurowe magazyny AWS, Google Cloud i Microsoft Azure).
System zarządzania bazą danych jest przedstawiony w postaci jednego pliku wykonywalnego z minimalnymi ustawieniami, przekazywanymi przez wiersz poleceń podczas uruchamiania. Wszystkie dane są przechowywane w jednym katalogu, określonym podczas uruchamiania za pomocą flagi „-storageDataPath”. Jako język zapytań używany jest MetricsQL, rozszerzona wersja języka PromQL, stosowanego w systemie monitorowania Prometheus. Oprócz ciągłego przetwarzania napływających danych, w VictoriaMetrics przewidziano również możliwość załadowania wcześniej zebranych danych historycznych.
Oferowane są narzędzia do ochrony integralności magazynu przed uszkodzeniem danych, na przykład w przypadku nagłego wyłączenia zasilania (magazyn ma formę drzewa strukturalnego z dziennikiem i scaleniem), a także prosty system tworzenia kopii zapasowych oparty na migawkach. Możliwe jest scalanie węzłów VictoriaMetrics w poziomo skalowalny klaster, wspierający mechanizmy zapewniające wysoką dostępność.
Wśród nowości w nowej wersji:
- W MetricsQL dla przejrzystości dozwolone jest dzielenie liczb podkreślnikiem (na przykład można podawać 1_234_567_890 i 1.234_567_890 zamiast 1234567890 i 1.234567890).
- W vmbackup dodano wsparcie dla pozostawiania na serwerze kopii utworzonych kopii zapasowych.
- W interfejsie vmui dodano opcję wyświetlania 25 ostatnich zapytań. Na stronę „Eksploruj kardynalność” dodano wsparcie dla eksportu danych do Prometheus. Dodano przycisk do automatycznego formatowania zapytań PromQL/MetricsQL. Zwiększono przejrzystość diagramów. W localStorage dodano magazyn historii zapytań.
- W vmagent rozszerzono możliwości zarządzania węzłami klastra, poprawiono obsługę błędów i zredukowano obciążenie panelu sterowania Kubernetes podczas początkowego wykrywania usługi.
- W klastrze maksymalny czas przywracania podczas wykonywania operacji vmselect i vminsert skrócono z 60 do 3 sekund w sytuacji, gdy niektóre węzły vmstorage są niedostępne.
Osobno można wspomnieć o dzisiejszej wirtualnej konferencji, która odbędzie się o godzinie 19:00 czasu moskiewskiego, podczas której twórcy VictoriaMetrics zaprezentują nowe możliwości projektu oraz plany rozwoju, opowiedzą o zarządzaniu platformą i wykrywaniu anomalii, a także podzielą się informacjami na temat rozwoju otwartej bazy danych do logów VictoriaLogs. Na zakończenie wydarzenia odbędzie się sekcja odpowiedzi na pytania.
Źródło: opennet.ru
