უფრო ღრმა ჩაძირვა Facebook-ის MySQL 8.0 მიგრაციაში

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

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

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

ძირითადი განახლება და განახლება საკუთარი ღრუბლოვანი MySQL სერვისი.

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

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

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

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

დაკავშირებული საკითხია API თავსებადობა და სწორედ აქ აღმოაჩინა ფეისბუქმა ფარული „გოჩა“. როგორც აღინიშნა, მომხმარებლები ჩვეულებრივ აჩერებენ მსხვილი საწარმოების სისტემების მიგრაცია დროისა და შეფერხების გამო, და ამ შემთხვევაში, ეს ნიშნავს, რომ Facebook-მა გამოტოვა ციკლი. იმის ნაცვლად, რომ გადასულიყვნენ MySQL 5.6-დან 5.7-ზე, მათ გამოტოვეს შუალედური გამოშვება და პირდაპირ გადავიდნენ 8.0-ზე. შედეგი იყო მხარდაჭერილ API-ებთან დაკავშირებით დეტექტიური სამუშაოების შესრულების აუცილებლობა; როგორც მათ გაიგეს რთული გზა, რამდენიმე API შეიცვალა 5.6 გამოშვებაში, რომლებიც არ იყო შეტანილი 8.0 დოკუმენტაციაში. ამან დაამატა დროის ჯარიმა.

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

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

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

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

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

საკითხავია, შეიძლება თუ არა ამ თავის ტკივილის თავიდან აცილება ან მინიმუმამდე შემცირება მომავალში, როდესაც ვთქვათ, არსებობს MySQL 9.0. ერთი პასუხი - თუ არ ხართ Facebook - გადადის Cloud Database-as-a-Service DBaaS-ზე), სადაც ღრუბელი მოვაჭრეები მუდმივად შეინახეთ ვერსია მიმდინარე და სავარაუდოდ იზოლირებს კლიენტებს პლატფორმის ძირითადი ცვლილებებისგან.

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