2019 წლის შემოდგომაზე Mail.ru Cloud iOS გუნდში დიდი ხნის ნანატრი ღონისძიება გაიმართა. აპლიკაციის მდგომარეობის მუდმივი შენახვის ძირითადი მონაცემთა ბაზა საკმაოდ ეგზოტიკური გახდა მობილური სამყაროსთვის Lightning Memory-Mapped მონაცემთა ბაზა (LMDB). ჭრის ქვეშ, თქვენი ყურადღება მიიპყრობს მის დეტალურ მიმოხილვას ოთხ ნაწილად. პირველ რიგში, მოდით ვისაუბროთ ასეთი არატრივიალური და რთული არჩევანის მიზეზებზე. შემდეგ მოდით გადავიდეთ სამი ვეშაპის განხილვაზე LMDB არქიტექტურის გულში: მეხსიერების რუკაზე დატანილი ფაილები, B + ხე, ასლი ჩაწერის მიდგომა ტრანზაქციის და მულტივერსიის განხორციელებისთვის. და ბოლოს, დესერტისთვის - პრაქტიკული ნაწილი. მასში ჩვენ განვიხილავთ, თუ როგორ შევქმნათ და განვახორციელოთ საბაზისო სქემა რამდენიმე ცხრილით, მათ შორის ინდექსური, დაბალი დონის გასაღების ღირებულების API-ს თავზე.

ინფორმაციის

1. განხორციელების მოტივაცია
2. LMDB პოზიციონირება
3. სამი ვეშაპი LMDB
   3.1. ვეშაპი #1. მეხსიერებით შედგენილი ფაილები
   3.2. ვეშაპი #2. B+-ხე
   3.3. ვეშაპი #3. კოპირება ჩაწერაზე
4. მონაცემთა სქემის შემუშავება გასაღები-მნიშვნელობის API-ს თავზე
   4.1. ძირითადი აბსტრაქციები
   4.2. მაგიდის მოდელირება
   4.3. ცხრილებს შორის ურთიერთობების მოდელირება

1. განხორციელების მოტივაცია

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

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

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

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

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

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

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

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

1. ძაფის უსაფრთხოება.
2. მრავალპროცესირება. ნაკარნახევია მონაცემთა ბაზის იგივე მაგალითის გამოყენების სურვილით, რათა მოხდეს მდგომარეობის სინქრონიზაცია არა მხოლოდ ძაფებს შორის, არამედ მთავარ აპლიკაციასა და iOS გაფართოებებს შორის.
3. შენახული ერთეულების არაცვალებადი ობიექტების სახით წარმოდგენის შესაძლებლობა
4. დინამიური განაწილების ნაკლებობა CRUD ოპერაციებში.
5. ტრანზაქციის მხარდაჭერა ძირითადი თვისებებისთვის ACIDსაკვანძო სიტყვები: ატომურობა, თანმიმდევრულობა, იზოლაცია და საიმედოობა.
6. სიჩქარე ყველაზე პოპულარულ შემთხვევებზე.

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

2. LMDB პოზიციონირება

LMDB არის ბიბლიოთეკა, ძალიან მცირე (მხოლოდ 10K ხაზი), რომელიც ახორციელებს მონაცემთა ბაზის ყველაზე დაბალ ფუნდამენტურ ფენას - საცავს.

ზემოთ მოყვანილი დიაგრამა აჩვენებს, რომ LMDB-ის შედარება SQLite-თან, რომელიც ახორციელებს კიდევ უფრო მაღალ დონეებს, ზოგადად არ არის უფრო სწორი, ვიდრე SQLite Core Data-ით. უფრო სამართლიანი იქნებოდა იგივე შესანახი ძრავების მოხსენიება, როგორც თანაბარი კონკურენტები - BerkeleyDB, LevelDB, Sophia, RocksDB და ა.შ. არსებობს განვითარებაც კი, სადაც LMDB მოქმედებს როგორც SQLite-ის შენახვის ძრავის კომპონენტი. პირველი ასეთი ექსპერიმენტი 2012 წელს გაატარა ავტორი LMDB ჰოვარდ ჩუ. დასკვნები იმდენად დამაინტრიგებელი აღმოჩნდა, რომ მისი ინიციატივა OSS-ის ენთუზიასტებმა აიტაცეს და მისი გაგრძელება იპოვეს. LumoSQL. 2020 წლის იანვარში ამ პროექტის ავტორია დენ შირერი წარმოდგენილი ის LinuxConfAu-ზე.

