HighLoad++, მიხაილ ტიულენევი (MongoDB): მიზეზობრივი თანმიმდევრულობა: თეორიიდან პრაქტიკამდე

შემდეგი HighLoad++ კონფერენცია გაიმართება 6 წლის 7 და 2020 აპრილს სანკტ-პეტერბურგში.
დეტალები და ბილეთები по ссылке. HighLoad++ ციმბირი 2019. დარბაზი „კრასნოიარსკი“. 25 ივნისს, 12:00 საათზე. თეზისები და პრეზენტაცია.

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

მიხაილ ტიულენევი (შემდგომში MT): – მე ვისაუბრებ მიზეზობრივი თანმიმდევრულობის შესახებ - ეს არის ფუნქცია, რომელზეც ვიმუშავეთ MongoDB-ში. მე ვმუშაობ განაწილებული სისტემების ჯგუფში, ეს გავაკეთეთ დაახლოებით ორი წლის წინ.

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

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

მიზეზობრივი თანმიმდევრულობა. მოდით განვსაზღვროთ ცნებები

დასაწყისისთვის, მინდა ვთქვა ზოგადად რა არის მიზეზობრივი თანმიმდევრულობა. ორი პერსონაჟია - ლეონარდი და პენი (სერიალი "დიდი აფეთქების თეორია"):

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

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

თანმიმდევრულობის მოდელები

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

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

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

მოდელი Strong

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

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

არის კიდევ ერთი, უფრო ძლიერი თვისება, რომელიც მხარდაჭერილია Spanner-ში - სახელწოდებით External Consistency. ამაზე ცოტა მოგვიანებით ვისაუბრებთ.

გამომწვევი

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

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

საბოლოოდ

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

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

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

რას ნიშნავს ეს ისრები?

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

CAP თეორემა

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

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

ეს თეორემა რეალურად დადასტურდა შემდეგი შემთხვევებისთვის... ჯერ ერთი, ხელმისაწვდომობა განიხილებოდა არა როგორც უწყვეტი მნიშვნელობა ნულიდან ასამდე (0 - სისტემა „მკვდარია“, 100 - სწრაფად პასუხობს; ჩვენ მიჩვეულები ვართ ასე განვიხილოთ) , მაგრამ როგორც ალგორითმის თვისება, რომელიც იძლევა გარანტიას, რომ მისი ყველა შესრულებისთვის იგი აბრუნებს მონაცემებს.

პასუხის დროზე საერთოდ არ არის სიტყვა! არსებობს ალგორითმი, რომელიც აბრუნებს მონაცემებს 100 წლის შემდეგ - აბსოლუტურად მშვენიერი ხელმისაწვდომი ალგორითმი, რომელიც არის CAP თეორემის ნაწილი.
მეორე: თეორემა დადასტურდა იმავე გასაღების მნიშვნელობებში ცვლილებებისთვის, მიუხედავად იმისა, რომ ეს ცვლილებები არის ზომის შეცვლა. ეს ნიშნავს, რომ სინამდვილეში ისინი პრაქტიკულად არ გამოიყენება, რადგან მოდელები განსხვავებულია Eventual Consistency, Strong Consistency (შესაძლოა).

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

მიზეზობრივი თანმიმდევრულობა ყველაზე ძლიერი მოდელია

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

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

MongoDB შიდა სამზარეულო

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

MongoDB (შემდგომში „MongoDB“) არის განაწილებული სისტემა, რომელიც მხარს უჭერს ჰორიზონტალურ სკალირებას, ანუ დაშლას; და თითოეულ ფრაგმენტში ის ასევე მხარს უჭერს მონაცემთა გადაჭარბებას, ანუ რეპლიკაციას.

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

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

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

ჩვენ გავაკეთეთ გამოშვება 4.2 - იქ ახალი საინტერესო რამ გამოჩნდა. კერძოდ, მათ ჩასვეს Lucene - ძიება - კერძოდ შესრულებადი java პირდაპირ Mongo-ში და იქ შესაძლებელი გახდა ძიების განხორციელება Lucene-ის მეშვეობით, იგივე როგორც Elastica-ში.

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

