მაღალი ხარისხის TSDB ბენჩმარკი VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB და InfluxDB შეადარეს წინა სტატია მონაცემთა ბაზაზე მილიარდი მონაცემთა წერტილით, რომლებიც ეკუთვნის 40K უნიკალურ დროის სერიას.

რამდენიმე წლის წინ იყო Zabbix-ის ეპოქა. თითოეულ შიშველი მეტალის სერვერს ჰქონდა არაუმეტეს რამდენიმე ინდიკატორი - CPU-ს გამოყენება, RAM-ის გამოყენება, დისკის გამოყენება და ქსელის გამოყენება. ამ გზით, ათასობით სერვერის მეტრიკა შეიძლება მოერგოს 40 ათას უნიკალურ დროის სერიას, ხოლო Zabbix-ს შეუძლია გამოიყენოს MySQL, როგორც დროის სერიების მონაცემების სარეზერვო საშუალება :)

ამჟამად მარტო კვანძი_ექსპორტიორი ნაგულისხმევი კონფიგურაციებით უზრუნველყოფს 500-ზე მეტ მეტრიკას საშუალო ჰოსტზე. Ბევრნი არიან ექსპორტიორები სხვადასხვა მონაცემთა ბაზებისთვის, ვებ სერვერებისთვის, ტექნიკის სისტემებისთვის და ა.შ. ყველა მათგანი უზრუნველყოფს სხვადასხვა სასარგებლო მეტრიკას. ყველა უფრო და უფრო მეტი აპლიკაცია იწყებენ საკუთარი თავისთვის სხვადასხვა ინდიკატორების დაყენებას. არის კუბერნეტები კლასტერებითა და პოდებით, რომლებიც ავლენს ბევრ მეტრიკას. ეს იწვევს სერვერებს ათასობით უნიკალური მეტრიკის გამოვლენას თითო ჰოსტზე. ასე რომ, უნიკალური 40K დროის სერია აღარ არის მაღალი სიმძლავრე. ის ხდება ძირითადი და ადვილად უნდა მართოს ნებისმიერი თანამედროვე TSDB ერთ სერვერზე.

რა არის ამ დროისთვის უნიკალური დროის სერიების დიდი რაოდენობა? ალბათ 400K თუ 4M? თუ 40 მ? მოდით შევადაროთ თანამედროვე TSDB ამ ციფრებს.

საორიენტაციო ნიშნის დაყენება

TSBS არის შესანიშნავი ბენჩმარკინგის ინსტრუმენტი TSDB-ებისთვის. ის საშუალებას გაძლევთ შექმნათ მეტრიკის თვითნებური რაოდენობა 10-ზე გაყოფილი დროის სერიების საჭირო რაოდენობის გავლის გზით. - მასშტაბი (ყოფილი -scale-var). 10 არის გაზომვების (მეტრიკის) რაოდენობა, რომლებიც გენერირებულია თითოეულ ჰოსტზე ან სერვერზე. შემდეგი მონაცემთა ნაკრები შეიქმნა TSBS-ის გამოყენებით საორიენტაციო ნიშნისთვის:

• 400K უნიკალური დროის სერიები, 60 წამი ინტერვალი მონაცემთა წერტილებს შორის, მონაცემები მოიცავს სრულ 3 დღეს, მონაცემთა რაოდენობა ~1.7 მილიარდი.
• 4M უნიკალური დროის სერიები, 600 წამის ინტერვალი, მონაცემები მოიცავს 3 სრულ დღეს, ~1.7 მილიარდი მონაცემთა საერთო რაოდენობა.
• 40M უნიკალური დროის სერია, 1 საათის ინტერვალი, მონაცემები მოიცავს 3 სრულ დღეს, ~2.8B მონაცემთა საერთო რაოდენობა.

კლიენტი და სერვერი მუშაობდა სპეციალურ ინსტანციებზე n1-სტანდარტი-16 Google ღრუბელში. ამ შემთხვევებს ჰქონდათ შემდეგი კონფიგურაციები:

• vCPU: 16
• ოპერატიული მეხსიერება: 60 GB
• მეხსიერება: სტანდარტული 1TB HDD. ის უზრუნველყოფს 120 Mbps წაკითხვის/ჩაწერის გამტარუნარიანობას, 750 წაკითხვის ოპერაციას წამში და 1,5K ჩაწერას წამში.

TSDB-ები ამოღებულია ოფიციალური დოკერის სურათებიდან და მუშაობს დოკერში შემდეგი კონფიგურაციებით:

• 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 პარალელური ძაფით.