LMDB-ის ძირითადი გამოყენება არის როგორც ძრავა აპლიკაციების მონაცემთა ბაზებისთვის. ბიბლიოთეკა თავის გარეგნობას დეველოპერებს ევალება OpenLDAP, რომლებიც კატეგორიულად უკმაყოფილონი იყვნენ BerkeleyDB-ით, როგორც მათი პროექტის საფუძველი. უბიძგებს მოშორებით თავმდაბალი ბიბლიოთეკა ბხეჰოვარდ ჩუმ შეძლო ჩვენი დროის ერთ-ერთი ყველაზე პოპულარული ალტერნატივის შექმნა. მან თავისი ძალიან მაგარი მოხსენება მიუძღვნა ამ ამბავს, ასევე LMDB-ის შიდა სტრუქტურას. "ელვისებური მეხსიერების რუქის მონაცემთა ბაზა". ლეონიდ იურიევი (aka ილეო) Positive Technologies-დან მის გამოსვლაში Highload 2015-ზე "LMDB ძრავა განსაკუთრებული ჩემპიონია". მასში ის საუბრობს LMDB-ზე ReOpenLDAP-ის დანერგვის მსგავსი ამოცანის კონტექსტში და LevelDB უკვე დაექვემდებარა შედარებითი კრიტიკას. განხორციელების შედეგად Positive Technologies-მაც კი მიიღო აქტიურად განვითარებადი ჩანგალი MDBX ძალიან გემრიელი ფუნქციებით, ოპტიმიზაციით და ხარვეზის შესწორება.

LMDB ხშირად გამოიყენება როგორც შესანახად. მაგალითად, Mozilla Firefox ბრაუზერი აირჩია იგი მთელი რიგი საჭიროებისთვის და, დაწყებული 9 ვერსიიდან, Xcode სასურველია მისი SQLite ინდექსების შესანახად.

ძრავა ასევე დაიჭირა მობილური განვითარების სამყაროში. მისი გამოყენების კვალი შეიძლება იყოს იპოვოს iOS კლიენტში Telegram-ისთვის. LinkedIn-მა ერთი ნაბიჯით წინ წავიდა და აირჩია LMDB, როგორც ნაგულისხმევი საცავი მისი მშობლიური მონაცემთა ქეშირების ჩარჩოსთვის, Rocket Data, რომლის შესახებაც უთხრა სტატიაში 2016 წელს.

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

3. სამი ვეშაპი LMDB

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

1. მეხსიერებით შედგენილი ფაილები, როგორც დისკთან მუშაობის მექანიზმი და მონაცემთა შიდა სტრუქტურების სინქრონიზაცია.
2. B+-ხე, როგორც შენახული მონაცემთა სტრუქტურის ორგანიზაცია.
3. Copy-on-Write როგორც მიდგომა ACID ტრანზაქციის თვისებებისა და მრავალვერსიის უზრუნველსაყოფად.

3.1. ვეშაპი #1. მეხსიერებით შედგენილი ფაილები

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

1. საცავში მონაცემთა თანმიმდევრულობის შენარჩუნება რამდენიმე პროცესიდან მასთან მუშაობისას ხდება ოპერაციული სისტემის პასუხისმგებლობა. შემდეგ განყოფილებაში ეს მექანიკა დეტალურად და სურათებით არის განხილული.
2. ქეშების არარსებობა მთლიანად ათავისუფლებს LMDB-ს ზედნადებისგან, რომელიც დაკავშირებულია დინამიურ განაწილებასთან. პრაქტიკაში მონაცემების წაკითხვა ნიშნავს მაჩვენებლის სწორ მისამართზე დაყენებას ვირტუალურ მეხსიერებაში და მეტი არაფერი. ჟღერს როგორც ფანტაზია, მაგრამ საცავის წყაროში ყველა calloc ზარი კონცენტრირებულია საცავის კონფიგურაციის ფუნქციაში.
3. ქეშების არარსებობა ასევე ნიშნავს საკეტების არარსებობას, რომლებიც დაკავშირებულია სინქრონიზაციასთან მათზე წვდომისთვის. მკითხველები, რომელთა თვითნებური რიცხვი ერთდროულად შეიძლება არსებობდეს, მონაცემებისკენ მიმავალ გზაზე არც ერთ მუტექსს არ აწყდებიან. ამის გამო წაკითხვის სიჩქარეს აქვს იდეალური ხაზოვანი მასშტაბირება CPU-ების რაოდენობის მიხედვით. LMDB-ში სინქრონიზებულია მხოლოდ მოდიფიცირებული ოპერაციები. შეიძლება იყოს მხოლოდ ერთი მწერალი ერთდროულად.
4. ქეშირებისა და სინქრონიზაციის მინიმალური ლოგიკა ინახავს კოდს უკიდურესად რთული ტიპის შეცდომებისგან, რომლებიც დაკავშირებულია მრავალ ხრახნიან გარემოში მუშაობასთან. Usenix OSDI 2014 კონფერენციაზე ორი საინტერესო მონაცემთა ბაზა იყო: "ყველა ფაილური სისტემა არ არის შექმნილი თანაბარი: Craft-ის თანმიმდევრული აპლიკაციების შექმნის სირთულეზე" и გართობისა და მოგების მიზნით მონაცემთა ბაზების წამება. მათგან შეგიძლიათ მიიღოთ ინფორმაცია როგორც LMDB-ის უპრეცედენტო საიმედოობის შესახებ, ასევე ტრანზაქციების ACID თვისებების თითქმის უნაკლო განხორციელების შესახებ, რაც მას აჭარბებს იმავე SQLite-ში.
5. LMDB-ის მინიმალიზმი საშუალებას აძლევს მისი კოდის მანქანურ წარმოდგენას მთლიანად განთავსდეს პროცესორის L1 ქეშში მიღებული სიჩქარის მახასიათებლებით.

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

