გადადით ოპტიმიზაციაზე VictoriaMetrics-ში. ალექსანდრე ვალიალკინი

გირჩევთ, წაიკითხოთ ალექსანდრე ვალიალკინის 2019 წლის ბოლოს მოხსენების ტრანსკრიპტი „გადადით ოპტიმიზაცია VictoriaMetrics-ში“

VictoriaMetrics — სწრაფი და მასშტაბირებადი DBMS მონაცემთა შენახვისა და დამუშავებისთვის დროის სერიების სახით (ჩანაწერი აყალიბებს დროს და ამ დროის შესაბამისი მნიშვნელობების ერთობლიობას, მაგალითად, მიღებული სენსორების სტატუსის პერიოდული გამოკითხვით ან შეგროვებით. მეტრიკა).

აქ მოცემულია ამ მოხსენების ვიდეოს ბმული - https://youtu.be/MZ5P21j_HLE

სლაიდები

Მოგვიყევი შენს შესახებ. მე ვარ ალექსანდრე ვალიალკინი. Აქ ჩემი GitHub ანგარიში. გატაცებული ვარ Go და შესრულების ოპტიმიზაციის მიმართ. დავწერე ბევრი სასარგებლო და არც თუ ისე სასარგებლო ბიბლიოთეკა. ისინი იწყებენ ორივეს fast, ან თან quick პრეფიქსი.

ამჟამად ვმუშაობ VictoriaMetrics-ზე. რა არის და რას ვაკეთებ იქ? ამ პრეზენტაციაში ვისაუბრებ ამაზე.

მოხსენების მონახაზი ასეთია:

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

აუდიტორიაში ვინმემ იცის რა არის VictoriaMetrics? ვაა, უკვე ბევრმა იცის. კარგი ამბავია. მათთვის, ვინც არ იცის, ეს არის დროის სერიების მონაცემთა ბაზა. ის დაფუძნებულია ClickHouse არქიტექტურაზე, ClickHouse-ის განხორციელების ზოგიერთ დეტალზე. მაგალითად, ისეთებზე, როგორიცაა: MergeTree, პარალელური გაანგარიშება ყველა ხელმისაწვდომ პროცესორის ბირთვზე და მუშაობის ოპტიმიზაცია მონაცემთა ბლოკებზე მუშაობით, რომლებიც მოთავსებულია პროცესორის ქეშში.

VictoriaMetrics უზრუნველყოფს მონაცემთა უკეთ შეკუმშვას, ვიდრე სხვა დროის სერიების მონაცემთა ბაზები.

ის ვერტიკალურად მასშტაბებს – ანუ, შეგიძლიათ დაამატოთ მეტი პროცესორი, მეტი ოპერატიული მეხსიერება ერთ კომპიუტერზე. VictoriaMetrics წარმატებით გამოიყენებს ამ ხელმისაწვდომ რესურსებს და გააუმჯობესებს ხაზოვან პროდუქტიულობას.

VictoriaMetrics ასევე მასშტაბირებს ჰორიზონტალურად - ანუ შეგიძლიათ დაამატოთ დამატებითი კვანძები VictoriaMetrics კლასტერში და მისი შესრულება თითქმის წრფივად გაიზრდება.

როგორც თქვენ მიხვდით, VictoriaMetrics არის სწრაფი მონაცემთა ბაზა, რადგან მე არ შემიძლია სხვების დაწერა. და ის Go-შია დაწერილი, ამიტომ მე ვსაუბრობ ამაზე ამ შეხვედრაზე.

ვინ იცის რა არის დროის სერია? ის ასევე ბევრ ადამიანს იცნობს. დროის სერია არის წყვილების სერია (timestamp, значение), სადაც ეს წყვილები დალაგებულია დროის მიხედვით. მნიშვნელობა არის მცურავი წერტილის ნომერი - float64.

თითოეული დროის სერია ცალსახად იდენტიფიცირებულია გასაღებით. რისგან შედგება ეს გასაღები? იგი შედგება გასაღები-მნიშვნელობის წყვილების არა ცარიელი ნაკრებისგან.

აქ არის დროის სერიების მაგალითი. ამ სერიის გასაღები არის წყვილების სია: __name__="cpu_usage" არის მეტრიკის სახელი, instance="my-server" - ეს არის კომპიუტერი, რომელზეც გროვდება ეს მეტრიკა, datacenter="us-east" - ეს არის მონაცემთა ცენტრი, სადაც ეს კომპიუტერი მდებარეობს.

ჩვენ მივიღეთ დროის სერიის სახელი, რომელიც შედგება სამი გასაღები-მნიშვნელობის წყვილისგან. ეს გასაღები შეესაბამება წყვილების სიას (timestamp, value). t1, t3, t3, ..., tN - ეს არის დროის შტამპები, 10, 20, 12, ..., 15 - შესაბამისი მნიშვნელობები. ეს არის cpu-გამოყენება მოცემულ დროს მოცემული სერიისთვის.

სად შეიძლება დროის სერიების გამოყენება? ვინმეს რამე იდეა აქვს?

• DevOps-ში შეგიძლიათ გაზომოთ CPU, RAM, ქსელი, rps, შეცდომების რაოდენობა და ა.შ.
• IoT - ჩვენ შეგვიძლია გავზომოთ ტემპერატურა, წნევა, გეოკოორდინატები და სხვა.
• ასევე ფინანსები - ჩვენ შეგვიძლია ვაკონტროლოთ ფასები ყველა სახის აქციებსა და ვალუტაზე.
• გარდა ამისა, დროის სერიები შეიძლება გამოყენებულ იქნას ქარხნებში წარმოების პროცესების მონიტორინგისთვის. ჩვენ გვყავს მომხმარებლები, რომლებიც იყენებენ VictoriaMetrics-ს ქარის ტურბინების მონიტორინგისთვის, რობოტებისთვის.
• დროის სერიები ასევე სასარგებლოა სხვადასხვა მოწყობილობების სენსორებისგან ინფორმაციის შეგროვებისთვის. მაგალითად, ძრავისთვის; საბურავებში წნევის გასაზომად; სიჩქარის, მანძილის გასაზომად; ბენზინის მოხმარების გასაზომად და ა.შ.
• დროის სერიები ასევე შეიძლება გამოყენებულ იქნას თვითმფრინავების მონიტორინგისთვის. თითოეულ თვითმფრინავს აქვს შავი ყუთი, რომელიც აგროვებს დროის სერიებს თვითმფრინავის ჯანმრთელობის სხვადასხვა პარამეტრებისთვის. დროის სერიები ასევე გამოიყენება საჰაერო კოსმოსურ ინდუსტრიაში.
• ჯანდაცვა არის არტერიული წნევა, პულსი და ა.შ.

შეიძლება იყოს უფრო მეტი აპლიკაცია, რომელიც დამავიწყდა, მაგრამ იმედია გესმით, რომ დროის სერიები აქტიურად გამოიყენება თანამედროვე სამყაროში. და მათი გამოყენების მოცულობა ყოველწლიურად იზრდება.

რატომ გჭირდებათ დროის სერიების მონაცემთა ბაზა? რატომ არ შეგიძლიათ გამოიყენოთ რეგულარული რელაციური მონაცემთა ბაზა დროის სერიების შესანახად?

რადგან დროის სერიები ჩვეულებრივ შეიცავს დიდი რაოდენობით ინფორმაციას, რომლის შენახვა და დამუშავება ჩვეულებრივ მონაცემთა ბაზებში რთულია. ამიტომ გამოჩნდა სპეციალიზებული მონაცემთა ბაზები დროის სერიებისთვის. ეს ბაზები ეფექტურად ინახავს წერტილებს (timestamp, value) მოცემული გასაღებით. ისინი უზრუნველყოფენ API-ს, რომ წაიკითხოს შენახული მონაცემები გასაღებით, ერთი გასაღები-მნიშვნელობის წყვილით, ან რამდენიმე გასაღები-მნიშვნელობის წყვილით, ან regexp-ით. მაგალითად, გსურთ იპოვოთ თქვენი ყველა სერვისის CPU დატვირთვა ამერიკაში მონაცემთა ცენტრში, მაშინ უნდა გამოიყენოთ ეს ფსევდო შეკითხვა.

