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

Შენიშვნა. თარგმნაჯაანა დოგანი არის Google-ის გამოცდილი ინჟინერი, რომელიც ამჟამად მუშაობს Go-ში დაწერილი კომპანიის წარმოების სერვისების დაკვირვებაზე. ამ სტატიაში, რომელმაც დიდი პოპულარობა მოიპოვა ინგლისურენოვან აუდიტორიაში, მან 17 პუნქტში შეაგროვა მნიშვნელოვანი ტექნიკური დეტალები DBMS-ებთან (და ზოგჯერ ზოგადად განაწილებულ სისტემებთან) დაკავშირებით, რომლებიც სასარგებლოა დიდი/მოთხოვნილი აპლიკაციების დეველოპერებისთვის.

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

1. თქვენ გაგიმართლათ, თუ 99,999% შემთხვევაში ქსელი არ იწვევს პრობლემებს.
2. ACID ნიშნავს ბევრ განსხვავებულ რამეს.
3. თითოეულ მონაცემთა ბაზას აქვს საკუთარი მექანიზმები თანმიმდევრულობისა და იზოლაციის უზრუნველსაყოფად.
4. ოპტიმისტური ბლოკირება სამაშველოში მოდის, როცა ძნელია ჩვეულის შენარჩუნება.
5. ბინძური წაკითხვისა და მონაცემთა დაკარგვის გარდა არის სხვა ანომალიები.
6. მონაცემთა ბაზა და მომხმარებელი ყოველთვის არ თანხმდებიან მოქმედების კურსზე.
7. აპლიკაციის დონის გაზიარება შეიძლება გადავიდეს აპლიკაციის გარეთ.
8. ავტომატური ზრდა შეიძლება საშიში იყოს.
9. ძველი მონაცემები შეიძლება იყოს სასარგებლო და არ საჭიროებს ჩაკეტვას.
10. დამახინჯებები დამახასიათებელია დროის ნებისმიერი წყაროსთვის.
11. დაგვიანებას ბევრი მნიშვნელობა აქვს.
12. შესრულების მოთხოვნები უნდა შეფასდეს კონკრეტული ტრანზაქციისთვის.
13. ჩადგმული ტრანზაქციები შეიძლება საშიში იყოს.
14. გარიგებები არ უნდა იყოს დაკავშირებული განაცხადის მდგომარეობასთან.
15. შეკითხვის დამგეგმავებს შეუძლიათ ბევრი რამ გითხრათ მონაცემთა ბაზების შესახებ.
16. ონლაინ მიგრაცია რთულია, მაგრამ შესაძლებელია.
17. მონაცემთა ბაზის მნიშვნელოვანი ზრდა იწვევს არაპროგნოზირებადობის ზრდას.

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

თქვენ გაგიმართლათ, თუ 99,999% შემთხვევაში ქსელი არ იწვევს პრობლემებს.

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

99,999% ხელმისაწვდომობის მაჩვენებლით Spanner-ისთვის (Google-ის გლობალურად გავრცელებული მონაცემთა ბაზა), Google აცხადებს, რომ მხოლოდ 7,6% პრობლემები დაკავშირებულია ქსელთან. ამავე დროს, კომპანია თავის სპეციალიზებულ ქსელს უწოდებს მაღალი ხელმისაწვდომობის „მთავარ საყრდენს“. Სწავლა ბეილისი და კინგსბერი2014 წელს ჩატარებული, გამოწვევას უქმნის ერთ-ერთ „მცდარი წარმოდგენები განაწილებული გამოთვლის შესახებ“, რომელიც პიტერ დოიჩმა ჩამოაყალიბა 1994 წელს. არის თუ არა ქსელი ნამდვილად სანდო?

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

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

ACID ნიშნავს ბევრ განსხვავებულ რამეს

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

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

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

