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

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

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

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

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

ვინ და როგორ იყენებს In-Memory-ს

In-Memory ყველაზე ხშირად გამოიყენება იქ, სადაც საჭიროა მომხმარებლის სწრაფი ურთიერთქმედება ან დიდი რაოდენობით მონაცემების დამუშავება.

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

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

მეხსიერებაში, როგორც პირველადი საცავი

ჩვენი ერთ-ერთი კლიენტი არის სამედიცინო სამეცნიერო აღჭურვილობის დიდი მიმწოდებელი აშშ-დან. ისინი იყენებენ In-Memory გადაწყვეტას, როგორც მონაცემთა ძირითად შესანახად. ყველა მონაცემი ინახება დისკზე, ხოლო მონაცემთა ქვეჯგუფი, რომელიც აქტიურად გამოიყენება, ინახება RAM-ში. შენახვის წვდომის მეთოდები სტანდარტულია - GDBC (Generic Database Connector) და SQL შეკითხვის ენა.

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

IMDB მახასიათებლები:

• მონაცემები, რომლებიც ინახება In-Memory-ში და ხელმისაწვდომია SQL-ის საშუალებით, იგივეა, რაც სხვა მიდგომებში. ისინი სინქრონიზებულია, განსხვავებულია მხოლოდ პრეზენტაციის, მიმართვის ხერხი. ტრანზაქცია მუშაობს მონაცემებს შორის.

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

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

შეცდომის ტოლერანტული აპლიკაციების შესაქმნელად

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

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

რა ხდება, როდესაც ერთ-ერთი სერვერი მარცხდება?

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

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

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

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

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

ჰიბრიდული ტრანზაქციების ანალიტიკური დამუშავება (HTAP)

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

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

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

In-Memory გადაწყვეტილებების ინტეგრაცია

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

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

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

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

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

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

წყარო: www.habr.com