როგორც წესი, დროის სერიების მონაცემთა ბაზები უზრუნველყოფენ შეკითხვის სპეციალიზებულ ენებს, რადგან დროის სერიები SQL არ არის ძალიან შესაფერისი. მიუხედავად იმისა, რომ არსებობს მონაცემთა ბაზები, რომლებიც მხარს უჭერენ SQL-ს, ის არ არის ძალიან შესაფერისი. შეკითხვის ენები, როგორიცაა PromQL, InfluxQL, Flux, Q. იმედი მაქვს, რომ ვინმეს სმენია ამ ენებიდან ერთი მაინც. ბევრს ალბათ სმენია PromQL-ის შესახებ. ეს არის პრომეთეს შეკითხვის ენა.

ასე გამოიყურება თანამედროვე დროის სერიების მონაცემთა ბაზის არქიტექტურა VictoriaMetrics-ის მაგალითის გამოყენებით.

იგი შედგება ორი ნაწილისაგან. ეს არის შებრუნებული ინდექსის საცავი და დროის სერიების მნიშვნელობების საცავი. ეს საცავი გამოყოფილია.

როდესაც მონაცემთა ბაზაში ახალი ჩანაწერი მოდის, ჩვენ ჯერ შევდივართ ინვერსიულ ინდექსზე, რათა ვიპოვოთ დროის სერიების იდენტიფიკატორი მოცემული ნაკრებისთვის. label=value მოცემული მეტრიკისთვის. ჩვენ ვპოულობთ ამ იდენტიფიკატორს და ვინახავთ მნიშვნელობას მონაცემთა მაღაზიაში.

როდესაც მოთხოვნა მოდის TSDB-დან მონაცემების მისაღებად, ჩვენ ჯერ გადავდივართ ინვერსიულ ინდექსზე. მივიღოთ ყველაფერი timeseries_ids ჩანაწერები, რომლებიც ემთხვევა ამ კომპლექტს label=value. შემდეგ კი ჩვენ ვიღებთ ყველა საჭირო მონაცემს მონაცემთა საწყობიდან, ინდექსირებული timeseries_ids.

მოდით შევხედოთ მაგალითს, თუ როგორ ამუშავებს დროის სერიების მონაცემთა ბაზა შემომავალ შერჩეულ შეკითხვას.

• პირველ რიგში ის ყველაფერს იღებს timeseries_ids ინვერსიული ინდექსიდან, რომელიც შეიცავს მოცემულ წყვილებს label=value, ან დააკმაყოფილეთ მოცემული რეგულარული გამოთქმა.
• შემდეგ ის ამოიღებს ყველა მონაცემთა წერტილს მონაცემთა საცავიდან მოცემულ დროის ინტერვალში ნაპოვნი პირებისთვის timeseries_ids.
• ამის შემდეგ, მონაცემთა ბაზა ახორციელებს გარკვეულ გამოთვლებს ამ მონაცემთა წერტილებზე, მომხმარებლის მოთხოვნის შესაბამისად. და ამის შემდეგ აბრუნებს პასუხს.

ამ პრეზენტაციაში მოგიყვებით პირველ ნაწილზე. ეს არის ძებნა timeseries_ids ინვერსიული ინდექსით. მეორე ნაწილის და მესამე ნაწილის შესახებ მოგვიანებით შეგიძლიათ ნახოთ VictoriaMetrics-ის წყაროები, ან დაელოდე სანამ სხვა ანგარიშებს მოვამზადებ :)

გადავიდეთ ინვერსიულ ინდექსზე. ბევრმა შეიძლება იფიქროს, რომ ეს მარტივია. ვინ იცის, რა არის ინვერსიული ინდექსი და როგორ მუშაობს იგი? ოჰ, ამდენი ხალხი აღარ არის. შევეცადოთ გავიგოთ რა არის ეს.

სინამდვილეში მარტივია. ეს უბრალოდ ლექსიკონია, რომელიც ასახავს მნიშვნელობის გასაღებს. რა არის გასაღები? ეს წყვილი label=valueსად label и value - ეს ხაზებია. და ღირებულებები არის კომპლექტი timeseries_ids, რომელიც მოიცავს მოცემულ წყვილს label=value.

ინვერსიული ინდექსი საშუალებას გაძლევთ სწრაფად იპოვოთ ყველაფერი timeseries_ids, რომლებმაც მისცეს label=value.

ის ასევე საშუალებას გაძლევთ სწრაფად იპოვოთ timeseries_ids დროის სერია რამდენიმე წყვილისთვის label=value, ან წყვილებისთვის label=regexp. როგორ ხდება ეს? კომპლექტის კვეთის პოვნის საშუალებით timeseries_ids თითოეული წყვილისთვის label=value.

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

ფუნქცია getMetricIDs იღებს სტრიქონების სიას. თითოეული ხაზი შეიცავს label=value. ეს ფუნქცია აბრუნებს სიას metricIDs.

Როგორ მუშაობს? აქ ჩვენ გვაქვს გლობალური ცვლადი ე.წ invertedIndex. ეს არის ჩვეულებრივი ლექსიკონი (map), რომელიც ასახავს სტრიქონს ინტების დასაჭრელად. ხაზი შეიცავს label=value.

ფუნქციის განხორციელება: მიიღეთ metricIDs პირველისთვის label=value, შემდეგ ჩვენ გავდივართ ყველაფერ დანარჩენს label=value, გავიგეთ metricIDs მათთვის. და გამოიძახეთ ფუნქცია intersectInts, რომელიც ქვემოთ იქნება განხილული. და ეს ფუნქცია აბრუნებს ამ სიების კვეთას.

როგორც ხედავთ, ინვერსიული ინდექსის განხორციელება არ არის ძალიან რთული. მაგრამ ეს გულუბრყვილო განხორციელებაა. რა მინუსები აქვს? გულუბრყვილო განხორციელების მთავარი მინუსი არის ის, რომ ასეთი ინვერსიული ინდექსი ინახება RAM-ში. აპლიკაციის გადატვირთვის შემდეგ ჩვენ ვკარგავთ ამ ინდექსს. ამ ინდექსის დისკზე შენახვა არ არის. ასეთი ინვერსიული ინდექსი ნაკლებად სავარაუდოა, რომ შესაფერისი იყოს მონაცემთა ბაზისთვის.

მეორე ნაკლი ასევე დაკავშირებულია მეხსიერებასთან. ინვერსიული ინდექსი უნდა შეესაბამებოდეს RAM-ს. თუ ის აღემატება ოპერატიული მეხსიერების ზომას, მაშინ აშკარად მივიღებთ - მეხსიერების შეცდომას. და პროგრამა არ იმუშავებს.

ამ პრობლემის მოგვარება შესაძლებელია მზა გადაწყვეტილებების გამოყენებით, როგორიცაა დონე DBან RocksDB.

მოკლედ, ჩვენ გვჭირდება მონაცემთა ბაზა, რომელიც საშუალებას მოგვცემს სწრაფად გავაკეთოთ სამი ოპერაცია.

• პირველი ოპერაცია ჩაწერაა ключ-значение ამ მონაცემთა ბაზაში. ის ამას აკეთებს ძალიან სწრაფად, სადაც ключ-значение არის თვითნებური სტრიქონები.
• მეორე ოპერაცია არის მნიშვნელობის სწრაფი ძებნა მოცემული გასაღების გამოყენებით.
• და მესამე ოპერაცია არის ყველა მნიშვნელობის სწრაფი ძებნა მოცემული პრეფიქსით.

LevelDB და RocksDB - ეს მონაცემთა ბაზები შეიქმნა Google-ისა და Facebook-ის მიერ. პირველი მოვიდა LevelDB. შემდეგ ფეისბუქის ბიჭებმა აიღეს LevelDB და დაიწყეს მისი გაუმჯობესება, გააკეთეს RocksDB. ახლა თითქმის ყველა შიდა მონაცემთა ბაზა მუშაობს RocksDB-ზე Facebook-ის შიგნით, მათ შორის ისეთებიც, რომლებიც გადატანილია RocksDB-სა და MySQL-ზე. მათ დაასახელეს იგი MyRocks.

