Koden för VictoriaMetrics har offentliggjorts, en tidsseriedatabas som är kompatibel med Prometheus

Öppna källtexter VictoriaMetrics — en snabb och skalbar databas för lagring och bearbetning av data i form av tidsserier (en post innefattar tid och en uppsättning värden som motsvarar denna tid, till exempel erhållna genom periodisk kontroll av sensorstatus eller insamling av mätvärden). Projektet konkurrerar med lösningar som InfluxDB, TimescaleDB, Thanos, Cortex och Uber M3. Koden är skriven i Go och sprids är licensierad under Apache 2.0.

Fördelar och egenskaper hos VictoriaMetrics:

• Enkel att använda. Består av en enda körbar fil med minimala inställningar som överförs via kommandoraden vid start. All data lagras i en enda katalog som anges vid start med flaggan "-storageDataPath";
• Stöd för frågespråk PromQL, som används i övervakningssystemet Prometheus. Underfrågor i PromQL och vissa utökade funktioner, såsom uttrycket "offset", mönster inom "WIDTH", operatörerna "if" och "default", extra funktioner och möjligheten att inkludera kommentarer;
• Möjlighet att använda som ett långvarigt dataförråd, kopplat till Prometheus och Grafana.
• Finns det en backfill-läge för att ladda historisk data;
• Stöd för olika dataöverföringsprotokoll, inklusive Prometheus API, Influx, Graphite och OpenTSDB. VictoriaMetrics kan även fungera som en transparent ersättning för InfluxDB och kan samarbeta med InfluxDB-kompatibla insamlare såsom Telegraf;
• Hög prestanda och lågt resursutnyttjande i jämförelse med konkurrerande system. I vissa tester överträffar VictoriaMetrics InfluxDB och TimescaleDB när det gäller insättnings- och urvaloperationer med upp till 20 gånger. Vid analyserande frågor kan vinsten jämfört med relationsdatabaser som PostgreSQL och MySQL vara från 10 till 1000 gånger.
  
  
  
• Det finns att bearbetning av mycket stora mängder unika tidsserier. Vid bearbetning av miljontals olika tidsserier använder den upp till 10 gånger mindre RAM än InfluxDB.
• Hög datakomprimering i disklagring. Jämfört med TimescaleDB kan den rymma upp till 70 gånger fler poster i samma lagringsutrymme;
• Optimeringar för lagringssystem med hög latens och låg I/O-operationer per sekund (till exempel hårddiskar och molnlagringar i AWS, Google Cloud och Microsoft Azure);
• Enkel backup-lösning baserad på snapshots;
• Tillgång till medel för att skydda lagringens integritet mot dataskador, till exempel vid oväntat strömavbrott (lagringen har formen av ett tidsstämplat strukturerat träd med sammanslagningar);
• Implementering på Go-språket, vilket ger en balans mellan prestanda och kodens komplexitet jämfört med Rust och C++.
• Källkoder tillhandahålls klusterversioner, vilket stödjer horisontell skalning över flera servrar och visar låga overheadkostnader. Det finns verktyg för att säkerställa hög tillgänglighet.

Källa: opennet.ru