ზოგადი ინფორმაცია მეხსიერებით შედგენილი ფაილების შესახებ

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

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

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

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

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

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

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

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

მეხსიერებით შედგენილი ფაილების სპეციფიკა iOS-ში

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

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

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

კარგი ამბავი, რომელიც უკვე აღვნიშნეთ, არის ის, რომ LMDB არ იყენებს mmap მექანიზმს ფაილების ნაგულისხმევად განახლებისთვის. აქედან გამომდინარეობს, რომ გაცემული მონაცემები კლასიფიცირდება როგორც სუფთა მეხსიერება iOS-ის მიერ და არ უწყობს ხელს მეხსიერების კვალს. ამის გადამოწმება შესაძლებელია Xcode ინსტრუმენტის გამოყენებით, სახელწოდებით VM Tracker. ქვემოთ მოყვანილი სკრინშოტი აჩვენებს iOS Cloud აპლიკაციის ვირტუალური მეხსიერების მდგომარეობას მუშაობის დროს. დასაწყისში მასში ინიციალიზაცია მოხდა 2 LMDB ინსტანცია. პირველს მიეცა საშუალება დაეწერა თავისი ფაილი 1GiB ვირტუალურ მეხსიერებაზე, მეორეს - 512MiB. მიუხედავად იმისა, რომ ორივე საცავი იკავებს რეზიდენტული მეხსიერების გარკვეულ რაოდენობას, არცერთი მათგანი არ უწყობს ხელს ბინძურ ზომას.

ახლა ცუდი ამბების დროა. 64-ბიტიან დესკტოპის ოპერაციულ სისტემებში სვოპის მექანიზმის წყალობით, თითოეულ პროცესს შეუძლია დაიკავოს იმდენი ვირტუალური მისამართის ადგილი, რამდენადაც თავისუფალი ადგილი მყარ დისკზე იძლევა მის პოტენციურ გაცვლას. IOS-ში სვოპის შეკუმშვით შეცვლა მკვეთრად ამცირებს თეორიულ მაქსიმუმს. ახლა ყველა ცოცხალი პროცესი უნდა შეესაბამებოდეს მთავარ (წაიკითხეთ RAM) მეხსიერებას და ყველა ის, რაც არ ჯდება, ექვემდებარება იძულებით შეწყვეტას. აღნიშნულია როგორც ზემოთ მოხსენება, და ოფიციალური დოკუმენტაცია. შედეგად, iOS მკვეთრად ზღუდავს მეხსიერების რაოდენობას, რომელიც ხელმისაწვდომია mmap-ის საშუალებით გამოსაყოფად. Აქ აქ შეგიძლიათ ნახოთ ემპირიული ლიმიტები მეხსიერების მოცულობის შესახებ, რომელიც შეიძლება გამოიყოს სხვადასხვა მოწყობილობებზე ამ სისტემური ზარის გამოყენებით. სმარტფონების ყველაზე თანამედროვე მოდელებზე iOS 2 გიგაბაიტით კეთილშობილური გახდა, ხოლო iPad-ის ტოპ ვერსიებზე - 4-ით. პრაქტიკაში, რა თქმა უნდა, ყურადღება უნდა გაამახვილოთ ყველაზე ახალგაზრდა მხარდაჭერილ მოწყობილობის მოდელებზე, სადაც ყველაფერი ძალიან სამწუხაროა. კიდევ უფრო უარესი, თუ გადავხედავთ აპლიკაციის მეხსიერების მდგომარეობას VM Tracker-ში, აღმოაჩენთ, რომ LMDB შორს არის ერთადერთი, რომელიც აცხადებს მეხსიერების რუკაზე დაწერილ მეხსიერებას. კარგ ნაწილებს ჭამს სისტემის გამანაწილებლები, რესურსების ფაილები, გამოსახულების ჩარჩოები და სხვა პატარა მტაცებლები.