ეს სტატია შეიცავს მხოლოდ შედეგებს ჩასმის ეტალონებისთვის. შერჩევითი ბენჩმარკის შედეგები გამოქვეყნდება ცალკე სტატიაში.

400K უნიკალური დროის სერია

დავიწყოთ მარტივი ელემენტებით - 400K. საორიენტაციო შედეგები:

• VictoriaMetrics: 2,6M მონაცემთა წერტილი წამში; ოპერატიული მეხსიერების მოხმარება: 3 GB; საბოლოო მონაცემების ზომა დისკზე: 965 მბ
• InfluxDB: 1.2M მონაცემთა წერტილი წამში; ოპერატიული მეხსიერების მოხმარება: 8.5 GB; საბოლოო მონაცემების ზომა დისკზე: 1.6 GB
• დროის მასშტაბი: 849K მონაცემთა რაოდენობა წამში; ოპერატიული მეხსიერების მოხმარება: 2,5 GB; საბოლოო მონაცემების ზომა დისკზე: 50 GB

როგორც ზემოთ მოყვანილი შედეგებიდან ხედავთ, VictoriaMetrics იგებს ჩასმის შესრულებასა და შეკუმშვის კოეფიციენტში. Timeline იმარჯვებს RAM-ის გამოყენებაში, მაგრამ ის იყენებს დიდ ადგილს დისკზე - 29 ბაიტი მონაცემთა წერტილზე.

ქვემოთ მოცემულია CPU-ს გამოყენების გრაფიკები თითოეული TSDB-სთვის ბენჩმარკის დროს:

ზემოთ არის სკრინშოტი: VictoriaMetrics - CPU დატვირთვა ჩასმის ტესტის დროს უნიკალური 400K მეტრიკისთვის.

ზემოთ არის სკრინშოტი: InfluxDB - CPU დატვირთვა ჩასმის ტესტის დროს უნიკალური მეტრიკული 400K.

ზემოთ არის სკრინშოტი: TimescaleDB - CPU დატვირთვა ჩასმის ტესტის დროს უნიკალური მეტრიკის 400K.

VictoriaMetrics იყენებს ყველა არსებულ vCPU-ს, ხოლო InfluxDB არასაკმარისად იყენებს 2 vCPU-დან ~16-ს.

Timescale იყენებს 3 vCPU-დან მხოლოდ 4-16-ს. iowait-ისა და სისტემის მაღალი პროპორციები TimescaleDB დროის მასშტაბის გრაფიკში მიუთითებს შეყვანის/გამოსვლის (I/O) ქვესისტემის შეფერხებაზე. მოდით შევხედოთ დისკის გამტარუნარიანობის გამოყენების გრაფიკებს:

ზემოთ არის ეკრანის სურათი: VictoriaMetrics - დისკის გამტარუნარიანობის გამოყენება Insertion Test-ში Unique Metrics 400K-ისთვის.

ზემოთ არის სკრინშოტი: InfluxDB - დისკის გამტარუნარიანობის გამოყენება ჩასმის ტესტზე Unique Metrics 400K-ისთვის.

ზემოთ არის სკრინშოტი: TimescaleDB - დისკის გამტარუნარიანობის გამოყენება ჩასმის ტესტისთვის Unique Metrics 400K.

VictoriaMetrics იწერს მონაცემებს 20 Mbps სიჩქარით, პიკით 45 Mbps-მდე. მწვერვალები შეესაბამება ხეში დიდ ნაწილობრივ შერწყმას არასამთავრობო ორგანიზაცია.

InfluxDB წერს მონაცემებს 160 მბ/წმ სიჩქარით, ხოლო 1 ტბ დისკზე შეზღუდული უნდა იყოს ჩაწერის გამტარუნარიანობა 120 მბ/წმ.

TimescaleDB შემოიფარგლება ჩაწერის გამტარუნარიანობით 120 Mbps, მაგრამ ზოგჯერ ის არღვევს ამ ლიმიტს და აღწევს 220 Mbps პიკური მნიშვნელობებით. ეს მწვერვალები შეესაბამება წინა გრაფაში CPU-ს არასაკმარისი გამოყენების ველებს.

მოდით შევხედოთ შეყვანის/გამოსვლის (I/O) გამოყენების გრაფიკებს:

ზემოთ არის სკრინშოტი: VictoriaMetrics - ჩადეთ I/O ტესტის გამოყენება 400K უნიკალური მეტრიკისთვის.

ზემოთ არის სკრინშოტი: InfluxDB - ჩადეთ I/O ტესტის გამოყენება 400K უნიკალური მეტრიკისთვის.

