გადაწერეთ VKontakte შეტყობინებების მონაცემთა ბაზა ნულიდან და გადარჩით

ჩვენი მომხმარებლები ერთმანეთს დაღლილობის გარეშე წერენ შეტყობინებებს.

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

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

ჩვენთვის ეს მომენტი წელიწადნახევრის წინ დადგა. როგორ მივედით აქამდე და რა მოხდა ბოლოს - თანმიმდევრობით მოგიყვებით.

შემთხვევაში ისტორია

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

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

ტექსტურ ძრავში შეტყობინებები ინახებოდა სიებში - ერთგვარი "ფოსტის ყუთები". თითოეულ ასეთ სიას განსაზღვრავს uid - მომხმარებელი, რომელიც ფლობს ყველა ამ შეტყობინებას. შეტყობინებას აქვს ატრიბუტების ნაკრები: თანამოსაუბრის იდენტიფიკატორი, ტექსტი, დანართები და ა.შ. შეტყობინებების იდენტიფიკატორი "box"-ში არის local_id, ის არასოდეს იცვლება და თანმიმდევრულად ენიჭება ახალ შეტყობინებებს. "ყუთები" დამოუკიდებელია და არ არის სინქრონიზებული ერთმანეთთან ძრავის შიგნით; მათ შორის კომუნიკაცია ხდება PHP დონეზე. თქვენ შეგიძლიათ ნახოთ ტექსტური ძრავის მონაცემთა სტრუქტურა და შესაძლებლობები შიგნიდან აქ.

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

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

„PHP, მოდით, გაგზავნოთ შეტყობინება ჩატში“, ამბობს მომხმარებელი.
„მოდით, {username}“, ამბობს PHP.

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

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

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

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

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

ახალი კონცეფცია

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

საჭირო მინიმუმია ორი ახალი მონაცემთა ბაზა:

• ჩატის ძრავა. ეს არის ჩატის ვექტორების საცავი. თითოეულ ჩატს აქვს მასთან დაკავშირებული შეტყობინებების ვექტორი. თითოეულ შეტყობინებას აქვს ტექსტი და უნიკალური შეტყობინების იდენტიფიკატორი ჩატის შიგნით - chat_local_id.
• მომხმარებლის ძრავა. ეს არის მომხმარებლის ვექტორების საცავი - მომხმარებლების ბმულები. თითოეულ მომხმარებელს აქვს peer_id-ის ვექტორი (თანამოსაუბრეები - სხვა მომხმარებლები, მრავალ ჩატი ან თემები) და შეტყობინებების ვექტორი. თითოეულ peer_id-ს აქვს შეტყობინებების ვექტორი, რომელიც ეხება მას. თითოეულ შეტყობინებას აქვს chat_local_id და უნიკალური შეტყობინების ID ამ მომხმარებლისთვის - user_local_id.

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

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

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

შეტყობინების გაგზავნა ახალ სქემაში ასე გამოიყურება:

1. PHP backend დაუკავშირდება მომხმარებლის ძრავას შეტყობინების გაგზავნის მოთხოვნით.
2. user-engine ახორციელებს მოთხოვნას სასურველ ჩეთ-ძრავის მაგალითზე, რომელიც უბრუნდება მომხმარებლის ძრავის chat_local_id-ს - ახალი შეტყობინების უნიკალური იდენტიფიკატორი ამ ჩატში. შემდეგ chat_engine ავრცელებს შეტყობინებას ჩატში ყველა მიმღებს.
3. user-engine იღებს chat_local_id-ს chat-engine-დან და აბრუნებს user_local_id-ს PHP-ში - უნიკალური შეტყობინების იდენტიფიკატორი ამ მომხმარებლისთვის. ეს იდენტიფიკატორი შემდეგ გამოიყენება, მაგალითად, API-ის საშუალებით შეტყობინებებთან მუშაობისთვის.

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

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

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

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

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

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

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

Მიგრაციის თარიღი

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

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

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

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

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

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

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

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

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

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

მონაცემები იწერება ჩატის წევრებსა და მომხმარებლის ძრავზე (და არა ტექსტურ ძრავზე, როგორც ჩვეულებრივ ფუნქციონირებაში ძველი სქემის მიხედვით). მომხმარებლის ძრავა ახორციელებს მოთხოვნას ჩეთ-ძრავზე - და აქ ქცევა დამოკიდებულია იმაზე, უკვე გაერთიანდა ეს ჩატი თუ არა. თუ ჩატი ჯერ არ არის გაერთიანებული, ჩატის ძრავა არ წერს შეტყობინებას თავისთვის და მისი დამუშავება ხდება მხოლოდ ტექსტურ ძრავში. თუ ჩატი უკვე გაერთიანდა chat-engine-ში, ის უბრუნებს chat_local_id-ს მომხმარებლის ძრავში და აგზავნის შეტყობინებას ყველა მიმღებს. მომხმარებლის ძრავა გადასცემს ყველა მონაცემს ტექსტურ ძრავში - ასე რომ, თუ რამე მოხდება, ჩვენ ყოველთვის შეგვიძლია უკან დავაბრუნოთ, ყველა მიმდინარე მონაცემი ძველ ძრავში გვქონდეს. text-engine აბრუნებს user_local_id-ს, რომელსაც user-engine ინახავს და აბრუნებს backend-ში.

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

დასკვნები

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

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

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

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

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

წყარო: www.habr.com