სტატიის თარგმანი მომზადდა სპეციალურად კურსის სტუდენტებისთვის "Მონაცემთა ბაზა". გაინტერესებთ ამ მიმართულებით განვითარება? გეპატიჟებით ღია კარის დღე, სადაც დეტალურად ვსაუბრობთ პროგრამაზე, ონლაინ ფორმატის თავისებურებებზე, კომპეტენციებზე და კარიერულ პერსპექტივაზე, რომელიც ელით კურსდამთავრებულებს ტრენინგის შემდეგ.

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

რატომ მჭირდება?

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

შეხვდით კომპრომისს

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

Tradeoff 1: შესრულება

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

Tradeoff 2: თანმიმდევრულობა

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

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

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

გარიგება 3: ავარია

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

ერთი კავშირი თითო ტრანზაქციაზე?

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

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

პრაქტიკაში კონტროლის უზრუნველყოფა

ნაგულისხმევად, PostgreSQL უზრუნველყოფს თანმიმდევრულობას. ეს კონტროლდება სერვერის პარამეტრით synchronous_commit. ნაგულისხმევად ის პოზიციაზეა on, მაგრამ მას აქვს კიდევ სამი ვარიანტი: local, remote_write ან off.

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

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

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

SET SESSION synchronous_commit TO ON;  
// Your writes go here

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

მეორე მეთოდი კარგია, როდესაც თქვენ უბრალოდ გსურთ დარწმუნდეთ, რომ მიიღებთ სინქრონულ რეპლიკაციას ერთი ტრანზაქციისთვის. ბევრ NoSQL-ის თაობის მონაცემთა ბაზაში ტრანზაქციების კონცეფცია არ არსებობს, მაგრამ PostgreSQL-ში არსებობს. ამ შემთხვევაში თქვენ იწყებთ ტრანზაქციას და შემდეგ აყენებთ synchronous_commit в on ტრანზაქციის ჩანაწერის შესრულებამდე. COMMIT განახორციელებს ტრანზაქციას ნებისმიერი პარამეტრის მნიშვნელობის გამოყენებით synchronous_commit, რომელიც დაყენებული იყო იმ დროს, თუმცა უმჯობესია ცვლადის დაყენება წინასწარ, რათა დარწმუნდეთ, რომ სხვა დეველოპერებმა გაიგეს, რომ ჩაწერა არ არის ასინქრონული.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

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

PostgreSQL-ის დაყენება

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

synchronous_commit = local  
synchronous_standby_names='*'

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

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

კიდევ რამდენიმე სიტყვა...

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

ამ პარამეტრის შეცვლა შესაძლებელია ნებისმიერ დროს. ნებისმიერი ტრანზაქციის ქცევა განისაზღვრება ჩადენის დროს მოქმედი პარამეტრით. აქედან გამომდინარე, შესაძლებელია და სასარგებლოა ზოგიერთი ტრანზაქციის სინქრონულად და სხვებისთვის ასინქრონულად შესრულება. მაგალითად, აიძულოს ერთი multistatement ტრანზაქცია to make commits ხდება ასინქრონულად, როდესაც პარამეტრის ნაგულისხმევი მნიშვნელობა საპირისპიროა, მითითებული SET LOCAL synchronous_commit TO OFF გარიგებაში.

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

წყარო: www.habr.com