პოსტგრესი: bloat, pg_repack და გადადებული შეზღუდვები

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

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

ეს სტატია დაწერილია საფუძველზე ჩემი გამოსვლა PgConf.Russia 2020-ზე.

რატომ ჩნდება შეშუპება?

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

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

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

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

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

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

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

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

როდესაც ასეთი ცარიელი ან ძალიან მწირი გვერდების რაოდენობა დიდი ხდება, რასაც bloat ჰქვია, ის იწყებს მოქმედებაზე ზემოქმედებას.

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

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

არსებობს რამდენიმე გზა იმის დასადგენად, გაქვთ თუ არა შეშუპება. პირველის იდეა არის Postgres-ის შიდა სტატისტიკის გამოყენება, რომელიც შეიცავს მიახლოებით ინფორმაციას ცხრილებში სტრიქონების რაოდენობის, „ცოცხალი“ სტრიქონების რაოდენობის შესახებ და ა.შ. ინტერნეტში შეგიძლიათ იპოვოთ მზა სკრიპტების მრავალი ვარიაცია. ჩვენ საფუძვლად ავიღეთ სკრიპტი PostgreSQL Experts-ისგან, რომელსაც შეუძლია შეაფასოს bloat ცხრილები სადღეგრძელო და bloat btree ინდექსებთან ერთად. ჩვენი გამოცდილებით, მისი ცდომილება არის 10-20%.

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

ჩვენ მიგვაჩნია, რომ მცირე bloat ღირებულება, მდე 20%, მისაღები. ის შეიძლება ჩაითვალოს შემავსებლის ანალოგად მაგიდები и ინდექსები. 50% და ზემოთ, მუშაობის პრობლემები შეიძლება დაიწყოს.

შებერილობის წინააღმდეგ ბრძოლის გზები

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

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

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

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

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

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

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

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

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

ამდენად, თუ ინდექსებისთვის არსებობს გზები, რათა აღმოიფხვრას აფეთქება "დაფრენისას", მაშინ მაგიდებისთვის არ არსებობს. აქ მოქმედებს სხვადასხვა გარე გაფართოებები: pg_repack (ყოფილი pg_reorg), pgcompact, pgcompacttable და სხვა. ამ სტატიაში მათ არ შევადარებ და მხოლოდ pg_repack-ზე ვისაუბრებ, რომელსაც გარკვეული მოდიფიკაციის შემდეგ ჩვენ თვითონ ვიყენებთ.

როგორ მუშაობს pg_repack

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

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

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

თეორიულად ყველაფერი მშვენივრად გამოიყურება, მაგრამ რა ხდება პრაქტიკაში? ჩვენ გამოვცადეთ pg_repack დატვირთვის გარეშე და დატვირთვის ქვეშ და შევამოწმეთ მისი მოქმედება ნაადრევი გაჩერების შემთხვევაში (სხვა სიტყვებით, Ctrl+C გამოყენებით). ყველა ტესტი დადებითი იყო.

წავედით კვების მაღაზიაში - შემდეგ კი ყველაფერი ისე არ წავიდა, როგორც ველოდით.

პირველი ბლინი იყიდება

პირველ კლასტერზე მივიღეთ შეცდომა უნიკალური შეზღუდვის დარღვევის შესახებ:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ამ შეზღუდვას ჰქონდა ავტომატურად გენერირებული სახელი index_16508 - ის შეიქმნა pg_repack-ის მიერ. მის შემადგენლობაში შემავალი ატრიბუტების საფუძველზე, ჩვენ განვსაზღვრეთ "ჩვენი" შეზღუდვა, რომელიც შეესაბამება მას. პრობლემა ის იყო, რომ ეს არ არის სრულიად ჩვეულებრივი შეზღუდვა, არამედ გადადებული (გადავადებული შეზღუდვა), ე.ი. მისი გადამოწმება ხდება sql ბრძანებაზე გვიან, რაც იწვევს მოულოდნელ შედეგებს.

გადავადებული შეზღუდვები: რატომ არის საჭირო და როგორ მუშაობს

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

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique
);

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