ინგრედიენტები მიზეზობრივი თანმიმდევრულობა

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

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

შეზღუდვები

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

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

ზოგადად, ეს ყველაფერი აწესებს შეზღუდვებს.

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

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

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

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

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

რატომ გადავწყვიტეთ არ გამოგვეყენებინა ეს მიდგომა (სრული თვალყურის დევნება)? ცხადია, რადგან ეს მიდგომა არაპრაქტიკულია: სოციალური ქსელის ნებისმიერი ცვლილება დამოკიდებულია ამ სოციალურ ქსელში არსებულ ყველა წინა ცვლილებაზე, ვთქვათ, Facebook-ის ან VKontakte-ის გადაცემაზე ყოველ განახლებაში. მიუხედავად ამისა, არსებობს უამრავი კვლევა სრული დამოკიდებულების თვალთვალის შესახებ - ეს არის პრესოციალური ქსელები; ზოგიერთ სიტუაციაში ეს ნამდვილად მუშაობს.

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

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

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

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

ლამპორტის საათი

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

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

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

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

ასე რომ, ამ Lamport საათისა და მიზეზობრივი თანმიმდევრულობის მთავარი თვისება (ახსნილია Lamport Clock-ის საშუალებით) არის ეს: თუ გვაქვს მოვლენები A და B, და მოვლენა B დამოკიდებულია მოვლენაზე A*-ზე, მაშინ გამოდის, რომ მოვლენის A ლოგიკური დრო ნაკლებია ვიდრე LogicalTime B მოვლენიდან.

* ზოგჯერ ისინი ასევე ამბობენ, რომ A მოხდა B-მდე, ანუ A მოხდა B-მდე - ეს არის გარკვეული მიმართება, რომელიც ნაწილობრივ აწესრიგებს მოვლენების მთელ კომპლექსს, რაც მოხდა ზოგადად.

პირიქით არასწორია. ეს არის რეალურად Lamport Clock-ის ერთ-ერთი მთავარი მინუსი - ნაწილობრივი შეკვეთა. არსებობს კონცეფცია ერთდროულ მოვლენებზე, ანუ მოვლენებზე, რომლებშიც არც (A მოხდა B-მდე) და არც (A მოხდა B-მდე). მაგალითი შეიძლება იყოს ლეონარდის მიერ სხვის მეგობრად დამატება (არა ლეონარდი, შელდონი, მაგალითად).
ეს ის თვისებაა, რომელსაც ხშირად იყენებენ Lamport-ის საათებთან მუშაობისას: ისინი კონკრეტულად უყურებენ ფუნქციას და აქედან ასკვნიან, რომ შესაძლოა ეს მოვლენები დამოკიდებულია. რადგან ერთი გზა მართალია: თუ LogicalTime A ნაკლებია LogicalTime B-ზე, მაშინ B არ შეიძლება მოხდეს A-მდე; და თუ მეტი, მაშინ შესაძლოა.

ვექტორული საათი

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

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

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

სპანერი TrueTime. ატომური საათი

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

რა იდეაა? "Spanner" არის Google სისტემა, რომელიც ახლახან ხელმისაწვდომი გახდა ხალხისთვის (მათ დაამატეს მას SQL). იქ თითოეულ ტრანზაქციას აქვს გარკვეული დროის ბეჭედი. იმის გამო, რომ დრო სინქრონიზებულია*, თითოეულ მოვლენას შეიძლება მიენიჭოს კონკრეტული დრო - ატომურ საათებს აქვთ მოლოდინის დრო, რის შემდეგაც გარანტირებულია სხვა დროის „მოხდება“.

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

* ეს არის Lampart საათების მთავარი პრობლემა - ისინი არასოდეს არიან სინქრონული განაწილებულ სისტემებზე. მათ შეუძლიათ განსხვავდებიან; თუნდაც NTP-ით, ისინი მაინც არ მუშაობენ ძალიან კარგად. "სპანერს" აქვს ატომური საათი და სინქრონიზაცია, როგორც ჩანს, მიკროწამია.

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

