მაღალი შესრულება და მშობლიური დანაყოფი: Zabbix TimescaleDB მხარდაჭერით

Zabbix არის მონიტორინგის სისტემა. ნებისმიერი სხვა სისტემის მსგავსად, მას აწყდება ყველა მონიტორინგის სისტემის სამი ძირითადი პრობლემა: მონაცემთა შეგროვება და დამუშავება, ისტორიის შენახვა და მისი გაწმენდა.

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

Zabbix-ში შეგროვებისა და შენახვის დროს შეფერხებების პრობლემები მოგვარებულია ქეშირებით: რამდენიმე ტიპის ქეში, ქეშირება მონაცემთა ბაზაში. მესამე პრობლემის გადასაჭრელად, ქეშირება არ არის შესაფერისი, ამიტომ Zabbix-მა გამოიყენა TimescaleDB. ის გეტყვის ამის შესახებ ანდრეი გუშჩინი - ტექნიკური დახმარების ინჟინერი Zabbix SIA. ანდრეი მხარს უჭერს Zabbix-ს 6 წელზე მეტი ხნის განმავლობაში და აქვს უშუალო გამოცდილება შესრულებაში.

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

პროდუქტიულობის გამოწვევები

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

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

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

ისტორიის გასუფთავება. ზოგჯერ დგება დღე, როდესაც არ გჭირდებათ მეტრიკის შენახვა. რატომ გჭირდებათ მონაცემები, რომლებიც შეგროვდა 5 წლის წინ, ერთი ან ორი თვის წინ: ზოგიერთი კვანძი წაშლილია, ზოგიერთი ჰოსტი ან მეტრიკა აღარ არის საჭირო, რადგან ისინი მოძველებულია და აღარ არის შეგროვებული. კარგი მონიტორინგის სისტემამ უნდა შეინახოს ისტორიული მონაცემები და დროდადრო წაშალოს, რომ მონაცემთა ბაზა არ გაიზარდოს.

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

ქეშირება Zabbix-ში

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

თავად Zabbix სერვერის მხარეს ქეშირება არის:

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache.

განვიხილოთ ისინი უფრო დეტალურად.

ConfigurationCache

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

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

მონაცემთა შეგროვება

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

კოლექციონერები გამოკვეთილია ნარინჯისფერში.

Zabbix-მა გამოთვალა აგრეგაციის ელემენტები, რომლებიც საჭიროა ჩეკების გაერთიანებისთვის. თუ ჩვენ გვაქვს ისინი, ჩვენ ვიღებთ მათ მონაცემებს პირდაპირ ValueCache-დან.

ისტორიის ქეშის წინასწარი დამუშავება

ყველა კოლექციონერი იყენებს ConfigurationCache-ს სამუშაოების მისაღებად. შემდეგ ისინი გადააქვთ PreProcessing-ზე.

PreProcessing იყენებს ConfigurationCache-ს წინასწარი დამუშავების ნაბიჯების მისაღებად. ის ამუშავებს ამ მონაცემებს სხვადასხვა გზით.

მონაცემთა PreProcessing-ის გამოყენებით დამუშავების შემდეგ, ჩვენ ვინახავთ მას HistoryCache-ში დასამუშავებლად. ამით სრულდება მონაცემთა შეგროვება და ჩვენ გადავდივართ Zabbix-ის მთავარ პროცესზე - ისტორიის სინქრონერი, ვინაიდან ეს არის მონოლითური არქიტექტურა.

შენიშვნა: წინასწარი დამუშავება საკმაოდ რთული ოპერაციაა. V 4.2-დან ის გადატანილია პროქსიში. თუ თქვენ გაქვთ ძალიან დიდი Zabbix მონაცემთა ელემენტების დიდი რაოდენობით და შეგროვების სიხშირით, მაშინ ეს ბევრად აადვილებს მუშაობას.

ValueCache, ისტორიისა და ტენდენციების ქეში

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

