HighLoad++, ანდრეი გუშჩინი (Zabbix): მაღალი ხარისხის და მშობლიური დანაყოფი

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

HighLoad++ ციმბირი 2019. Tomsk Hall. 24 ივნისს, 16:00 საათზე. თეზისები და პრეზენტაცია. შემდეგი HighLoad++ კონფერენცია გაიმართება 6 წლის 7 და 2020 აპრილს სანკტ-პეტერბურგში. დეტალები და ბილეთები по ссылке.

ანდრეი გუშჩინი (შემდგომში - AG): – მე ვარ ZABBIX ტექნიკური დახმარების ინჟინერი (შემდგომში „Zabbix“), ტრენერი. მე ვმუშაობ ტექნიკურ მხარდაჭერაში 6 წელზე მეტი ხნის განმავლობაში და მქონდა მუშაობის გამოცდილება. დღეს მე ვისაუბრებ იმ შესრულებაზე, რომელიც TimescaleDB-ს შეუძლია უზრუნველყოს ჩვეულებრივ PostgreSQL 10-თან შედარებით. ასევე, შესავალი ნაწილი იმის შესახებ, თუ როგორ მუშაობს იგი ზოგადად.

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

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

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

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

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

როგორ მოვაგვაროთ ქეშირების პრობლემები?

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

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

ასევე მონაცემთა ბაზის მხარეს არის ქეში ძირითადი შერჩევისთვის - გრაფიკებისთვის და სხვა ნივთებისთვის.

ქეშირება თავად Zabbix სერვერის მხარეს: ჩვენ გვაქვს ConfigurationCache, ValueCache, HistoryCache, TrendsCache. რა არის ეს?

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

ქეშირება Zabbix-ში. მონაცემთა შეგროვება

აქ დიაგრამა საკმაოდ დიდია:

სქემაში მთავარია ეს კოლექციონერები:

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

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

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

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

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

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

Zabbix-ში მთავარი პროცესი (რადგან ის მონოლითური არქიტექტურაა) არის History syncer. ეს არის მთავარი პროცესი, რომელიც კონკრეტულად ეხება თითოეული მონაცემთა ელემენტის ატომურ დამუშავებას, ანუ თითოეულ მნიშვნელობას:

• მნიშვნელობა მოდის (ის იღებს HistoryCache-დან);
• ამოწმებს Configuration syncer-ში: არის თუ არა რაიმე ტრიგერები გამოთვლისთვის - ითვლის მათ;
  თუ არსებობს - ქმნის მოვლენებს, ქმნის ესკალაციას განგაშის შესაქმნელად, საჭიროების შემთხვევაში, კონფიგურაციის მიხედვით;
• აღრიცხავს ტრიგერებს შემდგომი დამუშავებისთვის, აგრეგაციისთვის; თუ აგროვებთ ბოლო საათში და ასე შემდეგ, ეს მნიშვნელობა ახსოვს ValueCache-ს, რათა არ გადავიდეს ისტორიის ცხრილში; ამრიგად, ValueCache ივსება საჭირო მონაცემებით, რომლებიც აუცილებელია ტრიგერების, გამოთვლილი ელემენტების და ა.შ.
• შემდეგ History syncer ჩაწერს ყველა მონაცემს მონაცემთა ბაზაში;
• მონაცემთა ბაზა წერს მათ დისკზე - აქ მთავრდება დამუშავების პროცესი.

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

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

MySQL-სთვის არის Innodb_buffer_pool და სხვადასხვა ქეში, რომელთა კონფიგურაციაც შესაძლებელია.
მაგრამ ეს არის მთავარი:

• გაზიარებული_ბუფერები;
• ეფექტური_ქეში_ზომა;
• shared_pool.

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

მონაცემთა ბაზის მუშაობის შესახებ

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

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

ისტორიის გასუფთავება. ზაბიქსს ჰყავს დიასახლისი

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

