PostgreSQL ანტიპატერნები: "მკვდრების" ლაშქართა ბრძოლა

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

მოკლე ამბავი დან დიდი სტატია:

როდესაც მწკრივი იცვლება UPDATE ბრძანებით, რეალურად შესრულებულია ორი ოპერაცია: DELETE და INSERT. IN სტრიქონის მიმდინარე ვერსია xmax დაყენებულია ტრანზაქციის რაოდენობის ტოლი, რომელმაც შეასრულა განახლება. შემდეგ იქმნება ახალი ვერსია იგივე ხაზი; მისი xmin მნიშვნელობა ემთხვევა წინა ვერსიის xmax მნიშვნელობას.

ამ ტრანზაქციის დასრულებიდან გარკვეული დროის შემდეგ, ძველი ან ახალი ვერსია, დამოკიდებულია COMMIT/ROOLBACK, იქნება აღიარებული "მკვდარი" (მკვდარი ტუპლები) გავლისას VACUUM ცხრილის მიხედვით და გაწმენდილია.

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

#1: მე მომწონს მისი გადატანა

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

UPDATE tbl SET X = <newX> WHERE pk = $1;

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

UPDATE tbl SET Y = <newY> WHERE pk = $1;

... და შემდეგ ასევე Z - რატომ კარგავთ დროს წვრილმანებზე?

UPDATE tbl SET Z = <newZ> WHERE pk = $1;

ამ ჩანაწერის რამდენი ვერსია გვაქვს ახლა მონაცემთა ბაზაში? დიახ, 4 ცალი! აქედან ერთი აქტუალურია და 3 უნდა გაიწმინდოს თქვენს შემდეგ [ავტო]ვაკუუმით.

არ გააკეთოთ ეს ასე! გამოყენება ყველა ველის განახლება ერთი მოთხოვნით — მეთოდის ლოგიკა თითქმის ყოველთვის შეიძლება შეიცვალოს ასე:

UPDATE tbl SET X = <newX>, Y = <newY>, Z = <newZ> WHERE pk = $1;

#2: გამოყენება განსხვავდება, ლუკა!

ასე რომ, შენ მაინც გინდოდა განაახლეთ ბევრი, ბევრი ჩანაწერი ცხრილში (მაგალითად, სკრიპტის ან გადამყვანის გამოყენების დროს). და მსგავსი რამ გადადის სკრიპტში:

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2;

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

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2 AND X IS DISTINCT FROM <newX>;

ბევრმა არ იცის ასეთი მშვენიერი ოპერატორის არსებობის შესახებ, ასე რომ, აქ არის მოტყუების ფურცელი IS DISTINCT FROM და სხვა ლოგიკური ოპერატორები დასახმარებლად:

... და ცოტა კომპლექსზე ოპერაციების შესახებ ROW()- გამონათქვამები:

#3: მე ვიცნობ ჩემს საყვარელს... დაბლოკვით

იწყებენ ორი იდენტური პარალელური პროცესი, რომელთაგან თითოეული ცდილობს მონიშნოს ჩანაწერი, რომ ის "მიმდინარეობს":

UPDATE tbl SET processing = TRUE WHERE pk = $1;

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

გამოსავალი #1: დავალება შემცირებულია წინაზე

მოდით, კიდევ ერთხელ დავამატოთ IS DISTINCT FROM:

UPDATE tbl SET processing = TRUE WHERE pk = $1 AND processing IS DISTINCT FROM TRUE;

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

გამოსავალი #2: საკონსულტაციო საკეტები

დიდი თემა ცალკე სტატიისთვის, რომელშიც შეგიძლიათ წაიკითხოთ გამოყენების მეთოდები და სარეკომენდაციო ბლოკირების „რაკი“..

გამოსავალი #3: სულელური ზარები

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

წყარო: www.habr.com