ძვირფასო DELETE. ნიკოლაი სამოხვალოვი (Postgres.ai)

ოდესმე, შორეულ მომავალში, არასაჭირო მონაცემების ავტომატური ამოღება იქნება DBMS-ის ერთ-ერთი მნიშვნელოვანი ამოცანა [1]. ამასობაში, ჩვენ თვითონ უნდა ვიზრუნოთ არასაჭირო მონაცემების წაშლაზე ან გადატანაზე ნაკლებად ძვირადღირებულ შენახვის სისტემებზე. ვთქვათ, გადაწყვიტეთ რამდენიმე მილიონი მწკრივის წაშლა. საკმაოდ მარტივი ამოცანა, განსაკუთრებით იმ შემთხვევაში, თუ მდგომარეობა ცნობილია და არსებობს შესაბამისი ინდექსი. "DELETE FROM table1 WHERE col1 = :value" - რა შეიძლება იყოს უფრო მარტივი, არა?

ვიდეო:

• ჰაილოდის პროგრამის კომიტეტში ვარ პირველი წლიდან, ანუ 2007 წლიდან.

• და მე პოსტგრესში ვარ 2005 წლიდან. გამოიყენა იგი ბევრ პროექტში.

• ჯგუფი ასევე მუშაობს RuPostges-ში 2007 წლიდან.

• ჩვენ გავიზარდეთ 2100+ მონაწილემდე Meetup-ზე. ეს მსოფლიოში მეორე ადგილია ნიუ-იორკის შემდეგ, რომელმაც დიდი ხნის წინ გადაუსწრო სან-ფრანცისკოს.

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

https://postgres.ai/ - ეს ჩემი კომპანიაა. ჩვენ ვართ ამოცანების ავტომატიზაციის ბიზნესში, რომლებიც აღმოფხვრის განვითარების შენელებას.

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

ცოტა ხნის წინ ვიყავი VLDB-ში ლოს-ანჯელესში. ეს არის მონაცემთა ბაზის ყველაზე დიდი კონფერენცია. და იყო მოხსენება, რომ მომავალში DBMS არა მხოლოდ შეინახავს, ​​არამედ ავტომატურად წაშლის მონაცემებს. ეს ახალი თემაა.

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

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

და რა ვუყოთ მას? გასაგებია, რომ საჭიროა წაშლა. აქ მოცემულია ამ საინტერესო მოხსენების ბმული. მაგრამ ჯერჯერობით ეს არ არის დანერგილი DBMS-ში.

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

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

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

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

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

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

მონაცემთა ბაზა იზრდება და იზრდება. ყოველდღიური DELETE იწყებს მუშაობას ოდნავ ნელა.

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

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

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

Შემდეგ რა მოხდება? მაშინ ჩვენთვის ყველაფერი ინგრევა. ისე ეცემა, რომ რაღაც მომენტში ყველაფერი ძირს იშლება. ყველა შოკშია, არავის ესმის რა ხდება. შემდეგ კი აღმოჩნდება, რომ ეს DELETE იყო პრობლემა.

Რაღაც არასწორად წავიდა? აქ არის სია, რაც შეიძლება არასწორად წავიდეს. აქედან რომელია ყველაზე მნიშვნელოვანი?

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

• იქნებ რაღაც არასწორად შეამოწმეს.

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

• ან თავად მონაცემთა ბაზაში რაღაც არასწორია და ჩვენ უნდა გადავიდეთ Postgres-დან MySQL-ზე.

• ან იქნებ ოპერაციას რაღაც ჭირს.

• იქნებ არის გარკვეული შეცდომები სამუშაოს ორგანიზებაში და გჭირდებათ ვინმეს გათავისუფლება და უკეთესი ადამიანების დაქირავება?

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

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

http://bit.ly/nancy-hl2018-2

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

ჩვენ გვესმის, რომ ჩვენი ტესტები სუსტია, ანუ პროცესი, რომელიც აშენებულია, არ იჩენს პრობლემებს. ადექვატური DB ექსპერიმენტი არ ჩატარებულა.

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

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

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

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

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

Postgres-ის პარამეტრები ჩამორჩენილია. ისინი განკუთვნილია 10-15 წლის მოცულობის მონაცემებისა და ოპერაციებისთვის. და საგუშაგო არ არის გამონაკლისი.

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

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

და ნაგულისხმევად, max_wal_saze დაყენებულია 1 გიგაბაიტზე. სინამდვილეში, ეს რეალურად ხდება Postgres-ში 300-400 მეგაბაიტის შემდეგ. თქვენ შეცვალეთ ამდენი მონაცემები და გაქვთ საგუშაგო.

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

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

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

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