მე არ ვსაუბრობ TrendCache-ზე, რომელსაც ჩვენ ვანგარიშობთ: მონაცემები მოდის, ვაგროვებთ მას ერთი საათის განმავლობაში (ძირითადად ეს ბოლო საათის რიცხვებია), თანხა არის საშუალო/მინიმუმი და ჩავწერთ საათში ერთხელ ცვლილებების დინამიკის ცხრილი („ტენდენციები“). „Housekeeper“ იწყებს და წაშლის მონაცემებს მონაცემთა ბაზიდან რეგულარული სელექციების გამოყენებით, რაც ყოველთვის არ არის ეფექტური.

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

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

ავიღოთ ნივთის ID: თქვენ უნდა წაშალოთ ბოლო 5 ათასი; რა თქმა უნდა, ინდექსების მიხედვით. მაგრამ, როგორც წესი, მონაცემთა ნაკრები საკმაოდ დიდია - მონაცემთა ბაზა მაინც კითხულობს მას დისკიდან და ათავსებს ქეში, და ეს არის ძალიან ძვირი ოპერაცია მონაცემთა ბაზისთვის. მისი ზომიდან გამომდინარე, ამან შეიძლება გამოიწვიოს მუშაობის გარკვეული პრობლემები.

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

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

დაყოფა (სექციები)

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

თქვენი კონფიგურაციის მიხედვით (რამდენ მონაცემს ქმნით ერთ დღეში), ისინი ჩვეულებრივ ადგენენ მინიმუმს - ეს არის 1 დღე / პარტია, ხოლო "ტენდენციებისთვის", ცვლილებების დინამიკა - 1 თვე / ახალი პარტია. ეს შეიძლება შეიცვალოს, თუ ძალიან დიდი კონფიგურაცია გაქვთ.

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

ძალიან დიდ დანადგარებზე, 1 დღე შეიძლება არ იყოს ოპტიმალური. მე პირადად მინახავს ტიხრები MySQL-ზე 40 გიგაბაიტი დღეში (და შეიძლება იყოს მეტი). ეს არის მონაცემთა ძალიან დიდი რაოდენობა, რამაც შეიძლება გამოიწვიოს გარკვეული პრობლემები. საჭიროა მისი შემცირება.

რატომ გჭირდებათ დანაყოფი?

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

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

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

Elastics ძიება NoSQL-სთვის

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

TimescaleDB. ჰიპერტაბლები

4.4.2-ისთვის ჩვენ ყურადღება მივაქციეთ ერთ რამეს, როგორიცაა TimescaleDB. რა არის ეს? ეს არის გაფართოება PostgreSQL-ისთვის, ანუ მას აქვს მშობლიური PostgreSQL ინტერფეისი. გარდა ამისა, ეს გაფართოება საშუალებას გაძლევთ ბევრად უფრო ეფექტურად იმუშაოთ დროის სერიის მონაცემებთან და გქონდეთ ავტომატური დაყოფა. როგორ გამოიყურება:

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

TimescaleDB და PostgreSQL

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

როგორ დავაყენოთ TimescaleDB? Ეს მარტივია!

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

Zabbix-ზე ჩვენ უბრალოდ ვააქტიურებთ Extention-ს. მე ვფიქრობ, რომ ვინც გამოიყენა Extention Postgres-ში... თქვენ უბრალოდ ააქტიურებთ Extention-ს, შექმნით მას Zabbix მონაცემთა ბაზისთვის, რომელსაც იყენებთ.

და ბოლო ნაბიჯი...

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

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

