Tarantool Data Grid-ის არქიტექტურა და შესაძლებლობები

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

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

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

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

Connector

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

შეყვანის პროცესორი

შეყვანის პროცესორი მიღებულ მონაცემებს ახასიათებს დამახასიათებელი ნიშნების მიხედვით და იძახებს შესაბამის პროცესორებს. დამმუშავებლები არის Lua კოდი, რომელიც მუშაობს ქვიშის ყუთში, ამიტომ მათ არ შეუძლიათ გავლენა მოახდინონ სისტემის ფუნქციონირებაზე. ამ ეტაპზე, მონაცემები შეიძლება შემცირდეს საჭირო ფორმამდე და, საჭიროების შემთხვევაში, შეიძლება დაიწყოს დავალებების თვითნებური რაოდენობა, რომელსაც შეუძლია განახორციელოს საჭირო ლოგიკა. მაგალითად, Tarantool Data Grid-ზე აგებულ MDM (Master Data Management) პროდუქტში ახალი მომხმარებლის დამატებისას, რათა არ შეანელოთ მოთხოვნის დამუშავება, ცალკე დავალებად ვიწყებთ ოქროს ჩანაწერის შექმნას. Sandbox მხარს უჭერს მოთხოვნებს მონაცემების წაკითხვის, შეცვლისა და დამატების შესახებ, საშუალებას გაძლევთ შეასრულოთ გარკვეული ფუნქციები შენახვის ტიპისა და შედეგის აგრეგაციის ყველა როლზე (რუკა/შემცირება).

დამმუშავებლები შეიძლება აღწერილი იყოს ფაილებში:

sum.lua

local x, y = unpack(...)
return x + y

და შემდეგ, გამოცხადებულია კონფიგურაციაში:

functions:
  sum: { __file: sum.lua }

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

შენახვის სივრცე

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

{
    "name": "User",
    "type": "record",
    "logicalType": "Aggregate",
    "fields": [ 
        { "name": "id", "type": "string"}, 
        {"name": "first_name", "type": "string"}, 
        {"name": "last_name", "type": "string"} 
    ], 
    "indexes": ["id"] 
}

ამ აღწერილობიდან გამომდინარე, DDL (მონაცემთა განსაზღვრის ენა) ავტომატურად იქმნება Tarantula DBMS-ისთვის და GraphQL მონაცემთა წვდომის სქემა.

მონაცემთა ასინქრონული რეპლიკაცია მხარდაჭერილია (არსებობს გეგმები სინქრონულის დამატება).

გამომავალი პროცესორი

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

სკალირება

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

მონაცემთა თვისებები

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

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

ამოცანები

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

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

Logger

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

მომსახურება

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

სერვისი აღწერილია კონფიგურაციის ფაილში:

services:
   sum:
      doc: "adds two numbers"
      function: sum
      return_type: int
      args:
         x: int
         y: int

GraphQL API გენერირებულია ავტომატურად და სერვისი ხელმისაწვდომი ხდება დარეკვისთვის:

query {
   sum(x: 1, y: 2) 
}

ეს დაურეკავს დამმუშავებელს sumრომელიც დააბრუნებს შედეგს:

3

შეკითხვის პროფილირება და მეტრიკა

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

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

განლაგება

Tarantool Data Grid შეიძლება განლაგდეს RPM პაკეტებიდან ან არქივიდან, დისტრიბუციის ან Ansible-ის პროგრამის გამოყენებით, ასევე არის Kubernetes-ის მხარდაჭერა (Tarantool Kubernetes ოპერატორი).

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

აპლიკაციების ნიმუშები

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

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

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

რა არის შემდეგი?

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

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

წყარო: www.habr.com