Cloud-ში ექსპერიმენტების შედეგად მივიღეთ LMDB-ის მიერ გამოყოფილი მეხსიერების შემდეგი კომპრომისული მნიშვნელობები: 384 მეგაბაიტი 32-ბიტიანი მოწყობილობებისთვის და 768 64-ბიტიანი მოწყობილობებისთვის. ამ მოცულობის ამოწურვის შემდეგ, ნებისმიერი მოდიფიცირებული ოპერაცია იწყება კოდით MDB_MAP_FULL. ჩვენ ვაკვირდებით ასეთ შეცდომებს ჩვენს მონიტორინგში, მაგრამ ისინი საკმარისად მცირეა, რომ ამ ეტაპზე უგულებელყოფილი იყოს.

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

3.2. ვეშაპი #2. B+-ხე

გასაღების მნიშვნელობის მაღაზიის თავზე ცხრილების ემულაციისთვის, შემდეგი ოპერაციები უნდა იყოს წარმოდგენილი მის API-ში:

1. ახალი ელემენტის ჩასმა.
2. მოძებნეთ ელემენტი მოცემული გასაღებით.
3. ელემენტის წაშლა.
4. გაიმეორეთ ძირითადი ინტერვალებით მათი დალაგების თანმიმდევრობით.

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

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

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

ამით:

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

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

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

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

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

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

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

3.3. ვეშაპი #3. კოპირება ჩაწერაზე

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

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

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

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

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

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

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

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

4. მონაცემთა სქემის შემუშავება გასაღები-მნიშვნელობის API-ს თავზე

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

შენიშვნა კოდების ჩამონათვალის შესახებ

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

როგორც ყველაზე სწრაფი გზა LMDB iOS ან macOS პროექტთან დასაკავშირებლად, მე გთავაზობთ ჩემს CocoaPod-ს POSLMDB.

4.1. ძირითადი აბსტრაქციები

გარემო

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

mdb_env_create(env);​
mdb_env_set_map_size(*env, 1024 * 1024 * 512)​
mdb_env_open(*env, path.UTF8String, MDB_NOTLS, 0664);

Mail.ru Cloud აპლიკაციაში ჩვენ შევცვალეთ ნაგულისხმევი მნიშვნელობები მხოლოდ ორი პარამეტრისთვის.

პირველი არის ვირტუალური მისამართის სივრცის ზომა, რომელზედაც შედგენილია შენახვის ფაილი. სამწუხაროდ, იმავე მოწყობილობაზეც კი, კონკრეტული მნიშვნელობა შეიძლება მნიშვნელოვნად განსხვავდებოდეს გაშვებამდე. iOS-ის ამ ფუნქციის გასათვალისწინებლად, ჩვენ ვირჩევთ შენახვის მაქსიმალურ რაოდენობას დინამიურად. გარკვეული მნიშვნელობიდან დაწყებული, ის თანმიმდევრულად განახევრდება ფუნქციამდე mdb_env_open არ დააბრუნებს სხვა შედეგს გარდა ENOMEM. თეორიულად, არსებობს საპირისპირო გზა - ჯერ დაუთმეთ ძრავას მინიმალური მეხსიერება, შემდეგ კი შეცდომების მიღებისას. MDB_MAP_FULL, გაზარდეთ. თუმცა ბევრად უფრო ეკლიანია. მიზეზი ის არის, რომ ფუნქციის გამოყენებით მეხსიერების გადაკეთების პროცედურა mdb_env_set_map_size გააუქმებს ძრავიდან ადრე მიღებულ ყველა ერთეულს (კურსორებს, ტრანზაქციას, გასაღებს და მნიშვნელობებს). კოდში მოვლენების ასეთი შემობრუნების აღრიცხვა მის მნიშვნელოვან გართულებას გამოიწვევს. თუ, მიუხედავად ამისა, ვირტუალური მეხსიერება თქვენთვის ძალიან ძვირფასია, მაშინ ეს შეიძლება იყოს მიზეზი, რომ გადახედოთ იმ ჩანგალს, რომელიც წინ წავიდა. MDBX, სადაც დეკლარირებულ მახასიათებლებს შორის არის „ავტომატური ფრენის დროს მონაცემთა ბაზის ზომის კორექტირება“.