დებატები იმის შესახებ, შეესაბამება თუ არა MongoDB ACID მოთხოვნებს, გრძელდება მე-4 ვერსიის გამოშვების შემდეგაც. MongoDB დიდი ხანია არ არის მხარდაჭერილი ჭრის, თუმცა ნაგულისხმევად მონაცემები დისკზე იყო ჩადებული არა უმეტეს 60 წამში ერთხელ. წარმოიდგინეთ შემდეგი სცენარი: აპლიკაცია აქვეყნებს ორ ჩაწერას (w1 და w2). MongoDB წარმატებით ინახავს w1-ს, მაგრამ w2 იკარგება ტექნიკის გაუმართაობის გამო.

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

დისკზე დადება ძვირი პროცესია. ხშირი ვალდებულებების თავიდან აცილებით, დეველოპერები აუმჯობესებენ ჩაწერის შესრულებას საიმედოობის ხარჯზე. MongoDB ამჟამად მხარს უჭერს ანგარიშს, მაგრამ ბინძურმა ჩაწერამ მაინც შეიძლება გავლენა მოახდინოს მონაცემთა მთლიანობაზე, რადგან ჟურნალები იწერება ნაგულისხმევად ყოველ 100 ms-ში. ანუ მსგავსი სცენარი ჯერ კიდევ შესაძლებელია ლოგებსა და მათში წარმოდგენილ ცვლილებებზე, თუმცა რისკი გაცილებით დაბალია.

თითოეულ მონაცემთა ბაზას აქვს საკუთარი თანმიმდევრულობა და იზოლაციის მექანიზმები

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

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

არსებული კონკურენტულობის მოდელებისა და მათ შორის ურთიერთობების მიმოხილვა

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

SQL სტანდარტი აღნიშნავს იზოლაციის შემდეგ დონეებს:

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

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

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

კონკურენტულობის ანომალიების მიმოხილვა სხვადასხვა იზოლაციის დონეზე სხვადასხვა DBMS-ისთვის

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

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

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

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

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

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

ბინძური წაკითხვისა და მონაცემთა დაკარგვის გარდა არის სხვა ანომალიები

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

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

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

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

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

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

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

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

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

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

result1 = T1() // რეალური შედეგები დაპირებებია
შედეგი2 = T2()

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

აპლიკაციის დონის გაზიარება შეიძლება გადავიდეს აპლიკაციის გარეთ

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

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

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

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

ავტომატური ზრდა შეიძლება საშიში იყოს

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

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

სანამ მიდგომაზე გადაწყვეტთ, განიხილეთ ID-ების და UUID-ების ავტომატური გაზრდის გავლენა ინდექსირებაზე, დაყოფასა და განაწილებაზე.

ძველი მონაცემები შეიძლება იყოს სასარგებლო და არ საჭიროებს ჩაკეტვას

Multiversion Concurrency Control (MVCC) ახორციელებს თანმიმდევრულობის ბევრ მოთხოვნას, რომლებიც მოკლედ იყო განხილული ზემოთ. ზოგიერთი მონაცემთა ბაზა (მაგალითად, Postgres, Spanner) იყენებს MVCC-ს ტრანზაქციების გამოსაკვებად სნეპშოტებით - მონაცემთა ბაზის ძველი ვერსიებით. Snapshot ტრანზაქციები ასევე შეიძლება სერიული იყოს თანმიმდევრულობის უზრუნველსაყოფად. ძველი სნეპშოტის კითხვისას იკითხება მოძველებული მონაცემები.

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

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

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

DBMS ავტომატურად ასუფთავებს ძველ ვერსიებს და, ზოგიერთ შემთხვევაში, საშუალებას გაძლევთ ამის გაკეთება მოთხოვნით. მაგალითად, Postgres მომხმარებლებს საშუალებას აძლევს ამის გაკეთება VACUUM მოთხოვნის მიხედვით და ასევე პერიოდულად ასრულებს ამ ოპერაციას ავტომატურად. Spanner მართავს ნაგვის შემგროვებელს ერთ საათზე ძველი კადრების მოსაშორებლად.