ზემოთ არის სკრინშოტი: TimescaleDB - ჩასვით ტესტის I/O გამოყენება 400K უნიკალური მეტრიკისთვის.

ახლა ნათელია, რომ TimescaleDB აღწევს მის I/O ლიმიტს, ამიტომ მას არ შეუძლია გამოიყენოს დარჩენილი 12 vCPU.

4M უნიკალური დროის სერია

4M დროის სერიები ცოტა გამომწვევად გამოიყურება. მაგრამ ჩვენი კონკურენტები ამ გამოცდას წარმატებით აბარებენ. საორიენტაციო შედეგები:

• VictoriaMetrics: 2,2M მონაცემთა წერტილი წამში; ოპერატიული მეხსიერების მოხმარება: 6 GB; საბოლოო მონაცემების ზომა დისკზე: 3 GB.
• InfluxDB: 330K მონაცემთა წერტილი წამში; ოპერატიული მეხსიერების მოხმარება: 20,5 GB; საბოლოო მონაცემების ზომა დისკზე: 18,4 GB.
• TimescaleDB: 480K მონაცემთა წერტილი წამში; ოპერატიული მეხსიერების მოხმარება: 2,5 GB; საბოლოო მონაცემების ზომა დისკზე: 52 GB.

InfluxDB-ის შესრულება დაეცა 1,2M მონაცემთა წერტილიდან წამში 400K დროის სერიებისთვის 330K მონაცემთა წერტილამდე წამში 4M დროის სერიებისთვის. ეს არის მნიშვნელოვანი დანაკარგი სხვა კონკურენტებთან შედარებით. მოდით შევხედოთ CPU-ს გამოყენების გრაფიკებს, რომ გავიგოთ ამ დაკარგვის ძირითადი მიზეზი:

ზემოთ არის სკრინშოტი: VictoriaMetrics - CPU გამოყენება ჩასმის ტესტის დროს უნიკალური 4M დროის სერიებისთვის.

ზემოთ არის სკრინშოტი: InfluxDB - CPU გამოყენება ჩასმის ტესტის დროს უნიკალური 4M დროის სერიებისთვის.

ზემოთ არის სკრინშოტი: TimescaleDB - CPU გამოყენება ჩასმის ტესტის დროს უნიკალური 4M დროის სერიებისთვის.

VictoriaMetrics იყენებს თითქმის მთელ პროცესორულ ერთეულს (CPU). ბოლოს ვარდნა შეესაბამება დარჩენილ LSM შერწყმას ყველა მონაცემის ჩასმის შემდეგ.

InfluxDB იყენებს მხოლოდ 8-ს 16 vCPU-დან, ხოლო TimsecaleDB იყენებს 4-დან 16 vCPU-დან. რა საერთო აქვთ მათ გრაფიკებს? მაღალი წილი iowait, რაც ისევ მიუთითებს I/O ბოთლზე.

TimescaleDB-ს აქვს მაღალი წილი system. ჩვენ ვვარაუდობთ, რომ მაღალმა სიმძლავრემ გამოიწვია მრავალი სისტემური ზარი ან ბევრი გვერდის მცირე ხარვეზები.

მოდით შევხედოთ დისკის გამტარუნარიანობის გრაფიკებს:

ზემოთ არის ეკრანის სურათი: VictoriaMetrics - დისკის გამტარუნარიანობის გამოყენება 4M უნიკალური მეტრიკის ჩასართავად.

ზემოთ არის ეკრანის სურათი: InfluxDB - დისკის გამტარუნარიანობის გამოყენება 4M უნიკალური მეტრიკის ჩასართავად.

ზემოთ არის ეკრანის სურათი: TimescaleDB - დისკის გამტარუნარიანობის გამოყენება 4M უნიკალური მეტრიკის ჩასართავად.

VictoriaMetrics-მა მიაღწია ლიმიტს 120 მბ/წმ პიკზე, ხოლო ჩაწერის საშუალო სიჩქარე იყო 40 მბ/წმ. სავარაუდოა, რომ რამდენიმე მძიმე LSM შერწყმა შესრულდა პიკის დროს.

InfluxDB კვლავ ამცირებს ჩაწერის საშუალო გამტარუნარიანობას 200 მბ/წმ, პიკით 340 მბ/წმ-მდე დისკზე ჩაწერის ლიმიტით 120 მბ/წმ :)

TimescaleDB აღარ არის შეზღუდული დისკზე. როგორც ჩანს, ის შემოიფარგლება სხვა რამით, რომელიც დაკავშირებულია მაღალ პროპორციასთან системной CPU დატვირთვა.

მოდით შევხედოთ IO გამოყენების გრაფიკებს:

