VictoriaMetrics, TimescaleDB kaj InfluxDB estis komparitaj en sur datumaro kun miliardo da datumpunktoj apartenantaj al 40K unika temposerio.
Antaŭ kelkaj jaroj estis epoko de Zabbix. Ĉiu nuda metala servilo havis ne pli ol kelkaj indikiloj - CPU-uzado, RAM-uzado, disko-uzado kaj reto-uzado. Tiel, metrikoj de miloj da serviloj povas konveni en 40 mil unikajn temposerio, kaj Zabbix povas uzi MySQL kiel backend por temposerio datumoj :)
Nuntempe sola kun defaŭltaj agordoj provizas pli ol 500 metrikojn sur la averaĝa gastiganto. Estas multaj por diversaj datumbazoj, retserviloj, aparataj sistemoj, ktp. Ili ĉiuj provizas diversajn utilajn metrikojn. Ĉiuj komencas starigi diversajn indikilojn por si mem. Estas Kubernetes kun aretoj kaj podoj kiuj elmontras multajn metrikojn. Ĉi tio rezultigas servilojn elmontrantajn milojn da unikaj metrikoj per gastiganto. Do la unika 40K temposerio ne plu estas alta potenco. Ĝi fariĝas ĉefa kaj devus esti facile pritraktata de iu ajn moderna TSDB sur ununura servilo.
Kio estas la granda nombro da unikaj temposerio nuntempe? Verŝajne 400K aŭ 4M? Aŭ 40 m? Ni komparu modernajn TSDB-ojn kun ĉi tiuj nombroj.
Instalante benchmark
estas bonega benchmarking-ilo por TSDB-oj. Ĝi permesas vin generi arbitran nombron da metrikoj pasante la postulatan nombron da temposerio dividita per 10 - flago (iama -scale-var). 10 estas la nombro da mezuradoj (metriko) generitaj sur ĉiu gastiganto aŭ servilo. La sekvaj datenoj estis generitaj uzante TSBS por la komparnormo:
- 400K unika temposerio, 60-sekunda intervalo inter datumpunktoj, datumoj daŭras plene 3 tagojn, ~1.7B totala nombro da datumpunktoj.
- 4M unika temposerio, 600 sekunda intervalo, datumoj daŭras 3 plenajn tagojn, ~1.7B tutsumo de datenpunktoj.
- 40M unika temposerio, 1-hora intervalo, datumoj ampleksas plenajn 3 tagojn, ~2.8B totala nombro da datenpunktoj.
La kliento kaj servilo funkciis per dediĉitaj petskriboj en Google-nubo. Ĉi tiuj okazoj havis la sekvajn agordojn:
- vCPU-oj: 16
- RAM: 60 GB
- Stokado: Norma 1TB HDD. Ĝi provizas 120 Mbps legadon/skriban trairon, 750 legajn operaciojn je sekundo kaj 1,5K skribojn sekundo.
TSDB-oj estis ĉerpitaj de oficialaj docker-bildoj kaj rulitaj en docker kun la sekvaj agordoj:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
InfluxDB (-e) valoroj estas postulataj por subteni altan potencon. Vidu detalojn en ):
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 (agordo prenita de dosiero):
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=100La datuma ŝargilo funkciis per 16 paralelaj fadenoj.
Ĉi tiu artikolo enhavas nur rezultojn por enmetaj komparnormoj. La rezultoj de la elekta komparnormo estos publikigitaj en aparta artikolo.
400K unika temposerio
Ni komencu per simplaj elementoj - 400K. Konferencaj rezultoj:
- VictoriaMetrics: 2,6M datumpunktoj sekundo; RAM-uzado: 3 GB; fina datuma grandeco sur disko: 965 MB
- InfluxDB: 1.2M datumpunktoj sekundo; RAM-uzado: 8.5 GB; fina datuma grandeco sur disko: 1.6 GB
- Temposkalo: 849K datumpunktoj je sekundo; RAM-uzo: 2,5 GB; fina datuma grandeco sur disko: 50 GB
Kiel vi povas vidi de la rezultoj supre, VictoriaMetrics gajnas en eniga rendimento kaj kunprema proporcio. Templinio gajnas en RAM-uzado, sed ĝi uzas multe da diskospaco - 29 bajtoj per datumpunkto.
Malsupre estas la CPU-uzografikoj por ĉiu el la TSDB-oj dum la komparnormo:
Supre estas ekrankopio: VictoriaMetrics - CPU-ŝarĝo dum enmeta testo por unika 400K metriko.
Supre estas ekrankopio: InfluxDB - CPU-ŝarĝo dum enmeta testo por unika metriko 400K.
Supre estas ekrankopio: TimescaleDB - CPU-ŝarĝo dum enmeta testo por unika metriko de 400K.
VictoriaMetrics uzas ĉiujn disponeblajn vCPU-ojn, dum InfluxDB subuzas 2 el 16 vCPU-oj.
Tempskalo nur uzas 3-4 el la 16 vCPUoj. Altaj proporcioj de iowait kaj sistemo en la TimescaleDB temposkala grafeo indikas proplempunkton en la enigo/produktaĵo (I/O) subsistemo. Ni rigardu la grafikojn de uzado de diskoj de larĝa bando:
Supre estas ekrankopio: VictoriaMetrics - Disk Bandwidth Usage in Insertion Test for Unique Metrics 400K.
Supre estas ekrankopio: InfluxDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.
Supre estas ekrankopio: TimescaleDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.
VictoriaMetrics registras datumojn je 20 Mbps kun pintoj ĝis 45 Mbps. Pintoj egalrilatas al grandaj partaj fuzioj en la arbo .
InfluxDB skribas datumojn je 160 MB/s, dum 1 TB stirado skriba trairo 120 MB/s.
TimescaleDB estas limigita por skribi trairon de 120 Mbps, sed foje ĝi rompas ĉi tiun limon kaj atingas 220 Mbps en maksimumaj valoroj. Tiuj pintoj egalrilatas al la valoj de nesufiĉa CPU-utiligo en la antaŭa grafeo.
Ni rigardu la uzadografikojn de enigo/eligo (I/O):
Supre estas ekrankopio: VictoriaMetrics - Enmetu testan I/O-uzon por 400K unikaj metrikoj.
Supre estas ekrankopio: InfluxDB - Enmetu testan I/O-uzon por 400K unikaj metrikoj.
Supre estas ekrankopio: TimescaleDB - Enmetu testan I/O-uzon por 400K unikaj metrikoj.
Nun estas klare, ke TimescaleDB atingas sian I/O-limon, do ĝi ne povas uzi la ceterajn 12 vCPUojn.
4M unika temposerio
4M temposerio aspektas iom malfacila. Sed niaj konkurantoj sukcese trapasas ĉi tiun ekzamenon. Konferencaj rezultoj:
- VictoriaMetrics: 2,2M datumpunktoj sekundo; RAM-uzado: 6 GB; fina datuma grandeco sur disko: 3 GB.
- InfluxDB: 330K datumpunktoj por sekundo; RAM-uzado: 20,5 GB; fina datuma grandeco sur disko: 18,4 GB.
- TimescaleDB: 480K datumpunktoj por sekundo; RAM-uzo: 2,5 GB; fina datuma grandeco sur disko: 52 GB.
InfluxDB-efikeco falis de 1,2M datumpunktoj sekundo por 400K temposerio al 330K datumpunktoj sekundo por 4M temposerio. Ĉi tio estas grava rendimento perdo kompare kun aliaj konkurantoj. Ni rigardu la CPU-uzografeojn por kompreni la radikan kaŭzon de ĉi tiu perdo:
Supre estas ekrankopio: VictoriaMetrics - CPU-uzado dum enmeta testo por unika 4M temposerio.
Supre estas ekrankopio: InfluxDB - CPU-uzado dum enmeta testo por unikaj 4M temposerio.
Supre estas ekrankopio: TimescaleDB - CPU-uzado dum enmeta testo por unika 4M temposerio.
VictoriaMetrics uzas preskaŭ la tutan potencon de la procesunuo (CPU). La guto ĉe la fino respondas al la ceteraj LSM-kunfandaĵoj post kiam ĉiuj datumoj estis enmetitaj.
InfluxDB uzas nur 8 el 16 vCPUoj, dum TimsecaleDB uzas 4 el 16 vCPUoj. Kion havas iliaj grafikaĵoj komune? Alta kotizo iowait, kiu denove indikas I/O proplempunkton.
TimescaleDB havas altan parton system. Ni supozas, ke alta potenco rezultigis multajn sistemvokojn aŭ multajn .
Ni rigardu la diskajn trafluajn grafikojn:
Supre estas ekrankopio: VictoriaMetrics - Uzado de disko-larĝo por enmeti 4M unikajn metrikojn.
Supre estas ekrankopio: InfluxDB - Uzanta diskon bendolarĝon por enmeti 4M unikajn metrikojn.
Supre estas ekrankopio: TimescaleDB - Uzanta diskon bendolarĝon por enmeti 4M unikajn metrikojn.
VictoriaMetrics atingis limon de 120 MB/s ĉe pinto, dum la meza skribrapideco estis 40 MB/s. Estas verŝajne ke pluraj pezaj LSM-fuzioj estis faritaj dum la pinto.
InfluxDB denove elpremas mezan skriban trairon de 200 MB/s kun pintoj de ĝis 340 MB/s sur disko kun skriblimo de 120 MB/s :)
TimescaleDB ne plu estas disko limigita. Ĝi ŝajnas esti limigita de io alia rilata al alta proporcio системной CPU-ŝarĝo.
Ni rigardu la IO-uzografeojn:
Supre estas ekrankopio: VictoriaMetrics - Uzado de I/O dum enmeta testo por unika 4M temposerio.
Supre estas ekrankopio: InfluxDB - Uzado de I/O dum enmeta testo por unika 4M temposerio.
Supre estas ekrankopio: TimescaleDB - I/O-uzo dum enmeta testo por unikaj 4M temposerio.
IO-uzadopadronoj spegulas tiujn de disko-bendolarĝo - InfluxDB estas IO limigita, dum VictoriaMetrics kaj TimescaleDB havas rezervajn IO-resursojn.
40M unika temposerio
40M unika temposerio estis tro granda por InfluxDB :)
Konferencaj rezultoj:
- VictoriaMetrics: 1,7M datumpunktoj sekundo; RAM-uzo: 29 GB; Uzo de diskospaco: 17 GB.
- InfluxDB: Ne finiĝis ĉar ĝi postulis pli ol 60GB da RAM.
- TimecaleDB: 330K datumpunktoj sekundo, RAM-uzado: 2,5 GB; Uzo de diskospaco: 84GB.
TimescaleDB montras escepte malaltan kaj stabilan RAM-uzon ĉe 2,5 GB - la sama kiel por la unikaj 4M kaj 400K-metrikoj.
VictoriaMetrics malrapide kreskis kun rapideco de 100k datumpunktoj sekundo ĝis ĉiuj 40M etikeditaj metrikaj nomoj estis prilaboritaj. Li tiam atingis daŭran enmeton de 1,5-2,0M datumpunktoj je sekundo, do la fina rezulto estis 1,7M datumpunktoj sekundo.
La grafikaĵoj por 40M unika temposerio estas similaj al la grafikaĵoj por 4M unika temposerio, do ni preterlasu ilin.
trovoj
- Modernaj TSDBoj kapablas prilabori enigaĵojn por milionoj da unikaj temposerio sur ununura servilo. En la sekva artikolo, ni testos kiom bone TSDB-oj plenumas elekton tra milionoj da unikaj temposerio.
- Nesufiĉa CPU-uzado kutime indikas I/O proplempunkton. Ĝi ankaŭ povas indiki, ke la blokado estas tro kruda, kun nur kelkaj fadenoj kapablaj kuri samtempe.
- La I/O proplemkolo ja ekzistas, precipe en ne-SSD-stokado kiel ekzemple la virtualigitaj blokaj aparatoj de nubaj provizantoj.
- VictoriaMetrics provizas la plej bonan optimumigon por malrapida, malalta I/O-stokado. Ĝi provizas la plej bonan rapidon kaj la plej bonan kunpremadon.
Elŝutu kaj provu ĝin sur viaj datumoj. La responda statika binaro estas havebla ĉe .
Legu pli pri VictoriaMetrics en ĉi tio .
Ĝisdatigo: publikigita kun reprodukteblaj rezultoj.
Ĝisdatigo #2: Legu ankaŭ .
Ĝisdatigo #3: !
Telegram-babilejo:
fonto: www.habr.com