ინვერსიული ინდექსი შეიძლება განხორციელდეს LevelDB-ის გამოყენებით. Როგორ გავაკეთო ეს? ჩვენ ვინახავთ როგორც გასაღებს label=value. და მნიშვნელობა არის დროის სერიების იდენტიფიკატორი, სადაც წყვილი იმყოფება label=value.

თუ გვაქვს მრავალი დროის სერია მოცემულ წყვილთან label=value, მაშინ ამ მონაცემთა ბაზაში იქნება ბევრი მწკრივი ერთი და იგივე გასაღებით და განსხვავებული timeseries_ids. ყველა სიის მისაღებად timeseries_ids, რომელიც იწყება ამით label=prefix, ჩვენ ვაკეთებთ დიაპაზონის სკანირებას, რომლისთვისაც ეს მონაცემთა ბაზა ოპტიმიზებულია. ანუ, ჩვენ ვირჩევთ ყველა ხაზს, რომელიც იწყება label=prefix და მიიღეთ საჭირო timeseries_ids.

აქ არის განხორციელების ნიმუში, თუ როგორი იქნება ის Go-ში. ჩვენ გვაქვს ინვერსიული ინდექსი. ეს არის LevelDB.

ფუნქცია იგივეა, რაც გულუბრყვილო განხორციელებისთვის. იგი იმეორებს გულუბრყვილო განხორციელებას თითქმის სტრიქონი. ერთადერთი წერტილი არის ის, რომ ნაცვლად იმისა, რომ მივმართოთ map ჩვენ შევდივართ ინვერსიულ ინდექსზე. ჩვენ ვიღებთ ყველა მნიშვნელობას პირველისთვის label=value. შემდეგ ჩვენ გავდივართ ყველა დარჩენილ წყვილს label=value და მიიღეთ მათთვის მეტრიკის ID-ების შესაბამისი ნაკრები. შემდეგ ვპოულობთ კვეთას.

როგორც ჩანს, ყველაფერი კარგადაა, მაგრამ ამ გადაწყვეტას აქვს ნაკლოვანებები. VictoriaMetrics-მა თავდაპირველად დანერგა ინვერსიული ინდექსი LevelDB-ზე დაფუძნებული. მაგრამ ბოლოს მომიწია დათმობა.

რატომ? რადგან LevelDB უფრო ნელია ვიდრე გულუბრყვილო განხორციელება. გულუბრყვილო განხორციელებისას, მოცემული გასაღების მიცემით, ჩვენ დაუყოვნებლივ ვიღებთ მთელ ნაჭერს metricIDs. ეს არის ძალიან სწრაფი ოპერაცია - მთელი ნაჭერი მზად არის გამოსაყენებლად.

LevelDB-ში ყოველ ჯერზე, როცა ფუნქცია გამოიძახება GetValues თქვენ უნდა გაიაროთ ყველა ის ხაზი, რომელიც იწყება label=value. და მიიღეთ მნიშვნელობა თითოეული ხაზისთვის timeseries_ids. ასეთი timeseries_ids შეაგროვეთ მათი ნაჭერი timeseries_ids. ცხადია, ეს ბევრად უფრო ნელია, ვიდრე ჩვეულებრივი რუკაზე ღილაკით წვდომა.

მეორე ნაკლი არის ის, რომ LevelDB იწერება C-ში. Go-დან C ფუნქციების გამოძახება არც თუ ისე სწრაფია. ამას ასობით ნანოწამი სჭირდება. ეს არც თუ ისე სწრაფია, რადგან go-ში ჩაწერილ ჩვეულებრივ ფუნქციურ ზართან შედარებით, რომელსაც 1-5 ნანოწამი სჭირდება, შესრულებაში განსხვავება ათჯერ არის. VictoriaMetrics-ისთვის ეს საბედისწერო ხარვეზია :)

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

Mergeset ეფუძნება MergeTree მონაცემთა სტრუქტურას. მონაცემთა ეს სტრუქტურა ნასესხებია ClickHouse-დან. ცხადია, შერწყმა უნდა იყოს ოპტიმიზირებული სწრაფი ძიებისთვის timeseries_ids მოცემული გასაღების მიხედვით. Mergeset მთლიანად Go-შია დაწერილი. Შეგიძლია ნახო VictoriaMetrics წყაროები GitHub-ზე. mergeset-ის განხორციელება საქაღალდეშია /lib/mergeset. შეგიძლიათ სცადოთ იმის გარკვევა, თუ რა ხდება იქ.

mergeset API ძალიან ჰგავს LevelDB და RocksDB. ანუ ის საშუალებას გაძლევთ სწრაფად შეინახოთ იქ ახალი ჩანაწერები და სწრაფად აირჩიოთ ჩანაწერები მოცემული პრეფიქსით.

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

რატომ გაჩნდნენ ისინი?

პირველი მიზეზი არის გაფუჭების მაღალი მაჩვენებელი. რუსულად თარგმნილი, ეს არის დროის სერიების ხშირი ცვლილება. ამ დროს მთავრდება დროის სერია და იწყება ახალი სერია, ან იწყება ბევრი ახალი დროის სერია. და ეს ხშირად ხდება.

მეორე მიზეზი არის დროის სერიების დიდი რაოდენობა. თავიდან, როცა მონიტორინგი პოპულარობას იძენდა, დროის სერიების რაოდენობა მცირე იყო. მაგალითად, თითოეული კომპიუტერისთვის საჭიროა CPU, მეხსიერების, ქსელის და დისკის დატვირთვის მონიტორინგი. 4 დროის სერია თითო კომპიუტერზე. ვთქვათ, თქვენ გაქვთ 100 კომპიუტერი და 400 დროის სერია. ეს ძალიან ცოტაა.

დროთა განმავლობაში ადამიანებმა გააცნობიერეს, რომ მათ შეეძლოთ უფრო დეტალური ინფორმაციის გაზომვა. მაგალითად, გაზომეთ დატვირთვა არა მთელი პროცესორის, არამედ თითოეული პროცესორის ბირთვის ცალკე. თუ თქვენ გაქვთ 40 პროცესორის ბირთვი, მაშინ თქვენ გაქვთ 40-ჯერ მეტი დროის სერია პროცესორის დატვირთვის გასაზომად.

მაგრამ ეს ყველაფერი არ არის. პროცესორის თითოეულ ბირთვს შეიძლება ჰქონდეს რამდენიმე მდგომარეობა, როგორიცაა უმოქმედო, როდესაც ის უმოქმედოა. ასევე მუშაობა მომხმარებლის სივრცეში, მუშაობა ბირთვის სივრცეში და სხვა მდგომარეობებში. და თითოეული ასეთი მდგომარეობა ასევე შეიძლება გაიზომოს როგორც ცალკეული დროის სერია. ეს დამატებით ზრდის რიგების რაოდენობას 7-8-ჯერ.

ერთი მეტრიდან მივიღეთ 40 x 8 = 320 მეტრიკა მხოლოდ ერთი კომპიუტერისთვის. გავამრავლოთ 100-ზე, მივიღებთ 32-ს 000-ის ნაცვლად.

შემდეგ კუბერნეტები მოვიდა. და ეს გაუარესდა, რადგან Kubernetes-ს შეუძლია მრავალი განსხვავებული სერვისის მასპინძლობა. კუბერნეტის თითოეული სერვისი შედგება მრავალი პოდისგან. და ამ ყველაფერს მონიტორინგი სჭირდება. გარდა ამისა, ჩვენ გვაქვს თქვენი სერვისების ახალი ვერსიების მუდმივი განლაგება. ყოველი ახალი ვერსიისთვის უნდა შეიქმნას ახალი დროის სერიები. შედეგად, დროის სერიების რაოდენობა ექსპონენტურად იზრდება და ჩვენ ვდგებით დროის სერიების დიდი რაოდენობის პრობლემის წინაშე, რომელსაც მაღალი კარდინალობა ეწოდება. VictoriaMetrics წარმატებით უმკლავდება მას სხვა დროის სერიების მონაცემთა ბაზებთან შედარებით.