პირველი სერია - ჩვენ ვცვლით max_wal_size. და ჩვენ ვატარებთ მასიურ ოპერაციას. ჯერ ამას ვაკეთებთ ნაგულისხმევი პარამეტრით 1 გიგაბაიტი. და ჩვენ ვაკეთებთ მილიონობით ხაზის მასიურ DELETE-ს.

ხედავთ, რა ძნელია ჩვენთვის. ჩვენ ვხედავთ, რომ დისკის IO ძალიან ცუდია. ვნახოთ, რამდენი WAL გამოვიმუშავეთ, რადგან ეს ძალიან მნიშვნელოვანია. ვნახოთ რამდენჯერ მოხდა საგუშაგო. და ჩვენ ვხედავთ, რომ ეს არ არის კარგი.

შემდეგ ჩვენ გავზრდით max_wal_size. ვიმეორებთ. გაზარდეთ, გაიმეორეთ. და იმდენჯერ. პრინციპში კარგია 10 ქულა, სადაც 1, 2, 4, 8 გიგაბაიტი. და ჩვენ ვუყურებთ კონკრეტული სისტემის ქცევას. გასაგებია, რომ აქ აღჭურვილობა უნდა იყოს ისეთი, როგორიც არის პროდუქციაზე. თქვენ უნდა გქონდეთ იგივე დისკები, იგივე რაოდენობის მეხსიერება და იგივე Postgres პარამეტრები.

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

საგუშაგო რუსულად ნიშნავს საკონტროლო პუნქტებს.

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

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

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

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

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

რატომ?

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

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

და ჩვენ ვაიძულებთ საგუშაგოს გადარჩენა ბევრჯერ. თითქოს ამისთვის ზედმეტი ოპერაციებია.

მაგრამ ეს ყველაფერი არ არის. Postgres-ში გვერდები იწონის 8 კილობაიტს, ხოლო Linux-ში 4 კილობაიტს. და არის პარამეტრი full_page_writes. ის ჩართულია ნაგულისხმევად. და ეს სწორია, რადგან თუ გამორთეთ, არის საშიშროება, რომ ავარიის შემთხვევაში, მხოლოდ გვერდის ნახევარი შეინახება.

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

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

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

და, შესაბამისად, გვაქვს ორი ჭარბი რაოდენობა.

max_wal_size-ს თუ გავზრდით, გამოდის, რომ ვამარტივებთ როგორც საგუშაგოს, ისე wal Writer-ს მუშაობას. და ეს მშვენიერია.

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

ჩვენ ვაკეთებთ ოპერაციას და ვნახავთ, როდესაც საგუშაგო ახლოსაა დასრულებამდე, განზრახ ვაკეთებთ kill -9 Postgres.

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

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

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

და აქ არის ერთი საინტერესო წერტილი. კონფერენციაზე ორიოდე მოხსენება გვაქვს პატრონის შესახებ. და იქნებ თქვენ იყენებთ მას. ეს არის Autofailover Postgres-ისთვის. ამის შესახებ GitLab და Data Egret ისაუბრეს.

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

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

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

იმისათვის, რომ გაიმეოროთ, მაგალითად, max_wal_size = 1, 8, თქვენ უნდა გაიმეოროთ მასობრივი ოპერაცია ბევრჯერ. შენ გააკეთე. და თქვენ გსურთ ამის გაკეთება ისევ იმავე ბაზაზე, მაგრამ თქვენ უკვე წაშალეთ ყველაფერი. Რა უნდა ვქნა?

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

მაგრამ ამ შემთხვევაში ჩვენ გაგვიმართლა. თუ, როგორც აქ წერია „BEGIN, DELETE, ROLLBACK“, მაშინ შეგვიძლია გავიმეოროთ DELETE. ანუ, თუ ჩვენ თვითონ გავაუქმეთ, მაშინ შეგვიძლია გავიმეოროთ. და ფიზიკურად თქვენი მონაცემები იქ იქნება. თქვენ არც კი გექნებათ შებერილობა. თქვენ შეგიძლიათ გაიმეოროთ ასეთი DELETE.

ეს DELETE ROLLBACK-ით იდეალურია საგუშაგოს დასარეგულირებლად, მაშინაც კი, თუ არ გაქვთ სათანადოდ განლაგებული მონაცემთა ბაზის ლაბორატორიები.

ჩვენ გავაკეთეთ ნიშანი ერთი სვეტით "i". Postgres-ს აქვს სერვისის სვეტები. ისინი უხილავია, თუ ამას კონკრეტულად არ ითხოვენ. ესენია: ctid, xmid, xmax.

Ctid არის ფიზიკური მისამართი. გვერდი ნულოვანი, პირველი ტოპი გვერდზე.

ჩანს, რომ ROOLBACK-ის შემდეგ ტუპლი იმავე ადგილას დარჩა. ანუ შეგვიძლია კიდევ ვცადოთ, ასე მოიქცევა. ეს არის მთავარი.

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