დროის ნებისმიერი წყარო ექვემდებარება დამახინჯებას

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

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

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

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

Google TrueTime სრულიად განსხვავებულ მიდგომას იღებს. ადამიანების უმეტესობას მიაჩნია, რომ Google-ის პროგრესი ამ მიმართულებით აიხსნება ბანალური გადასვლით ატომურ და GPS საათებზე, მაგრამ ეს მხოლოდ დიდი სურათის ნაწილია. აი, როგორ მუშაობს TrueTime:

• TrueTime იყენებს ორ განსხვავებულ წყაროს: GPS და ატომურ საათებს. ამ საათებს აქვთ არაკორელირებული წარუმატებლობის რეჟიმები. [იხილეთ გვერდი 5 დეტალებისთვის აქ - დაახლ. თარგმანი.), ამიტომ მათი ერთობლივი გამოყენება ზრდის საიმედოობას.
• TrueTime-ს აქვს უჩვეულო API. ის აბრუნებს დროს ინტერვალის სახით გაზომვის შეცდომით და მასში ჩაშენებული გაურკვევლობით. დროის რეალური მომენტი არის სადღაც ინტერვალის ზედა და ქვედა საზღვრებს შორის. Spanner, Google-ის განაწილებული მონაცემთა ბაზა, უბრალოდ ელოდება, სანამ უსაფრთხოდ იქნება იმის თქმა, რომ მიმდინარე დრო დიაპაზონს სცილდება. ეს მეთოდი სისტემაში გარკვეულ შეყოვნებას ნერგავს, განსაკუთრებით იმ შემთხვევაში, თუ მასტერებზე გაურკვევლობა მაღალია, მაგრამ უზრუნველყოფს სისწორეს გლობალურად განაწილებულ სიტუაციაშიც კი.

Spanner კომპონენტები იყენებენ TrueTime-ს, სადაც TT.now() აბრუნებს ინტერვალს, ასე რომ, Spanner უბრალოდ იძინებს იმ წერტილამდე, სადაც დარწმუნდება, რომ მიმდინარე დრომ გაიარა გარკვეული წერტილი.

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

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

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

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

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

• ჩაწერეთ გამტარუნარიანობა და დაყოვნება X ცხრილში ახალი მწკრივის ჩასმისას (50 მილიონი მწკრივით) მითითებული შეზღუდვებით და მწკრივების ჩასმა შესაბამის ცხრილებში.
• გარკვეული მომხმარებლის მეგობრების მეგობრების ჩვენების შეფერხება, როდესაც მეგობრების საშუალო რაოდენობა 500-ია.
• მომხმარებლის ისტორიიდან 100 საუკეთესო ჩანაწერის მოპოვების შეყოვნება, როდესაც მომხმარებელი მიჰყვება 500 სხვა მომხმარებელს X ჩანაწერით საათში.

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

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

ჩადგმული ტრანზაქციები შეიძლება საშიში იყოს

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

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

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

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

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

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

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

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

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

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

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

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

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

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

SELECT * FROM articles where author = "rakyll" order by title;

შედეგების მიღება შესაძლებელია ორი გზით:

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

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

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

ონლაინ მიგრაცია რთულია, მაგრამ შესაძლებელია

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

არსებობს სხვადასხვა ონლაინ მიგრაციის მოდელები. აქ არის ერთი მათგანი:

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

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

მონაცემთა ბაზის მნიშვნელოვანი ზრდა იწვევს არაპროგნოზირებადობის ზრდას

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

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

...

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

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «მონაცემთა ბაზები და Kubernetes (მიმოხილვა და ვიდეო ანგარიში)";
• «Distributed Tracing: ჩვენ არასწორად გავაკეთეთ";
• «სერვისის ბადე: რა უნდა იცოდეს ყველა პროგრამული უზრუნველყოფის ინჟინერმა ყველაზე ცხელი ტექნოლოგიის შესახებ".

წყარო: www.habr.com