მეორე პარამეტრი, რომლის ნაგულისხმევი მნიშვნელობა არ შეგვეფერება, არეგულირებს ძაფის უსაფრთხოების უზრუნველყოფის მექანიზმს. სამწუხაროდ, iOS 10-ში მაინც არის პრობლემები ძაფების ლოკალური შენახვის მხარდაჭერასთან დაკავშირებით. ამ მიზეზით, ზემოთ მოცემულ მაგალითში, საცავი იხსნება დროშით MDB_NOTLS. გარდა ამისა, ასევე მოითხოვდა ჩანგალი C++ შეფუთვა lmdbxxცვლადების ამოჭრა ამ ატრიბუტით და.

მონაცემთა ბაზები

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

MDB_txn *txn;​
MDB_dbi dbi;​
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn);​
mdb_dbi_open(txn, NULL, MDB_CREATE, &dbi);​
mdb_txn_abort(txn);

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

გასაღებები და ღირებულებები

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

typedef struct MDB_val {​
    size_t mv_size;​
    void *mv_data;​
} MDB_val;​​

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

გარიგებები

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

1. მხარდაჭერა ყველა ძირითადი თვისებისთვის ACIDსაკვანძო სიტყვები: ატომურობა, თანმიმდევრულობა, იზოლაცია და საიმედოობა. არ შემიძლია არ აღვნიშნო, რომ macOS-სა და iOS-ზე გამძლეობის მხრივ MDBX-ში გამოსწორებულია შეცდომა. მეტი შეგიძლიათ წაიკითხოთ მათში README.
2. მიდგომა მრავალძალიანობისადმი აღწერილია სქემით „ერთი მწერალი/მრავალჯერადი მკითხველი“. მწერლები ერთმანეთს ბლოკავენ, მაგრამ მკითხველებს არ ბლოკავენ. მკითხველი არ ბლოკავს მწერლებს ან ერთმანეთს.
3. ჩადგმული ტრანზაქციების მხარდაჭერა.
4. მრავალვერსიის მხარდაჭერა.

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

ტესტის ჩანაწერის დამატება

MDB_env *env;
MDB_dbi dbi;
MDB_txn *txn;

mdb_env_create(&env);
mdb_env_open(env, "./testdb", MDB_NOTLS, 0664);

mdb_txn_begin(env, NULL, 0, &txn);
mdb_dbi_open(txn, NULL, 0, &dbi);
mdb_txn_abort(txn);

char k = 'k';
MDB_val key;
key.mv_size = sizeof(k);
key.mv_data = (void *)&k;

int v = 997;
MDB_val value;
value.mv_size = sizeof(v);
value.mv_data = (void *)&v;

mdb_txn_begin(env, NULL, 0, &txn);
mdb_put(txn, dbi, &key, &value, MDB_NOOVERWRITE);
mdb_txn_commit(txn);

MDB_txn *txn1, *txn2, *txn3;
MDB_val val;

// Открываем 2 транзакции, каждая из которых смотрит
// на версию базы данных с одной записью.
mdb_txn_begin(env, NULL, 0, &txn1); // read-write
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn2); // read-only

// В рамках первой транзакции удаляем из базы данных существующую в ней запись.
mdb_del(txn1, dbi, &key, NULL);
// Фиксируем удаление.
mdb_txn_commit(txn1);

// Открываем третью транзакцию, которая смотрит на
// актуальную версию базы данных, где записи уже нет.
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn3);
// Убеждаемся, что запись по искомому ключу уже не существует.
assert(mdb_get(txn3, dbi, &key, &val) == MDB_NOTFOUND);
// Завершаем транзакцию.
mdb_txn_abort(txn3);

// Убеждаемся, что в рамках второй транзакции, открытой на момент
// существования записи в базе данных, её всё ещё можно найти по ключу.
assert(mdb_get(txn2, dbi, &key, &val) == MDB_SUCCESS);
// Проверяем, что по ключу получен не абы какой мусор, а валидные данные.
assert(*(int *)val.mv_data == 997);
// Завершаем транзакцию, работающей хоть и с устаревшей, но консистентной базой данных.
mdb_txn_abort(txn2);

სურვილისამებრ, გირჩევთ სცადოთ იგივე ხრიკი SQLite-ით და ნახოთ რა მოხდება.