ეს ეხება პროგრამისტებს. DBA-ს შესახებაც, ისინი ყოველთვის საყვედურობენ პროგრამისტებს ამის გამო: "რატომ აკეთებთ ასეთ გრძელ და რთულ ოპერაციებს?" ეს სრულიად განსხვავებული პერპენდიკულარული თემაა. ადრე ადმინისტრაცია იყო, ახლა კი განვითარება იქნება.

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

რატომ არის მნიშვნელოვანი გატეხვა?

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

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

https://postgres.ai/products/joe/

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

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

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

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

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

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

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

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

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

რა არის დაყოფის სტრატეგიები? მე ვხედავ 3 განსხვავებულ დაყოფის სტრატეგიას, რომელსაც დეველოპერები იყენებენ პაკეტზე.

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

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

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

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

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

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

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

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

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

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

ხანგრძლივი გარიგებები - https://gitlab.com/snippets/1890447

დაბლოკილი ავტოვაკუუმი https://gitlab.com/snippets/1889668

დაბლოკვის საკითხი https://gitlab.com/snippets/1890428

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

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

თუ არის დიდი IO, მაშინ გასაგებია, რომ ეს არ არის კარგი.

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

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

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

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

ზოგჯერ ყველა ეს შეცდომა ერთად ხდება.

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

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

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

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

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

რასაც ჩვენ ვაკეთებთ არის ღია წყარო. ეს გამოქვეყნებულია GitLab-ზე. და ჩვენ ვაკეთებთ ისე, რომ ხალხს შეეძლოს შემოწმება DBA-ის გარეშეც. ვაკეთებთ მონაცემთა ბაზის ლაბორატორიას, ანუ ვუწოდებთ საბაზისო კომპონენტს, რომელზეც ამჟამად მუშაობს ჯო. და თქვენ შეგიძლიათ აიღოთ წარმოების ასლი. ახლა არის Joe-ს დანერგვა slack-ისთვის, შეგიძლიათ იქ თქვათ: „აუხსენით ასეთი და ასეთი მოთხოვნა“ და დაუყოვნებლივ მიიღოთ შედეგი თქვენი მონაცემთა ბაზის ასლისთვის. იქ შეგიძლიათ DELETE-იც კი გააკეთოთ და ვერავინ შეამჩნევს.

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

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

მაგალითი: 5 ტერაბაიტი მონაცემთა ბაზა, ასლის მიღება 30 წამზე ნაკლებ დროში. და ეს არც არის დამოკიდებული ზომაზე, ანუ არ აქვს მნიშვნელობა რამდენი ტერაბაიტი.

დღეს შეგიძლიათ წასვლა პოსტგრესი.აი და იჭრება ჩვენს იარაღებში. შეგიძლიათ დარეგისტრირდეთ და ნახოთ რა არის იქ. თქვენ შეგიძლიათ დააინსტალიროთ ეს ბოტი თქვენთვის. Უფასოა. დაწერე.

კითხვები

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

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

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

თუ გადავხედავთ pg_repack-ს GitHub-ზე, მაშინ როდესაც იყო დავალება ID-ის გადაქცევა int 4-დან int 8-ში, მაშინ გაჩნდა იდეა თავად გამოეყენებინა pg_repack. ეს ასევე შესაძლებელია, მაგრამ ეს ცოტა ჰაკერული მეთოდია, მაგრამ ამისთვისაც იმუშავებს. შეგიძლიათ ჩაერიოთ ტრიგერში, რომელიც იყენებს pg_repack და იქ თქვათ: „ჩვენ არ გვჭირდება ეს მონაცემები“, ანუ ჩვენ გადავცემთ მხოლოდ იმას, რაც გვჭირდება. შემდეგ კი ის უბრალოდ გადართავს და ეს არის ის.

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

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

მე სულ ცოტათი ვარ MySQL სამყაროდან, ამიტომ მოვედი მოსასმენად. და ჩვენ ვიყენებთ ამ მიდგომას.

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

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

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

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

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

იგივე გააკეთეს ინდექსებით.

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

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

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

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

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

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

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

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

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

ეს არის ის, რასაც ავტოვაკუუმი ავტომატურად აკეთებს Postgres-ში.

ოჰ, ის აკეთებს ამას?

ავტოვაკუუმი არის ნაგვის შემგროვებელი.

დიდი მადლობა!

გმადლობთ ანგარიშისთვის! არის თუ არა შესაძლებლობა, რომ დაუყოვნებლივ შეიმუშაოთ მონაცემთა ბაზა დანაყოფით ისე, რომ ყველა ნაგავი ამოღებულ იქნეს მთავარი მაგიდიდან სადღაც გვერდით?

რა თქმა უნდა აქვს.

შეგვიძლია დავიცვათ თუ არა მაგიდა, რომელიც არ უნდა გამოვიყენოთ?

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

წყარო: www.habr.com