ზემოთ არის ეკრანის სურათი: VictoriaMetrics - I/O გამოყენება ჩასმის ტესტის დროს უნიკალური 4M დროის სერიებისთვის.

ზემოთ არის სკრინშოტი: InfluxDB - I/O გამოყენება ჩასმის ტესტის დროს უნიკალური 4M დროის სერიებისთვის.

ზემოთ არის ეკრანის სურათი: TimescaleDB - I/O გამოყენება ჩასმის ტესტის დროს უნიკალური 4M დროის სერიებისთვის.

IO-ს გამოყენების შაბლონები ასახავს დისკის გამტარუნარიანობას - InfluxDB შეზღუდულია IO-ით, ხოლო VictoriaMetrics-სა და TimescaleDB-ს აქვთ სათადარიგო IO რესურსები.

40M უნიკალური დროის სერია

40 მილიონი უნიკალური დროის სერია ძალიან დიდი იყო InfluxDB-სთვის :)

საორიენტაციო შედეგები:

• VictoriaMetrics: 1,7M მონაცემთა წერტილი წამში; ოპერატიული მეხსიერების მოხმარება: 29 GB; დისკის მოხმარება: 17 GB.
• InfluxDB: არ დასრულებულა, რადგან საჭიროებდა 60 გბ-ზე მეტ ოპერატიული მეხსიერებას.
• TimescaleDB: 330K მონაცემთა წერტილი წამში, ოპერატიული მეხსიერების მოხმარება: 2,5 GB; დისკის მოხმარება: 84 GB.

TimescaleDB აჩვენებს RAM-ის განსაკუთრებულად დაბალ და სტაბილურ გამოყენებას 2,5 გბ-ზე - იგივე, რაც უნიკალური 4M და 400K მეტრიკებისთვის.

VictoriaMetrics ნელ-ნელა იზრდებოდა 100 40 მონაცემთა წერტილი წამში, სანამ ყველა 1,5M მონიშნული მეტრიკული სახელი არ დამუშავდებოდა. შემდეგ მან მიაღწია 2,0-1,7M მონაცემთა ქულის მდგრად ჩასმას წამში, ასე რომ საბოლოო შედეგი იყო XNUMXM მონაცემთა წერტილი წამში.

40M უნიკალური დროის სერიების გრაფიკები მსგავსია 4M უნიკალური დროის სერიების გრაფიკების, ასე რომ, მოდით გამოვტოვოთ ისინი.

დასკვნები

• თანამედროვე TSDB-ებს შეუძლიათ დამუშავონ ჩანართები მილიონობით უნიკალური დროის სერიებისთვის ერთ სერვერზე. შემდეგ სტატიაში ჩვენ შევამოწმებთ, რამდენად კარგად ასრულებს TSDBs შერჩევა მილიონობით უნიკალური დროის სერიაში.
• CPU-ს არასაკმარისი გამოყენება ჩვეულებრივ მიუთითებს I/O ბოთლზე. ეს ასევე შეიძლება მიუთითებდეს, რომ დაბლოკვა ძალიან უხეშია, მხოლოდ რამდენიმე ძაფს შეუძლია ერთდროულად გაშვება.
• I/O bottleneck ნამდვილად არსებობს, განსაკუთრებით არა SSD საცავებში, როგორიცაა ღრუბლოვანი პროვაიდერების ვირტუალური ბლოკის მოწყობილობები.
• VictoriaMetrics უზრუნველყოფს საუკეთესო ოპტიმიზაციას ნელი, დაბალი I/O შენახვისთვის. ის უზრუნველყოფს საუკეთესო სიჩქარეს და საუკეთესო შეკუმშვის კოეფიციენტს.

გადმოწერა VictoriaMetrics ერთი სერვერის სურათი და სცადეთ თქვენს მონაცემებზე. შესაბამისი სტატიკური ორობითი ხელმისაწვდომია მისამართზე GitHub.

წაიკითხეთ მეტი VictoriaMetrics-ის შესახებ აქ მუხლი.

განახლება: გამოქვეყნდა სტატია, რომელიც ადარებს VictoriaMetrics-ის ჩანართის შესრულებას InfluxDB-სთან განმეორებადი შედეგებით.

განახლება #2: წაიკითხეთ ასევე სტატია ვერტიკალური მასშტაბურობის შესახებ VictoriaMetrics vs InfluxDB vs TimescaleDB.

განახლება #3: VictoriaMetrics ახლა ღია წყაროა!

ტელეგრამის ჩატი: https://t.me/VictoriaMetrics_ru1

წყარო: www.habr.com