Multiversioning მოაქვს ძალიან კარგი სარგებელი iOS დეველოპერების ცხოვრებაში. ამ თვისების გამოყენებით, თქვენ შეგიძლიათ მარტივად და ბუნებრივად დაარეგულიროთ მონაცემთა წყაროს განახლების სიჩქარე ეკრანის ფორმებისთვის, მომხმარებლის გამოცდილების გათვალისწინებით. მაგალითად, ავიღოთ Mail.ru Cloud აპლიკაციის ისეთი ფუნქცია, როგორიცაა შინაარსის ავტომატური ჩატვირთვა სისტემის მედია გალერეიდან. კარგი კავშირით კლიენტს შეუძლია სერვერზე წამში რამდენიმე ფოტოს დამატება. თუ განაახლებთ ყოველი ჩამოტვირთვის შემდეგ UICollectionView მომხმარებლის ღრუბელში მედია კონტენტით, შეგიძლიათ დაივიწყოთ დაახლოებით 60 fps და გლუვი გადახვევა ამ პროცესის განმავლობაში. ეკრანის ხშირი განახლების თავიდან ასაცილებლად, თქვენ უნდა შეზღუდოთ მონაცემთა ბაზის ცვლილების სიჩქარე UICollectionViewDataSource.

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

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

კურსორები

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

4.2. მაგიდის მოდელირება

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

ცხრილის სქემა

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

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

კლავიშებისა და მნიშვნელობების სერიალიზაცია

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

typedef struct NodeKey {​
    EntityId parentId;​
    uint8_t type;​
    uint8_t nameBuffer[256];​
} NodeKey;

Შენახვა NodeKey შენახვის საჭიროება ობიექტში MDB_val განათავსეთ მაჩვენებელი მონაცემების სტრუქტურის დასაწყისის მისამართზე და გამოთვალეთ მათი ზომა ფუნქციით sizeof.

MDB_val serialize(NodeKey * const key) {
    return MDB_val {
        .mv_size = sizeof(NodeKey),
        .mv_data = (void *)key
    };
}

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

გასაღებების შეკვეთა ბინარული შედარებით

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

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

// value (hex dump)
000 (0000)
256 (0001)
001 (0100)
257 (0101)
...
254 (fe00)
510 (fe01)
255 (ff00)
511 (ff01)

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

პროგრამირებაში სტრიქონების წარმოდგენის ფორმატი, როგორც მოგეხსენებათ, არის მთლიანობა история. თუ სტრიქონების სემანტიკა, ისევე როგორც დაშიფვრა, რომელიც გამოიყენება მეხსიერებაში, ვარაუდობს, რომ შეიძლება იყოს ერთზე მეტი ბაიტი თითო სიმბოლოზე, მაშინ უმჯობესია უარი თქვან ნაგულისხმევი შედარების გამოყენების იდეაზე.

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

გასაღების შეკვეთა გარე შედარების მიერ

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

typedef struct NodeKey {​
    EntityId parentId;​
    uint8_t type;​
    uint8_t nameBuffer[256];​
} NodeKey;

მთელი მისი სიმარტივის მიუხედავად, უმეტეს შემთხვევაში ის ძალიან ბევრ მეხსიერებას მოიხმარს. სათაურის ბუფერი არის 256 ბაიტი, თუმცა საშუალოდ ფაილის და საქაღალდის სახელები იშვიათად აღემატება 20-30 სიმბოლოს.

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

typedef struct NodeKey {​
    EntityId parentId;​
    uint8_t type;​
    uint8_t nameLength;​
    uint8_t nameBuffer[256];​
} NodeKey;

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

MDB_val serialize(NodeKey * const key) {
    return MDB_val {
        .mv_size = offsetof(NodeKey, nameBuffer) + key->nameLength,
        .mv_data = (void *)key
    };
}

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

LMDB საშუალებას აძლევს თითოეულ მონაცემთა ბაზას ჰქონდეს საკუთარი ძირითადი შედარების ფუნქცია. ეს კეთდება ფუნქციის გამოყენებით mdb_set_compare მკაცრად გახსნამდე. აშკარა მიზეზების გამო, მონაცემთა ბაზა არ შეიძლება შეიცვალოს მთელი მისი სიცოცხლის განმავლობაში. შეყვანისას, შედარება იღებს ორ კლავიშს ბინარულ ფორმატში, ხოლო გამოსავალზე აბრუნებს შედარების შედეგს: (-1-ზე ნაკლები), (1)-ზე მეტი ან ტოლი (0). ფსევდოკოდი ამისთვის NodeKey ასე გამოიყურება.

int compare(MDB_val * const a, MDB_val * const b) {​
    NodeKey * const aKey = (NodeKey * const)a->mv_data;​
    NodeKey * const bKey = (NodeKey * const)b->mv_data;​
    return // ...
}​

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

ღირებულების სერიალიზაცია

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

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

NSData *data = serialize(object);​
MDB_val value = {​
    .mv_size = data.length,​
    .mv_data = (void *)data.bytes​
};

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

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