მოდით უფრო ახლოს მივხედოთ მაღალი ცურვის სიჩქარეს. რა განაპირობებს წარმოების მაღალ ცვენას? იმის გამო, რომ ეტიკეტებისა და ტეგების ზოგიერთი მნიშვნელობა მუდმივად იცვლება.

მაგალითად, ავიღოთ Kubernetes, რომელსაც აქვს კონცეფცია deployment, ანუ როცა თქვენი აპლიკაციის ახალი ვერსია გამოდის. რატომღაც, Kubernetes-ის დეველოპერებმა გადაწყვიტეს დაემატებინათ განლაგების ID ლეიბლზე.

რა გამოიწვია ამან? უფრო მეტიც, ყოველი ახალი განლაგებისას, ყველა ძველი დროის სერია წყდება და მათ ნაცვლად, ახალი დროის სერიები იწყება ახალი ეტიკეტის მნიშვნელობით. deployment_id. ასეთი რიგები შეიძლება იყოს ასობით ათასი და თუნდაც მილიონობით.

ამ ყველაფერში მთავარი ის არის, რომ დროის სერიების ჯამური რაოდენობა იზრდება, მაგრამ დროის სერიების რაოდენობა, რომლებიც ამჟამად აქტიურია და მონაცემებს იღებენ, უცვლელი რჩება. ამ მდგომარეობას ჰქვია მაღალი ჩაქრობის სიჩქარე.

მაღალი ცურვის სიჩქარის მთავარი პრობლემა არის ძებნის მუდმივი სიჩქარის უზრუნველყოფა ყველა დროის სერიებისთვის ეტიკეტების მოცემული ნაკრებისთვის გარკვეული დროის ინტერვალზე. როგორც წესი, ეს არის დროის ინტერვალი ბოლო საათის ან ბოლო დღისთვის.

როგორ მოვაგვაროთ ეს პრობლემა? აი პირველი ვარიანტი. ეს არის ინვერსიული ინდექსის დაყოფა დამოუკიდებელ ნაწილებად დროთა განმავლობაში. ანუ გადის გარკვეული დროის ინტერვალი, ვასრულებთ მუშაობას მიმდინარე ინვერსიულ ინდექსთან. და შექმენით ახალი ინვერსიული ინდექსი. სხვა დროის ინტერვალი გადის, ჩვენ ვქმნით მეორეს და მეორეს.

და ამ ინვერსიული ინდექსებიდან შერჩევისას, ჩვენ ვპოულობთ შებრუნებული ინდექსების ერთობლიობას, რომლებიც მოცემულ ინტერვალშია. და, შესაბამისად, იქიდან ვირჩევთ დროის სერიების id-ს.

ეს დაზოგავს რესურსებს, რადგან ჩვენ არ გვჭირდება შევხედოთ ნაწილებს, რომლებიც არ ჯდება მოცემულ ინტერვალში. ანუ, ჩვეულებრივ, თუ ჩვენ ვირჩევთ მონაცემებს ბოლო საათის განმავლობაში, მაშინ წინა დროის ინტერვალებისთვის გამოვტოვებთ მოთხოვნებს.

ამ პრობლემის მოგვარების კიდევ ერთი ვარიანტი არსებობს. ეს არის შესანახად ყოველი დღისთვის იმ დღეს მომხდარი დროის სერიების ID-ების ცალკეული სია.

ამ გადაწყვეტის უპირატესობა წინა გადაწყვეტასთან შედარებით არის ის, რომ ჩვენ არ ვამეორებთ დროის სერიების ინფორმაციას, რომელიც დროთა განმავლობაში არ ქრება. ისინი მუდმივად იმყოფებიან და არ იცვლებიან.

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

მე მომიწია მასთან ბრძოლა. ბრძოლა იმაში მდგომარეობდა, რომ ამ განხორციელებისას თქვენ ჯერ კიდევ გჭირდებათ ბევრად უფრო დიდი რაოდენობის არჩევა timeseries_ids მონაცემებისთვის, ვიდრე ინვერსიული ინდექსის დროის დაყოფისას.

როგორ მოვაგვარეთ ეს პრობლემა? ჩვენ ეს გადავწყვიტეთ ორიგინალური გზით - ერთი იდენტიფიკატორის ნაცვლად რამდენიმე დროის სერიების იდენტიფიკატორის შენახვით ინვერსიულ ინდექსის ჩანაწერში. ანუ გასაღები გვაქვს label=value, რომელიც გვხვდება ყველა დროის სერიაში. ახლა კი რამდენიმეს დავზოგავთ timeseries_ids ერთ ჩანაწერში.

აი მაგალითი. ადრე გვქონდა N ჩანაწერი, მაგრამ ახლა გვაქვს ერთი ჩანაწერი, რომლის პრეფიქსი იგივეა, რაც ყველა სხვა. წინა ჩანაწერისთვის, მნიშვნელობა შეიცავს ყველა დროის სერიების ID-ებს.

ამან შესაძლებელი გახადა ასეთი ინვერსიული ინდექსის სკანირების სიჩქარის 10-ჯერ გაზრდა. და ამან მოგვცა საშუალება შეგვემცირებინა მეხსიერების მოხმარება ქეშისთვის, რადგან ახლა ჩვენ ვინახავთ სტრიქონს label=value მხოლოდ ერთხელ ქეშში ერთად N ჯერ. და ეს ხაზი შეიძლება იყოს დიდი, თუ თქვენ ინახავთ გრძელ ხაზებს თქვენს ტეგებსა და ლეიბლებში, რომლებიც Kubernetes-ს უყვარს იქ ჩასმა.

ინვერსიულ ინდექსზე ძიების დაჩქარების კიდევ ერთი ვარიანტია დაშლა. ერთის ნაცვლად რამდენიმე ინვერსიული ინდექსის შექმნა და მათ შორის მონაცემთა გაზიარება გასაღებით. ეს არის ნაკრები key=value ორთქლი. ანუ ჩვენ ვიღებთ რამდენიმე დამოუკიდებელ ინვერსიულ ინდექსს, რომელიც შეგვიძლია პარალელურად გამოვიკითხოთ რამდენიმე პროცესორზე. წინა დანერგვა მხოლოდ ერთ პროცესორულ რეჟიმში იყო დაშვებული, ანუ მონაცემთა სკანირება მხოლოდ ერთ ბირთვზე. ეს გამოსავალი საშუალებას გაძლევთ დაასკანიროთ მონაცემები ერთდროულად რამდენიმე ბირთვზე, როგორც ამას ClickHouse-ს მოსწონს. სწორედ ამის განხორციელებას ვგეგმავთ.

ახლა დავუბრუნდეთ ჩვენს ცხვარს - გადაკვეთის ფუნქციას timeseries_ids. მოდით განვიხილოთ რა დანერგვები შეიძლება იყოს. ეს ფუნქცია საშუალებას გაძლევთ იპოვოთ timeseries_ids მოცემული ნაკრებისთვის label=value.

პირველი ვარიანტი არის გულუბრყვილო განხორციელება. ორი წყობილი მარყუჟი. აქ ვიღებთ ფუნქციის შეყვანას intersectInts ორი ნაჭერი - a и b. გამოსავალზე უნდა დაგვიბრუნოს ამ ნაჭრების კვეთა.

გულუბრყვილო განხორციელება ასე გამოიყურება. ჩვენ ვიმეორებთ ყველა მნიშვნელობას ნაჭერიდან a, ამ მარყუჟის შიგნით ჩვენ გავდივართ ნაჭრის ყველა მნიშვნელობას b. და ჩვენ ვადარებთ მათ. თუ ისინი ემთხვევა, მაშინ ჩვენ ვიპოვეთ კვეთა. და შეინახეთ იგი result.

რა არის უარყოფითი მხარეები? კვადრატული სირთულე მისი მთავარი ნაკლია. მაგალითად, თუ თქვენი ზომები ნაჭერია a и b ერთი მილიონი ერთდროულად, მაშინ ეს ფუნქცია არასოდეს დაგიბრუნებთ პასუხს. რადგან მას დასჭირდება ერთი ტრილიონი გამეორების გაკეთება, რაც ბევრია თანამედროვე კომპიუტერებისთვისაც კი.

