ინდექსების ჯანმრთელობა PostgreSQL-ში Java დეველოპერის თვალით

მისალოცი.

მე მქვია ვანია და ვარ ჯავის დეველოპერი. ხდება ისე, რომ PostgreSQL-თან ბევრს ვმუშაობ - მონაცემთა ბაზის დაყენება, სტრუქტურის ოპტიმიზაცია, შესრულება და პატარა DBA-ს დაკვრა შაბათ-კვირას.

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

პასუხისმგებლობის შეზღუდვის განაცხადი

PostgreSQL-ის ძირითადი ვერსია, რომლითაც მე ვმუშაობ არის 10. ყველა SQL მოთხოვნა, რომელსაც მე ვიყენებ, ასევე გამოცდილია 11 ვერსიაზე. მინიმალური მხარდაჭერილი ვერსიაა 9.6.

წინაისტორია

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

პრობლემა პირველი - ნაგულისხმევი კონფიგურაცია

ალბათ ყველას საკმაოდ მობეზრდა მეტაფორა Postgres-ის შესახებ, რომლის გაშვებაც შესაძლებელია ყავის მადუღარაზე, მაგრამ... ნაგულისხმევი კონფიგურაცია ნამდვილად აჩენს უამრავ კითხვას. მინიმუმ, ღირს ყურადღების მიქცევა maintenance_work_mem, temp_file_limit, განცხადება_დროიმი и lock_timeout.

ჩვენს შემთხვევაში maintenance_work_mem იყო ნაგულისხმევი 64 მბ და temp_file_limit დაახლოებით 2 GB - ჩვენ უბრალოდ არ გვქონდა საკმარისი მეხსიერება დიდ მაგიდაზე ინდექსის შესაქმნელად.

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

პრობლემა მეორე - ინდექსების დუბლიკატი

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

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

ამოცანა მესამე - ინდექსების გადაკვეთა

დამწყები დეველოპერების უმეტესობა ქმნის ინდექსებს ერთ სვეტზე. თანდათანობით, ამ ბიზნესის საფუძვლიანად გასინჯვის შემდეგ, ადამიანები იწყებენ თავიანთი მოთხოვნების ოპტიმიზაციას და უფრო რთულ ინდექსების დამატებას, რომლებიც მოიცავს რამდენიმე სვეტს. ასე ჩნდება ინდექსები სვეტებზე A, A + B, A+B+C და ასე შემდეგ. ამ ინდექსებიდან პირველი ორი უსაფრთხოდ შეიძლება ამოღებულ იქნეს, რადგან ისინი მესამეს პრეფიქსებია. ეს ასევე დაზოგავს დიდ ადგილს დისკზე და ამისთვის არსებობს დიაგნოსტიკა გადაკვეთილი_ინდექსები.

პრობლემა მეოთხე - უცხოური გასაღებები ინდექსების გარეშე

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

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

delete from <table> where id in (…)

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

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

ამოცანა მეხუთე – ნულოვანი მნიშვნელობა ინდექსებში

ნაგულისხმევად, Postgres მოიცავს null მნიშვნელობებს btree ინდექსებში, მაგრამ ისინი ჩვეულებრივ არ არის საჭირო იქ. ამიტომ, გულმოდგინედ ვცდილობ ამ ნულიდან ამოგდება (დიაგნოსტიკა ინდექსები_ნულის_მნიშვნელობებით), ნაწილობრივი ინდექსების შექმნა ნულირებად სვეტებზე ტიპის მიხედვით where <A> is not null. ამ გზით მე შევძელი ჩვენი ერთ-ერთი ინდექსის ზომის შემცირება 1877 მბ-დან 16 კბ-მდე. და ერთ-ერთ სერვისში, მონაცემთა ბაზის ზომა შემცირდა მთლიანობაში 16% -ით (4.3 გბ-ით აბსოლუტურ რიცხვებში) ინდექსებიდან ნულოვანი მნიშვნელობების გამორიცხვის გამო. უზარმაზარი დანაზოგი დისკზე ძალიან მარტივი ცვლილებებით. 🙂

პრობლემა მეექვსე – პირველადი გასაღებების ნაკლებობა

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

ერთ დღეს, ერთმა მშვენიერმა მიგრაციამ აიღო და განაახლა ყველა ჩანაწერი დიდ და აქტიურად გამოყენებულ ცხრილში. ჩვენ მივიღეთ +100 გბაიტი მაგიდის ზომაზე ლურჯად. სირცხვილი იყო, მაგრამ ჩვენი უბედურება ამით არ დასრულებულა. მას შემდეგ, რაც ამ მაგიდაზე ავტოვაკუუმი დასრულდა 15 საათის შემდეგ, გაირკვა, რომ ფიზიკური მდებარეობა არ დაბრუნდებოდა. ჩვენ ვერ შევძელით სერვისის შეჩერება და VACUUM FULL, ამიტომ გადავწყვიტეთ გამოგვეყენებინა pg_repack. და შემდეგ აღმოჩნდა, რომ pg_repack არ იცის ცხრილების დამუშავება პირველადი გასაღების ან სხვა უნიკალურობის შეზღუდვის გარეშე და ჩვენს ცხრილს არ ჰქონდა პირველადი გასაღები. ასე დაიბადა დიაგნოსტიკა ცხრილები_ძირითადი_გასაღების გარეშე.

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

ამოცანები მეშვიდე და მერვე - არასაკმარისი ინდექსები და გამოუყენებელი ინდექსები

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

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

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

როგორც დასკვნა

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

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

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

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

წყარო: www.habr.com