NewSQL = NoSQL+ACID

ბოლო დრომდე Odnoklassniki ინახავდა SQL Server-ში რეალურ დროში დამუშავებულ დაახლოებით 50 ტბ მონაცემს. ასეთი მოცულობისთვის, თითქმის შეუძლებელია SQL DBMS-ის გამოყენებით სწრაფი და საიმედო და მონაცემთა ცენტრის წარუმატებლობის ტოლერანტული წვდომის უზრუნველყოფა. როგორც წესი, ასეთ შემთხვევებში გამოიყენება ერთ-ერთი NoSQL საცავი, მაგრამ ყველაფრის NoSQL-ზე გადატანა არ შეიძლება: ზოგიერთი სუბიექტი მოითხოვს ACID ტრანზაქციის გარანტიებს.

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

როგორ მუშაობს და რა მოხდა - წაიკითხეთ ჭრილის ქვეშ.

დღეს ოდნოკლასნიკის ყოველთვიური აუდიტორია 70 მილიონზე მეტი უნიკალური ვიზიტორია. ჩვენ ჩვენ ხუთეულში ვართ მსოფლიოში ყველაზე დიდი სოციალური ქსელები და იმ ოც საიტს შორის, რომლებზეც მომხმარებლები ყველაზე მეტ დროს ატარებენ. OK ინფრასტრუქტურა უმკლავდება ძალიან დიდ დატვირთვას: მილიონზე მეტი HTTP მოთხოვნა/წმ თითო ფრონტზე. 8000-ზე მეტი ცალი სერვერის ფლოტის ნაწილები განლაგებულია ერთმანეთთან ახლოს - მოსკოვის ოთხ მონაცემთა ცენტრში, რაც მათ შორის 1 ms-ზე ნაკლები ქსელის შეყოვნების საშუალებას იძლევა.

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

თუმცა, ეს არის ყველა ჩვეულებრივი NoSQL კლასტერი, რომელიც გამოიყენება შესანახად სუსტად კოორდინირებული მონაცემები. ჩვენ გვინდოდა შეგვეცვალა ძირითადი თანმიმდევრული მეხსიერება, Microsoft SQL Server, რომელიც გამოიყენება Odnoklassniki-ის დაარსებიდან. საცავი შედგებოდა 300-ზე მეტი SQL Server Standard Edition აპარატისგან, რომელიც შეიცავდა 50 ტბ მონაცემს - ბიზნეს სუბიექტებს. ეს მონაცემები შეცვლილია, როგორც ACID ტრანზაქციების ნაწილი და მოითხოვს მაღალი თანმიმდევრულობა.

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

გაზიარებისა და SQL-ის დაჩქარების წყალობით:

• ჩვენ არ ვიყენებთ უცხოური გასაღების შეზღუდვებს, რადგან განაწილებისას ერთეულის ID შეიძლება განთავსდეს სხვა სერვერზე.
• ჩვენ არ ვიყენებთ შენახულ პროცედურებსა და ტრიგერებს DBMS CPU-ზე დამატებითი დატვირთვის გამო.
• ჩვენ არ ვიყენებთ JOIN-ებს ყოველივე ზემოთქმულის და დისკიდან უამრავი შემთხვევითი წაკითხვის გამო.
• ტრანზაქციის მიღმა, ჩვენ ვიყენებთ Read Uncommitted იზოლაციის დონეს ჩიხების შესამცირებლად.
• ჩვენ ვასრულებთ მხოლოდ მოკლე ტრანზაქციებს (საშუალოდ 100 ms-ზე მოკლე).
• ჩვენ არ ვიყენებთ მრავალ რიგის განახლებას და DELETE-ს ჩიხების დიდი რაოდენობის გამო - ვაახლებთ მხოლოდ ერთ ჩანაწერს ერთდროულად.
• ჩვენ ყოველთვის ვასრულებთ შეკითხვებს მხოლოდ ინდექსებზე - მოთხოვნა ჩვენთვის ცხრილის სრული სკანირების გეგმით ნიშნავს მონაცემთა ბაზის გადატვირთვას და მის წარუმატებლობას.

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

პრობლემები SQL-თან

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

მაგრამ მთავარი პრობლემა ისაა

შეცდომის ტოლერანტობა

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

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

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

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

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

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

მარტივი გარიგება

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

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

ან ფსევდოკოდში:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

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

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

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

სხვა, არანაკლებ მნიშვნელოვანი მოთხოვნები იყო:

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

გადაწყვეტილებები, გადაწყვეტილებები

შესაძლო გადაწყვეტილებების გაანალიზებით, ჩვენ მივედით ორ შესაძლო არქიტექტურულ არჩევანამდე:

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

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

კასანდრა და CQL

მაშ, რა არის კასანდრაში საინტერესო, რა შესაძლებლობები აქვს მას?

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

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

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

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

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

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

რაც გვაკლდა კასანდრაში

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

C * ერთი

ასე დაიბადა ახალი DBMS C * ერთი, რომელიც შედგება სამი ტიპის სერვერის კვანძისგან:

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

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

