Es van comparar VictoriaMetrics, TimescaleDB i InfluxDB en un conjunt de dades amb mil milions de punts de dades que pertanyen a 40 sèries temporals úniques.
Fa uns anys hi va haver una era de Zabbix. Cada servidor de metall nu tenia més que uns quants indicadors: ús de CPU, ús de RAM, ús de disc i ús de xarxa. D'aquesta manera, les mètriques de milers de servidors poden encaixar en 40 mil sèries temporals úniques i Zabbix pot utilitzar MySQL com a backend per a dades de sèries temporals :)
Actualment sol amb configuracions predeterminades proporciona més de 500 mètriques a l'amfitrió mitjà. Hi ha molts per a diverses bases de dades, servidors web, sistemes de maquinari, etc. Tots proporcionen una varietat de mètriques útils. Tots començar a establir diversos indicadors per si mateixos. Hi ha Kubernetes amb clústers i pods que exposen moltes mètriques. Això fa que els servidors exposin milers de mètriques úniques per host. Així, la sèrie temporal única de 40K ja no té una gran potència. S'està convertint en corrent i qualsevol TSDB modern hauria de gestionar-lo fàcilment en un sol servidor.
Quin és el gran nombre de sèries temporals úniques actualment? Probablement 400K o 4M? O 40 m? Comparem els TSDB moderns amb aquests números.
Instal·lació d'un punt de referència
és una excel·lent eina de benchmarking per a TSDB. Us permet generar un nombre arbitrari de mètriques passant el nombre necessari de sèries temporals dividit per 10 - bandera (anterior -scale-var). 10 és el nombre de mesures (mètriques) generades a cada host o servidor. Els següents conjunts de dades es van generar mitjançant TSBS per al punt de referència:
- Sèries temporals úniques de 400 60, interval de 3 segons entre punts de dades, les dades abasten un total de 1.7 dies, ~ XNUMX milions de punts de dades totals.
- Sèries temporals úniques de 4 milions, interval de 600 segons, les dades abasten 3 dies complets, ~1.7 mil milions de punts de dades totals.
- 40 milions de sèries temporals úniques, interval d'1 hora, les dades abasten 3 dies complets, ~ 2.8 milions de punts de dades totals.
El client i el servidor s'executaven en instàncies dedicades al núvol de Google. Aquestes instàncies tenien les configuracions següents:
- vCPU: 16
- RAM: 60 GB
- Emmagatzematge: HDD estàndard de 1 TB. Proporciona un rendiment de lectura/escriptura de 120 Mbps, 750 operacions de lectura per segon i 1,5 K escriptures per segon.
Els TSDB es van extreure d'imatges oficials de Docker i es van executar a Docker amb les configuracions següents:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
Els valors d'InfluxDB (-e) són necessaris per suportar una gran potència. Vegeu els detalls a ):
docker run -it --rm -p 8086:8086 -e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 -e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g -e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 -v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdb -
TimescaleDB (configuració extreta de dossier):
MEM=`free -m | grep "Mem" | awk ‘{print $7}’`
let "SHARED=$MEM/4"
let "CACHE=2*$MEM/3"
let "WORK=($MEM-$SHARED)/30"
let "MAINT=$MEM/16"
let "WAL=$MEM/16"
docker run -it — rm -p 5432:5432
--shm-size=${SHARED}MB
-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data
timescale/timescaledb:latest-pg10 postgres
-cmax_wal_size=${WAL}MB
-clog_line_prefix="%m [%p]: [%x] %u@%d"
-clogging_collector=off
-csynchronous_commit=off
-cshared_buffers=${SHARED}MB
-ceffective_cache_size=${CACHE}MB
-cwork_mem=${WORK}MB
-cmaintenance_work_mem=${MAINT}MB
-cmax_files_per_process=100El carregador de dades es va executar amb 16 fils paral·lels.
Aquest article només conté resultats per a punts de referència d'inserció. Els resultats del benchmark selectiu es publicaran en un article separat.
400K sèries temporals úniques
Comencem amb elements simples: 400K. Resultats de referència:
- VictoriaMetrics: 2,6 milions de punts de dades per segon; Ús de RAM: 3 GB; Mida final de les dades al disc: 965 MB
- InfluxDB: 1.2 milions de punts de dades per segon; Ús de RAM: 8.5 GB; Mida final de les dades al disc: 1.6 GB
- Escala de temps: 849K punts de dades per segon; Ús de RAM: 2,5 GB; Mida final de les dades al disc: 50 GB
Com podeu veure als resultats anteriors, VictoriaMetrics guanya en rendiment d'inserció i relació de compressió. La línia de temps guanya en l'ús de la memòria RAM, però utilitza molt d'espai en disc: 29 bytes per punt de dades.
A continuació es mostren els gràfics d'ús de la CPU per a cadascun dels TSDB durant el benchmark:
A dalt hi ha una captura de pantalla: VictoriaMetrics: càrrega de la CPU durant la prova d'inserció per a una mètrica única de 400K.
A dalt hi ha una captura de pantalla: InfluxDB: càrrega de la CPU durant la prova d'inserció per a una mètrica única de 400K.
A dalt hi ha una captura de pantalla: TimescaleDB: càrrega de la CPU durant la prova d'inserció per a una mètrica única de 400K.
VictoriaMetrics utilitza totes les vCPU disponibles, mentre que InfluxDB infrautilitza ~ 2 de cada 16 vCPU.
L'escala de temps només utilitza 3-4 de les 16 vCPU. Altes proporcions d'iowait i sistema al gràfic d'escala de temps de TimescaleDB indiquen un coll d'ampolla al subsistema d'entrada/sortida (I/O). Vegem els gràfics d'ús de l'ample de banda del disc:
A dalt hi ha una captura de pantalla: VictoriaMetrics - Ús de l'ample de banda del disc a la prova d'inserció per a mètriques úniques 400K.
A dalt hi ha una captura de pantalla: InfluxDB - Ús d'amplada de banda del disc a la prova d'inserció per a mètriques úniques 400K.
A dalt hi ha una captura de pantalla: TimescaleDB - Ús de l'ample de banda del disc a la prova d'inserció per a mètriques úniques 400K.
VictoriaMetrics registra dades a 20 Mbps amb pics de fins a 45 Mbps. Els pics corresponen a grans fusions parcials a l'arbre .
InfluxDB escriu dades a 160 MB/s, mentre que una unitat d'1 TB rendiment d'escriptura 120 MB/s.
TimescaleDB es limita a un rendiment d'escriptura de 120 Mbps, però de vegades supera aquest límit i arriba als 220 Mbps en valors màxims. Aquests pics corresponen a les valls d'utilització insuficient de la CPU del gràfic anterior.
Vegem els gràfics d'ús d'entrada/sortida (I/O):
A dalt hi ha una captura de pantalla: VictoriaMetrics - Insereix l'ús d'E/S de prova per a 400K mètriques úniques.
A dalt hi ha una captura de pantalla: InfluxDB - Insereix l'ús d'E/S de prova per a 400K mètriques úniques.
A dalt hi ha una captura de pantalla: TimescaleDB - Insereix l'ús d'E/S de prova per a 400K mètriques úniques.
Ara està clar que TimescaleDB està arribant al seu límit d'E/S, de manera que no pot utilitzar les 12 vCPU restants.
Sèrie temporal única de 4M
Les sèries de temps 4M semblen una mica difícils. Però els nostres competidors aproven aquest examen amb èxit. Resultats de referència:
- VictoriaMetrics: 2,2 milions de punts de dades per segon; Ús de RAM: 6 GB; Mida final de les dades al disc: 3 GB.
- InfluxDB: 330K punts de dades per segon; Ús de RAM: 20,5 GB; Mida final de les dades al disc: 18,4 GB.
- TimescaleDB: 480K punts de dades per segon; Ús de RAM: 2,5 GB; Mida final de les dades al disc: 52 GB.
El rendiment d'InfluxDB va baixar d'1,2 milions de punts de dades per segon per a una sèrie temporal de 400 a 330 punts de dades per segon per a una sèrie de temps de 4 milions. Aquesta és una pèrdua de rendiment important en comparació amb altres competidors. Mirem els gràfics d'ús de la CPU per entendre la causa principal d'aquesta pèrdua:
A dalt hi ha una captura de pantalla: VictoriaMetrics: ús de la CPU durant la prova d'inserció per a una sèrie temporal única de 4M.
A dalt hi ha una captura de pantalla: InfluxDB: ús de la CPU durant la prova d'inserció per a sèries temporals úniques de 4M.
A dalt hi ha una captura de pantalla: TimescaleDB: ús de la CPU durant la prova d'inserció per a una sèrie temporal única de 4M.
VictoriaMetrics utilitza gairebé tota la potència de la unitat de processament (CPU). La caiguda al final correspon a les fusions LSM restants després d'haver inserit totes les dades.
InfluxDB només utilitza 8 de 16 vCPU, mentre que TimsecaleDB utilitza 4 de 16 vCPU. Què tenen en comú els seus gràfics? Alta quota iowait, que de nou indica un coll d'ampolla d'E/S.
TimescaleDB té una quota alta system. Suposem que l'alta potència va donar lloc a moltes trucades al sistema o moltes .
Vegem els gràfics de rendiment del disc:
A dalt hi ha una captura de pantalla: VictoriaMetrics: ús de l'amplada de banda del disc per inserir 4M mètriques úniques.
A dalt hi ha una captura de pantalla: InfluxDB: ús de l'amplada de banda del disc per inserir 4M mètriques úniques.
A dalt hi ha una captura de pantalla: TimescaleDB: ús de l'amplada de banda del disc per inserir 4M mètriques úniques.
VictoriaMetrics va assolir un límit de 120 MB/s al màxim, mentre que la velocitat mitjana d'escriptura era de 40 MB/s. És probable que es van realitzar diverses fusions LSM pesades durant el pic.
InfluxDB torna a extreure un rendiment mitjà d'escriptura de 200 MB/s amb pics de fins a 340 MB/s en un disc amb un límit d'escriptura de 120 MB/s :)
TimescaleDB ja no està limitat al disc. Sembla que està limitat per una altra cosa relacionada amb una proporció elevada системной Càrrega de la CPU.
Vegem els gràfics d'ús d'IO:
A dalt hi ha una captura de pantalla: VictoriaMetrics - Ús d'E/S durant la prova d'inserció per a una sèrie temporal única de 4M.
A dalt hi ha una captura de pantalla: InfluxDB - Ús d'I/O durant la prova d'inserció per a una sèrie temporal única de 4M.
A dalt hi ha una captura de pantalla: TimescaleDB - Ús d'E/S durant la prova d'inserció per a sèries temporals úniques de 4M.
Els patrons d'ús d'IO reflecteixen els de l'amplada de banda del disc: InfluxDB és limitat d'IO, mentre que VictoriaMetrics i TimescaleDB tenen recursos d'IO de recanvi.
40 milions de sèries temporals úniques
La sèrie temporal única de 40 milions era massa gran per a InfluxDB :)
Resultats de referència:
- VictoriaMetrics: 1,7 milions de punts de dades per segon; Ús de RAM: 29 GB; Ús d'espai en disc: 17 GB.
- InfluxDB: no s'ha acabat perquè necessitava més de 60 GB de RAM.
- TimescaleDB: 330K punts de dades per segon, ús de RAM: 2,5 GB; Ús d'espai en disc: 84 GB.
TimescaleDB mostra un ús de RAM excepcionalment baix i estable a 2,5 GB, el mateix que per a les mètriques úniques de 4M i 400K.
VictoriaMetrics va augmentar lentament a una velocitat de 100 punts de dades per segon fins que es van processar tots els 40 milions de noms de mètriques etiquetats. Després va aconseguir una taxa d'inserció sostinguda d'1,5-2,0 milions de punts de dades per segon, de manera que el resultat final va ser d'1,7 milions de punts de dades per segon.
Els gràfics de sèries temporals úniques de 40 milions són similars als gràfics de sèries temporals úniques de 4 milions, així que ometem-los.
Troballes
- Els TSDB moderns són capaços de processar insercions per a milions de sèries temporals úniques en un sol servidor. En el següent article, provarem fins a quin punt els TSDB fan la selecció en milions de sèries temporals úniques.
- La utilització insuficient de la CPU sol indicar un coll d'ampolla d'E/S. També pot indicar que el bloqueig és massa gros, amb només uns quants fils capaços d'executar-se alhora.
- El coll d'ampolla d'E/S existeix, especialment en l'emmagatzematge no SSD, com els dispositius de blocs virtualitzats dels proveïdors de núvol.
- VictoriaMetrics ofereix la millor optimització per a l'emmagatzematge d'E/S lent i baix. Proporciona la millor velocitat i la millor relació de compressió.
Descarrega i prova-ho amb les teves dades. El binari estàtic corresponent està disponible a .
Llegiu més sobre VictoriaMetrics en això .
Actualització: publicat amb resultats reproduïbles.
Actualització núm. 2: llegiu també .
Actualització #3: !
Xat de Telegram:
Font: www.habr.com