მეორე განხორციელება ეფუძნება რუკას. ჩვენ ვქმნით რუკას. ჩვენ ყველა მნიშვნელობას ვდებთ ამ რუკაზე ფრაგმენტიდან a. შემდეგ ჩვენ გავდივართ ნაჭერს ცალკე მარყუჟში b. და ჩვენ ვამოწმებთ არის თუ არა ეს მნიშვნელობა ნაჭერიდან b რუკაზე. თუ ის არსებობს, მაშინ დაამატეთ იგი შედეგს.

რა არის სარგებელი? უპირატესობა ის არის, რომ არსებობს მხოლოდ წრფივი სირთულე. ანუ, ფუნქცია ბევრად უფრო სწრაფად შესრულდება უფრო დიდი ნაჭრებისთვის. მილიონი ზომის ნაჭრისთვის, ეს ფუნქცია შესრულდება 2 მილიონი გამეორებით, წინა ფუნქციის ტრილიონი გამეორებისგან განსხვავებით.

მინუსი არის ის, რომ ამ ფუნქციას მეტი მეხსიერება სჭირდება ამ რუკის შესაქმნელად.

მეორე ნაკლი არის ჰეშირების დიდი ზედნადები. ეს ნაკლი არც თუ ისე აშკარაა. ჩვენთვის ეს ასევე არ იყო ძალიან აშკარა, ასე რომ, თავიდან VictoriaMetrics-ში კვეთის განხორციელება ხდებოდა რუქის საშუალებით. მაგრამ შემდეგ პროფილირებამ აჩვენა, რომ მთავარი პროცესორის დრო იხარჯება რუკაზე ჩაწერაზე და ამ რუკაზე მნიშვნელობის არსებობის შემოწმებაზე.

რატომ იკარგება CPU დრო ამ ადგილებში? რადგან Go ასრულებს ჰეშირების ოპერაციას ამ ხაზებზე. ანუ, ის ითვლის გასაღების ჰეშს, რათა შემდეგ შევიდეს მას HashMap-ის მოცემულ ინდექსზე. ჰეშის გამოთვლის ოპერაცია სრულდება ათობით ნანოწამში. ეს ნელია VictoriaMetrics-ისთვის.

მე გადავწყვიტე ამ შემთხვევისთვის სპეციალურად ოპტიმიზირებული ბიტის დანერგვა. ასე გამოიყურება ახლა ორი ნაჭერის გადაკვეთა. აქ ჩვენ ვქმნით ბიტს. მას ვამატებთ ელემენტებს პირველი ნაჭრიდან. შემდეგ ჩვენ ვამოწმებთ ამ ელემენტების არსებობას მეორე ნაჭერში. და დაამატეთ ისინი შედეგს. ანუ ის თითქმის არაფრით განსხვავდება წინა მაგალითისგან. აქ მხოლოდ ის არის, რომ ჩვენ შევცვალეთ რუკაზე წვდომა მორგებული ფუნქციებით add и has.

ერთი შეხედვით, როგორც ჩანს, ეს უფრო ნელა უნდა იმუშაოს, თუ მანამდე იქ გამოიყენებოდა სტანდარტული რუკა, შემდეგ კი სხვა ფუნქციებია გამოძახებული, მაგრამ პროფილირება აჩვენებს, რომ ეს ნივთი 10-ჯერ უფრო სწრაფად მუშაობს, ვიდრე სტანდარტული რუკა VictoriaMetrics-ის შემთხვევაში.

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

ამ განხორციელების მინუსი ის არის, რომ ის არც ისე აშკარაა, არც ტრივიალური.

კიდევ ერთი ნაკლი, რომელიც ბევრმა შეიძლება ვერ შეამჩნიოს არის ის, რომ ზოგიერთ შემთხვევაში ამ განხორციელებამ შეიძლება კარგად არ იმუშაოს. ანუ ის ოპტიმიზებულია კონკრეტული შემთხვევისთვის, VictoriaMetrics დროის სერიების ID-ების გადაკვეთის ამ შემთხვევისთვის. ეს არ ნიშნავს, რომ ის ყველა შემთხვევისთვის არის შესაფერისი. თუ ის არასწორად გამოიყენება, ჩვენ მივიღებთ არა შესრულების გაზრდას, არამედ მეხსიერების ამოწურვას და შესრულების შენელებას.

მოდით განვიხილოთ ამ სტრუქტურის განხორციელება. თუ გსურთ ნახოთ, ის მდებარეობს VictoriaMetrics-ის წყაროებში, საქაღალდეში lib/uint64set. ის ოპტიმიზებულია სპეციალურად VictoriaMetrics-ის შემთხვევისთვის, სადაც timeseries_id არის 64-ბიტიანი მნიშვნელობა, სადაც პირველი 32 ბიტი ძირითადად მუდმივია და მხოლოდ ბოლო 32 ბიტი იცვლება.

მონაცემთა ეს სტრუქტურა არ ინახება დისკზე, ის მუშაობს მხოლოდ მეხსიერებაში.

აქ არის მისი API. ეს არ არის ძალიან რთული. API მორგებულია კონკრეტულად VictoriaMetrics-ის გამოყენების კონკრეტულ მაგალითზე. ანუ აქ არ არის ზედმეტი ფუნქციები. აქ არის ფუნქციები, რომლებსაც აშკარად იყენებს VictoriaMetrics.

არის ფუნქციები add, რომელიც ამატებს ახალ ღირებულებებს. არის ფუნქცია has, რომელიც ამოწმებს ახალ მნიშვნელობებს. და არის ფუნქცია del, რომელიც შლის მნიშვნელობებს. არსებობს დამხმარე ფუნქცია len, რომელიც აბრუნებს ნაკრების ზომას. ფუნქცია clone კლონებს ბევრს. და ფუნქცია appendto გარდაქმნის ამ კომპლექტს ნაჭერად timeseries_ids.

ასე გამოიყურება ამ მონაცემთა სტრუქტურის განხორციელება. კომპლექტს აქვს ორი ელემენტი:

• ItemsCount არის დამხმარე ველი კომპლექტის ელემენტების რაოდენობის სწრაფად დასაბრუნებლად. ამის გაკეთება შესაძლებელი იქნებოდა ამ დამხმარე ველის გარეშე, მაგრამ ის აქ უნდა დაემატოს, რადგან VictoriaMetrics ხშირად კითხულობს ბიტების სიგრძეს თავის ალგორითმებში.

• მეორე ველი არის buckets. ეს არის ნაჭერი სტრუქტურიდან bucket32. თითოეული სტრუქტურა ინახავს hi ველი. ეს არის ზედა 32 ბიტი. და ორი ნაჭერი - b16his и buckets საქართველოს bucket16 სტრუქტურები.

აქ ინახება 16-ბიტიანი სტრუქტურის მეორე ნაწილის ზედა 64 ბიტი. და აქ ბიტები ინახება თითოეული ბაიტის ქვედა 16 ბიტისთვის.

Bucket64 შედგება მასივისაგან uint64. სიგრძე გამოითვლება ამ მუდმივების გამოყენებით. Ერთში bucket16 მაქსიმალური შენახვა შესაძლებელია 2^16=65536 ცოტა. თუ ამას 8-ზე გაყოფთ, ეს იქნება 8 კილობაიტი. თუ ისევ 8-ზე გაყოფთ, ეს იქნება 1000 uint64 მნიშვნელობა. ანუ Bucket16 - ეს არის ჩვენი 8 კილობაიტიანი სტრუქტურა.

მოდი ვნახოთ, როგორ არის დანერგილი ამ სტრუქტურის ერთ-ერთი მეთოდი ახალი მნიშვნელობის დასამატებლად.