ჰიბრიდული საათი

ეს არის ფაქტობრივად ის, რაც იკლებს MongoDB-ში მიზეზობრივი თანმიმდევრულობის უზრუნველსაყოფად. როგორ არიან ისინი ჰიბრიდული? ჰიბრიდი არის სკალარული მნიშვნელობა, მაგრამ მას აქვს ორი კომპონენტი:

• პირველი არის Unix-ის ეპოქა (რამდენი წამი გავიდა "კომპიუტერის სამყაროს დასაწყისიდან").
• მეორე არის გარკვეული ზრდა, ასევე 32-ბიტიანი ხელმოუწერელი ინტ.

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

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

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

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

საათის სინქრონიზაცია

სამეცნიერო ლიტერატურაში აღწერილია სინქრონიზაციის რამდენიმე მეთოდი. მე ვსაუბრობ სინქრონიზაციაზე, როდესაც გვაქვს ორი განსხვავებული ფრაგმენტი. თუ არსებობს ერთი რეპლიკა კომპლექტი, არ არის საჭირო რაიმე სინქრონიზაცია: ეს არის "ერთი ოსტატი"; ჩვენ გვაქვს OpLog, რომელშიც ყველა ცვლილება მოდის - ამ შემთხვევაში, ყველაფერი უკვე თანმიმდევრულად არის დალაგებული თავად "Oplog"-ში. მაგრამ თუ გვაქვს ორი განსხვავებული ფრაგმენტი, აქ დროის სინქრონიზაცია მნიშვნელოვანია. ეს არის ის, სადაც ვექტორული საათი უფრო მეტად დაეხმარა! მაგრამ ჩვენ არ გვაქვს ისინი.

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

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

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

როგორ მუშაობს ეს ყველაფერი ერთად?

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

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

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

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

"Oplog"-ში უკვე ჩაწერილი მნიშვნელობა დაბრუნდა - ჩვენ ვიცით, რომ "Oplog" უკვე შეიცავს ამ მნიშვნელობას და მისი დრო არის 12. ახლა, ვთქვათ, კითხვა იწყება სხვა კვანძიდან (მეორადი) და ის გადასცემს შემდეგ ClusterTime-ს. შეტყობინება. ის ამბობს: „მე მჭირდება ყველაფერი, რაც მოხდა 12-ის ან თორმეტის შემდეგ მაინც“ (იხ. სურათი ზემოთ).

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

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

ეს ყველაფერი თითქმის ასე მუშაობს. თითქმის.

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

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

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

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

ჩვენი გზაა ხელი მოვაწეროთ clusterTime-ს

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

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

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

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

გააკეთე სწრაფად!

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

ასეთი ხელმოწერის მიღებით ჩვენ ვაჩქარებთ სისტემას (შედარებით) 65 ათასჯერ. ეს მშვენივრად მუშაობს: როდესაც ჩვენ ექსპერიმენტებს ვატარებდით, დრო რეალურად 10 ათასით შემცირდა, როდესაც თანმიმდევრული განახლება გვქონდა. ნათელია, რომ როდესაც ისინი წინააღმდეგობაში არიან, ეს არ მუშაობს. მაგრამ უმეტეს შემთხვევაში ის მუშაობს. Range ხელმოწერის კომბინაციამ ხელმოწერასთან ერთად გადაჭრა უსაფრთხოების პრობლემა.

რა ვისწავლეთ?

გაკვეთილები ვისწავლეთ აქედან:

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

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

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

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

ამით დავამთავრებ. Გმადლობთ!

კითხვები

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

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

In: – მინდოდა გამეგო, როგორ ხდება სინქრონიზაცია და არჩევა ერთ ლოგიკურ დროს?