History syncer იღებს მნიშვნელობებს HistoryCache-დან და ამოწმებს კონფიგურაციას გამოთვლებისთვის ტრიგერების არსებობისთვის. თუ ისინი არსებობენ, ის ითვლის.

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

History syncer წერს ყველა მონაცემს მონაცემთა ბაზაში და წერს დისკზე. დამუშავების პროცესი აქ მთავრდება.

ქეშირება მონაცემთა ბაზაში

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

• Innodb_buffer_pool MySQL მხარეს;
• shared_buffers PostgreSQL მხარეს;
• effective_cache_size Oracle-ის მხარეს;
• shared_pool DB2 მხარეს.

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

მონაცემთა ბაზის შესრულება კრიტიკულია

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

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

Housekeeper

მესამე შესრულების გამოწვევა Zabbix-ში არის ისტორიის გასუფთავება Housekeeper-ის გამოყენებით. ის მიჰყვება ყველა პარამეტრს - მონაცემთა ელემენტები მიუთითებს რამდენ ხანს შეინახება ცვლილებების (ტენდენციების) დინამიკა დღეებში.

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

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

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

როდის უნდა გამორთოთ Housekeeper? მაგალითად, არის „საგნის ID“ და თქვენ უნდა წაშალოთ ბოლო 5 ათასი მწკრივი გარკვეული დროის განმავლობაში. რა თქმა უნდა, ეს ხდება ინდექსით. მაგრამ ჩვეულებრივ მონაცემთა ნაკრები ძალიან დიდია და მონაცემთა ბაზა მაინც კითხულობს დისკიდან და ათავსებს მას ქეშში. ეს ყოველთვის ძალიან ძვირი ოპერაციაა მონაცემთა ბაზისთვის და, ბაზის ზომის მიხედვით, შეიძლება გამოიწვიოს მუშაობის პრობლემები.

დიასახლისის გამორთვა ადვილია. ვებ ინტერფეისში არის პარამეტრი "Administration General" Housekeeper-ისთვის. ჩვენ გამორთეთ შიდა Housekeeping შიდა ტენდენციების ისტორიისთვის და ის აღარ მართავს მას.

Housekeeper გამორთული იყო, გრაფიკები გაათანაბრა - რა პრობლემები შეიძლება იყოს ამ შემთხვევაში და რა დაეხმარებოდა მესამე შესრულების გამოწვევას?

დაყოფა - დაყოფა ან დაყოფა

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

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

მნიშვნელობები შეიძლება შეიცვალოს, თუ "კონფიგურაცია" ძალიან დიდია. თუ პატარა "კონფიგურაცია" არის 5 nvps-მდე (ახალი მნიშვნელობები წამში), საშუალო არის 000-დან 5-მდე, მაშინ დიდი არის 000 nvps-ზე მეტი. ეს არის დიდი და ძალიან დიდი ინსტალაციები, რომლებიც საჭიროებენ მონაცემთა ბაზის ფრთხილად კონფიგურაციას.

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

რას იძლევა დაყოფა?

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

სწრაფი მოცილება - DELETE. არჩეულია ერთი ფაილი/ქვეცხრილი, ვიდრე სტრიქონების შერჩევა წაშლისთვის.

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

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

TimescaleDB

V 4.2-ისთვის ჩვენ ყურადღება მივაქციეთ TimescaleDB-ს. ეს არის PostgreSQL-ის გაფართოება მშობლიური ინტერფეისით. გაფართოება ეფექტურად მუშაობს დროის სერიების მონაცემებთან, რელაციური მონაცემთა ბაზების უპირატესობების დაკარგვის გარეშე. TimescaleDB ასევე დაყოფს ავტომატურად.

