VictoriaMetrics, TimescaleDB en InfluxDB waarden fergelike yn op in dataset mei in miljard gegevenspunten dy't hearre ta 40K unike tiidsearjes.
In pear jier lyn wie der in tiidrek fan Zabbix. Elke bleate metalen tsjinner hie net mear as in pear yndikatoaren - CPU-gebrûk, RAM-gebrûk, skiifgebrûk en netwurkgebrûk. Op dizze manier kinne metriken fan tûzenen servers passe yn 40 tûzen unike tiidsearjes, en Zabbix kin MySQL brûke as in backend foar tiidsearjegegevens :)
Op it stuit allinnich mei standertkonfiguraasjes leveret mear dan 500 metriken op 'e gemiddelde host. Der binne in soad foar ferskate databases, web servers, hardware systemen, ensfh Se jouwe allegear in ferskaat oan brûkbere metriken. Alle begjinne ferskate yndikatoaren foar harsels yn te stellen. D'r binne Kubernetes mei klusters en pods dy't in protte metriken bleatstelle. Dit resultearret yn servers dy't tûzenen unike metriken per host bleatstelle. Dat de unike 40K-tiidrige is net langer heech krêft. It wurdt mainstream en moat maklik wurde behannele troch elke moderne TSDB op ien server.
Wat is it grutte oantal unike tiidrige op it stuit? Wierskynlik 400K of 4M? Of 40m? Litte wy moderne TSDB's fergelykje mei dizze nûmers.
It ynstallearjen fan in benchmark
is in poerbêst benchmarking-ark foar TSDB's. It lit jo in willekeurich oantal metriken generearje troch it fereaske oantal tiidsearjes dield troch 10 troch te jaan - flagge (earder -scale-var). 10 is it oantal mjittingen (metriken) generearre op elke host of server. De folgjende datasets waarden generearre mei TSBS foar de benchmark:
- 400K unike tiidsearje, 60 sekonden ynterval tusken gegevenspunten, gegevens oerspant in folsleine 3 dagen, ~1.7B totaal oantal gegevenspunten.
- 4M unike tiidsearje, ynterval fan 600 sekonden, gegevens oerspant 3 folsleine dagen, ~1.7B totaal oantal gegevenspunten.
- 40M unike tiidsearje, 1 oere ynterval, gegevens oerspant in folsleine 3 dagen, ~2.8B totaal oantal gegevenspunten.
De client en tsjinner rinne op tawijde eksimplaren yn Google Cloud. Dizze eksimplaren hiene de folgjende konfiguraasjes:
- vCPU's: 16
- RAM: 60 GB
- Opslach: Standert 1TB HDD. It soarget foar 120 Mbps lêzen / skriuw trochput, 750 lêsoperaasjes per sekonde en 1,5K skriuwt per sekonde.
TSDB's waarden ekstrahearre út offisjele dockerôfbyldings en útfierd yn docker mei de folgjende konfiguraasjes:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
InfluxDB (-e) wearden binne fereaske om hege macht te stypjen. Sjoch details yn ):
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 (konfiguraasje nommen út map):
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=100De gegevenslader waard útfierd mei 16 parallelle triedden.
Dit artikel befettet allinich resultaten foar ynfoegje benchmarks. De resultaten fan 'e selektive benchmark sille wurde publisearre yn in apart artikel.
400K unike tiid rige
Litte wy begjinne mei ienfâldige eleminten - 400K. Benchmark resultaten:
- VictoriaMetrics: 2,6M gegevenspunten per sekonde; RAM gebrûk: 3 GB; finale gegevens grutte op skiif: 965 MB
- InfluxDB: 1.2M gegevenspunten per sekonde; RAM gebrûk: 8.5 GB; finale gegevens grutte op skiif: 1.6 GB
- Tiidskaal: 849K gegevenspunten per sekonde; RAM gebrûk: 2,5 GB; finale gegevens grutte op skiif: 50 GB
Sa't jo sjen kinne út de resultaten hjirboppe, VictoriaMetrics wint yn ynstekken prestaasjes en kompresje ratio. Timeline wint yn RAM gebrûk, mar it brûkt in soad skiif romte - 29 bytes per gegevens punt.
Hjirûnder binne de CPU-gebrûkgrafiken foar elk fan 'e TSDB's tidens de benchmark:
Hjirboppe is in skermôfbylding: VictoriaMetrics - CPU-lading tidens ynfoegje test foar in unike 400K metrysk.
Hjirboppe is in skermôfbylding: InfluxDB - CPU-lading tidens ynfoegje test foar unike metryske 400K.
Hjirboppe is in skermôfbylding: TimescaleDB - CPU-lading tidens ynfoegje test foar in unike metrysk fan 400K.
VictoriaMetrics brûkt alle beskikbere vCPU's, wylst InfluxDB ~ 2 fan 16 vCPU's te min brûkt.
Tiidskaal brûkt allinich 3-4 fan 'e 16 vCPU's. Hege proporsjes fan iowait en systeem yn 'e TimescaleDB-tiidskaalgrafyk jouwe in knelpunt oan yn it subsysteem ynput / útfier (I/O). Litte wy nei de skiifbânbreedtegebrûkgrafiken sjen:
Hjirboppe is in skermôfbylding: VictoriaMetrics - Disk Bandwidth Usage in Insertion Test for Unique Metrics 400K.
Hjirboppe is in skermôfbylding: InfluxDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.
Hjirboppe is in skermôfbylding: TimescaleDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.
VictoriaMetrics registrearret gegevens op 20 Mbps mei peaks oant 45 Mbps. Peaks oerienkomme mei grutte parsjele fúzjes yn 'e beam .
InfluxDB skriuwt gegevens op 160 MB / s, wylst in 1 TB drive skriuwe trochstreaming 120 MB / s.
TimescaleDB is beheind ta skriuw trochfier fan 120 Mbps, mar soms brekt it dizze limyt en berikt 220 Mbps yn pykwearden. Dizze peaks oerienkomme mei de dellingen fan ûnfoldwaande CPU-gebrûk yn 'e foarige grafyk.
Litte wy nei de ynput/útfier (I/O) gebrûksgrafiken sjen:
Hjirboppe is in skermôfbylding: VictoriaMetrics - Ynfoegje test I/O-gebrûk foar 400K unike metriken.
Hjirboppe is in skermôfbylding: InfluxDB - Ynfoegje test I/O-gebrûk foar 400K unike metriken.
Hjirboppe is in skermôfbylding: TimescaleDB - Test I/O-gebrûk ynfoegje foar 400K unike metriken.
It is no dúdlik dat TimescaleDB syn I / O-limyt berikt, sadat it de oerbleaune 12 vCPU's net kin brûke.
4M unike tiid rige
4M tiidrige sjogge in bytsje útdaagjend. Mar ús konkurrinten passe dit eksamen mei súkses. Benchmark resultaten:
- VictoriaMetrics: 2,2M gegevenspunten per sekonde; RAM gebrûk: 6 GB; finale gegevens grutte op skiif: 3 GB.
- InfluxDB: 330K gegevenspunten per sekonde; RAM gebrûk: 20,5 GB; finale gegevens grutte op skiif: 18,4 GB.
- TiidskaalDB: 480K gegevenspunten per sekonde; RAM gebrûk: 2,5 GB; finale gegevens grutte op skiif: 52 GB.
InfluxDB-prestaasjes sakke fan 1,2M gegevenspunten per sekonde foar in 400K tiidsearje nei 330K gegevenspunten per sekonde foar in 4M tiidsearje. Dit is in signifikant prestaasjeferlies yn ferliking mei oare konkurrinten. Litte wy nei de CPU-gebrûkgrafiken sjen om de root-oarsaak fan dit ferlies te begripen:
Hjirboppe is in skermôfbylding: VictoriaMetrics - CPU-gebrûk by ynfoegje test foar in unike 4M tiidsearje.
Hjirboppe is in skermôfbylding: InfluxDB - CPU-gebrûk by ynfoegje test foar unike 4M tiidsearjes.
Hjirboppe is in skermôfbylding: TimescaleDB - CPU-gebrûk by ynfoegje test foar in unike 4M tiidsearje.
VictoriaMetrics brûkt hast alle macht fan 'e ferwurkingsienheid (CPU). De drop oan 'e ein komt oerien mei de oerbleaune LSM fusearret nei alle gegevens binne ynfoege.
InfluxDB brûkt mar 8 fan 16 vCPU's, wylst TimsecaleDB 4 fan 16 vCPU's brûkt. Wat hawwe har grafiken mienskiplik? Heech oandiel iowait, wat wer in I/O-knelhals oanjout.
TimescaleDB hat in heech oandiel system. Wy geane derfan út dat hege macht resultearre yn in protte systeem oproppen of in protte .
Litte wy nei de skiif-trochputgrafiken sjen:
Hjirboppe is in skermôfbylding: VictoriaMetrics - Skiifbânbreedte brûke om 4M unike metriken yn te foegjen.
Hjirboppe is in skermôfbylding: InfluxDB - Skiifbânbreedte brûke om 4M unike metriken yn te foegjen.
Hjirboppe is in skermôfbylding: TimescaleDB - Skiifbânbreedte brûke om 4M unike metriken yn te foegjen.
VictoriaMetrics berikte in limyt fan 120 MB / s op peak, wylst de gemiddelde skriuwsnelheid 40 MB / s wie. It is wierskynlik dat ferskate swiere LSM-fúzjes waarden útfierd tidens de peak.
InfluxDB drukt wer in gemiddelde skriuwsnelheid fan 200 MB/s mei peaks fan oant 340 MB/s op in skiif mei in skriuwlimyt fan 120 MB/s :)
TimescaleDB is net langer skyf beheind. It liket te wêzen beheind troch wat oars yn ferbân mei hege oanpart системной CPU load.
Litte wy nei de IO-gebrûkgrafiken sjen:
Hjirboppe is in skermôfbylding: VictoriaMetrics - I/O brûke by ynfoegje test foar in unike 4M tiidsearje.
Hjirboppe is in skermôfbylding: InfluxDB - I/O brûke by ynfoegjetest foar in unike 4M tiidsearje.
Hjirboppe is in skermôfbylding: TimescaleDB - I/O-gebrûk by ynfoegje test foar unike 4M tiidsearjes.
IO-gebrûkspatroanen spegelje dy fan skiifbânbreedte - InfluxDB is IO beheind, wylst VictoriaMetrics en TimescaleDB ekstra IO-boarnen hawwe.
40M unike tiid rige
40M unike tiidsearje wie te grut foar InfluxDB :)
Benchmark resultaten:
- VictoriaMetrics: 1,7M gegevenspunten per sekonde; RAM gebrûk: 29 GB; Skiif romte gebrûk: 17 GB.
- InfluxDB: Is net klear, om't it mear dan 60 GB RAM fereaske.
- TimescaleDB: 330K gegevenspunten per sekonde, RAM-gebrûk: 2,5 GB; Skiifromtegebrûk: 84GB.
TimescaleDB toant útsûnderlik leech en stabyl RAM-gebrûk op 2,5 GB - itselde as foar de unike 4M en 400K metriken.
VictoriaMetrics skaalde stadichoan op mei in taryf fan 100k gegevenspunten per sekonde oant alle 40M tagged metryske nammen waarden ferwurke. Hy berikte doe in oanhâldende ynfoegingsrate fan 1,5-2,0M gegevenspunten per sekonde, sadat it einresultaat 1,7M gegevenspunten per sekonde wie.
De grafiken foar 40M unike tiidsearjes binne fergelykber mei de grafiken foar 4M unike tiidsearjes, dus litte wy se oerslaan.
befinings
- Moderne TSDB's binne yn steat om ynserts te ferwurkjen foar miljoenen unike tiidsearjes op ien tsjinner. Yn it folgjende artikel sille wy testen hoe goed TSDB's seleksje útfiere oer miljoenen unike tiidsearjes.
- Net genôch CPU-gebrûk jout normaal in I/O-knelhals oan. It kin ek oanjaan dat it blokkearjen te grof is, mei mar in pear triedden dy't tagelyk rinne kinne.
- De I/O-knelhals bestiet wol, fral yn net-SSD-opslach, lykas virtualisearre blokapparaten fan wolkproviders.
- VictoriaMetrics leveret de bêste optimalisaasje foar trage, lege I / O-opslach. It leveret de bêste snelheid en de bêste kompresjeferhâlding.
Download en besykje it op jo gegevens. De oerienkommende statyske binêre is beskikber by .
Lês mear oer VictoriaMetrics yn dizze .
Update: publisearre mei reprodusearjende resultaten.
Update #2: Lês ek .
Update #3: !
Telegram petear:
Boarne: www.habr.com