მომხმარებელთა

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

C*One ტრანზაქციის კოორდინატორი

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

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

საკეტები

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

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

ვინაიდან ჩვენს შემთხვევაში მონაცემები უკვე განაწილებულია SQL-ში ლოკალური ტრანზაქციის ჯგუფებს შორის, გადაწყდა, რომ ადგილობრივი ტრანზაქციის ჯგუფები მიენიჭოთ კოორდინატორებს: ერთი კოორდინატორი ასრულებს ყველა ტრანზაქციას ტოკენებით 0-დან 9-მდე, მეორე - ტოკენებით 10-დან 19-მდე. და ასე შემდეგ. შედეგად, თითოეული კოორდინატორი ინსტანცია ხდება ტრანზაქციის ჯგუფის ოსტატი.

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

კოორდინატორის წარუმატებლობა

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

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

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

გულისცემის შეტყობინებები იგზავნება მაღალი სიხშირით, დაახლოებით 20 ჯერ წამში, 50 ms პერიოდით. ჯავაში რთულია აპლიკაციის პასუხის გარანტია 50 ms-ში, ნაგვის შემგროვებლის მიერ გამოწვეული პაუზების შედარებით ხანგრძლივობის გამო. ჩვენ შევძელით ამ რეაგირების დროის მიღწევა G1 ნაგვის შემგროვებლის გამოყენებით, რომელიც საშუალებას გვაძლევს განვსაზღვროთ სამიზნე GC პაუზების ხანგრძლივობისთვის. თუმცა, ზოგჯერ, საკმაოდ იშვიათად, კოლექტორის პაუზები აღემატება 50 ms-ს, რამაც შეიძლება გამოიწვიოს ცრუ ხარვეზის გამოვლენა. ამის თავიდან ასაცილებლად, კოორდინატორი არ ატყობინებს დისტანციური კვანძის წარუმატებლობას, როდესაც მისგან პირველი გულისცემის შეტყობინება გაქრება, მხოლოდ იმ შემთხვევაში, თუ რამდენიმე გაქრა ზედიზედ. ასე მოვახერხეთ კოორდინატორის კვანძის უკმარისობის აღმოჩენა 200 წელს. ქალბატონი.

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

დაჯავშნა

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

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

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

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

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

როგორ მუშაობს გარიგება

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

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

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

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

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

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

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

ზემოაღნიშნული გაუმჯობესების შედეგად ჩვენ განვახორციელეთ ACID პრინციპები:

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

კითხვა ინდექსების მიხედვით

ავიღოთ მარტივი ცხრილი:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

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

SELECT *
WHERE owner=?
AND modified>?

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

ინდექსები C*One-ში

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

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

ახლა მოთხოვნა „მფლობელი ბოლო დღისთვის“ შეიძლება გადაიწეროს, როგორც სხვა ცხრილის არჩევა:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

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

Რა მოხდა

ჩვენ შევქმენით C*One სამი წლის წინ და გავუშვით კომერციულ ექსპლუატაციაში.

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

როდესაც ჩვენ ვიყენებდით SQL რეპლიკაციის კოეფიციენტით = 1 (მაგრამ RAID 10-ში), ფოტო მეტაინფორმაცია ინახებოდა 32 აპარატის მაღალ ხელმისაწვდომ კლასტერზე, რომელიც მუშაობს Microsoft SQL Server-ზე (პლუს 11 სარეზერვო ასლი). ასევე გამოიყო 10 სერვერი სარეზერვო ასლების შესანახად. სულ 50 ძვირადღირებული მანქანა. ამავდროულად, სისტემა მუშაობდა ნომინალური დატვირთვით, რეზერვის გარეშე.

ახალ სისტემაში მიგრაციის შემდეგ მივიღეთ რეპლიკაციის ფაქტორი = 3 - ასლი თითოეულ მონაცემთა ცენტრში. სისტემა შედგება 63 Cassandra შენახვის კვანძისა და 6 კოორდინატორის აპარატისგან, სულ 69 სერვერისთვის. მაგრამ ეს მანქანები გაცილებით იაფია, მათი საერთო ღირებულება არის SQL სისტემის ღირებულების დაახლოებით 30%. ამავე დროს, დატვირთვა ინახება 30%.

C*One-ის დანერგვით, შეფერხებაც შემცირდა: SQL-ში ჩაწერის ოპერაციას დაახლოებით 4,5 ms დასჭირდა. C*One-ში - დაახლოებით 1,6 ms. ტრანზაქციის ხანგრძლივობა საშუალოდ 40 ms-ზე ნაკლებია, დასრულება სრულდება 2 ms-ში, წაკითხვისა და ჩაწერის ხანგრძლივობა საშუალოდ 2 ms. 99-ე პროცენტული - მხოლოდ 3-3,1 ms, თაიმაუტების რაოდენობა 100-ჯერ შემცირდა - ეს ყველაფერი სპეკულაციის ფართო გამოყენების გამო.

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

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

წყარო: www.habr.com