ჩვენ ვწერთ PostgreSQL-ში ქვეშუქზე: 1 ჰოსტი, 1 დღე, 1 ტბ

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

#1. განყოფილება

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

"გასული დღეები..."

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

დრო თითქმის ეპიკურ პერიოდს ჰგავდა, PostgreSQL 9.x-ის სხვადასხვა ვერსია იყო აქტუალური, ამიტომ ყველა დანაყოფი უნდა მომხდარიყო „ხელით“ - მეშვეობით ცხრილის მემკვიდრეობა და ტრიგერები მარშრუტირება დინამიურით EXECUTE.

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

• გამოცხადდა ცარიელი „სათაურის“ მშობელი ცხრილი, რომელიც აღწერდა ყველაფერს საჭირო ინდექსები და ტრიგერები.
• კლიენტის თვალსაზრისით ჩანაწერი გაკეთდა „ძირეული“ ცხრილში და შიდა გამოყენებით მარშრუტიზაციის ტრიგერი BEFORE INSERT ჩანაწერი "ფიზიკურად" იყო ჩასმული საჭირო განყოფილებაში. ასეთი რამ ჯერ რომ არ იყო, გამონაკლისი დავიჭირეთ და...
• … გამოყენებით CREATE TABLE ... (LIKE ... INCLUDING ...) შეიქმნა მშობელი ცხრილის შაბლონის საფუძველზე განყოფილება სასურველ თარიღზე შეზღუდვითისე, რომ მონაცემების მოპოვებისას წაკითხვა მხოლოდ მასში შესრულდეს.

PG10: პირველი მცდელობა

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

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

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

• არ აქვს ინდექსის აღწერილობების მხარდაჭერა
• მასზე ტრიგერების მხარდაჭერა არ აქვს
• არ შეიძლება იყოს ვინმეს "შთამომავალი"
• არ დაუჭიროს მხარი INSERT ... ON CONFLICT
• განყოფილების ავტომატურად გენერირება შეუძლებელია

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

PG10: მეორე შანსი

ასე რომ, ჩვენ დავიწყეთ სათითაოდ წამოჭრილი პრობლემების მოგვარება:

1. რადგან იწვევს და ON CONFLICT აღმოვაჩინეთ, რომ ისინი ჯერ კიდევ გვჭირდებოდა აქეთ-იქით, ამიტომ შუალედური ეტაპი გავაკეთეთ მათ დასამუშავებლად მარიონეტული მაგიდა.
2. განთავისუფლდი "მარშრუტიზაციისგან" გამომწვევებში - ანუ დან EXECUTE.
3. ცალკე გამოიტანეს შაბლონის ცხრილი ყველა ინდექსითისე, რომ მარიონეტულ ცხრილშიც კი არ იმყოფებიან.

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

ლექსიკონები "სახნავი".

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

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

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

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

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

ღონისძიებების მთელი კომპლექსის შედეგად პროცესორის დატვირთვა შემცირდა ~30%-ით, დისკის დატვირთვა ~50%-ით:

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

#2. მონაცემთა ბაზის ევოლუცია და რეფაქტორირება

ასე რომ, ჩვენ დავრჩით იმაზე, რაც გვაქვს თითოეულ დღეს აქვს თავისი განყოფილება მონაცემებით. რეალურად, CHECK (dt = '2018-10-12'::date) — და არის დანაყოფის გასაღები და პირობა, რომ ჩანაწერი მოხვდეს კონკრეტულ განყოფილებაში.

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

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

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

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

#3. პიკური დატვირთვის "გავრცელება".

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

მოდით გავადიდოთ წინა სურათი და ვნახოთ, რომ გვაქვს დისკი "ტუმბოები" დატვირთვის ქვეშ ორმაგი ამპლიტუდით მიმდებარე ნიმუშებს შორის, რაც აშკარად „სტატისტიკურად“ არ უნდა მოხდეს ასეთი რაოდენობის ოპერაციების დროს:

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

setInterval(sendToDB, interval)

პრობლემა აქ მდგომარეობს ზუსტად იმაში, რომ ყველა თემა იწყება დაახლოებით ერთსა და იმავე დროს, ასე რომ, მათი გაგზავნის დრო თითქმის ყოველთვის ემთხვევა „საქმეზე“. უი #2...

საბედნიეროდ, ამის გამოსწორება საკმაოდ მარტივია, "შემთხვევითი" გაშვების დამატება დროით:

setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))

#4. ჩვენ ქეშირებთ იმას, რაც გვჭირდება

მესამე ტრადიციული მაღალი დატვირთვის პრობლემაა არ არის ქეში სადაც ის არის შეეძლო ყოფნა.

მაგალითად, ჩვენ შევძელით ანალიზი გეგმის კვანძების თვალსაზრისით (ეს ყველაფერი Seq Scan on users), მაგრამ მაშინვე იფიქრეთ, რომ ისინი, უმეტესწილად, იგივეა - დაავიწყდათ.

არა, რა თქმა უნდა, ისევ არაფერი იწერება მონაცემთა ბაზაში, ეს წყვეტს ტრიგერს INSERT ... ON CONFLICT DO NOTHING. მაგრამ ეს მონაცემები კვლავ აღწევს მონაცემთა ბაზას და ეს არასაჭიროა კითხვა კონფლიქტის შესამოწმებლად უნდა გავაკეთო. უი #3...

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

და ეს არის შენახვის დატვირთვის თანმხლები ვარდნა:

საერთო ჯამში

"ტერაბაიტი დღეში" უბრალოდ საშინლად ჟღერს. თუ ყველაფერს სწორად აკეთებ, მაშინ ეს უბრალოდ 2^40 ბაიტი / 86400 წამი = ~ 12.5 მბ/წმრომ დესკტოპის IDE ხრახნებიც კი ეჭირა. 🙂

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

წყარო: www.habr.com