ყველაფერი იწყება იმით uint64 მნიშვნელობები. ჩვენ ვიანგარიშებთ ზედა 32 ბიტს, ვიანგარიშებთ ქვედა 32 ბიტს. მოდი გავიაროთ ყველაფერი buckets. ჩვენ ვადარებთ თითოეულ თაიგულში ზედა 32 ბიტს დამატებულ მნიშვნელობას. და თუ ისინი ემთხვევა, მაშინ ჩვენ ვუწოდებთ ფუნქციას add სტრუქტურაში b32 buckets. და დაამატეთ ქვედა 32 ბიტი იქ. და თუ დაბრუნდა true, მაშინ ეს ნიშნავს, რომ ჩვენ დავამატეთ იქ ასეთი ღირებულება და არ გვქონდა ასეთი მნიშვნელობა. თუ დაბრუნდება false, მაშინ ასეთი მნიშვნელობა უკვე არსებობდა. შემდეგ ჩვენ გავზრდით ელემენტების რაოდენობას სტრუქტურაში.

თუ ჩვენ ვერ ვიპოვეთ თქვენთვის საჭირო bucket საჭირო hi-მნიშვნელობით, მაშინ ჩვენ ვუწოდებთ ფუნქციას addAlloc, რომელიც აწარმოებს ახალს bucket, დაამატეთ იგი თაიგულის სტრუქტურაში.

ეს არის ფუნქციის განხორციელება b32.add. წინა განხორციელების მსგავსია. ჩვენ ვიანგარიშებთ ყველაზე მნიშვნელოვან 16 ბიტს, ყველაზე ნაკლებად მნიშვნელოვან 16 ბიტს.

შემდეგ ჩვენ გავდივართ ყველა ზედა 16 ბიტს. ჩვენ ვპოულობთ მატჩებს. და თუ არის შესატყვისი, ჩვენ ვუწოდებთ დამატების მეთოდს, რომელსაც განვიხილავთ შემდეგ გვერდზე bucket16.

და აქ არის ყველაზე დაბალი დონე, რომელიც მაქსიმალურად უნდა იყოს ოპტიმიზირებული. ჩვენ ვიანგარიშებთ ამისთვის uint64 id ღირებულება slice bit-ში და ასევე bitmask. ეს არის ნიღაბი მოცემული 64-ბიტიანი მნიშვნელობისთვის, რომელიც შეიძლება გამოყენებულ იქნას ამ ბიტის არსებობის შესამოწმებლად ან მის დასაყენებლად. ჩვენ ვამოწმებთ დაყენებულია თუ არა ეს ბიტი და ვაყენებთ მას და ვაბრუნებთ ყოფნას. ეს არის ჩვენი იმპლემენტაცია, რამაც საშუალება მოგვცა 10-ჯერ დავაჩქაროთ დროის სერიების გადაკვეთის იდენტიფიკატორის მოქმედება ჩვეულებრივ რუქებთან შედარებით.

ამ ოპტიმიზაციის გარდა, VictoriaMetrics-ს აქვს მრავალი სხვა ოპტიმიზაცია. ამ ოპტიმიზაციის უმეტესობა დაემატა მიზეზის გამო, მაგრამ კოდის პროფილების შემდეგ წარმოებაში.

ეს არის ოპტიმიზაციის მთავარი წესი - ნუ დაამატებთ ოპტიმიზაციას, თუ ვივარაუდებთ, რომ აქ იქნება ბოთლი, რადგან შეიძლება აღმოჩნდეს, რომ იქ ბოთლი არ იქნება. ოპტიმიზაცია ჩვეულებრივ ამცირებს კოდის ხარისხს. აქედან გამომდინარე, ღირს ოპტიმიზაცია მხოლოდ პროფილირების შემდეგ და სასურველია წარმოებაში, რათა ეს იყოს რეალური მონაცემები. თუ ვინმეს აინტერესებს, შეგიძლიათ გადახედოთ VictoriaMetrics-ის წყაროს კოდს და შეისწავლოთ იქ არსებული სხვა ოპტიმიზაცია.

კითხვა მაქვს ბითსეტთან დაკავშირებით. ძალიან ჰგავს C++ ვექტორული ბულის იმპლემენტაციას, ოპტიმიზებული ბიტების ნაკრები. იმპლემენტაცია იქიდან აიღე?

არა, იქიდან არა. ამ ბიტების დანერგვისას მე ვხელმძღვანელობდი ამ ID-ების სერიების სტრუქტურის ცოდნით, რომლებიც გამოიყენება VictoriaMetrics-ში. და მათი სტრუქტურა ისეთია, რომ ზედა 32 ბიტი ძირითადად მუდმივია. ქვედა 32 ბიტი ექვემდებარება ცვლილებას. რაც უფრო დაბალია ბიტი, მით უფრო ხშირად შეიძლება შეიცვალოს იგი. ამიტომ, ეს განხორციელება სპეციალურად ოპტიმიზებულია ამ მონაცემთა სტრუქტურისთვის. C++ იმპლემენტაცია, რამდენადაც მე ვიცი, ოპტიმიზებულია ზოგადი შემთხვევისთვის. თუ ოპტიმიზაციას აკეთებთ ზოგადი შემთხვევისთვის, ეს ნიშნავს, რომ ის არ იქნება ყველაზე ოპტიმალური კონკრეტული შემთხვევისთვის.

ასევე გირჩევთ უყუროთ ალექსეი მილოვიდის რეპორტაჟს. დაახლოებით ერთი თვის წინ მან ისაუბრა ClickHouse-ში ოპტიმიზაციაზე კონკრეტული სპეციალიზაციებისთვის. ის უბრალოდ ამბობს, რომ ზოგად შემთხვევაში, C++ დანერგვა ან სხვა დანერგვა მორგებულია საავადმყოფოში საშუალოდ კარგად იმუშაოს. ის შეიძლება უარესად მუშაობდეს, ვიდრე ცოდნის სპეციფიკური განხორციელება, როგორიც ჩვენია, სადაც ვიცით, რომ ტოპ 32 ბიტი ძირითადად მუდმივია.

მეორე კითხვა მაქვს. რა არის ფუნდამენტური განსხვავება InfluxDB-სგან?

ბევრი ფუნდამენტური განსხვავებაა. შესრულებისა და მეხსიერების მოხმარების თვალსაზრისით, ტესტებში InfluxDB აჩვენებს 10-ჯერ მეტ მეხსიერების მოხმარებას მაღალი კარდინალურობის დროის სერიებისთვის, როცა ბევრი მათგანი გაქვთ, მაგალითად, მილიონები. მაგალითად, VictoriaMetrics მოიხმარს 1 გბაიტს მილიონ აქტიურ მწკრივზე, ხოლო InfluxDB მოიხმარს 10 გბ-ს. და ეს დიდი განსხვავებაა.

მეორე ფუნდამენტური განსხვავება ისაა, რომ InfluxDB-ს აქვს უცნაური შეკითხვის ენები - Flux და InfluxQL. ისინი არ არიან ძალიან მოსახერხებელი დროის სერიებთან შედარებით PromQL, რომელსაც მხარს უჭერს VictoriaMetrics. PromQL არის პრომეთეს შეკითხვის ენა.

და კიდევ ერთი განსხვავება ისაა, რომ InfluxDB-ს აქვს ოდნავ უცნაური მონაცემთა მოდელი, სადაც თითოეულ ხაზს შეუძლია შეინახოს რამდენიმე ველი სხვადასხვა ტეგებით. ეს ხაზები შემდგომში იყოფა სხვადასხვა ცხრილებად. ეს დამატებითი გართულებები ართულებს ამ მონაცემთა ბაზასთან შემდგომ მუშაობას. ძნელია მხარდაჭერა და გაგება.

VictoriaMetrics-ში ყველაფერი გაცილებით მარტივია. იქ ყოველი დროის სერია არის გასაღები-მნიშვნელობა. ღირებულება არის ქულების ნაკრები - (timestamp, value), და გასაღები არის კომპლექტი label=value. არ არსებობს გამიჯვნა ველებსა და გაზომვებს შორის. ის საშუალებას გაძლევთ აირჩიოთ ნებისმიერი მონაცემი და შემდეგ დააკავშიროთ, დაამატოთ, გამოკლოთ, გაამრავლოთ, გაყოთ, განსხვავებით InfluxDB-ისგან, სადაც სხვადასხვა სტრიქონებს შორის გამოთვლები ჯერ კიდევ არ არის განხორციელებული, რამდენადაც მე ვიცი. რომც განხორციელდეს, ძნელია, ბევრი კოდი უნდა დაწერო.