typedef struct NodeValue {​
    EntityId localId;​
    EntityType type;​
    union {​
        FileInfo file;​
        DirectoryInfo directory;​
    } info;​
    uint8_t nameLength;​
    uint8_t nameBuffer[256];​
} NodeValue;​

ჩანაწერების დამატება და განახლება

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

// key и value имеют тип MDB_val​
mdb_put(..., &key, &value, MDB_NOOVERWRITE);

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

ჩანაწერების კითხვა

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

NodeValue * const readNode(..., NodeKey * const key) {​
    MDB_val rawKey = serialize(key);​
    MDB_val rawValue;​
    mdb_get(..., &rawKey, &rawValue);​
    return (NodeValue * const)rawValue.mv_data;​
}

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

1. მხოლოდ წაკითხული ტრანზაქციისთვის, ღირებულების სტრუქტურის მაჩვენებელი გარანტირებულია, რომ მოქმედებს მხოლოდ ტრანზაქციის დახურვამდე. როგორც უკვე აღვნიშნეთ, B-ხის გვერდები, რომლებზეც ობიექტი მდებარეობს, კოპირება-ჩაწერის პრინციპის წყალობით, უცვლელი რჩება მანამ, სანამ მინიმუმ ერთი გარიგება ეხება მათ. ამავდროულად, როგორც კი მათთან დაკავშირებული ბოლო ტრანზაქცია დასრულდება, გვერდების ხელახლა გამოყენება შესაძლებელია ახალი მონაცემებისთვის. თუ აუცილებელია ობიექტების გადარჩენა ტრანზაქციის შედეგად, რომელმაც შექმნა ისინი, მაშინ ისინი მაინც უნდა დაკოპირდეს.
2. წაკითხვის ტრანზაქციისთვის, მიღებული სტრუქტურა-მნიშვნელობის მითითება მოქმედი იქნება მხოლოდ პირველ მოდიფიკაციის პროცედურამდე (მონაცემების ჩაწერა ან წაშლა).
3. მიუხედავად იმისა, რომ სტრუქტურა NodeValue არა სრულფასოვანი, მაგრამ მოჭრილი (იხ. ქვეგანყოფილება "გასაღების შეკვეთა გარე შედარების საშუალებით"), კურსორის საშუალებით შეგიძლიათ მარტივად შეხვიდეთ მის ველებზე. მთავარია, არ გადაიტანოთ იგი!
4. არავითარ შემთხვევაში არ შეგიძლიათ სტრუქტურის შეცვლა მიღებული მაჩვენებლის საშუალებით. ყველა ცვლილება უნდა განხორციელდეს მხოლოდ მეთოდით mdb_put. თუმცა, ამის გაკეთების მთელი სურვილით, ეს არ იმუშავებს, რადგან მეხსიერების არეალი, სადაც ეს სტრუქტურა მდებარეობს, არის მხოლოდ წაკითხვის რეჟიმში.
5. გადაიტანეთ ფაილი პროცესის მისამართების სივრცეში, რათა, მაგალითად, გაზარდოთ შენახვის მაქსიმალური ზომა ფუნქციის გამოყენებით mdb_env_set_map_size მთლიანად გააუქმებს ყველა ტრანზაქციას და დაკავშირებულ ერთეულს ზოგადად და მითითებებს კონკრეტულად ობიექტების წასაკითხად.

დაბოლოს, კიდევ ერთი თვისება იმდენად მზაკვრულია, რომ მისი არსის გამჟღავნება მხოლოდ ერთ პუნქტში არ ჯდება. B-ხის შესახებ თავში მე მივეცი მეხსიერებაში მისი გვერდების ორგანიზების დიაგრამა. აქედან გამომდინარეობს, რომ სერიული მონაცემებით ბუფერის დასაწყისის მისამართი შეიძლება იყოს აბსოლუტურად თვითნებური. ამის გამო, მათზე მითითება, მიღებული სტრუქტურაში MDB_val და მიცემული სტრუქტურის მაჩვენებელზე ზოგადად მიუმართავია. ამავდროულად, ზოგიერთი ჩიპის არქიტექტურა (IOS-ის შემთხვევაში, ეს არის armv7) მოითხოვს, რომ ნებისმიერი მონაცემების მისამართი იყოს მანქანური სიტყვის ზომის მრავალჯერადი, ან, სხვა სიტყვებით რომ ვთქვათ, სისტემის ბიტი. (armv7-ისთვის ეს არის 32 ბიტი). სხვა სიტყვებით რომ ვთქვათ, ოპერაცია, როგორიცაა *(int *foo)0x800002 მათზე გაქცევას უტოლდება და განაჩენით აღსრულებამდე მივყავართ EXC_ARM_DA_ALIGN. ასეთი სევდიანი ბედის თავიდან ასაცილებლად ორი გზა არსებობს.

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