ველი, რომლითაც უნდა შეიქმნას, და chunk_time_interval (ეს არის ბლოკების ინტერვალი (პარტიციები, რომლებიც უნდა იქნას გამოყენებული). 86 არის ერთი დღე.

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

მე თვითონ გამოვიყენე migrate_data - ამას საკმაოდ დიდი დრო სჭირდება, იმისდა მიხედვით, თუ რამდენად დიდია თქვენი მონაცემთა ბაზა. მე მქონდა ტერაბაიტზე მეტი - მის შექმნას საათზე მეტი დასჭირდა. ზოგიერთ შემთხვევაში, ტესტირების დროს, მე წავშალე ისტორიული მონაცემები ტექსტისთვის (history_text) და სტრიქონისთვის (history_str), რათა არ გადამეტანა - ისინი ნამდვილად არ იყო ჩემთვის საინტერესო.

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

სერვერის კონფიგურაცია

გამოვიყენე ორი სერვერი. პირველი სერვერი არის საკმაოდ პატარა ვირტუალური მანქანა, 20 პროცესორი, 16 გიგაბაიტი ოპერატიული მეხსიერება. მე მასზე დავაყენე Postgres 10.8:

ოპერაციული სისტემა იყო Debian, ფაილური სისტემა იყო xfs. მე გავაკეთე მინიმალური პარამეტრები ამ კონკრეტული მონაცემთა ბაზის გამოსაყენებლად, გამოკლებული რასაც თავად Zabbix გამოიყენებს. იმავე აპარატზე იყო Zabbix სერვერი, PostgreSQL და დატვირთვის აგენტები.

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

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

შესრულების ტესტი. PostgreSQL: 36 ათასი NVP

პირველი გაშვება, პირველი დაყენება, რაც მე მქონდა, იყო სუფთა PostreSQL 10-ზე ამ აპარატურაზე (35 ათასი მნიშვნელობა წამში). ზოგადად, როგორც ეკრანზე ხედავთ, მონაცემების ჩასმა წამის ნაწილს სჭირდება - ყველაფერი კარგი და სწრაფია, SSD დისკები (200 გიგაბაიტი). ერთადერთი ის არის, რომ 20 GB საკმაოდ სწრაფად ივსება.

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

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

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

შესრულების ტესტი. PostgreSQL: 50 ათასი NVP

შემდეგი, მე გავზარდე დატვირთვა 50 ათას მნიშვნელობამდე წამში იმავე აპარატურაზე. Housekeeper-ის მიერ ჩატვირთვისას, გაანგარიშებით 10-2 წამში დაფიქსირდა 3 ათასი მნიშვნელობა. რა, ფაქტობრივად, ნაჩვენებია შემდეგ ეკრანის სურათზე:

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

შესრულების ტესტი. PostgreSQL: 80 ათასი NVP

შემდეგ გავზარდე ის 80 ათას მნიშვნელობამდე წამში:

ეს იყო დაახლოებით 400 ათასი მონაცემთა ელემენტი, 280 ათასი ტრიგერი. ჩანართი, როგორც ხედავთ, ისტორიის ნიჟარების დატვირთვის მხრივ (ისინი 30 იყო) უკვე საკმაოდ მაღალი იყო. შემდეგ გავზარდე სხვადასხვა პარამეტრი: history sinkers, cache... ამ აპარატურაზე, ისტორიის ჩაძირვის დატვირთვა დაიწყო მაქსიმუმზე მატება, თითქმის „თაროზე“ - შესაბამისად, HistoryCache შევიდა ძალიან მაღალ დატვირთვაში:

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

მე ავიღე სხვა სერვერი, რომელსაც უკვე ჰქონდა 48 პროცესორი და 128 გიგაბაიტი ოპერატიული მეხსიერება:

მე ასევე „დაამუშავა“ - დავაყენე History syncer (60 ცალი) და მივაღწიე მისაღებ შესრულებას. სინამდვილეში, ჩვენ არ ვართ "თაროზე", მაგრამ ეს არის ალბათ პროდუქტიულობის ზღვარი, სადაც უკვე საჭიროა რაიმეს გაკეთება.

შესრულების ტესტი. TimescaleDB: 80 ათასი NVP

ჩემი მთავარი ამოცანა იყო TimescaleDB-ის გამოყენება. თითოეული გრაფიკი აჩვენებს ჩაძირვას:

ეს წარუმატებლობა არის ზუსტად მონაცემთა მიგრაცია. ამის შემდეგ, Zabbix სერვერზე, ისტორიის ნიჟარების ჩატვირთვის პროფილი, როგორც ხედავთ, ძალიან შეიცვალა. ის საშუალებას გაძლევთ ჩაწეროთ მონაცემები თითქმის 3-ჯერ უფრო სწრაფად და გამოიყენოთ ნაკლები HistoryCache - შესაბამისად, თქვენ გექნებათ მონაცემები დროულად მიწოდებული. ისევ და ისევ, 80 ათასი მნიშვნელობა წამში საკმაოდ მაღალი მაჩვენებელია (რა თქმა უნდა, არა Yandex-ისთვის). საერთო ჯამში, ეს არის საკმაოდ დიდი კონფიგურაცია, ერთი სერვერით.

PostgreSQL შესრულების ტესტი: 120 ათასი NVP

შემდეგი, მე გავზარდე მონაცემთა ელემენტების რაოდენობა ნახევარ მილიონამდე და მივიღე გამოთვლილი მნიშვნელობა 125 ათასი წამში:

და მე მივიღე ეს გრაფიკები:

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

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

ასევე არის მაგალითები საზოგადოებაში:

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

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

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

აუდიტორიის კითხვები

კითხვა აუდიტორიისგან (შემდგომში - A): - თუ TimescaleDB ასე მარტივია კონფიგურაციისთვის და ის იძლევა ეფექტურობის ასეთ სტიმულს, მაშინ იქნებ ეს უნდა იქნას გამოყენებული, როგორც საუკეთესო პრაქტიკა Zabbix-ის კონფიგურაციისთვის Postgres-თან? და არის თუ არა ამ გადაწყვეტის ხარვეზები და უარყოფითი მხარეები, ან ბოლოს და ბოლოს, თუ გადავწყვიტე Zabbix-ის გაკეთება ჩემთვის, შემიძლია ადვილად ავიღო Postgres, დაუყოვნებლივ დავაყენო იქ Timescale, გამოვიყენო და არ ვიფიქრო რაიმე პრობლემაზე?

AG: – დიახ, მე ვიტყოდი, რომ ეს კარგი რეკომენდაციაა: გამოიყენეთ Postgres დაუყოვნებლივ TimescaleDB გაფართოებით. როგორც უკვე ვთქვი, ბევრი კარგი მიმოხილვაა, მიუხედავად იმისა, რომ ეს "მახასიათებელი" ექსპერიმენტულია. მაგრამ რეალურად ტესტები აჩვენებს, რომ ეს შესანიშნავი გამოსავალია (TimescaleDB-ით) და ვფიქრობ, რომ ის განვითარდება! ჩვენ ვაკვირდებით, თუ როგორ განვითარდება ეს გაფართოება და საჭიროების შემთხვევაში შევიტანთ ცვლილებებს.

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

A: – საზოგადოების ბოლო გრაფიკებზე იყო გრაფიკი „სახლის მეურნეთან“:

მან განაგრძო მუშაობა. რას აკეთებს Housekeeper TimescaleDB-თან?

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

A: – მეც მაქვს მსგავსი შეკითხვა – წაშლის ოპერაციის შესრულების შესახებ Timescale-ში.
პასუხი (პასუხი აუდიტორიისგან): – როდესაც თქვენ წაშლით მონაცემებს ცხრილიდან, თუ ამას აკეთებთ წაშლის გზით, მაშინ უნდა გაიაროთ ცხრილი - წაშალეთ, გაასუფთავეთ, მონიშნეთ ყველაფერი მომავალი ვაკუუმისთვის. Timescale-ში, რადგან თქვენ გაქვთ ნაჭრები, შეგიძლიათ ჩამოაგდოთ. უხეშად რომ ვთქვათ, თქვენ უბრალოდ ეუბნებით ფაილს, რომელიც დიდ მონაცემებშია: "წაშლა!"

Timescale უბრალოდ ესმის, რომ ასეთი ნაწილი აღარ არსებობს. და რადგან ის ინტეგრირებულია შეკითხვის დამგეგმავში, ის იყენებს კაკვებს თქვენი პირობების დასაჭერად შერჩეულ ან სხვა ოპერაციებში და მაშინვე ხვდება, რომ ეს ნაწილი აღარ არსებობს - "აღარ წავალ იქ!" (მონაცემები მიუწვდომელია). Სულ ეს არის! ანუ, ცხრილის სკანირება შეიცვალა ბინარული ფაილის წაშლით, ასე რომ, ის სწრაფია.

A: – ჩვენ უკვე შევეხეთ არა-SQL-ის თემას. რამდენადაც მე მესმის, Zabbix-ს ნამდვილად არ სჭირდება მონაცემების შეცვლა და ეს ყველაფერი არის ჟურნალის მსგავსი. შესაძლებელია თუ არა სპეციალიზებული მონაცემთა ბაზების გამოყენება, რომლებიც ვერ ცვლიან მონაცემებს, მაგრამ ამავდროულად ინახავენ, აგროვებენ და ავრცელებენ ბევრად უფრო სწრაფად - Clickhouse, მაგალითად, რაღაც კაფკას მსგავსი?.. კაფკაც არის ჟურნალი! შესაძლებელია თუ არა მათი როგორმე ინტეგრირება?

AG: - განტვირთვა შეიძლება. ჩვენ გვაქვს გარკვეული „მახასიათებელი“ 3.4 ვერსიიდან: თქვენ შეგიძლიათ ჩაწეროთ ყველა ისტორიული ფაილი, მოვლენა, ყველაფერი დანარჩენი ფაილებში; და შემდეგ გაგზავნეთ იგი ნებისმიერ სხვა მონაცემთა ბაზაში ზოგიერთი დამმუშავებლის გამოყენებით. სინამდვილეში, ბევრი ადამიანი გადაამუშავებს და წერს პირდაპირ მონაცემთა ბაზაში. ფრენისას, ისტორიის ჩაძირვები წერენ ამ ყველაფერს ფაილებში, ატრიალებენ ამ ფაილებს და ა.შ. და თქვენ შეგიძლიათ ეს გადაიტანოთ Clickhouse-ში. გეგმებზე ვერ ვიტყვი, მაგრამ შესაძლოა NoSQL გადაწყვეტილებების შემდგომი მხარდაჭერა (როგორიცაა Clickhouse) გაგრძელდეს.

A: – ზოგადად, გამოდის, რომ შეგიძლიათ მთლიანად მოიცილოთ პოსტგრესი?

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

A: – შეგიძლიათ შეაფასოთ, რამდენად სწრაფად იმუშავებს ყველაფერი, თუ მაგალითად, Clickhouse-ზე გადახვალთ?

AG: - არ გამომიცდია. მე ვფიქრობ, რომ სულ მცირე იგივე რიცხვების მიღწევა შესაძლებელია საკმაოდ მარტივად, იმის გათვალისწინებით, რომ Clickhouse–ს აქვს საკუთარი ინტერფეისი, მაგრამ დანამდვილებით ვერ ვიტყვი. ჯობია ტესტირება. ეს ყველაფერი დამოკიდებულია კონფიგურაციაზე: რამდენი ჰოსტი გაქვთ და ა.შ. ჩასმა ერთია, მაგრამ თქვენ ასევე გჭირდებათ ამ მონაცემების მოძიება - Grafana ან სხვა რამ.

A: – ანუ თანაბარ ბრძოლაზეა საუბარი და არა ამ სწრაფი მონაცემთა ბაზების დიდ უპირატესობაზე?

AG: - ვფიქრობ, როდესაც ჩვენ ინტეგრირდებით, უფრო ზუსტი ტესტები იქნება.

A: – სად წავიდა ძველი კარგი RRD? რამ აიძულა გადახვიდეთ SQL მონაცემთა ბაზებზე? თავდაპირველად, ყველა მეტრიკა შეგროვდა RRD-ზე.

AG: – Zabbix-ს ჰქონდა RRD, ალბათ ძალიან უძველესი ვერსიით. ყოველთვის იყო SQL მონაცემთა ბაზები - კლასიკური მიდგომა. კლასიკური მიდგომაა MySQL, PostgreSQL (ისინი არსებობენ ძალიან დიდი ხნის განმავლობაში). ჩვენ თითქმის არასოდეს გამოგვიყენებია საერთო ინტერფეისი SQL და RRD მონაცემთა ბაზებისთვის.

რამდენიმე რეკლამა 🙂

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com