VictoriaMetrics, TimescaleDB і InfluxDB былі параўнаныя ў па наборы дадзеных з мільярдам кропак дадзеных, якія належаць 40K унікальным часовым шэрагам.
Некалькі гадоў таму была эпоха Zabbix. Кожны bare metal сервер меў не больш за некалькі паказчыкаў – выкарыстанне працэсара, выкарыстанне аператыўнай памяці, выкарыстанне дыска і выкарыстанне сеткі. Такім чынам метрыкі з тысяч сервераў могуць змясціцца ў 40 тысяч унікальных часовых шэрагаў, а Zabbix можа выкарыстоўваць MySQL у якасці бэкенда для дадзеных часовых шэрагаў 🙂
У цяперашні час адзін з канфігурацыямі па змаўчанні падае больш за 500 метрык на сярэднім хасце. Існуе мноства для розных баз дадзеных, вэб-сервераў, апаратных сістэм і т. д. Усе яны падаюць мноства карысных паказчыкаў. Усё пачынаюць выстаўляць розныя паказчыкі на сябе. Існуе Kubernetes з кластарамі і pod-амі, якія расчыняюць мноства метрык. Гэта прыводзіць да таго, што серверы выстаўляюць тысячы ўнікальных метрык на хост. Такім чынам, унікальны часавы шэраг 40K больш не з'яўляецца высокай магутнасцю. Ён становіцца мэйнстрымам, які павінен быць лёгка апрацаваны любой сучаснай TSDB на адным серверы.
Што такое вялікая колькасць унікальных часовых шэрагаў на дадзены момант? Мусіць, 400К або 4М? Ці 40м? Давайце параўнаем сучасныя TSDBs з гэтымі лічбамі.
Ўстаноўка бенчмарку
- гэта выдатны інструмент бенчмаркетынгу для TSDBs. Ён дазваляе генераваць адвольную колькасць метрык, перадаючы неабходную колькасць часавых шэрагаў, падзеленых на 10 - сцяг. (былы -scale-var). 10 – гэта колькасць вымярэнняў (метрык), якія генерыруюцца на кожным хасце, серверы. Наступныя наборы дадзеных былі створаны з дапамогай TSBS для бенчмарку:
- 400K унікальны часавы шэраг, 60 секунд інтэрвал паміж кропкамі дадзеных, дадзеныя ахопліваюць поўныя 3 дні, ~1.7B агульная колькасць кропак дадзеных.
- 4M унікальны часавы шэраг, інтэрвал 600 секунд, дадзеныя ахопліваюць поўныя 3 дні, ~1.7B агульная колькасць кропак дадзеных.
- 40M унікальны часавы шэраг, інтэрвал 1 гадзіну, дадзеныя ахопліваюць поўныя 3 дні, ~2.8 B агульная колькасць кропак дадзеных.
Кліент і сервер былі запушчаны на выдзеленых экзэмплярах у воблаку Google. Гэтыя асобнікі мелі наступныя канфігурацыі:
- vCPUs: 16
- АЗП: 60 ГБ
- Захоўванне: стандартны жорсткі дыск ёмістасцю 1 ТБ. Ён забяспечвае прапускную здольнасць чытання/запісы 120 Мбіт/з, 750 аперацый чытання ў секунду і 1,5К аперацый запісу ў секунду.
TSDBs былі вынятыя з афіцыйных вобразаў docker і запушчаны ў docker з наступнымі канфігурацыямі:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
Значэнні InfluxDB (- e неабходны для падтрымкі высокай магутнасці. Падрабязнасці глядзіце ў ):
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 (канфігурацыя была прынята з файла):
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=100Загрузнік дадзеных быў запушчаны з 16 раўналежнымі струменямі.
Гэты артыкул змяшчае толькі вынікі для кантрольных паказчыкаў устаўкі. Вынікі выбарачнага бенчмарку будуць апублікаваны ў асобным артыкуле.
400К унікальных часовых шэрагаў
Давайце пачнем з простых элементаў - 400К. Вынікі бенчмарку:
- VictoriaMetrics: 2,6 М кропак дадзеных у секунду; выкарыстанне аператыўнай памяці: 3 ГБ; канчатковы памер дадзеных на дыску: 965 МБ
- InfluxDB: 1.2M кропак дадзеных у секунду; выкарыстанне аператыўнай памяці: 8.5/1.6 GB; канчатковы памер дадзеных на дыску: XNUMX GB
- Timescale: 849K кропак дадзеных у секунду; выкарыстанне аператыўнай памяці: 2,5 ГБ; канчатковы памер дадзеных на дыску: 50 ГБ
Як вы можаце бачыць з прыведзеных вышэй вынікаў, VictoriaMetrics выйграе ў прадукцыйнасці ўстаўкі і ступені сціску. Часавая шкала выйграе ў выкарыстанні аператыўнай памяці, але яна выкарыстоўвае шмат дыскавай прасторы - 29 байт на кропку дадзеных.
Ніжэй прыведзены графікі выкарыстання працэсара (CPU) для кожнага з TSDBs падчас бенчмарку:
Вышэй скрыншот: VictoriaMetrics - Загрузка CPU пры тэсце ўстаўкі для ўнікальнай метрыкі 400K.
Вышэй скрыншот: InfluxDB - Загрузка CPU пры тэсце ўстаўкі для ўнікальнай метрыкі 400K.
Вышэй скрыншот: TimescaleDB - Загрузка CPU пры тэсце ўстаўкі для унікальнай метрыкі 400K.
VictoriaMetrics выкарыстоўвае ўсе даступныя vCPUs, у той час як InfluxDB недастаткова выкарыстоўвае ~2 з 16 vCPUs.
Timescale выкарыстоўвае толькі 3-4 з 16 vCPUs. Высокія долі iowait і system на TimescaleDB графіцы часовых маштабаў паказваюць на вузкае месца ў падсістэме ўводу-вываду (I/O). Давайце паглядзім на графікі выкарыстання прапускной здольнасці дыска:
Вышэйшы скрыншот: VictoriaMetrics - Выкарыстанне прапускной здольнасці дыска пры тэсце ўстаўкі для унікальных паказчыкаў 400K.
Вышэй скрыншот: InfluxDB - Выкарыстанне прапускной здольнасці дыска пры тэсце ўстаўкі для унікальных паказчыкаў 400K.
Вышэйшы скрыншот: TimescaleDB - Выкарыстанне прапускной здольнасці дыска пры тэсце ўстаўкі для унікальных паказчыкаў 400K.
VictoriaMetrics запісвае дадзеныя са хуткасцю 20 Мбіт/з з пікамі да 45 Мбіт/з. Пікі адпавядаюць вялікім частковым зліццям у дрэве .
InfluxDB запісвае дадзеныя са хуткасцю 160 МБ / с, у той час як 1 ТБ дыск прапускной здольнасцю запісу 120 МБ/С.
TimescaleDB абмежаваная прапускной здольнасцю запісу 120 Мбіт/з, але часам яна парушае гэтую мяжу і дасягае 220 Мбіт/з у пікавых значэннях. Гэтыя пікі адпавядаюць правалам недастатковай загрузкі працэсара на папярэднім графіку.
Давайце паглядзім на графікі выкарыстання ўводу-вываду (I/O):
Вышэйшы скрыншот: VictoriaMetrics - Выкарыстанне ўводу-вываду пры тэсце ўстаўкі для 400K унікальных метрык.
Вышэй скрыншот: InfluxDB - Выкарыстанне ўводу-вываду пры тэсце ўстаўкі для 400K унікальных метрык.
Вышэй скрыншот: TimescaleDB - Выкарыстанне ўводу-вываду пры тэсце ўстаўкі для 400K унікальных метрык.
Цяпер ясна, што TimescaleDB дасягае мяжы ўводу-вываду, таму ён не можа выкарыстоўваць пакінутыя 12 vCPUs.
4M унікальныя часовыя шэрагі
4M часовыя шэрагі выглядаюць крыху абуральна. Але нашы канкурэнты паспяхова здаюць гэты іспыт. Вынікі бенчмарку:
- VictoriaMetrics: 2,2М кропак дадзеных у секунду; выкарыстанне аператыўнай памяці: 6 ГБ; канчатковы памер дадзеных на дыску: 3 ГБ.
- InfluxDB: 330К кропак дадзеных у секунду; выкарыстанне аператыўнай памяці: 20,5 ГБ; канчатковы памер дадзеных на дыску: 18,4 ГБ.
- TimescaleDB: 480K кропак дадзеных у секунду; выкарыстанне аператыўнай памяці: 2,5 ГБ; канчатковы памер дадзеных на дыску: 52 ГБ.
Прадукцыйнасць InfluxDB звалілася з 1,2 млн кропак дадзеных у секунду для 400К часавага шэрагу да 330 тыс. кропак дадзеных у секунду для 4M часавага шэрагу. Гэта значная страта прадукцыйнасці ў параўнанні з іншымі канкурэнтамі. Давайце паглядзім на графікі выкарыстання працэсара, каб зразумець першапрычыну гэтай страты:
Вышэй скрыншот: VictoriaMetrics - Выкарыстанне CPU пры тэсце ўстаўкі для унікальнага часовага шэрагу 4M.
Вышэй скрыншот: InfluxDB - Выкарыстанне CPU пры тэсце ўстаўкі для унікальнага часовага шэрагу 4M.
Вышэй скрыншот: TimescaleDB - Выкарыстанне CPU пры тэсце ўстаўкі для унікальнага часовага шэрагу 4M.
VictoriaMetrics выкарыстоўвае амаль усю магутнасць працэсара (CPU). Зніжэнне ў канцы адпавядае пакінутым LSM зліццям пасля ўстаўкі ўсіх дадзеных.
InfluxDB выкарыстоўвае толькі 8 з 16 vCPUs, у той час як TimsecaleDB выкарыстоўвае 4 з 16 vCPUs. Што агульнае ў іх графікаў? Высокая доля iowait, Што, зноў жа, паказвае на вузкае месца ўводу-вываду.
TimescaleDB мае высокую долю system. Мяркуем, што высокая магутнасць прывяла да шматлікіх сістэмных выклікаў ці да шматлікіх .
Давайце паглядзім на графікі прапускной здольнасці дыска:
Вышэйшы скрыншот: VictoriaMetrics - Выкарыстанне паласы прапускання дыска для ўстаўкі 4M унікальных метрык.
Вышэй скрыншот: InfluxDB - Выкарыстанне паласы прапускання дыска для ўстаўкі 4M унікальных метрык.
Вышэй скрыншот: TimescaleDB - Выкарыстанне паласы прапускання дыска для ўстаўкі 4M унікальных метрык.
VictoriaMetrics дасягалі мяжы 120 МБ/С у пік, у той час як сярэдняя хуткасць запісу складала 40 МБ/С. Верагодна, падчас піка было выканана некалькі цяжкіх зліццяў LSM.
InfluxDB зноў выціскае сярэднюю прапускную здольнасць запісу 200 МБ/С з пікамі да 340 МБ/С на дыску з абмежаваннем запісу 120 МБ/С 🙂
TimescaleDB больш не абмежавана дыскам. Падобна, што ён абмежаваны нечым яшчэ, звязаным з высокай доляй системной загрузкі CPU.
Давайце паглядзім на графікі выкарыстання IO:
Вышэйшы скрыншот: VictoriaMetrics — Выкарыстанне ўводу-высновы падчас тэсту ўстаўкі для ўнікальнага часавага шэрагу 4M.
Вышэй скрыншот: InfluxDB - Выкарыстанне ўводу-вываду падчас тэсту ўстаўкі для унікальнага часовага шэрагу 4M.
Вышэй скрыншот: TimescaleDB - Выкарыстанне ўводу-вываду падчас тэсту ўстаўкі для унікальнага часовага шэрагу 4M.
Графікі выкарыстання IO паўтараюць графікі выкарыстання паласы прапускання дыска – InfluxDB абмежаваны IO, у той час як VictoriaMetrics і TimescaleDB маюць запасныя рэсурсы ўводу-вываду IO.
40М унікальныя тайм серыі
40М унікальныя часовыя шэрагі былі занадта вялікімі для InfluxDB 🙁
Вынікі бечмарку:
- VictoriaMetrics: 1,7 М кропак дадзеных у секунду; выкарыстанне аператыўнай памяці: 29 ГБ; выкарыстанне дыскавай прасторы: 17 ГБ.
- InfluxDB: не скончыў, таму што для гэтага патрабавалася больш за 60 ГБ аператыўнай памяці.
- TimescaleDB: 330К кропак дадзеных у секунду, выкарыстанне аператыўнай памяці: 2,5 ГБ; выкарыстанне дыскавай прасторы: 84GB.
TimescaleDB паказвае выключна нізкае і стабільнае выкарыстанне аператыўнай памяці – 2,5 ГБ – столькі ж, колькі і для ўнікальных метрык 4M і 400K.
VictoriaMetrics павольна павялічваліся з хуткасцю 100 тысяч кропак дадзеных у секунду, пакуль не былі апрацаваны ўсе 40М метрычных імёнаў з пазнакамі. Затым ён дасягнуў устойлівай хуткасці ўстаўкі 1,5-2,0м кропак дадзеных у секунду, так што канчатковы вынік склаў 1,7м кропак дадзеных у секунду.
Графікі для 40М унікальных часовых шэрагаў аналагічныя графікам для 4М унікальных часовых шэрагаў, таму давайце іх прапусцім.
Высновы
- Сучасныя TSDBs здольныя апрацоўваць устаўкі для мільёнаў унікальных часовых шэрагаў на адным серверы. У наступным артыкуле мы праверым, наколькі добра TSDBs выконвае выбар па мільёнах унікальных часовых шэрагаў.
- Недастатковая загрузка працэсара звычайна паказвае на вузкае месца ўводу-высновы. Акрамя таго, гэта можа паказваць на занадта грубіянскую блакіроўку, калі адначасова можа працаваць толькі некалькі струменяў.
- Вузкае месца ўводу-вываду сапраўды існуе, асабліва ў сховішчах без SSD, такіх як віртуалізаваныя блокавыя прылады хмарных правайдэраў.
- VictoriaMetrics забяспечвае найлепшую аптымізацыю для павольных сховішчаў з нізкім узроўнем уводу-высновы. Ён забяспечвае найлепшую хуткасць і найлепшую ступень сціску.
загрузіце і паспрабуйце яго на сваіх дадзеных. Адпаведны статычны двайковы файл даступны на .
Больш падрабязна пра VictoriaMetrics чытайце ў гэтай .
Абнаўленне: апублікавана з прайграваемымі вынікамі.
Абнаўленне#2: Чытайце таксама .
Абнаўленне #3: !
Тэлеграм чат:
Крыніца: habr.com