MT: - ძალიან მარტივია სინქრონიზაცია. Shard, როდესაც afterClusterTime მოდის მასთან და ის ვერ პოულობს დროს "Oplog"-ში, იწყებს არ დამტკიცებას. ანუ ის თავის დროს ხელებით ამაღლებს ამ ღირებულებამდე. ეს ნიშნავს, რომ მას არ აქვს ამ მოთხოვნის შესაბამისი მოვლენები. ის ამ მოვლენას ხელოვნურად ქმნის და ამით ხდება მიზეზობრივი თანმიმდევრული.

In: – რა მოხდება, თუ ამის შემდეგ მას სხვა მოვლენები მოუვიდა, რომლებიც სადღაც ქსელში დაიკარგა?

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

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

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

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

In: – როდესაც ჩვენ ვქმნით ინსტანციას, რომელიც ახორციელებს ჩვენთვის დაშლას (შესაბამისად, არა master, არამედ slave), ის ეყრდნობა საკუთარი აპარატის Unix-ის დროს ან „ოსტატის“ დროს; სინქრონიზდება პირველად თუ პერიოდულად?

MT: – ახლავე დავაზუსტებ. Shard (ანუ ჰორიზონტალური დანაყოფი) - იქ ყოველთვის არის Primary. და ნატეხს შეიძლება ჰქონდეს "ოსტატი" და შეიძლება იყოს რეპლიკა. მაგრამ ფრაგმენტი ყოველთვის მხარს უჭერს ჩაწერას, რადგან მას უნდა ჰქონდეს გარკვეული დომენის მხარდაჭერა (ნატეხს აქვს ძირითადი).

In: – მაშ, ყველაფერი მხოლოდ „ოსტატზე“ არის დამოკიდებული? ყოველთვის გამოიყენება სამაგისტრო დრო?

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

In: – გვყავს კლიენტი, რომელიც აკავშირებს და არ უნდა იცოდეს რაიმე დროის შესახებ?

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

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

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

In: – გამოთვლითი მეცნიერების ახალი ფენა – CRDT (Conflict-free Replicated Data Types) მონაცემთა ტიპები – მტკიცედ არის დაკავშირებული Eventual Consistency-ის თემასთან. გიფიქრიათ თუ არა ამ ტიპის მონაცემთა ბაზაში ინტეგრირება და რას იტყვით ამაზე?

MT: - კარგი კითხვაა! CRDT აზრი აქვს ჩაწერის კონფლიქტებს: MongoDB-ში, ერთი ძირითადი.

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

MT: – ბოროტი ადამიანები პერიმეტრში ტროას ცხენივით არიან! ბოროტ ადამიანებს პერიმეტრის შიგნით შეუძლიათ ბევრი ცუდის გაკეთება.

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

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

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

In: – დაცულ პერიმეტრში ვიღაც ცდილობდა შეექმნა სერვერისთვის მოულოდნელი პროტოკოლები, რათა მთლიანად გაენადგურებინა სერვერი და თუ გაგიმართლა, მთელი კლასტერი... ოდესმე ასე „კარგს“?

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

In: - მადლობა მოხსენებისთვის. სერგეი (იანდექსი). მონგში არის მუდმივი, რომელიც ზღუდავს ხმის მიცემის წევრთა რაოდენობას Replica Set-ში და ეს მუდმივი არის 7 (შვიდი). რატომ არის ეს მუდმივი? რატომ არ არის ეს ერთგვარი პარამეტრი?

MT: – ჩვენ გვაქვს Replica Sets 40 კვანძით. ყოველთვის არის უმრავლესობა. არ ვიცი რომელი ვერსია...

In: – Replica Set-ში შეგიძლიათ გაუშვათ ხმის არმქონე წევრები, მაგრამ არის მაქსიმუმ 7 ხმის მიცემის წევრი. როგორ გადავრჩეთ გამორთვას ამ შემთხვევაში, თუ ჩვენი Replica Set განაწილებულია 3 მონაცემთა ცენტრში? ერთი მონაცემთა ცენტრი შეიძლება ადვილად გამორთოს, ხოლო მეორე მანქანა შეიძლება ამოვარდეს.

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

რამდენიმე რეკლამა 🙂

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com