TimescaleDB-ს აქვს კონცეფცია ჰიპერტაბლეტი (ჰიპერტაბლი), რომელსაც თქვენ ქმნით. Შეიცავს ნაჭრები - ტიხრები. ბლოკები არის ავტომატურად მართული ჰიპერტაბლეტური ფრაგმენტები, რომლებიც გავლენას არ ახდენენ სხვა ფრაგმენტებზე. თითოეულ ნაწილს აქვს თავისი დროის დიაპაზონი.

TimescaleDB vs PostgreSQL

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

200 მილიონი მწკრივის შემდეგ, PostgreSQL ჩვეულებრივ იწყებს მნიშვნელოვნად იკლებს და კარგავს შესრულებას 0-მდე. TimescaleDB საშუალებას გაძლევთ ეფექტურად ჩადოთ „ჩანართები“ ნებისმიერი რაოდენობის მონაცემისთვის.

დაყენების

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

Zabbix მონაცემთა ბაზისთვის ჩვენ უბრალოდ ვააქტიურებთ გაფართოებას:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

შენ ააქტიურებ extension და შექმენით იგი Zabbix მონაცემთა ბაზისთვის. ბოლო ნაბიჯი არის ჰიპერმაგიდის შექმნა.

ისტორიის ცხრილების მიგრაცია TimescaleDB-ში

ამისათვის არის სპეციალური ფუნქცია create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

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

მესამე პარამეტრი - migrate_data. თუ დააყენე true, შემდეგ ყველა მიმდინარე მონაცემი გადადის წინასწარ შექმნილ ნაწილებზე. მე თვითონ გამოვიყენე migrate_data. მე მქონდა დაახლოებით 1 ტუბერკულოზი, რომელსაც ერთ საათზე მეტი დრო დასჭირდა. ზოგიერთ შემთხვევაშიც კი, ტესტირების დროს, მე წავშალე პერსონაჟების ტიპების ისტორიული მონაცემები, რომლებიც არ იყო საჭირო შესანახად, რათა არ გადამეტანა.

ბოლო ნაბიჯი - UPDATE: ინ db_extension დადება timescaledbრათა მონაცემთა ბაზამ გაიგოს, რომ ეს გაფართოება არსებობს. Zabbix ააქტიურებს მას და სწორად იყენებს სინტაქსს და შეკითხვებს მონაცემთა ბაზაში - იმ ფუნქციებს, რომლებიც აუცილებელია TimescaleDB-სთვის.

აპარატურის კონფიგურაცია

გამოვიყენე ორი სერვერი. Პირველი - VMware მანქანა. ის საკმაოდ მცირეა: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz პროცესორი, 16 GB ოპერატიული მეხსიერება და 200 GB SSD.

მე დავაინსტალირე PostgreSQL 10.8 მასზე Debian 10.8-1.pgdg90+1 OS და xfs ფაილური სისტემით. მე მინიმალურად დავაყენე ყველაფერი ამ კონკრეტული მონაცემთა ბაზის გამოსაყენებლად, გამოკლებული რასაც თავად Zabbix გამოიყენებს.

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

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

მონაცემთა ელემენტის განახლების ინტერვალი − 4-7 წამში. მე თვითონ დავარეგულირე დატვირთვა არა მხოლოდ 50 აგენტის გამოყენებით, არამედ მეტის დამატებით. ასევე, მონაცემთა ელემენტების გამოყენებით, დინამიურად დავარეგულირე დატვირთვა და შევამცირე განახლების ინტერვალი 4 წმ-მდე.

PostgreSQL. 35 nvps

ჩემი პირველი გაშვება ამ აპარატზე იყო სუფთა PostgreSQL - 35 ათასი მნიშვნელობა წამში. როგორც ხედავთ, მონაცემების ჩასმა წამის ნაწილს იღებს - ყველაფერი კარგი და სწრაფია. ერთადერთი ის არის, რომ 200 GB SSD დისკი სწრაფად ივსება.

ეს არის სტანდარტული Zabbix სერვერის მუშაობის დაფა.

