როგორ გამოვცადეთ მრავალი დროის სერიების მონაცემთა ბაზა

ბოლო რამდენიმე წლის განმავლობაში, დროის სერიების მონაცემთა ბაზები უჩვეულო ნივთიდან (უაღრესად სპეციალიზებული, რომელიც გამოიყენება ღია მონიტორინგის სისტემებში (და მიბმული კონკრეტულ გადაწყვეტილებებთან) ან დიდი მონაცემთა პროექტებში) გადაიქცა „სამომხმარებლო პროდუქტად“. რუსეთის ფედერაციის ტერიტორიაზე, ამისათვის განსაკუთრებული მადლობა უნდა გადაიხადოთ Yandex-სა და ClickHouse-ს. ამ მომენტამდე, თუ დაგჭირდათ დიდი რაოდენობით დროის სერიების მონაცემების შენახვა, თქვენ ან უნდა შეეგუოთ Hadoop-ის ამაზრზენი სტეკის აშენებას და მის შენარჩუნებას, ან დაუკავშირდით თითოეულ სისტემას ინდივიდუალურ პროტოკოლებს.

შეიძლება ჩანდეს, რომ 2019 წელს სტატია, რომლის შესახებაც TSDB ღირს გამოყენება, შედგება მხოლოდ ერთი წინადადებისგან: „უბრალოდ გამოიყენეთ ClickHouse“. მაგრამ... არის ნიუანსები.

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

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

პრობლემის შესახებ განცხადება

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

ჩვენ დავიწყეთ მხარდაჭერის სერვისების მიწოდება 2008 წელს და 2010 წლისთვის გაირკვა, რომ რთული გახდა მონაცემების აგრეგაცია კლიენტის ინფრასტრუქტურაში მიმდინარე პროცესების შესახებ იმ გადაწყვეტილებებით, რომლებიც იმ დროს არსებობდა (საუბარია ღმერთმა მაპატიოს, Cacti, Zabbix და წარმოქმნილი გრაფიტი).

ჩვენი ძირითადი მოთხოვნები იყო:

• კლიენტის მხარდაჭერა (იმ დროს - ათეულობით, ხოლო მომავალში - ასობით) ერთ სისტემაში და ამავე დროს ცენტრალიზებული გაფრთხილების მართვის სისტემის არსებობა;
• მოქნილობა განგაშის სისტემის მართვაში (მორიგეებს შორის გაფრთხილებების ესკალაცია, განრიგი, ცოდნის ბაზა);
• გრაფიკების ღრმად დეტალების უნარი (იმ დროს Zabbix გრაფიკებს ასახავდა სურათების სახით);
• დიდი რაოდენობით მონაცემების გრძელვადიანი შენახვა (ერთი წელი ან მეტი) და მისი სწრაფად აღდგენის შესაძლებლობა.

ამ სტატიაში ჩვენ გვაინტერესებს ბოლო წერტილი.

რაც შეეხება შენახვას, მოთხოვნები შემდეგი იყო:

• სისტემა სწრაფად უნდა მუშაობდეს;
• სასურველია, რომ სისტემას ჰქონდეს SQL ინტერფეისი;
• სისტემა უნდა იყოს სტაბილური და ჰქონდეს აქტიური მომხმარებლის ბაზა და მხარდაჭერა (ერთხელ დაგვხვდა ისეთი სისტემების მხარდაჭერის აუცილებლობა, როგორიცაა MemcacheDB, რომელიც აღარ იყო განვითარებული, ან MooseFS განაწილებული საცავი, რომლის შეცდომების ტრეკერი ინახებოდა ჩინურ ენაზე: ჩვენ ვიმეორებთ ამ ამბავს ჩვენი პროექტისთვის არ მინდოდა);
• შესაბამისობა CAP თეორემასთან: თანმიმდევრულობა (აუცილებელია) - მონაცემები უნდა იყოს განახლებული, ჩვენ არ გვინდა, რომ სიგნალიზაციის მართვის სისტემამ არ მიიღოს ახალი მონაცემები და არ გამოაქვეყნოს სიგნალები ყველა პროექტისთვის მონაცემების არ ჩამოსვლის შესახებ; გაყოფის ტოლერანტობა (აუცილებელია) - არ გვინდა მივიღოთ Split Brain სისტემა; ხელმისაწვდომობა (არ არის კრიტიკული, თუ არის აქტიური რეპლიკა) - ჩვენ შეგვიძლია თავად გადავიდეთ სარეზერვო სისტემაზე ავარიის შემთხვევაში, კოდის გამოყენებით.

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

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

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

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

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

2017 წელს, Percona Live კონფერენციაზე სან ხოსეში, Clickhouse დეველოპერებმა ალბათ პირველად გამოაცხადეს თავი. ერთი შეხედვით, სისტემა მზად იყო წარმოებისთვის (კარგად, Yandex.Metrica არის მკაცრი წარმოების სისტემა), მხარდაჭერა იყო სწრაფი და მარტივი და, რაც მთავარია, ოპერაცია მარტივი იყო. 2018 წლიდან დავიწყეთ გარდამავალი პროცესი. მაგრამ იმ დროისთვის არსებობდა უამრავი „ზრდასრული“ და დროში გამოცდილი TSDB სისტემა, და ჩვენ გადავწყვიტეთ დაგვეთმო მნიშვნელოვანი დრო და შევადაროთ ალტერნატივები, რათა დავრწმუნდეთ, რომ არ არსებობდა Clickhouse-ის ალტერნატიული გადაწყვეტილებები, ჩვენი მოთხოვნების შესაბამისად.

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