დამაზუსტებელი კითხვა მაქვს. სწორად გავიგე, რომ იყო რაღაც პრობლემა, რაზეც თქვენ ისაუბრეთ, რომ ეს ინვერსიული ინდექსი არ ჯდება მეხსიერებაში, ამიტომ იქ არის დაყოფა?

პირველ რიგში, მე ვაჩვენე ინვერსიული ინდექსის გულუბრყვილო განხორციელება სტანდარტულ Go რუკაზე. ეს განხორციელება არ არის შესაფერისი მონაცემთა ბაზებისთვის, რადგან ეს ინვერსიული ინდექსი არ არის შენახული დისკზე და მონაცემთა ბაზა უნდა შეინახოს დისკზე ისე, რომ ეს მონაცემები ხელმისაწვდომი დარჩეს გადატვირთვისას. ამ განხორციელებაში, როდესაც თქვენ გადატვირთავთ აპლიკაციას, თქვენი ინვერსიული ინდექსი გაქრება. და თქვენ დაკარგავთ წვდომას ყველა მონაცემზე, რადგან ვერ იპოვით მათ.

გამარჯობა! გმადლობთ ანგარიშისთვის! მე მქვია პაველი. მე ვარ Wildberries-დან. რამდენიმე კითხვა მაქვს თქვენთან. კითხვა პირველი. როგორ ფიქრობთ, რომ თქვენი აპლიკაციის არქიტექტურის შექმნისას განსხვავებული პრინციპი რომ აირჩიო და დროთა განმავლობაში დანაწილებულიყავი მონაცემები, მაშინ იქნებ შეგეძლოთ მონაცემების გადაკვეთა ძიებისას, მხოლოდ იმის საფუძველზე, რომ ერთი დანაყოფი შეიცავს მონაცემებს ერთისთვის. დროის მონაკვეთი, ანუ ერთი დროის ინტერვალით და არ მოგიწევთ ფიქრი იმაზე, რომ თქვენი ნაჭრები განსხვავებულად არის მიმოფანტული? კითხვა ნომერი 2 - რადგან თქვენ ახორციელებთ მსგავს ალგორითმს ბიტ-სეტებით და სხვა ყველაფრით, მაშინ იქნებ სცადეთ პროცესორის ინსტრუქციების გამოყენება? იქნებ სცადეთ ასეთი ოპტიმიზაცია?

მეორეზეც მაშინვე გიპასუხებ. ჩვენ ჯერ არ მივსულვართ ამ პუნქტამდე. მაგრამ თუ საჭირო იქნება, ჩვენ იქ მივალთ. და პირველი, რა კითხვა იყო?

თქვენ განიხილეთ ორი სცენარი. და მათ თქვეს, რომ აირჩიეს მეორე უფრო რთული განხორციელებით. და მათ არ ამჯობინეს პირველი, სადაც მონაცემები იყოფა დროის მიხედვით.

დიახ. პირველ შემთხვევაში, ინდექსის მთლიანი მოცულობა უფრო დიდი იქნებოდა, რადგან თითოეულ დანაყოფში ჩვენ უნდა შევინახოთ დუბლიკატი მონაცემები იმ დროის სერიებისთვის, რომლებიც გაგრძელდება ყველა ამ დანაყოფზე. და თუ თქვენი დროის სერიების ჩაქრობის სიხშირე მცირეა, ანუ მუდმივად გამოიყენება იგივე სერიები, მაშინ პირველ შემთხვევაში ჩვენ ბევრად მეტს დავკარგავთ დისკზე დაკავებულ სივრცეში მეორე შემთხვევაში.

და ასე - დიახ, დროის დაყოფა კარგი ვარიანტია. პრომეთე იყენებს მას. მაგრამ პრომეთეს კიდევ ერთი ნაკლი აქვს. მონაცემთა ამ ნაწილების შერწყმისას, მან უნდა შეინახოს მეხსიერებაში მეტა ინფორმაცია ყველა ლეიბლისა და დროის სერიებისთვის. ამიტომ, თუ მონაცემთა ნაწილი, რომელსაც ის აერთიანებს, დიდია, მაშინ მეხსიერების მოხმარება ძალიან იზრდება გაერთიანების დროს, განსხვავებით VictoriaMetrics-ისგან. შერწყმისას VictoriaMetrics საერთოდ არ მოიხმარს მეხსიერებას; იხარჯება მხოლოდ რამდენიმე კილობაიტი, მიუხედავად მონაცემთა გაერთიანებული ნაწილების ზომისა.

ალგორითმი, რომელსაც იყენებთ, იყენებს მეხსიერებას. ის აღნიშნავს დროის სერიის ტეგებს, რომლებიც შეიცავს მნიშვნელობებს. და ამ გზით თქვენ შეამოწმებთ დაწყვილებულ ყოფნას მონაცემთა ერთ მასივში და მეორეში. და გესმით, მოხდა თუ არა გადაკვეთა. როგორც წესი, მონაცემთა ბაზები ახორციელებენ კურსორებსა და იტერატორებს, რომლებიც ინახავს მათ მიმდინარე შინაარსს და გადის დახარისხებულ მონაცემებს ამ ოპერაციების მარტივი სირთულის გამო.

რატომ არ ვიყენებთ კურსორებს მონაცემების გადასასვლელად?

დიახ.

ჩვენ ვინახავთ დახარისხებულ რიგებს LevelDB-ში ან mergeset-ში. ჩვენ შეგვიძლია გადავიტანოთ კურსორი და ვიპოვოთ კვეთა. რატომ არ ვიყენებთ მას? იმიტომ რომ ნელია. რადგან კურსორები ნიშნავს, რომ თქვენ უნდა გამოიძახოთ ფუნქცია თითოეული ხაზისთვის. ფუნქციის გამოძახება არის 5 ნანოწამი. და თუ თქვენ გაქვთ 100 ხაზი, მაშინ გამოდის, რომ ჩვენ ვხარჯავთ ნახევარ წამს მხოლოდ ფუნქციის გამოძახებით.

არის ასეთი რამ, კი. და ჩემი ბოლო კითხვა. კითხვა შეიძლება ცოტა უცნაურად ჟღერდეს. რატომ არ არის შესაძლებელი მონაცემების ჩამოსვლის მომენტში ყველა საჭირო აგრეგატის წაკითხვა და საჭირო ფორმით შენახვა? რატომ უნდა შეინახოთ უზარმაზარი მოცულობები ზოგიერთ სისტემაში, როგორიცაა VictoriaMetrics, ClickHouse და ა.შ. და შემდეგ დახარჯოთ დიდი დრო მათზე?

მაგალითს მოვიყვან უფრო გასაგებად. ვთქვათ, როგორ მუშაობს პატარა სათამაშო სპიდომეტრი? ის აღრიცხავს თქვენ მიერ განვლილ მანძილს, მუდმივად უმატებს მას ერთ მნიშვნელობას, ხოლო მეორე - დროს. და ყოფს. და იღებს საშუალო სიჩქარეს. თქვენ შეგიძლიათ გააკეთოთ დაახლოებით იგივე. დაამატეთ ყველა საჭირო ფაქტი ფრენის დროს.

კარგი, მესმის კითხვა. შენს მაგალითს თავისი ადგილი აქვს. თუ იცით რა აგრეგატები გჭირდებათ, მაშინ ეს საუკეთესო განხორციელებაა. მაგრამ პრობლემა ის არის, რომ ხალხი ინახავს ამ მეტრიკას, ზოგიერთ მონაცემს ClickHouse-ში და მათ ჯერ არ იციან, როგორ შეაგროვებენ და გაფილტრავენ მათ მომავალში, ამიტომ მათ უნდა შეინახონ ყველა ნედლი მონაცემი. მაგრამ თუ იცით, რომ რაღაცის გამოთვლა გჭირდებათ საშუალოდ, მაშინ რატომ არ გამოთვალოთ ის, ნაცვლად იმისა, რომ იქ შეინახოთ ნედლეული მნიშვნელობები? მაგრამ ეს მხოლოდ იმ შემთხვევაშია, თუ ზუსტად იცით რა გჭირდებათ.