პირველი ლურჯი გრაფიკი არის მნიშვნელობების რაოდენობა წამში. მეორე გრაფიკი მარჯვნივ არის build პროცესების ჩატვირთვა. მესამე არის შიდა build პროცესების ჩატვირთვა: history syncers და Housekeeper, რომელიც აქ საკმაოდ დიდი ხანია მუშაობს.

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

PostgreSQL. 50 nvps

შემდეგ გავზარდე დატვირთვა 50 ათას მნიშვნელობამდე წამში იმავე აპარატურაზე.

Housekeeper-დან ჩატვირთვისას 10 ათასი მნიშვნელობის ჩასმას 2-3 წამი დასჭირდა.

დიასახლისი უკვე იწყებს მუშაობაში ჩარევას.

მესამე გრაფიკი აჩვენებს, რომ ზოგადად, ტრაპერებზე და ისტორიის სინჩერებზე დატვირთვა ჯერ კიდევ 60%-ია. მეოთხე გრაფაში HistoryCache უკვე იწყებს საკმაოდ აქტიურად შევსებას Housekeeper-ის ოპერაციის დროს. ის სავსეა 20%-ით, რაც დაახლოებით 0,5 GB-ია.

PostgreSQL. 80 nvps

შემდეგ გავზარდე დატვირთვა 80 ათას მნიშვნელობამდე წამში. ეს არის დაახლოებით 400 ათასი მონაცემთა ელემენტი და 280 ათასი ტრიგერი.

ოცდაათი ისტორიის სინჩერის ჩატვირთვის ღირებულება უკვე საკმაოდ მაღალია.

მე ასევე გავზარდე სხვადასხვა პარამეტრი: ისტორიის სინკერები, ქეშები.

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

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

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

მეორე სერვერი

ავიღე სხვა სერვერი, რომელსაც უკვე ჰქონდა 48 პროცესორი და 128 GB ოპერატიული მეხსიერება. მე დავაკონკრეტე - დავაყენე ის 60 ისტორიის სინქრონზე და მივაღწიე მისაღებ შესრულებას.

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

TimescaleDB. 80 nvps

ჩემი მთავარი ამოცანაა TimescaleDB-ის შესაძლებლობების გამოცდა Zabbix დატვირთვის წინააღმდეგ. 80 ათასი მნიშვნელობა წამში ბევრია, მეტრიკის შეგროვების სიხშირე (გარდა Yandex-ისა, რა თქმა უნდა) და საკმაოდ დიდი „კონფიგურაცია“.

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

TimescaleDB გაძლევთ საშუალებას ჩაწეროთ მონაცემები თითქმის 3-ჯერ უფრო სწრაფად და გამოიყენოთ ნაკლები HistoryCache.

შესაბამისად, თქვენ მიიღებთ მონაცემებს დროულად.

TimescaleDB. 120 nvps

შემდეგ მონაცემთა ელემენტების რაოდენობა გავზარდე 500 ათასამდე. მთავარი ამოცანა იყო TimescaleDB-ის შესაძლებლობების შემოწმება - მე მივიღე გამოთვლილი მნიშვნელობა 125 ათასი მნიშვნელობის წამში.

ეს არის სამუშაო "კონფიგურაცია", რომელსაც შეუძლია დიდი ხნის განმავლობაში იმუშაოს. მაგრამ რადგან ჩემი დისკი მხოლოდ 1,5 ტბ იყო, რამდენიმე დღეში შევავსე.

ყველაზე მნიშვნელოვანი ის არის, რომ ამავე დროს შეიქმნა ახალი TimescaleDB ტიხრები.

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

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

დასკვნები

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

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

თუ იყენებთ PostgreSQL-ს და არ გეგმავთ მის შეცვლას, გირჩევთ გამოიყენეთ PostgreSQL TimescaleDB გაფართოებით Zabbix-თან ერთად. ეს გამოსავალი ეფექტურად მუშაობს საშუალო "კონფიგურაციამდე".

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

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

წყარო: www.habr.com