• ახალმა სისტემამ უნდა უზრუნველყოს მინიმუმ იგივე შესრულება, რაც MySQL-ს იგივე რაოდენობის აპარატურაზე;
• ახალი სისტემის შენახვა მნიშვნელოვნად ნაკლებ ადგილს უნდა დაიკავოს;
• DBMS მაინც უნდა იყოს მარტივი სამართავი;
• მინდოდა აპლიკაციის მინიმალურად შეცვლა DBMS-ის შეცვლისას.

რა სისტემების განხილვა დავიწყეთ?

Apache Hive/Apache Impala
ძველი, ბრძოლაში გამოცდილი Hadoop სტეკი. არსებითად, ეს არის SQL ინტერფეისი, რომელიც აგებულია HDFS-ზე მონაცემთა მშობლიურ ფორმატებში შესანახად.

დადებითი

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

Cons.

• ეს არის Hadoop და მისი გამოყენება რთულია. თუ ჩვენ არ ვართ მზად ღრუბელში მზა გადაწყვეტის მისაღებად (და ჩვენ არ ვართ მზად ღირებულების თვალსაზრისით), მთელი დასტა უნდა იყოს აწყობილი და მხარდაჭერილი ადმინების ხელით და ჩვენ ნამდვილად არ გვინდა ეს.
• მონაცემები აგრეგირებულია ძალიან სწრაფად.

თუმცა:

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

დრუიდი/პინო

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

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

რამდენიმე სიტყვით: დრუიდი/პინო უფრო კარგად გამოიყურება ვიდრე Clickhouse იმ შემთხვევებში, როდესაც:

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

საპირისპირო შემთხვევაში, ClickHouse უკეთესად მუშაობს და ეს არის ჩვენი შემთხვევა.

clickhouse

• SQL-ის მსგავსი
• მარტივი მართვა.
• ხალხი ამბობს, რომ მუშაობს.

შერჩეულია ტესტირებისთვის.

InfluxDB

ClickHouse-ის უცხოური ალტერნატივა. მინუსებიდან: მაღალი ხელმისაწვდომობა მხოლოდ კომერციულ ვერსიაშია, მაგრამ მისი შედარებაა საჭირო.

შერჩეულია ტესტირებისთვის.

Cassandra

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

Cassandra არ არის სვეტური მონაცემთა ბაზა ტრადიციული გაგებით. ის უფრო ჰგავს მწკრივის ხედს, მაგრამ თითოეულ ხაზს შეიძლება ჰქონდეს სვეტების განსხვავებული რაოდენობა, რაც აადვილებს სვეტოვანი ხედის ორგანიზებას. ამ თვალსაზრისით, ცხადია, რომ 2 მილიარდი სვეტის ლიმიტით, შესაძლებელია გარკვეული მონაცემების შენახვა სვეტებში (და იგივე დროის სერიებში). მაგალითად, MySQL-ში არის 4096 სვეტის ლიმიტი და ადვილია წააწყდე შეცდომას 1117 კოდით, თუ იგივეს ცდილობ.

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

პრომეთე

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

ტესტირების მეთოდოლოგია და შედეგები

ასე რომ, ჩვენ გამოვცადეთ 5 მონაცემთა ბაზა შემდეგ 6 კონფიგურაციაში: ClickHouse (1 კვანძი), ClickHouse (განაწილებული ცხრილი 3 კვანძისთვის), InfluxDB, Mysql 8, Cassandra (3 კვანძი) და Prometheus. ტესტის გეგმა ასეთია:

1. ატვირთეთ ისტორიული მონაცემები ერთი კვირის განმავლობაში (840 მილიონი მნიშვნელობა დღეში; 208 ათასი მეტრიკა);
2. ჩვენ ვქმნით ჩაწერის დატვირთვას (განხილული იყო ჩატვირთვის 6 რეჟიმი, იხილეთ ქვემოთ);
3. ჩაწერის პარალელურად, პერიოდულად ვაკეთებთ არჩევანს, ვაბაძავთ სქემებთან მომუშავე მომხმარებლის მოთხოვნებს. იმისათვის, რომ საქმე ძალიან არ გართულდეს, ჩვენ შევარჩიეთ მონაცემები 10 მეტრიკისთვის (ეს არის ზუსტად რამდენია CPU გრაფიკზე) ერთი კვირის განმავლობაში.

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

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

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

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

და აი, ამ ყველაფრის გათვალისწინებით, არის ჩვენი მონაცემთა ბაზის ჩაწერის ჩაწერის 6 რეჟიმი:

აქ არის ორი წერტილი. ჯერ ერთი, კასანდრასთვის ეს პარტიების ზომები ძალიან დიდი აღმოჩნდა, იქ გამოვიყენეთ მნიშვნელობები 50 ან 100. და მეორეც, რადგან პრომეთე მუშაობს მკაცრად წევის რეჟიმში, ე.ი. ის თავად მიდის და აგროვებს მონაცემებს მეტრიკის წყაროებიდან (და თუნდაც pushgateway, სახელის მიუხედავად, ძირეულად არ ცვლის სიტუაციას), შესაბამისი დატვირთვები განხორციელდა სტატიკური კონფიგურაციის კომბინაციის გამოყენებით.

ტესტის შედეგები ასეთია:

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

შედეგად,: ClickHouse-მა და InfluxDB-მა თავი გამოიჩინეს საუკეთესოებად, მაგრამ Influx-ის კლასტერი შეიძლება მხოლოდ Enterprise ვერსიის საფუძველზე აშენდეს, რომელიც ფული ღირს, ხოლო ClickHouse არაფერი ღირს და დამზადებულია რუსეთში. ლოგიკურია, რომ აშშ-ში არჩევანი ალბათ არის inInfluxDB-ს, ჩვენში კი ClickHouse-ის სასარგებლოდ.

წყარო: www.habr.com