სხვათა შორის, მონაცემთა ბაზები დროის სერიების შესანახად მხარს უჭერს აგრეგატების დათვლას. მაგალითად, პრომეთე მხარს უჭერს ჩაწერის წესები. ანუ, ეს შეიძლება გაკეთდეს, თუ იცით, რა ერთეული დაგჭირდებათ. VictoriaMetrics-ს ეს ჯერ არ აქვს, მაგრამ მას ჩვეულებრივ წინ უძღვის პრომეთე, რომელშიც ეს შეიძლება გაკეთდეს გადაკოდირების წესებში.

მაგალითად, წინა სამუშაოში, საჭირო იყო ბოლო საათის განმავლობაში მოცურების ფანჯარაში მოვლენების რაოდენობის დათვლა. პრობლემა ისაა, რომ Go-ში მომიწია პერსონალური იმპლემენტაციის შექმნა, ანუ სერვისი ამ ნივთის დასათვლელად. ეს სერვისი საბოლოოდ არა ტრივიალური იყო, რადგან ძნელია გამოთვლა. განხორციელება შეიძლება იყოს მარტივი, თუ საჭიროა გარკვეული აგრეგატების დათვლა ფიქსირებული დროის ინტერვალებით. თუ გსურთ მოვლენების დათვლა მოცურების ფანჯარაში, მაშინ ეს არც ისე მარტივია, როგორც ჩანს. ვფიქრობ, ეს ჯერ არ არის დანერგილი ClickHouse-ში ან Timeseries მონაცემთა ბაზებში, რადგან ძნელია განხორციელება.

და კიდევ ერთი კითხვა. ჩვენ მხოლოდ საშუალოზე ვსაუბრობდით და გამახსენდა, რომ ოდესღაც არსებობდა ისეთი რამ, როგორიცაა გრაფიტი კარბონის ფონით. და მან იცოდა ძველი მონაცემების გათხელება, ანუ ერთი ქულის დატოვება წუთში, ერთი ქულა საათში და ა.შ. პრინციპში, ეს საკმაოდ მოსახერხებელია, თუ ჩვენ გვჭირდება ნედლეული მონაცემები, შედარებით რომ ვთქვათ, ერთი თვის განმავლობაში და სხვა ყველაფერი შეიძლება. იყოს გათხელებული. მაგრამ Prometheus და VictoriaMetrics არ უჭერენ მხარს ამ ფუნქციას. იგეგმება თუ არა მისი მხარდაჭერა? თუ არა, რატომაც არა?

მადლობა შეკითხვისთვის. ჩვენი მომხმარებლები ამ კითხვას პერიოდულად სვამენ. ისინი გვეკითხებიან, როდის დავამატებთ მხარდაჭერას შემცირებისთვის. აქ რამდენიმე პრობლემაა. პირველ რიგში, ყველა მომხმარებელს ესმის downsampling რაღაც განსხვავებული: ვინმეს სურს მიიღოს რაიმე თვითნებური წერტილი მოცემულ ინტერვალზე, ვიღაცას სურს მაქსიმალური, მინიმალური, საშუალო მნიშვნელობები. თუ ბევრი სისტემა წერს მონაცემებს თქვენს მონაცემთა ბაზაში, მაშინ ვერ შეძლებთ ამ ყველაფრის ერთობლიობას. შესაძლოა, თითოეულ სისტემას განსხვავებული გათხელება სჭირდება. და ამის განხორციელება რთულია.

და მეორე ის არის, რომ VictoriaMetrics, ისევე როგორც ClickHouse, ოპტიმიზირებულია დიდი რაოდენობით ნედლეულ მონაცემებზე მუშაობისთვის, ასე რომ, მას შეუძლია მილიარდი ხაზის ამოღება წამზე ნაკლებ დროში, თუ თქვენს სისტემაში ბევრი ბირთვი გაქვთ. დროის სერიის წერტილების სკანირება VictoriaMetrics-ში – 50 ქულა წამში თითო ბირთვზე. და ეს შესრულება ვრცელდება არსებულ ბირთვებზე. ანუ, თუ თქვენ გაქვთ, მაგალითად, 000 ბირთვი, თქვენ დაასკანირებთ მილიარდ ქულას წამში. და VictoriaMetrics-ისა და ClickHouse-ის ეს თვისება ამცირებს შემცირების საჭიროებას.

კიდევ ერთი თვისება ის არის, რომ VictoriaMetrics ეფექტურად აკუმშავს ამ მონაცემებს. შეკუმშვა საშუალოდ წარმოებაში არის 0,4-დან 0,8 ბაიტამდე პუნქტში. თითოეული წერტილი არის დროის ანაბეჭდი + მნიშვნელობა. და ის შეკუმშულია საშუალოდ ერთ ბაიტზე ნაკლებზე.

სერგეი. Მე მაქვს შეკითხვა. რა არის მინიმალური ჩაწერის დრო კვანტური?

ერთი მილიწამი. ჩვენ ახლახან გვქონდა საუბარი სხვა დროის სერიების მონაცემთა ბაზის დეველოპერებთან. მათი მინიმალური დროის მონაკვეთი არის ერთი წამი. და გრაფიტში, მაგალითად, ის ასევე ერთი წამია. OpenTSDB-ში ის ასევე ერთი წამია. InfluxDB-ს აქვს ნანოწამის სიზუსტე. VictoriaMetrics-ში ეს არის ერთი მილიწამი, რადგან პრომეთეში ერთი მილიწამია. და VictoriaMetrics თავდაპირველად შეიქმნა როგორც პრომეთეს დისტანციური საცავი. მაგრამ ახლა მას შეუძლია შეინახოს მონაცემები სხვა სისტემებიდან.

ადამიანი, ვისაც ვესაუბრე, ამბობს, რომ მათ აქვთ წამის წამში სიზუსტე - ეს მათთვის საკმარისია, რადგან ეს დამოკიდებულია მონაცემთა ტიპზე, რომელიც ინახება დროის სერიების მონაცემთა ბაზაში. თუ ეს არის DevOps მონაცემები ან მონაცემები ინფრასტრუქტურიდან, სადაც აგროვებთ 30 წამის ინტერვალით, წუთში, მაშინ წამის სიზუსტე საკმარისია, ნაკლები არაფერი გჭირდებათ. და თუ ამ მონაცემებს აგროვებთ მაღალი სიხშირის სავაჭრო სისტემებიდან, მაშინ გჭირდებათ ნანოწამის სიზუსტე.

მილიწამის სიზუსტე VictoriaMetrics-ში ასევე შესაფერისია DevOps-ის შემთხვევისთვის და შეიძლება იყოს შესაფერისი იმ შემთხვევების უმეტესობისთვის, რომლებიც მე აღვნიშნე მოხსენების დასაწყისში. ერთადერთი, რისთვისაც ის შეიძლება არ იყოს შესაფერისი, არის მაღალი სიხშირის სავაჭრო სისტემები.

Გმადლობთ! და კიდევ ერთი კითხვა. რა არის თავსებადობა PromQL-ში?

სრული უკან თავსებადობა. VictoriaMetrics სრულად უჭერს მხარს PromQL-ს. გარდა ამისა, ის ამატებს დამატებით გაფართოებულ ფუნქციონირებას PromQL-ში, რომელსაც ე.წ MetricsQL. YouTube-ზე არის საუბარი ამ გაფართოებულ ფუნქციონირებაზე. მე ვესაუბრე გაზაფხულზე სანქტ-პეტერბურგში გამართულ მონიტორინგის შეხვედრაზე.

დეპეშა არხი VictoriaMetrics.

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

რა გიშლის ხელს VictoriaMetrics-ზე, როგორც პრომეთეს გრძელვადიან საცავზე გადასვლაში? (დაწერეთ კომენტარებში, დავამატებ გამოკითხვას))

• 71,4%მე არ ვიყენებ Prometheus5-ს

• 28,6%არ ვიცოდი VictoriaMetrics2-ის შესახებ

მისცა ხმა 7 მომხმარებელმა. 12-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com