begin;
  update cars set ord = 2 where name = 'audi';
  update cars set ord = 1 where name = 'bmw';
commit;

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

[23305] ERROR: duplicate key value violates unique constraint “uk_cars”
Detail: Key (ord)=(2) already exists.

როგორ გავაკეთო სხვანაირად? ვარიანტი პირველი: დაამატეთ დამატებითი ღირებულების ჩანაცვლება შეკვეთას, რომელიც გარანტირებულია, რომ არ არსებობს ცხრილში, მაგალითად "-1". პროგრამირებაში ამას ეწოდება "ორი ცვლადის მნიშვნელობების გაცვლა მესამეში". ამ მეთოდის ერთადერთი ნაკლი არის დამატებითი განახლება.

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

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

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique deferrable initially deferred
);

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

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

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

წყარო: მთხოვნელებს

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

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

pg_repack-ის გაუმჯობესება

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

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

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

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

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

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

მაშ რა იდეები გვქონდა?

შექმენით გადადებულის მსგავსი ინდექსი

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

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

CREATE UNIQUE INDEX CONCURRENTLY uk_tablename__immediate ON tablename (id, index);
-- run pg_repack
DROP INDEX CONCURRENTLY uk_tablename__immediate;

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

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

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

შეცვალეთ ინდექსები ახალ ცხრილში თავდაპირველი ცხრილის გადავადებული შეზღუდვებით

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

ჩვენი ცვლილებების შესამოწმებლად, ჩვენ დავწერეთ მარტივი ტესტი:

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

create table test_table
(
  id serial,
  val int,
  constraint uk_test_table__val unique (val) deferrable initially deferred 
);

INSERT INTO test_table (val) VALUES (0);
FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (0) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    COMMIT;
  END;
END LOOP;

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

ჩვენ მივდივართ წარმოებაზე და კვლავ ვიღებთ შეცდომას ჟურნალის ცხრილიდან მონაცემების ახალზე კოპირების იმავე ფაზაში:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

კლასიკური სიტუაცია: ყველაფერი მუშაობს სატესტო გარემოში, მაგრამ არა წარმოებაში?!

APPLY_COUNT და ორი ჯგუფის შეერთება

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

for (;;)
{
num = apply_log(connection, table, APPLY_COUNT);

if (num > MIN_TUPLES_BEFORE_SWITCH)
     continue;  /* there might be still some tuples, repeat. */
...
}

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

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

FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (1) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    UPDATE test_table set val = i where id = v_id; -- one more update
    COMMIT;
  END;
END LOOP;

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

უარის თქმა ნაკრებზე

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

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

ასე რომ, ჩვენ გადავწყვიტეთ დავიწყოთ პირველი ვარიანტით, რადგან ეს უფრო მარტივია. პირველ რიგში, საჭირო იყო იმის გაგება, იქნებოდა თუ არა ხანგრძლივი გარიგება რეალური პრობლემა. ვინაიდან მონაცემთა ძირითადი გადაცემა ძველი ცხრილიდან ახალზე ასევე ხდება ერთ ხანგრძლივ ტრანზაქციაში, კითხვა გადაკეთდა "რამდენად გავზრდით ამ ტრანზაქციას?" პირველი ტრანზაქციის ხანგრძლივობა ძირითადად დამოკიდებულია მაგიდის ზომაზე. ახლის ხანგრძლივობა დამოკიდებულია იმაზე, თუ რამდენი ცვლილება გროვდება ცხრილში მონაცემთა გადაცემის დროს, ე.ი. დატვირთვის ინტენსივობაზე. pg_repack გაშვება მოხდა მინიმალური სერვისის დატვირთვის დროს და ცვლილებების მოცულობა არაპროპორციულად მცირე იყო ცხრილის თავდაპირველ ზომასთან შედარებით. ჩვენ გადავწყვიტეთ, რომ შეგვიძლია უგულებელვყოთ ახალი ტრანზაქციის დრო (შედარებისთვის, საშუალოდ 1 საათი და 2-3 წუთია).

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

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

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

დასკვნები

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

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

წყარო: www.habr.com