int compare(MDB_val * const a, MDB_val * const b) {
    NodeKey aKey, bKey;
    memcpy(&aKey, a->mv_data, a->mv_size);
    memcpy(&bKey, b->mv_data, b->mv_size);
    return // ...
}

ალტერნატიული გზაა შემდგენლის წინასწარ ინფორმირება, რომ გასაღებისა და მნიშვნელობის მქონე სტრუქტურები შეიძლება არ იყოს გასწორებული ატრიბუტის გამოყენებით. aligned(1). ARM-ზე იგივე ეფექტი შეიძლება იყოს მივაღწიოთ და შეფუთული ატრიბუტის გამოყენებით. იმის გათვალისწინებით, რომ ის ასევე ხელს უწყობს სტრუქტურის მიერ დაკავებული სივრცის ოპტიმიზაციას, ეს მეთოდი უფრო სასურველია, თუმცა приводит მონაცემთა ხელმისაწვდომობის ოპერაციების ღირებულების გაზრდის მიზნით.

typedef struct __attribute__((packed)) NodeKey {
    uint8_t parentId;
    uint8_t type;
    uint8_t nameLength;
    uint8_t nameBuffer[256];
} NodeKey;

დიაპაზონის მოთხოვნები

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

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

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

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

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

NodeKey upperBoundSearchKey = {​
    .parentId = 2,​
    .type = 0,​
    .nameLength = 0​
};​
MDB_val value, key = serialize(upperBoundSearchKey);​
MDB_cursor *cursor;​
mdb_cursor_open(..., &cursor);​
mdb_cursor_get(cursor, &key, &value, MDB_SET_RANGE);

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

do {​
    rc = mdb_cursor_get(cursor, &key, &value, MDB_NEXT);​
    // processing...​
} while (MDB_NOTFOUND != rc && // check end of table​
         IsTargetKey(key));    // check end of keys group​​

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

4.3. ცხრილებს შორის ურთიერთობების მოდელირება

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

​

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

ინდექსის ცხრილები

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

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

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

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

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

ცხრილებს შორის ურთიერთობების ორგანიზება

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

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

Cloud მობილური კლიენტებს აქვთ გვერდი, სადაც ნაჩვენებია ყველა ფაილი და საქაღალდე, რომელიც მომხმარებელმა გაუზიარა სხვა ადამიანებს. ვინაიდან ასეთი ფაილები შედარებით ცოტაა და მათთან დაკავშირებულია ბევრი კონკრეტული ინფორმაცია საჯაროობის შესახებ (ვის აქვს წვდომა, რა უფლებებით და ა.შ.), არ იქნება რაციონალური მისი დატვირთვა ღირებულების ნაწილით. ჩანაწერი მთავარ ცხრილში. თუმცა, თუ გსურთ ასეთი ფაილების ოფლაინ ჩვენება, მაშინ მაინც უნდა შეინახოთ სადმე. ბუნებრივი გამოსავალია მისთვის ცალკე მაგიდის შექმნა. ქვემოთ მოცემულ დიაგრამაში მის კლავიშს აქვს პრეფიქსი "P", ხოლო "propname" ჩანაცვლების ადგილი შეიძლება შეიცვალოს უფრო კონკრეტული მნიშვნელობით "public info".​

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

დასკვნა

ჩვენ დადებითად ვაფასებთ LMDB განხორციელების შედეგებს. ამის შემდეგ აპლიკაციების გაყინვის რაოდენობა 30%-ით შემცირდა.

შესრულებული სამუშაოს შედეგებმა იპოვა გამოხმაურება iOS გუნდის გარეთ. ამ დროისთვის ანდროიდის აპლიკაციის ერთ-ერთი მთავარი „ფაილის“ განყოფილებაც LMDB-ზეა გადართული და სხვა ნაწილებიც გზაშია. C ენა, რომელშიც დანერგილია საკვანძო მნიშვნელობების შენახვა, კარგი დახმარება იყო, რათა თავდაპირველად მის ირგვლივ გამოყენებული აკინძვა ჯვარედინი პლატფორმა ყოფილიყო C ++ ენაზე. C ++ ბიბლიოთეკის უწყვეტი კავშირისთვის Objective-C-სა და Kotlin-ის პლატფორმის კოდთან, გამოყენებული იქნა კოდის გენერატორი. ჯინი Dropbox-დან, მაგრამ ეს სხვა ამბავია.

წყარო: www.habr.com