នៅរដូវស្លឹកឈើជ្រុះឆ្នាំ 2019 ព្រឹត្តិការណ៍ដែលរង់ចាំជាយូរមកហើយបានកើតឡើងនៅក្នុងក្រុម Mail.ru Cloud iOS ។ មូលដ្ឋានទិន្នន័យចម្បងសម្រាប់ការផ្ទុកជាប់លាប់នៃស្ថានភាពកម្មវិធីបានក្លាយទៅជាកម្រនិងអសកម្មសម្រាប់ពិភពទូរស័ព្ទ Lightning Memory-Mapped Database (LMDB) ។ ខាងក្រោមការកាត់នេះ យើងផ្តល់ជូនអ្នកនូវការពិនិត្យឡើងវិញលម្អិតអំពីវាជាបួនផ្នែក។ ជាដំបូង ចូរយើងនិយាយអំពីហេតុផលសម្រាប់ជម្រើសដែលមិនសំខាន់ និងពិបាកបែបនេះ។ បន្ទាប់មកយើងនឹងបន្តពិចារណាសសរស្តម្ភទាំងបីដែលជាបេះដូងនៃស្ថាបត្យកម្ម LMDB: ឯកសារដែលបានគូសផែនទីអង្គចងចាំ B+-tree វិធីសាស្រ្តចម្លងលើការសរសេរសម្រាប់ការអនុវត្តប្រតិបត្តិការ និងពហុកំណែ។ ទីបំផុតសម្រាប់បង្អែម - ផ្នែកជាក់ស្តែង។ នៅក្នុងវា យើងនឹងពិនិត្យមើលរបៀបរចនា និងអនុវត្តគ្រោងការណ៍មូលដ្ឋានទិន្នន័យដែលមានតារាងជាច្រើន រួមទាំងលិបិក្រមមួយនៅលើកំពូលនៃ 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 ខ្សែស្រឡាយពីរ នៅលើ Twitter រួម និង អត្ថបទអំពី Habre. ជាផ្នែកនៃនិទានរឿងបច្ចុប្បន្ន ខ្ញុំចង់បញ្ជាក់ទិដ្ឋភាពទាំងនោះនៃការសម្រេចចិត្តដែលមានឥទ្ធិពលលើជម្រើសនៃមូលដ្ឋានទិន្នន័យ។​

គំរូតួនៃអង្គការប្រព័ន្ធសន្មត់ថា multithreading ក្លាយជាខ្លឹមសារទីពីររបស់វា។ វត្ថុគំរូនៅក្នុងវាចូលចិត្តឆ្លងកាត់ព្រំដែនស្ទ្រីម។ ហើយ​គេ​ធ្វើ​បែប​នេះ​មិន​មែន​ពេល​ខ្លះ​ហើយ​នៅ​ទី​នោះ​ទេ ប៉ុន្តែ​ស្ទើរ​តែ​គ្រប់​ទីកន្លែង

មូលដ្ឋានទិន្នន័យគឺជាធាតុផ្សំដ៏សំខាន់មួយនៅក្នុងដ្យាក្រាមដែលបានបង្ហាញ។ ភារកិច្ចចម្បងរបស់វាគឺដើម្បីអនុវត្ត macropattern មូលដ្ឋានទិន្នន័យដែលបានចែករំលែក. ប្រសិនបើនៅក្នុងពិភពសហគ្រាសវាត្រូវបានប្រើដើម្បីរៀបចំការធ្វើសមកាលកម្មទិន្នន័យរវាងសេវាកម្មបន្ទាប់មកនៅក្នុងករណីនៃស្ថាបត្យកម្មតារាសម្តែង - ទិន្នន័យរវាងខ្សែស្រឡាយ។ ដូច្នេះហើយ យើងត្រូវការមូលដ្ឋានទិន្នន័យដែលនឹងមិនបង្កឱ្យមានការលំបាកតិចតួចនៅពេលធ្វើការជាមួយវានៅក្នុងបរិយាកាសពហុខ្សែ។ ជាពិសេស នេះមានន័យថាវត្ថុដែលទទួលបានពីវាត្រូវតែមានសុវត្ថិភាពយ៉ាងតិចបំផុត ហើយតាមឧត្ដមគតិមិនអាចផ្លាស់ប្តូរបានទាំងស្រុង។ ដូចដែលអ្នកបានដឹងហើយថាក្រោយមកទៀតអាចត្រូវបានប្រើក្នុងពេលដំណាលគ្នាពីខ្សែស្រឡាយជាច្រើនដោយមិនងាកទៅរកការចាក់សោរណាមួយដែលមានឥទ្ធិពលជន៍លើការអនុវត្ត។

កត្តាសំខាន់ទីពីរដែលជះឥទ្ធិពលលើជម្រើសនៃមូលដ្ឋានទិន្នន័យគឺ Cloud API របស់យើង។ វាត្រូវបានបំផុសគំនិតដោយវិធីសាស្រ្តធ្វើសមកាលកម្មដែលត្រូវបានអនុម័តដោយ git ។ ដូចគាត់ដែរ យើងមានគោលបំណង Offline-first APIដែលមើលទៅសមស្របជាងសម្រាប់អតិថិជនពពក។ វាត្រូវបានគេសន្មត់ថាពួកគេនឹងបូមចេញនូវស្ថានភាពពេញលេញនៃពពកតែម្តងប៉ុណ្ណោះ ហើយបន្ទាប់មកការធ្វើសមកាលកម្មនៅក្នុងករណីភាគច្រើនលើសលប់នឹងកើតឡើងតាមរយៈការចេញផ្សាយការផ្លាស់ប្តូរ។ Alas ឱកាសនេះនៅតែមានតែនៅក្នុងតំបន់ទ្រឹស្តីប៉ុណ្ណោះ ហើយអតិថិជនមិនទាន់បានរៀនពីរបៀបធ្វើការជាមួយបំណះក្នុងការអនុវត្តទេ។ មានហេតុផលគោលបំណងមួយចំនួនសម្រាប់បញ្ហានេះ ដែលដើម្បីកុំឱ្យពន្យារពេលការណែនាំ យើងនឹងទុកតង្កៀបនៅពីក្រោយ។ ឥឡូវនេះ អ្វីដែលគួរឱ្យចាប់អារម្មណ៍ជាងនេះទៅទៀតនោះគឺការសន្និដ្ឋានជាមេរៀនអំពីអ្វីដែលកើតឡើងនៅពេលដែល API និយាយថា "A" ហើយអ្នកប្រើប្រាស់របស់វាមិននិយាយថា "B" ទេ។

ដូច្នេះ ប្រសិនបើអ្នកស្រមៃមើល git ដែលនៅពេលប្រតិបត្តិពាក្យបញ្ជាទាញ ជំនួសឱ្យការអនុវត្តបំណះទៅនឹងរូបថតមូលដ្ឋាន ប្រៀបធៀបស្ថានភាពពេញលេញរបស់វាជាមួយនឹងស្ថានភាពម៉ាស៊ីនមេពេញលេញ នោះអ្នកនឹងមានគំនិតត្រឹមត្រូវអំពីរបៀបដែលការធ្វើសមកាលកម្មកើតឡើងនៅក្នុងពពក។ អតិថិជន។ វាងាយស្រួលក្នុងការទាយថា ដើម្បីអនុវត្តវា អ្នកត្រូវបែងចែកមែកធាង DOM ពីរនៅក្នុងសតិជាមួយនឹងព័ត៌មានមេតាអំពីម៉ាស៊ីនមេ និងឯកសារមូលដ្ឋានទាំងអស់។ វាប្រែថាប្រសិនបើអ្នកប្រើរក្សាទុកឯកសារចំនួន 500 ពាន់នៅក្នុងពពកបន្ទាប់មកដើម្បីធ្វើសមកាលកម្មវាចាំបាច់ត្រូវបង្កើតឡើងវិញនិងបំផ្លាញដើមឈើពីរដែលមានថ្នាំង 1 លាន។ ប៉ុន្តែថ្នាំងនីមួយៗគឺជាការប្រមូលផ្តុំដែលមានក្រាហ្វនៃវត្ថុ។ នៅក្នុងពន្លឺនេះ លទ្ធផលនៃទម្រង់ត្រូវបានរំពឹងទុក។ វាបានប្រែក្លាយថា ទោះបីជាមិនបានគិតគូរពីក្បួនដោះស្រាយការបញ្ចូលគ្នាក៏ដោយ ក៏នីតិវិធីនៃការបង្កើត និងបំផ្លាញវត្ថុតូចៗជាបន្តបន្ទាប់មួយចំនួនធំត្រូវចំណាយអស់មួយកាក់ស្អាត។ នៃស្គ្រីបអ្នកប្រើប្រាស់។ ជាលទ្ធផលយើងជួសជុលលក្ខណៈវិនិច្ឆ័យសំខាន់ទីពីរក្នុងការជ្រើសរើសមូលដ្ឋានទិន្នន័យ - សមត្ថភាពក្នុងការអនុវត្តប្រតិបត្តិការ CRUD ដោយគ្មានការបែងចែកថាមវន្តនៃវត្ថុ។

តម្រូវការផ្សេងទៀតមានលក្ខណៈប្រពៃណីជាង ហើយបញ្ជីទាំងមូលរបស់ពួកគេមានដូចខាងក្រោម។

1. សុវត្ថិភាពខ្សែស្រឡាយ។
2. ដំណើរការច្រើន។ កំណត់ដោយបំណងប្រាថ្នាដើម្បីប្រើឧទាហរណ៍មូលដ្ឋានទិន្នន័យដូចគ្នាដើម្បីធ្វើសមកាលកម្មស្ថានភាពមិនត្រឹមតែរវាងខ្សែស្រឡាយប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងរវាងកម្មវិធីសំខាន់និងផ្នែកបន្ថែម iOS ផងដែរ។
3. សមត្ថភាពក្នុងការតំណាងឱ្យអង្គភាពដែលបានរក្សាទុកជាវត្ថុដែលមិនអាចផ្លាស់ប្តូរបាន ..
4. មិនមានការបែងចែកថាមវន្តនៅក្នុងប្រតិបត្តិការ CRUD ទេ។
5. ការគាំទ្រប្រតិបត្តិការសម្រាប់ទ្រព្យសម្បត្តិមូលដ្ឋាន ទឹកអាស៊ីដ៖ អាតូមិច ភាពស៊ីសង្វាក់ ភាពឯកោ និងភាពជឿជាក់។
6. ល្បឿនលើករណីពេញនិយមបំផុត។

ជាមួយនឹងសំណុំនៃតម្រូវការនេះ SQLite គឺជាជម្រើសដ៏ល្អ។ ទោះយ៉ាងណាក៏ដោយ ជាផ្នែកនៃការសិក្សាអំពីជម្រើស ខ្ញុំបានជួបសៀវភៅមួយ។ "ចាប់ផ្តើមជាមួយ LevelDB". ក្រោមការដឹកនាំរបស់នាង ស្តង់ដារមួយត្រូវបានសរសេរប្រៀបធៀបល្បឿននៃការងារជាមួយនឹងមូលដ្ឋានទិន្នន័យផ្សេងៗគ្នានៅក្នុងសេណារីយ៉ូពពកពិតប្រាកដ។ លទ្ធផលលើសពីការរំពឹងទុកដ៏ព្រៃផ្សៃបំផុតរបស់យើង។ ក្នុងករណីដែលពេញនិយមបំផុត - ការទទួលបានទស្សន៍ទ្រនិចនៅលើបញ្ជីដែលបានតម្រៀបនៃឯកសារទាំងអស់ និងបញ្ជីតម្រៀបនៃឯកសារទាំងអស់សម្រាប់ថតដែលបានផ្តល់ឱ្យ - LMDB ប្រែទៅជាលឿនជាង SQLite 10 ដង។ ជម្រើសបានក្លាយជាជាក់ស្តែង។

2. ការកំណត់ទីតាំង LMDB

LMDB គឺជាបណ្ណាល័យតូចមួយ (ត្រឹមតែ 10K ជួរ) ដែលអនុវត្តស្រទាប់មូលដ្ឋានទិន្នន័យទាបបំផុត - ការផ្ទុក។

ដ្យាក្រាមខាងលើបង្ហាញថាការប្រៀបធៀប LMDB ជាមួយ SQLite ដែលអនុវត្តកម្រិតខ្ពស់ផងដែរ ជាទូទៅមិនត្រឹមត្រូវជាង SQLite ដែលមានទិន្នន័យស្នូលទេ។ វានឹងមានភាពយុត្តិធម៌ជាងក្នុងការដកស្រង់ម៉ាស៊ីនផ្ទុកដូចគ្នាទៅនឹងដៃគូប្រកួតប្រជែងស្មើគ្នា - BerkeleyDB, LevelDB, Sophia, RocksDB ជាដើម។ មានសូម្បីតែការអភិវឌ្ឍន៍ដែល LMDB ដើរតួជាសមាសធាតុម៉ាស៊ីនផ្ទុកសម្រាប់ SQLite ។ ការពិសោធន៍បែបនេះជាលើកដំបូងគឺនៅឆ្នាំ 2012 បានចំណាយ ដោយ LMDB លោក Howard Chu. Результаты មើលទៅពិតជាគួរឱ្យចាប់អារម្មណ៍ខ្លាំងណាស់ ដែលគំនិតផ្តួចផ្តើមរបស់គាត់ត្រូវបានជ្រើសរើសដោយអ្នកចូលចិត្ត OSS ហើយបានរកឃើញការបន្តរបស់វានៅក្នុងបុគ្គលនោះ។ LumoSQL. នៅខែមករាឆ្នាំ 2020 អ្នកនិពន្ធនៃគម្រោងនេះគឺ Den Shearer បានបង្ហាញ វានៅ LinuxConfAu ។

LMDB ត្រូវបានប្រើជាចម្បងជាម៉ាស៊ីនសម្រាប់មូលដ្ឋានទិន្នន័យកម្មវិធី។ បណ្ណាល័យជំពាក់រូបរាងរបស់វាចំពោះអ្នកអភិវឌ្ឍន៍ OpenLDAPដែលមិនពេញចិត្តយ៉ាងខ្លាំងចំពោះ BerkeleyDB ជាមូលដ្ឋានសម្រាប់គម្រោងរបស់ពួកគេ។ ចាប់ផ្តើមពីបណ្ណាល័យតិចតួច btreeHoward Chu អាចបង្កើតជម្រើសដ៏ពេញនិយមបំផុតមួយនៅសម័យរបស់យើង។ គាត់បានឧទ្ទិសរបាយការណ៍ដ៏ល្អរបស់គាត់ចំពោះរឿងនេះ ក៏ដូចជារចនាសម្ព័ន្ធផ្ទៃក្នុងរបស់ LMDB ។ "មូលដ្ឋានទិន្នន័យដែលបានគូសផែនទីអង្គចងចាំរន្ទះ". ឧទាហរណ៍ដ៏ល្អនៃការដណ្តើមយកកន្លែងស្តុកទុកត្រូវបានចែករំលែកដោយ Leonid Yuryev (aka អ៊ីឡូ) ពី Positive Technologies នៅក្នុងរបាយការណ៍របស់គាត់នៅ Highload 2015 "ម៉ាស៊ីន LMDB គឺជាជើងឯកពិសេស". នៅក្នុងវា គាត់និយាយអំពី LMDB នៅក្នុងបរិបទនៃភារកិច្ចស្រដៀងគ្នានៃការអនុវត្ត ReOpenLDAP ហើយ LevelDB បានទទួលរងនូវការរិះគន់ប្រៀបធៀបរួចហើយ។ ជាលទ្ធផលនៃការអនុវត្ត បច្ចេកវិទ្យាវិជ្ជមាន ថែមទាំងមានការវិវឌ្ឍន៍យ៉ាងសកម្មផងដែរ។ MDBX ជាមួយនឹងលក្ខណៈពិសេសហ៊ានណាស់ ការបង្កើនប្រសិទ្ធភាព និង កែកំហុស.

LMDB ជាញឹកញាប់ត្រូវបានគេប្រើជាកន្លែងផ្ទុក។ ឧទាហរណ៍កម្មវិធីរុករក Mozilla Firefox បានជ្រើសរើស វាសម្រាប់តម្រូវការមួយចំនួន ហើយចាប់ផ្តើមពីកំណែ 9 Xcode ពេញចិត្ត SQLite របស់វាសម្រាប់រក្សាទុកលិបិក្រម។

ម៉ាស៊ីននេះក៏បានធ្វើឱ្យមានការសម្គាល់របស់ខ្លួននៅក្នុងពិភពនៃការអភិវឌ្ឍន៍ទូរស័ព្ទ។ ដាននៃការប្រើប្រាស់របស់វាអាចមាន ដើម្បីរក នៅក្នុងម៉ាស៊ីនភ្ញៀវ iOS សម្រាប់ Telegram ។ LinkedIn បានទៅបន្ថែមទៀតហើយជ្រើសរើស LMDB ជាកន្លែងផ្ទុកទិន្នន័យលំនាំដើមសម្រាប់មូលដ្ឋានទិន្នន័យឃ្លាំងសម្ងាត់ទិន្នន័យ Rocket Data អំពីអ្វីដែល បានប្រាប់ នៅក្នុងអត្ថបទរបស់គាត់ក្នុងឆ្នាំ 2016 ។

LMDB កំពុងប្រយុទ្ធដោយជោគជ័យដើម្បីកន្លែងមួយនៅក្នុងព្រះអាទិត្យនៅក្នុងទីផ្សារពិសេសដែលចាកចេញដោយ BerkeleyDB បន្ទាប់ពីវាស្ថិតនៅក្រោមការគ្រប់គ្រងរបស់ Oracle ។ បណ្ណាល័យត្រូវបានគេស្រឡាញ់សម្រាប់ល្បឿន និងភាពជឿជាក់របស់វា សូម្បីតែបើប្រៀបធៀបទៅនឹងមិត្តរួមការងាររបស់វាក៏ដោយ។ ដូចដែលអ្នកបានដឹងហើយថាមិនមានអាហារថ្ងៃត្រង់ដោយឥតគិតថ្លៃទេហើយខ្ញុំចង់សង្កត់ធ្ងន់លើការដោះដូរដែលអ្នកនឹងត្រូវប្រឈមមុខនៅពេលជ្រើសរើសរវាង LMDB និង SQLite ។ ដ្យាក្រាមខាងលើបង្ហាញយ៉ាងច្បាស់ពីរបៀបដែលការបង្កើនល្បឿនត្រូវបានសម្រេច។ ទីមួយ យើងមិនបង់ប្រាក់សម្រាប់ស្រទាប់បន្ថែមនៃ abstraction នៅផ្នែកខាងលើនៃកន្លែងផ្ទុកថាសទេ។ វាច្បាស់ណាស់ថាស្ថាបត្យកម្មល្អនៅតែមិនអាចធ្វើបានដោយគ្មានពួកវា ហើយពួកវានឹងលេចឡើងក្នុងកូដកម្មវិធីដោយជៀសមិនរួច ប៉ុន្តែពួកវានឹងកាន់តែច្បាស់។ ពួកវានឹងមិនមានលក្ខណៈពិសេសដែលមិនត្រូវបានទាមទារដោយកម្មវិធីជាក់លាក់ទេ ឧទាហរណ៍ ការគាំទ្រសម្រាប់សំណួរនៅក្នុងភាសា SQL ។ ទីពីរ វា​អាច​ធ្វើ​ទៅ​បាន​ក្នុង​ការ​អនុវត្ត​ការ​ធ្វើ​ផែនទី​នៃ​ប្រតិបត្តិការ​កម្មវិធី​ឱ្យ​បាន​ល្អ​ប្រសើរ​តាម​សំណើ​ទៅ​កន្លែង​ផ្ទុក​ថាស។ ប្រសិនបើ SQLite នៅក្នុងការងាររបស់ខ្ញុំ គឺផ្អែកលើតម្រូវការស្ថិតិជាមធ្យមនៃកម្មវិធីជាមធ្យម បន្ទាប់មកអ្នកជាអ្នកបង្កើតកម្មវិធី បានដឹងយ៉ាងច្បាស់អំពីសេណារីយ៉ូនៃបន្ទុកការងារសំខាន់ៗ។ សម្រាប់ដំណោះស្រាយដែលមានផលិតភាពកាន់តែច្រើន អ្នកនឹងត្រូវបង់ថ្លៃដំឡើងថ្លៃទាំងសម្រាប់ការអភិវឌ្ឍន៍ដំណោះស្រាយដំបូង និងសម្រាប់ការគាំទ្រជាបន្តបន្ទាប់របស់វា។

3. សសរស្តម្ភទាំងបីរបស់ LMDB

ដោយបានក្រឡេកមើល LMDB ពីទិដ្ឋភាពភ្នែកបក្សី វាដល់ពេលដែលត្រូវចូលកាន់តែជ្រៅ។ ផ្នែកទាំងបីបន្ទាប់នឹងត្រូវបានឧទ្ទិសដល់ការវិភាគនៃសសរស្តម្ភសំខាន់ៗដែលស្ថាបត្យកម្មផ្ទុកនៅសល់៖

1. ឯកសារដែលបានគូសផែនទីអង្គចងចាំជាយន្តការសម្រាប់ធ្វើការជាមួយថាស និងធ្វើសមកាលកម្មរចនាសម្ព័ន្ធទិន្នន័យខាងក្នុង។
2. B+-tree ជាអង្គការនៃរចនាសម្ព័ន្ធនៃទិន្នន័យដែលបានរក្សាទុក។
3. Copy-on-write ជាវិធីសាស្រ្តមួយដើម្បីផ្តល់នូវទ្រព្យសម្បត្តិប្រតិបត្តិការ ACID និងពហុកំណែ។

៣.១. ត្រីបាឡែនលេខ 3.1 ។ ឯកសារ​ដែល​បាន​គូស​ផែនទី​អង្គ​ចងចាំ

ឯកសារដែលបានគូសផែនទីអង្គចងចាំគឺជាធាតុស្ថាបត្យកម្មដ៏សំខាន់មួយ ដែលពួកគេថែមទាំងបង្ហាញនៅក្នុងឈ្មោះរបស់ឃ្លាំង។ បញ្ហានៃឃ្លាំងសម្ងាត់ និងការធ្វើសមកាលកម្មនៃការចូលប្រើព័ត៌មានដែលបានរក្សាទុកត្រូវបានទុកចោលទាំងស្រុងចំពោះប្រព័ន្ធប្រតិបត្តិការ។ LMDB មិនមានឃ្លាំងសម្ងាត់ណាមួយនៅក្នុងខ្លួនវាទេ។ នេះជាការសម្រេចចិត្តដោយមនសិការដោយអ្នកនិពន្ធ ចាប់តាំងពីការអានទិន្នន័យដោយផ្ទាល់ពីឯកសារដែលបានគូសវាសអនុញ្ញាតឱ្យអ្នកកាត់ជ្រុងជាច្រើនក្នុងការអនុវត្តម៉ាស៊ីន។ ខាងក្រោមនេះគឺនៅឆ្ងាយពីបញ្ជីពេញលេញនៃពួកគេមួយចំនួន។

1. ការរក្សាភាពស៊ីសង្វាក់គ្នានៃទិន្នន័យនៅក្នុងការផ្ទុកនៅពេលធ្វើការជាមួយវាពីដំណើរការជាច្រើនក្លាយជាការទទួលខុសត្រូវនៃប្រព័ន្ធប្រតិបត្តិការ។ នៅផ្នែកបន្ទាប់យន្តការនេះត្រូវបានពិភាក្សាលម្អិតនិងជាមួយរូបភាព។
2. អវត្ដមាននៃឃ្លាំងសម្ងាត់លុបបំបាត់ LMDB ទាំងស្រុងពីការចំណាយលើសដែលទាក់ទងនឹងការបែងចែកថាមវន្ត។ ការអានទិន្នន័យក្នុងការអនុវត្តមានន័យថាកំណត់ទ្រនិចទៅអាសយដ្ឋានត្រឹមត្រូវនៅក្នុងសតិនិម្មិត ហើយគ្មានអ្វីទៀតទេ។ វាស្តាប់ទៅដូចជាប្រឌិតវិទ្យាសាស្រ្ត ប៉ុន្តែនៅក្នុងកូដប្រភពផ្ទុក ការហៅទូរស័ព្ទទាំងអស់ទៅកាន់ calloc ត្រូវបានប្រមូលផ្តុំនៅក្នុងមុខងារកំណត់រចនាសម្ព័ន្ធផ្ទុក។
3. អវត្ដមាននៃឃ្លាំងសម្ងាត់ក៏មានន័យថាអវត្តមាននៃការចាក់សោដែលទាក់ទងនឹងការធ្វើសមកាលកម្មនៃការចូលប្រើរបស់ពួកគេ។ អ្នកអាន ដែលអាចមានចំនួនអ្នកអានតាមចិត្តក្នុងពេលតែមួយ មិនត្រូវជួប mutex តែមួយនៅលើផ្លូវរបស់ពួកគេទៅកាន់ទិន្នន័យនោះទេ។ ដោយសារតែនេះ ល្បឿនអានមានវិសាលភាពលីនេអ៊ែរដ៏ល្អ ដោយផ្អែកលើចំនួនស៊ីភីយូ។ នៅក្នុង LMDB មានតែការកែប្រែប្រតិបត្តិការប៉ុណ្ណោះដែលត្រូវបានធ្វើសមកាលកម្ម។ អាច​មាន​អ្នក​និពន្ធ​តែ​ម្នាក់​ប៉ុណ្ណោះ​ក្នុង​ពេល​មួយ។
4. អប្បរមានៃឃ្លាំងសម្ងាត់ និងតក្កវិជ្ជាធ្វើសមកាលកម្មលុបបំបាត់ប្រភេទនៃកំហុសដែលស្មុគស្មាញបំផុតដែលទាក់ទងនឹងការធ្វើការនៅក្នុងបរិយាកាសពហុខ្សែ។ មានការសិក្សាមូលដ្ឋានទិន្នន័យគួរឱ្យចាប់អារម្មណ៍ចំនួនពីរនៅឯសន្និសីទ Usenix OSDI 2014៖ "ប្រព័ន្ធឯកសារទាំងអស់មិនត្រូវបានបង្កើតស្មើៗគ្នាទេ៖ នៅលើភាពស្មុគស្មាញនៃការបង្កើតកម្មវិធីដែលជាប់គាំង" и "ការធ្វើទារុណកម្មមូលដ្ឋានទិន្នន័យសម្រាប់ការសប្បាយនិងប្រាក់ចំណេញ". ពីពួកគេ អ្នកអាចប្រមូលព័ត៌មានអំពីភាពជឿជាក់ដែលមិនធ្លាប់មានពីមុនមករបស់ LMDB និងការអនុវត្តស្ទើរតែគ្មានកំហុសនៃលក្ខណៈសម្បត្តិប្រតិបត្តិការ ACID ដែលល្អជាង SQLite ។
5. ភាពតិចតួចបំផុតនៃ LMDB អនុញ្ញាតឱ្យតំណាងម៉ាស៊ីននៃកូដរបស់វាមានទីតាំងនៅទាំងស្រុងក្នុងឃ្លាំងសម្ងាត់ L1 នៃខួរក្បាលជាមួយនឹងលក្ខណៈល្បឿនបន្តបន្ទាប់។

ជាអកុសលនៅក្នុងប្រព័ន្ធប្រតិបត្តិការ iOS ជាមួយនឹងឯកសារដែលបានគូសផែនទីអង្គចងចាំ អ្វីៗទាំងអស់គឺមិនមានលក្ខណៈពពកដូចដែលយើងចង់បាននោះទេ។ ដើម្បីនិយាយអំពីការខ្វះខាតដែលទាក់ទងនឹងពួកគេកាន់តែដឹងខ្លួនវាចាំបាច់ត្រូវចងចាំគោលការណ៍ទូទៅនៃការអនុវត្តយន្តការនេះនៅក្នុងប្រព័ន្ធប្រតិបត្តិការ។

ព័ត៌មានទូទៅអំពីឯកសារដែលបានគូសផែនទីអង្គចងចាំ

ជាមួយនឹងរាល់កម្មវិធីដែលដំណើរការ ប្រព័ន្ធប្រតិបត្តិការបានភ្ជាប់អង្គភាពមួយហៅថាដំណើរការ។ ដំណើរការនីមួយៗត្រូវបានបែងចែកអាស័យដ្ឋានជាប់គ្នាដែលវាដាក់អ្វីគ្រប់យ៉ាងដែលវាត្រូវការដើម្បីដំណើរការ។ នៅអាសយដ្ឋានទាបបំផុត មានផ្នែកដែលមានកូដ និងទិន្នន័យ និងធនធានដែលមានកូដរឹង។ បន្ទាប់​មក​មាន​ការ​កើន​ឡើង​នៃ​ទំហំ​អាសយដ្ឋាន​ថាមវន្ត ដែល​យើង​ស្គាល់​យ៉ាង​ច្បាស់​ក្រោម​ឈ្មោះ​ហ៊ប។ វាមានអាសយដ្ឋានរបស់អង្គភាពដែលលេចឡើងកំឡុងពេលប្រតិបត្តិការនៃកម្មវិធី។ នៅផ្នែកខាងលើគឺជាតំបន់អង្គចងចាំដែលប្រើដោយជង់កម្មវិធី។ វាលូតលាស់ ឬចុះកិច្ចសន្យា ម្យ៉ាងវិញទៀត ទំហំរបស់វាក៏មានធម្មជាតិថាមវន្តផងដែរ។ ដើម្បីការពារជង់ និងហ៊ាពីការរុញ និងជ្រៀតជ្រែកគ្នាទៅវិញទៅមក ពួកវាមានទីតាំងនៅចុងផ្សេងគ្នានៃលំហអាសយដ្ឋាន។ វាមានរន្ធរវាងផ្នែកថាមវន្តទាំងពីរនៅផ្នែកខាងលើ និងខាងក្រោម។ ប្រព័ន្ធប្រតិបត្តិការប្រើអាសយដ្ឋាននៅក្នុងផ្នែកកណ្តាលនេះ ដើម្បីភ្ជាប់អង្គភាពផ្សេងៗជាមួយដំណើរការ។ ជាពិសេស វាអាចភ្ជាប់សំណុំអាសយដ្ឋានបន្តជាក់លាក់មួយជាមួយនឹងឯកសារនៅលើថាស។ ឯកសារបែបនេះត្រូវបានគេហៅថា memory-mapped.

ទំហំអាសយដ្ឋានដែលបានបែងចែកសម្រាប់ដំណើរការគឺធំណាស់។ តាមទ្រឹស្តី ចំនួនអាស័យដ្ឋានត្រូវបានកំណត់ត្រឹមទំហំនៃទ្រនិចប៉ុណ្ណោះ ដែលត្រូវបានកំណត់ដោយសមត្ថភាពប៊ីតនៃប្រព័ន្ធ។ ប្រសិនបើអង្គចងចាំរូបវន្តត្រូវបានគូសវាស 1-to-1 នោះដំណើរការដំបូងបំផុតនឹងគាស់ RAM ទាំងមូល ហើយវានឹងមិនមានការនិយាយអំពីកិច្ចការច្រើននោះទេ។

ទោះជាយ៉ាងណាក៏ដោយ តាមបទពិសោធន៍របស់យើង យើងដឹងថាប្រព័ន្ធប្រតិបត្តិការទំនើបក្នុងពេលដំណាលគ្នាអាចដំណើរការដំណើរការជាច្រើនតាមដែលចង់បាន។ នេះគឺអាចធ្វើទៅបានដោយសារតែការពិតដែលថាពួកគេគ្រាន់តែបែងចែកអង្គចងចាំជាច្រើនសម្រាប់ដំណើរការនៅលើក្រដាស ប៉ុន្តែតាមពិតពួកវាផ្ទុកទៅក្នុងអង្គចងចាំរូបវន្តសំខាន់តែផ្នែកដែលមានតម្រូវការនៅទីនេះ និងឥឡូវនេះប៉ុណ្ណោះ។ ដូច្នេះអង្គចងចាំដែលភ្ជាប់ជាមួយដំណើរការត្រូវបានគេហៅថានិម្មិត។

ប្រព័ន្ធប្រតិបត្តិការរៀបចំអង្គចងចាំនិម្មិត និងរូបវន្តទៅជាទំព័រនៃទំហំជាក់លាក់មួយ។ ដរាបណាទំព័រជាក់លាក់នៃសតិនិម្មិតមានតម្រូវការ ប្រព័ន្ធប្រតិបត្តិការនឹងផ្ទុកវាទៅក្នុងអង្គចងចាំរូបវន្ត ហើយផ្គូផ្គងពួកវាក្នុងតារាងពិសេសមួយ។ ប្រសិនបើមិនមានរន្ធដោតឥតគិតថ្លៃទេ នោះទំព័រមួយក្នុងចំណោមទំព័រដែលបានផ្ទុកពីមុនត្រូវបានចម្លងទៅឌីស ហើយទំព័រដែលត្រូវការជំនួស។ នីតិវិធីនេះដែលយើងនឹងត្រលប់ទៅក្នុងរយៈពេលខ្លីត្រូវបានគេហៅថា swapping រូបខាងក្រោមបង្ហាញពីដំណើរការដែលបានពិពណ៌នា។ នៅលើវា ទំព័រ A ដែលមានអាសយដ្ឋាន 0 ត្រូវបានផ្ទុក និងដាក់នៅលើទំព័រមេម៉ូរីដែលមានអាសយដ្ឋាន 4។ ការពិតនេះត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងតារាងការឆ្លើយឆ្លងនៅក្នុងក្រឡាលេខ 0។

រឿង​គឺ​ដូចគ្នា​នឹង​ឯកសារ​ដែល​បាន​ផ្គូផ្គង​ទៅ​អង្គចងចាំ។ តាមបែបឡូជីខល ពួកគេត្រូវបានគេសន្មត់ថាបន្ត និងមានទីតាំងនៅទាំងស្រុងក្នុងចន្លោះអាសយដ្ឋាននិម្មិត។ ទោះយ៉ាងណាក៏ដោយ ពួកគេបញ្ចូលទំព័រសតិរូបវន្តតាមទំព័រ ហើយតាមសំណើតែប៉ុណ្ណោះ។ ការកែប្រែទំព័របែបនេះត្រូវបានធ្វើសមកាលកម្មជាមួយឯកសារនៅលើថាស។ តាមវិធីនេះ អ្នកអាចអនុវត្តឯកសារ I/O ដោយគ្រាន់តែធ្វើការជាមួយបៃក្នុងអង្គចងចាំ - ការផ្លាស់ប្តូរទាំងអស់នឹងត្រូវបានផ្ទេរដោយស្វ័យប្រវត្តិដោយខឺណែលប្រព័ន្ធប្រតិបត្តិការទៅឯកសារប្រភព។
'' '"
រូបភាពខាងក្រោមបង្ហាញពីរបៀបដែល LMDB ធ្វើសមកាលកម្មស្ថានភាពរបស់វានៅពេលធ្វើការជាមួយមូលដ្ឋានទិន្នន័យពីដំណើរការផ្សេងៗ។ តាមរយៈការគូសផែនទីសតិនិម្មិតនៃដំណើរការផ្សេងៗគ្នាទៅជាឯកសារតែមួយ យើងតម្រូវឱ្យប្រព័ន្ធប្រតិបត្តិការធ្វើសមកាលកម្មបណ្តោះអាសន្ននៃប្លុកមួយចំនួននៃចន្លោះអាសយដ្ឋានរបស់ពួកគេជាមួយគ្នា ដែល LMDB មើលទៅ។
'' '"

ចំនុចសំខាន់មួយគឺថា LMDB តាមលំនាំដើម កែប្រែឯកសារទិន្នន័យតាមរយៈយន្តការហៅប្រព័ន្ធសរសេរ ហើយបង្ហាញឯកសារដោយខ្លួនឯងនៅក្នុងរបៀបបានតែអាន។ វិធីសាស្រ្តនេះមានផលវិបាកសំខាន់ពីរ។

ផលវិបាកដំបូងគឺជារឿងធម្មតាសម្រាប់ប្រព័ន្ធប្រតិបត្តិការទាំងអស់។ ខ្លឹមសាររបស់វាគឺដើម្បីបន្ថែមការការពារប្រឆាំងនឹងការខូចខាតដោយអចេតនាទៅកាន់មូលដ្ឋានទិន្នន័យដោយលេខកូដមិនត្រឹមត្រូវ។ ដូចដែលអ្នកដឹង ការណែនាំដែលអាចប្រតិបត្តិបាននៃដំណើរការមួយគឺអាចចូលប្រើទិន្នន័យបានដោយសេរីពីគ្រប់ទីកន្លែងក្នុងទំហំអាសយដ្ឋានរបស់វា។ ក្នុងពេលជាមួយគ្នា ដូចដែលយើងទើបតែចងចាំ ការបង្ហាញឯកសារក្នុងរបៀបអាន-សរសេរ មានន័យថាការណែនាំណាមួយក៏អាចកែប្រែវាបានដែរ។ ប្រសិនបើនាងធ្វើវាដោយកំហុស ដោយព្យាយាមឧទាហរណ៍ ដើម្បីសរសេរជាន់លើធាតុអារេនៅលិបិក្រមដែលមិនមាននោះ នាងអាចផ្លាស់ប្តូរឯកសារដែលបានគូសផែនទីទៅអាសយដ្ឋាននេះដោយចៃដន្យ ដែលនឹងនាំឱ្យមានអំពើពុករលួយនៃមូលដ្ឋានទិន្នន័យ។ ប្រសិនបើឯកសារត្រូវបានបង្ហាញក្នុងរបៀបបានតែអាន នោះការព្យាយាមផ្លាស់ប្តូរទំហំអាសយដ្ឋានដែលត្រូវគ្នានឹងនាំទៅដល់ការបញ្ចប់កម្មវិធីជាបន្ទាន់ជាមួយនឹងសញ្ញាមួយ។ SIGSEGVហើយឯកសារនឹងនៅដដែល។

ផលវិបាកទីពីរគឺជាក់លាក់រួចទៅហើយចំពោះ iOS ។ ទាំងអ្នកនិពន្ធ ឬប្រភពណាមួយផ្សេងទៀតបញ្ជាក់យ៉ាងច្បាស់អំពីវា ប៉ុន្តែបើគ្មានវា LMDB នឹងមិនស័ក្តិសមសម្រាប់ការដំណើរការលើប្រព័ន្ធប្រតិបត្តិការទូរស័ព្ទនេះទេ។ ផ្នែកបន្ទាប់ត្រូវបានឧទ្ទិសដល់ការពិចារណារបស់វា។

លក្ខណៈ​ពិសេស​នៃ​ឯកសារ​ដែល​បាន​គូស​ផែនទី​អង្គ​ចងចាំ​នៅ​ក្នុង iOS

មានរបាយការណ៍ដ៏អស្ចារ្យមួយនៅឯ WWDC ក្នុងឆ្នាំ 2018 "iOS Memory Deep Dive". វាប្រាប់យើងថានៅក្នុងប្រព័ន្ធប្រតិបត្តិការ iOS ទំព័រទាំងអស់ដែលមាននៅក្នុងអង្គចងចាំរាងកាយគឺជាប្រភេទមួយក្នុងចំណោម 3 ប្រភេទ៖ កខ្វក់ បង្ហាប់ និងស្អាត។

សតិស្អាតគឺជាបណ្តុំនៃទំព័រដែលអាចត្រូវបានដកចេញដោយគ្មានការឈឺចាប់ពីសតិរាងកាយ។ ទិន្នន័យដែលពួកគេផ្ទុកអាចត្រូវបានផ្ទុកឡើងវិញតាមតម្រូវការពីប្រភពដើមរបស់វា។ ឯកសារដែលបានគូសផែនទីអង្គចងចាំបានតែអាន ស្ថិតក្នុងប្រភេទនេះ។ ប្រព័ន្ធប្រតិបត្តិការ iOS មិនភ័យខ្លាចក្នុងការដកទំព័រដែលបានគូសវាសទៅជាឯកសារពីអង្គចងចាំគ្រប់ពេលនោះទេ ដោយសារពួកវាត្រូវបានធានាថានឹងធ្វើសមកាលកម្មជាមួយឯកសារនៅលើថាស។
'' '"
ទំព័រដែលបានកែប្រែទាំងអស់បញ្ចប់ដោយអង្គចងចាំកខ្វក់ មិនថាពួកគេស្ថិតនៅកន្លែងណាពីដើមឡើយ។ ជាពិសេស ឯកសារដែលបានគូសផែនទីអង្គចងចាំដែលបានកែប្រែដោយការសរសេរទៅកាន់អង្គចងចាំនិម្មិតដែលភ្ជាប់ជាមួយពួកវានឹងត្រូវបានចាត់ថ្នាក់តាមវិធីនេះ។ បើក LMDB ជាមួយទង់ MDB_WRITEMAPបន្ទាប់​ពី​ធ្វើ​ការ​ផ្លាស់​ប្តូ​រ​ទៅ​វា អ្នក​អាច​ផ្ទៀងផ្ទាត់​វា​ផ្ទាល់​ខ្លួន.

​ដរាបណា​កម្មវិធី​មួយ​ចាប់ផ្តើម​យក​អង្គ​ចងចាំ​ច្រើន​ពេក ប្រព័ន្ធ​ប្រតិបត្តិការ iOS នឹង​ធ្វើ​ឱ្យ​វា​ទៅ​នឹង​ការ​បង្ហាប់​ទំព័រ​កខ្វក់។ អង្គចងចាំសរុបដែលកាន់កាប់ដោយទំព័រដែលកខ្វក់ និងបានបង្ហាប់បង្កើតបានជាកម្មវិធីដែលហៅថា ដានអង្គចងចាំរបស់កម្មវិធី។ នៅពេលដែលវាឈានដល់តម្លៃកម្រិតជាក់លាក់មួយ ដេមិនប្រព័ន្ធឃាតករ OOM មកបន្ទាប់ពីដំណើរការ ហើយបង្ខំវាចោល។ នេះគឺជាលក្ខណៈពិសេសរបស់ iOS បើប្រៀបធៀបទៅនឹងប្រព័ន្ធប្រតិបត្តិការលើតុ។ ផ្ទុយ​ទៅ​វិញ ការ​កាត់​បន្ថយ​ទំហំ​មេម៉ូរី​ដោយ​ការ​ប្តូរ​ទំព័រ​ពី​អង្គ​ចងចាំ​រូបវន្ត​ទៅ​ថាស​មិន​ត្រូវ​បាន​ផ្តល់​ឱ្យ​នៅ​ក្នុង iOS ទេ។ ហេតុផល​អាច​ត្រូវ​បាន​គេ​ស្មាន​តែ​ប៉ុណ្ណោះ។ ប្រហែលជានីតិវិធីនៃការផ្លាស់ប្តូរទំព័រទៅឌីស និងថយក្រោយគឺប្រើប្រាស់ថាមពលខ្លាំងពេកសម្រាប់ឧបករណ៍ចល័ត ឬប្រព័ន្ធប្រតិបត្តិការ iOS រក្សាទុកធនធាននៃការសរសេរក្រឡាឡើងវិញនៅលើដ្រាយ SSD ឬប្រហែលជាអ្នករចនាមិនពេញចិត្តនឹងដំណើរការទាំងមូលនៃប្រព័ន្ធ ដែលអ្វីៗទាំងអស់គឺ ផ្លាស់ប្តូរឥតឈប់ឈរ។ ត្រូវថាតាមដែលអាចធ្វើបាន ការពិតនៅតែជាការពិត។

ដំណឹង​ល្អ​ដែល​បាន​និយាយ​រួច​ហើយ​មុន​នេះ​គឺ​ថា LMDB តាម​លំនាំដើម​មិន​ប្រើ​យន្តការ mmap ដើម្បី​ធ្វើ​បច្ចុប្បន្នភាព​ឯកសារ​ទេ។ នេះមានន័យថាទិន្នន័យដែលបង្ហាញត្រូវបានចាត់ថ្នាក់ដោយប្រព័ន្ធប្រតិបត្តិការ iOS ជាអង្គចងចាំស្អាត និងមិនរួមចំណែកដល់ការចាប់យកអង្គចងចាំនោះទេ។ អ្នកអាចផ្ទៀងផ្ទាត់វាដោយប្រើឧបករណ៍ Xcode ដែលហៅថា VM Tracker។ រូបថតអេក្រង់ខាងក្រោមបង្ហាញពីស្ថានភាពនៃអង្គចងចាំនិម្មិត iOS របស់កម្មវិធី Cloud កំឡុងពេលប្រតិបត្តិការ។ នៅពេលចាប់ផ្តើម ករណី LMDB ចំនួន 2 ត្រូវបានចាប់ផ្តើមនៅក្នុងវា។ ទីមួយត្រូវបានអនុញ្ញាតឱ្យបង្ហាញឯកសាររបស់គាត់នៅលើ 1GiB នៃសតិនិម្មិត ទីពីរ - 512MiB ។ ទោះបីជាការពិតដែលថាការផ្ទុកទាំងពីរកាន់កាប់ចំនួនជាក់លាក់នៃអង្គចងចាំអ្នករស់នៅក៏ដោយក៏ពួកគេទាំងពីរមិនរួមចំណែកទំហំកខ្វក់នោះទេ។

ហើយឥឡូវនេះវាជាពេលវេលាសម្រាប់ដំណឹងអាក្រក់។ សូមអរគុណចំពោះយន្តការ swap នៅក្នុងប្រព័ន្ធប្រតិបត្តិការផ្ទៃតុ 64 ប៊ីត ដំណើរការនីមួយៗអាចកាន់កាប់កន្លែងអាសយដ្ឋាននិម្មិតបានច្រើន ដូចដែលទំហំថាសរឹងឥតគិតថ្លៃសម្រាប់ការផ្លាស់ប្តូរសក្តានុពលរបស់វាអនុញ្ញាត។ ការជំនួស swap ជាមួយការបង្ហាប់នៅក្នុង iOS កាត់បន្ថយយ៉ាងខ្លាំងនូវទ្រឹស្តីបទ។ ឥឡូវនេះដំណើរការរស់នៅទាំងអស់ត្រូវតែសមនឹងអង្គចងចាំមេ (អាន RAM) ហើយអ្វីៗទាំងអស់ដែលមិនសមត្រូវតែបង្ខំឱ្យបញ្ចប់។ នេះ​ជា​ការ​បញ្ជាក់​ដូច​ការ​លើក​ឡើង​ខាង​លើ របាយការណ៍និងក្នុង ឯកសារផ្លូវការ. ជាលទ្ធផល iOS កំណត់យ៉ាងធ្ងន់ធ្ងរនូវចំនួនអង្គចងចាំដែលមានសម្រាប់ការបែងចែកតាមរយៈ mmap ។ នៅទីនេះ នៅទីនេះ អ្នកអាចមើលដែនកំណត់ជាក់ស្តែងនៃចំនួនអង្គចងចាំដែលអាចត្រូវបានបែងចែកនៅលើឧបករណ៍ផ្សេងៗដោយប្រើការហៅតាមប្រព័ន្ធនេះ។ នៅលើម៉ូដែលស្មាតហ្វូនទំនើបបំផុត ប្រព័ន្ធប្រតិបត្តិការ iOS បានក្លាយទៅជាសប្បុរសដោយ 2 ជីហ្គាបៃ និងនៅលើកំណែកំពូលនៃ iPad - ដោយ 4. នៅក្នុងការអនុវត្តជាក់ស្តែង អ្នកត្រូវតែផ្តោតលើម៉ូដែលឧបករណ៍ដែលគាំទ្រទាបបំផុត ដែលអ្វីគ្រប់យ៉ាងគឺសោកសៅបំផុត។ អាក្រក់ជាងនេះទៅទៀត ដោយមើលស្ថានភាពអង្គចងចាំរបស់កម្មវិធីនៅក្នុង VM Tracker អ្នកនឹងឃើញថា LMDB គឺនៅឆ្ងាយពីតែមួយគត់ដែលអះអាងថាត្រូវបានគូសផែនទីអង្គចងចាំ។ កំណាត់ល្អត្រូវបានស៊ីដាច់ដោយអ្នកបែងចែកប្រព័ន្ធ ឯកសារធនធាន ក្របខណ្ឌរូបភាព និងសត្វមំសាសីតូចៗផ្សេងទៀត។

ដោយផ្អែកលើលទ្ធផលនៃការពិសោធន៍នៅក្នុង Cloud យើងបានមកដល់តម្លៃសម្របសម្រួលដូចខាងក្រោមសម្រាប់អង្គចងចាំដែលបានបែងចែកដោយ LMDB: 384 មេកាបៃសម្រាប់ឧបករណ៍ 32 ប៊ីត និង 768 សម្រាប់ឧបករណ៍ 64 ប៊ីត។ បន្ទាប់ពីបរិមាណនេះត្រូវបានប្រើអស់ហើយ ប្រតិបត្តិការកែប្រែណាមួយចាប់ផ្តើមបញ្ចប់ដោយលេខកូដ MDB_MAP_FULL. យើងសង្កេតឃើញកំហុសបែបនេះនៅក្នុងការត្រួតពិនិត្យរបស់យើង ប៉ុន្តែវាមានតិចតួចដែលនៅដំណាក់កាលនេះ ពួកគេអាចត្រូវបានគេមិនយកចិត្តទុកដាក់។

ហេតុផលមិនច្បាស់លាស់សម្រាប់ការប្រើប្រាស់អង្គចងចាំច្រើនពេកដោយការផ្ទុកអាចជាប្រតិបត្តិការយូរអង្វែង។ ដើម្បីយល់ពីរបៀបដែលបាតុភូតទាំងពីរនេះត្រូវបានភ្ជាប់គ្នា យើងនឹងត្រូវបានជួយដោយពិចារណាលើសសរស្តម្ភពីរដែលនៅសល់នៃ LMDB ។

៣.២. ត្រីបាឡែន #3.2. ខ + - ដើមឈើ

ដើម្បីត្រាប់តាមតារាងនៅលើកំពូលនៃការផ្ទុកតម្លៃសោ ប្រតិបត្តិការខាងក្រោមត្រូវតែមានវត្តមាននៅក្នុង API របស់វា៖

1. ការបញ្ចូលធាតុថ្មី។
2. ស្វែងរកធាតុដែលមានសោដែលបានផ្តល់ឱ្យ។
3. ការដកធាតុមួយ។
4. ធ្វើម្តងទៀតលើចន្លោះពេលនៃគ្រាប់ចុចតាមលំដាប់ដែលពួកគេត្រូវបានតម្រៀប។

រចនាសម្ព័ន្ធទិន្នន័យសាមញ្ញបំផុតដែលអាចអនុវត្តបានយ៉ាងងាយស្រួលនូវប្រតិបត្តិការទាំងបួនគឺជាមែកធាងស្វែងរកប្រព័ន្ធគោលពីរ។ ថ្នាំងនីមួយៗរបស់វាតំណាងឱ្យកូនសោដែលបែងចែកសំណុំរងទាំងមូលនៃកូនសោរទៅជាមែកធាងរងពីរ។ ខាងឆ្វេងមានរបស់ដែលតូចជាងមេ ហើយខាងស្តាំមានរបស់ដែលធំជាង។ ការទទួលបានកូនសោដែលបានបញ្ជាទិញគឺសម្រេចបានតាមរយៈការឆ្លងកាត់ដើមឈើបុរាណមួយ។

ដើមឈើគោលពីរមានគុណវិបត្តិជាមូលដ្ឋានពីរដែលរារាំងពួកគេមិនឱ្យមានប្រសិទ្ធភាពជារចនាសម្ព័ន្ធទិន្នន័យផ្អែកលើថាស។ ទីមួយកម្រិតនៃតុល្យភាពរបស់ពួកគេគឺមិនអាចទាយទុកជាមុនបាន។ មានហានិភ័យសន្ធឹកសន្ធាប់ក្នុងការទទួលបានដើមឈើ ដែលកម្ពស់នៃមែកឈើផ្សេងៗគ្នាអាចខុសគ្នាយ៉ាងខ្លាំង ដែលធ្វើឲ្យភាពស្មុគស្មាញនៃក្បួនដោះស្រាយនៃការស្វែងរកកាន់តែអាក្រក់ទៅៗ បើប្រៀបធៀបទៅនឹងអ្វីដែលរំពឹងទុក។ ទីពីរ ភាពសម្បូរបែបនៃតំណភ្ជាប់ឆ្លងរវាងថ្នាំងដកហូតដើមឈើគោលពីរនៃមូលដ្ឋាននៅក្នុងសតិ។ ថ្នាំងបិទ (ទាក់ទងនឹងការតភ្ជាប់រវាងពួកវា) អាចមានទីតាំងនៅលើទំព័រផ្សេងគ្នាទាំងស្រុងនៅក្នុងសតិនិម្មិត។ ជាលទ្ធផល សូម្បីតែការឆ្លងកាត់ដ៏សាមញ្ញនៃថ្នាំងជិតខាងជាច្រើននៅក្នុងមែកធាងមួយអាចតម្រូវឱ្យចូលមើលចំនួនទំព័រដែលអាចប្រៀបធៀបបាន។ នេះគឺជាបញ្ហាសូម្បីតែនៅពេលដែលយើងនិយាយអំពីប្រសិទ្ធភាពនៃដើមឈើគោលពីរជារចនាសម្ព័ន្ធទិន្នន័យក្នុងអង្គចងចាំក៏ដោយ ចាប់តាំងពីការបង្វិលទំព័រឥតឈប់ឈរនៅក្នុងឃ្លាំងសម្ងាត់របស់ខួរក្បាលមិនមែនជាការរីករាយថោកនោះទេ។ នៅពេលដែលវាមកដល់ជាញឹកញាប់ទៅយកទំព័រដែលភ្ជាប់ជាមួយថ្នាំងពីថាស ស្ថានភាពនឹងក្លាយទៅជាទាំងស្រុង គួរ​ឲ្យ​អាណិត។

B-trees ដែលជាការវិវត្តន៍នៃដើមឈើគោលពីរ ដោះស្រាយបញ្ហាដែលបានកំណត់ក្នុងកថាខណ្ឌមុន។ ទីមួយពួកគេមានតុល្យភាពដោយខ្លួនឯង។ ទីពីរ ថ្នាំងនីមួយៗរបស់ពួកគេបំបែកសំណុំកូនសោមិនទៅជា 2 ប៉ុន្តែទៅជាសំណុំរង M ហើយលេខ M អាចមានទំហំធំណាស់ តាមលំដាប់នៃរាប់រយ ឬរាប់ពាន់។

ដោយហេតុនេះ៖

1. ថ្នាំងនីមួយៗមានកូនសោដែលបានបញ្ជាទិញរួចហើយមួយចំនួនធំ ហើយដើមឈើខ្លីណាស់។
2. មែកធាងទទួលបានទ្រព្យសម្បត្តិនៃទីតាំងនៃទីតាំងនៅក្នុងសតិ ចាប់តាំងពីគ្រាប់ចុចដែលមានតម្លៃជិតគឺស្ថិតនៅជាប់គ្នាដោយធម្មជាតិនៅលើថ្នាំងដូចគ្នា ឬជិតខាង។
3. ចំនួនថ្នាំងឆ្លងកាត់ពេលចុះដើមឈើកំឡុងពេលប្រតិបត្តិការស្វែងរកត្រូវបានកាត់បន្ថយ។
4. ចំនួននៃថ្នាំងគោលដៅដែលបានអានក្នុងអំឡុងពេលសំណួរជួរត្រូវបានកាត់បន្ថយ ដោយសារពួកវានីមួយៗមានកូនសោដែលបានបញ្ជាទិញមួយចំនួនធំរួចហើយ។

LMDB ប្រើបំរែបំរួលនៃ B-tree ដែលហៅថា B+ tree ដើម្បីរក្សាទុកទិន្នន័យ។ ដ្យាក្រាមខាងលើបង្ហាញពីថ្នាំងបីប្រភេទដែលមាននៅក្នុងវា៖

1. នៅផ្នែកខាងលើគឺជាឫស។ វាមិនមានអ្វីលើសពីគំនិតនៃមូលដ្ឋានទិន្នន័យនៅក្នុងឃ្លាំងនោះទេ។ នៅក្នុងឧទាហរណ៍ LMDB មួយ អ្នកអាចបង្កើតមូលដ្ឋានទិន្នន័យជាច្រើនដែលចែករំលែកទំហំអាសយដ្ឋាននិម្មិតដែលបានគូសផែនទី។ ពួកវានីមួយៗចាប់ផ្តើមពីឫសរបស់វា។
2. នៅកម្រិតទាបបំផុតគឺស្លឹក។ ពួកវា និងមានតែពួកវាប៉ុណ្ណោះដែលមានគូតម្លៃសោដែលរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ។ និយាយអញ្ចឹងនេះគឺជាលក្ខណៈពិសេសរបស់ B+-trees ។ ប្រសិនបើមែកធាង B ធម្មតារក្សាទុកផ្នែកតម្លៃនៅក្នុងថ្នាំងគ្រប់កម្រិត នោះការប្រែប្រួល B+ គឺត្រឹមតែមួយទាបបំផុតប៉ុណ្ណោះ។ ដោយបានជួសជុលការពិតនេះ យើងនឹងហៅប្រភេទរងនៃមែកធាងដែលប្រើក្នុង LMDB ថាជាមែកធាង B។
3. នៅចន្លោះឫស និងស្លឹកមានកម្រិតបច្ចេកទេស 0 ឬច្រើនជាងនេះ ជាមួយនឹងថ្នាំងរុករក (សាខា)។ ភារកិច្ចរបស់ពួកគេគឺត្រូវបែងចែកកូនសោដែលបានតម្រៀបរវាងស្លឹក។

តាមរូបវិទ្យា ថ្នាំងគឺជាប្លុកនៃការចងចាំនៃប្រវែងដែលបានកំណត់ទុកជាមុន។ ទំហំរបស់ពួកគេគឺជាទំហំច្រើននៃទំព័រសតិនៅក្នុងប្រព័ន្ធប្រតិបត្តិការដែលយើងបានពិភាក្សាខាងលើ។ រចនាសម្ព័ន្ធថ្នាំងត្រូវបានបង្ហាញខាងក្រោម។ បឋមកថាមានព័ត៌មានមេតា ​​ដែលជាក់ស្តែងបំផុតដែលជាឧទាហរណ៍គឺ មូលប្បទានប័ត្រ។ បន្ទាប់មានព័ត៌មានអំពីអុហ្វសិតដែលកោសិកាដែលមានទិន្នន័យស្ថិតនៅ។ ទិន្នន័យអាចជាគ្រាប់ចុចទាំងពីរ ប្រសិនបើយើងកំពុងនិយាយអំពីថ្នាំងរុករក ឬគូតម្លៃសោទាំងមូលនៅក្នុងករណីនៃស្លឹក។ អ្នកអាចអានបន្ថែមអំពីរចនាសម្ព័ន្ធនៃទំព័រនៅក្នុងការងារ។ "ការវាយតម្លៃនៃហាងដែលមានតម្លៃខ្ពស់".

ដោយបានដោះស្រាយជាមួយមាតិកាខាងក្នុងនៃថ្នាំងទំព័រ យើងនឹងតំណាងឱ្យ LMDB B-tree បន្ថែមទៀតក្នុងលក្ខណៈសាមញ្ញក្នុងទម្រង់ខាងក្រោម។

ទំព័រដែលមានថ្នាំងមានទីតាំងនៅតាមលំដាប់លំដោយនៅលើថាស។ ទំព័រដែលមានលេខខ្ពស់ជាងមានទីតាំងនៅខាងចុងឯកសារ។ ទំព័រមេតាដែលគេហៅថាមានព័ត៌មានអំពីអុហ្វសិតដែលឫសនៃដើមឈើទាំងអស់អាចត្រូវបានរកឃើញ។ នៅពេលបើកឯកសារ LMDB ស្កេនទំព័រឯកសារដោយទំព័រពីចុងដល់ដើម ដើម្បីស្វែងរកទំព័រមេតាត្រឹមត្រូវ ហើយតាមរយៈវារកឃើញមូលដ្ឋានទិន្នន័យដែលមានស្រាប់។

ឥឡូវនេះដោយមានគំនិតអំពីរចនាសម្ព័ន្ធឡូជីខល និងរូបវន្តនៃអង្គការទិន្នន័យ យើងអាចបន្តទៅពិចារណាសសរស្តម្ភទីបីនៃ LMDB ។ វាគឺដោយមានជំនួយរបស់វា ដែលការកែប្រែការផ្ទុកទាំងអស់កើតឡើងក្នុងប្រតិបត្តិការ និងនៅដាច់ដោយឡែកពីគ្នាទៅវិញទៅមក ដោយផ្តល់ឱ្យមូលដ្ឋានទិន្នន័យទាំងមូលនូវទ្រព្យសម្បត្តិនៃពហុកំណែ។

៣.៣. ត្រីបាឡែន #3.3. ចម្លងលើការសរសេរ

ប្រតិបត្តិការ B-tree មួយចំនួនពាក់ព័ន្ធនឹងការធ្វើការផ្លាស់ប្តូរជាបន្តបន្ទាប់ទៅលើថ្នាំងរបស់វា។ ឧទាហរណ៍មួយគឺការបន្ថែមកូនសោថ្មីទៅថ្នាំងដែលឈានដល់សមត្ថភាពអតិបរមារបស់វារួចហើយ។ ក្នុងករណីនេះ វាចាំបាច់ក្នុងការបំបែកថ្នាំងជាពីរ ហើយទីពីរគឺត្រូវបន្ថែមតំណទៅថ្នាំងកូនបង្កើតថ្មីនៅក្នុងមេរបស់វា។ នីតិវិធីនេះគឺមានគ្រោះថ្នាក់ខ្លាំងណាស់។ ប្រសិនបើសម្រាប់ហេតុផលមួយចំនួន (ការគាំង ការដាច់ចរន្តអគ្គិសនី។

ដំណោះស្រាយបែបប្រពៃណីមួយសម្រាប់ការធ្វើឱ្យមូលដ្ឋានទិន្នន័យមានភាពអត់ធ្មត់គឺការបន្ថែមរចនាសម្ព័ន្ធទិន្នន័យនៅលើឌីសបន្ថែមនៅជាប់នឹង B-tree - កំណត់ហេតុប្រតិបត្តិការ ដែលត្រូវបានគេស្គាល់ថាជាកំណត់ហេតុសរសេរជាមុន (WAL) ។ វាគឺជាឯកសារនៅចុងបញ្ចប់នៃប្រតិបត្តិការដែលមានបំណងត្រូវបានសរសេរយ៉ាងតឹងរ៉ឹងមុនពេលកែប្រែ B-tree ដោយខ្លួនឯង។ ដូច្នេះ ប្រសិនបើទិន្នន័យត្រូវបានរកឃើញថាមានអំពើពុករលួយកំឡុងពេលធ្វើរោគវិនិច្ឆ័យដោយខ្លួនឯង នោះមូលដ្ឋានទិន្នន័យនឹងពិភាក្សាលើកំណត់ហេតុដើម្បីដាក់ខ្លួនវាតាមលំដាប់លំដោយ។

LMDB បានជ្រើសរើសវិធីសាស្រ្តផ្សេងគ្នាជាយន្តការអត់ឱនកំហុសរបស់ខ្លួន ដែលហៅថាការចម្លងលើការសរសេរ។ ខ្លឹមសាររបស់វាគឺថា ជំនួសឱ្យការធ្វើបច្ចុប្បន្នភាពទិន្នន័យនៅលើទំព័រដែលមានស្រាប់ វាចម្លងវាទាំងស្រុង និងធ្វើការកែប្រែទាំងអស់នៅក្នុងច្បាប់ចម្លង។

បន្ទាប់មក ដើម្បីឱ្យទិន្នន័យដែលបានអាប់ដេតមាន វាចាំបាច់ត្រូវផ្លាស់ប្តូរតំណភ្ជាប់ទៅថ្នាំងដែលបានក្លាយជាបច្ចុប្បន្ននៅក្នុងថ្នាំងមេរបស់វា។ ដោយសារ​វា​ក៏​ត្រូវ​កែប្រែ​សម្រាប់​វា​ដែរ វា​ក៏​ត្រូវ​បាន​ចម្លង​ទុក​ជាមុន​ដែរ។ ដំណើរការបន្តកើតឡើងដដែលៗរហូតដល់ឫស។ រឿងចុងក្រោយដែលត្រូវផ្លាស់ប្តូរគឺទិន្នន័យនៅលើទំព័រមេតា.

ប្រសិនបើភ្លាមៗនោះដំណើរការគាំងកំឡុងពេលធ្វើបច្ចុប្បន្នភាព នោះទំព័រមេតាថ្មីនឹងមិនត្រូវបានបង្កើតទេ ឬវានឹងមិនត្រូវបានសរសេរទៅក្នុងថាសទាំងស្រុងនោះទេ ហើយការពិនិត្យរបស់វានឹងមិនត្រឹមត្រូវ។ ក្នុងករណីទាំងពីរនេះ ទំព័រថ្មីនឹងមិនអាចទៅដល់បាន ប៉ុន្តែទំព័រចាស់នឹងមិនរងផលប៉ះពាល់ទេ។ នេះលុបបំបាត់តម្រូវការសម្រាប់ LMDB ក្នុងការសរសេរកំណត់ហេតុជាមុន ដើម្បីរក្សាភាពស៊ីសង្វាក់គ្នានៃទិន្នន័យ។ តាមការពិត រចនាសម្ព័ន្ធនៃការផ្ទុកទិន្នន័យនៅលើថាសដែលបានពិពណ៌នាខាងលើក្នុងពេលដំណាលគ្នានឹងដំណើរការមុខងាររបស់វា។ អវត្ដមាននៃកំណត់ហេតុប្រតិបត្តិការច្បាស់លាស់គឺជាលក្ខណៈពិសេសមួយនៃ LMDB ដែលផ្តល់នូវល្បឿនអានទិន្នន័យខ្ពស់។

ការរចនាលទ្ធផល ដែលហៅថា append-only B-tree ផ្តល់នូវភាពឯកោប្រតិបត្តិការ និងពហុកំណែដោយធម្មជាតិ។ នៅក្នុង LMDB ប្រតិបត្តិការបើកនីមួយៗត្រូវបានភ្ជាប់ជាមួយឫសមែកធាងដែលពាក់ព័ន្ធបច្ចុប្បន្ន។ រហូតទាល់តែប្រតិបត្តិការត្រូវបានបញ្ចប់ ទំព័រនៃមែកធាងដែលភ្ជាប់ជាមួយវានឹងមិនត្រូវបានផ្លាស់ប្តូរ ឬប្រើឡើងវិញសម្រាប់កំណែថ្មីនៃទិន្នន័យនោះទេ។ ដូច្នេះអ្នកអាចធ្វើការឱ្យបានយូរតាមដែលអ្នកចង់បានជាមួយនឹងសំណុំទិន្នន័យដែលពាក់ព័ន្ធនៅពេលនោះ។ ប្រតិបត្តិការត្រូវបានបើក ទោះបីជាទំហំផ្ទុកនៅតែបន្តធ្វើបច្ចុប្បន្នភាពយ៉ាងសកម្មនៅពេលនេះក៏ដោយ។ នេះគឺជាខ្លឹមសារនៃការបំប្លែងច្រើន ដែលធ្វើឲ្យ LMDB ជាប្រភពទិន្នន័យដ៏ល្អសម្រាប់មនុស្សជាទីស្រឡាញ់របស់យើង។ UICollectionView. ដោយបានបើកប្រតិបត្តិការ មិនចាំបាច់បង្កើនទំហំអង្គចងចាំរបស់កម្មវិធីដោយប្រញាប់ប្រញាល់បញ្ចូនទិន្នន័យបច្ចុប្បន្នទៅក្នុងរចនាសម្ព័ន្ធក្នុងអង្គចងចាំមួយចំនួន ព្រោះខ្លាចមិនទុកអ្វីទាំងអស់។ លក្ខណៈពិសេសនេះបែងចែក LMDB ពី SQLite ដូចគ្នា ដែលមិនអាចមានអំនួតពីភាពឯកោសរុបបែបនេះ។ ដោយបានបើកប្រតិបត្តិការពីរនៅក្នុងពេលក្រោយ ហើយបានលុបកំណត់ត្រាជាក់លាក់មួយនៅក្នុងមួយក្នុងចំណោមពួកគេ វានឹងមិនអាចទទួលបានកំណត់ត្រាដូចគ្នានៅក្នុងទីពីរដែលនៅសល់នោះទេ។

ផ្នែកត្រឡប់នៃកាក់គឺជាការប្រើប្រាស់សក្ដានុពលខ្ពស់នៃអង្គចងចាំនិម្មិត។ ស្លាយបង្ហាញថាតើរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យនឹងមើលទៅដូចម្ដេច ប្រសិនបើវាត្រូវបានកែប្រែក្នុងពេលដំណាលគ្នាជាមួយនឹងប្រតិបត្តិការអានចំនួន 3 ដែលបើកមើលកំណែផ្សេងគ្នានៃមូលដ្ឋានទិន្នន័យ។ ដោយសារ LMDB មិនអាចប្រើឡើងវិញនូវថ្នាំងដែលអាចទៅដល់បានពីឫសដែលទាក់ទងនឹងប្រតិបត្តិការបច្ចុប្បន្ន ហាងមិនមានជម្រើសអ្វីក្រៅពីបែងចែកឫសទីបួនផ្សេងទៀតនៅក្នុងសតិ ហើយម្តងទៀតក្លូនទំព័រដែលបានកែប្រែនៅក្រោមវា។

នៅទីនេះវានឹងមានប្រយោជន៍ក្នុងការរំលឹកឡើងវិញនូវផ្នែកនៅលើឯកសារដែលបានគូសផែនទីអង្គចងចាំ។ វាហាក់បីដូចជាការប្រើប្រាស់បន្ថែមនៃសតិនិម្មិតមិនគួរព្រួយបារម្ភយើងច្រើននោះទេ ព្រោះវាមិនបានរួមចំណែកដល់ការចងចាំរបស់កម្មវិធីនោះទេ។ ទោះយ៉ាងណាក៏ដោយ ក្នុងពេលជាមួយគ្នានេះ វាត្រូវបានគេកត់សម្គាល់ថាប្រព័ន្ធប្រតិបត្តិការ iOS មានភាពតឹងតែងក្នុងការបែងចែកវា ហើយយើងមិនអាច ដូចជានៅលើម៉ាស៊ីនមេ ឬកុំព្យូទ័រលើតុ ផ្តល់តំបន់ LMDB នៃ 1 តេរ៉ាបៃ ហើយមិនគិតពីលក្ខណៈពិសេសនេះទាល់តែសោះ។ បើអាចធ្វើបាន អ្នកគួរតែព្យាយាមធ្វើឱ្យប្រតិបត្តិការរយៈពេលខ្លីតាមដែលអាចធ្វើទៅបាន។

4. ការរចនាគ្រោងការណ៍ទិន្នន័យនៅលើកំពូលនៃ key-value 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, បង្កើនវា។ ទោះយ៉ាងណាក៏ដោយវាមានបន្លាច្រើនជាង។ ហេតុផលគឺថានីតិវិធីសម្រាប់ការបែងចែកអង្គចងចាំឡើងវិញ (remap) ដោយប្រើមុខងារ mdb_env_set_map_size ធ្វើឱ្យអង្គភាពទាំងអស់មានសុពលភាព (ទស្សន៍ទ្រនិច ប្រតិបត្តិការ សោ និងតម្លៃ) ដែលបានទទួលពីមុនពីម៉ាស៊ីន។ ការទទួលយកវេននៃព្រឹត្តិការណ៍នេះទៅក្នុងគណនីនៅក្នុងកូដនឹងនាំឱ្យមានផលវិបាកដ៏សំខាន់របស់វា។ បើទោះជាយ៉ាងណា អង្គចងចាំនិម្មិតមានសារៈសំខាន់ចំពោះអ្នក នោះអាចជាហេតុផលដើម្បីពិនិត្យមើលឱ្យកាន់តែច្បាស់អំពីសមដែលបានទៅឆ្ងាយ។ MDBXដែលជាកន្លែងដែលក្នុងចំណោមលក្ខណៈពិសេសដែលបានប្រកាសមាន "ការលៃតម្រូវទំហំមូលដ្ឋានទិន្នន័យដោយស្វ័យប្រវត្តិ" ។

ប៉ារ៉ាម៉ែត្រទីពីរដែលជាតម្លៃលំនាំដើមដែលមិនសមនឹងយើងគ្រប់គ្រងយន្តការនៃការធានាសុវត្ថិភាពខ្សែស្រឡាយ។ ជាអកុសល យ៉ាងហោចណាស់ប្រព័ន្ធប្រតិបត្តិការ iOS 10 មានបញ្ហាជាមួយនឹងការគាំទ្រសម្រាប់ការផ្ទុកទិន្នន័យក្នុងតំបន់។ សម្រាប់ហេតុផលនេះនៅក្នុងឧទាហរណ៍ខាងលើឃ្លាំងត្រូវបានបើកជាមួយទង់ MDB_NOTLS. បន្ថែមពីលើនេះវាក៏ចាំបាច់ផងដែរ។ សម រុំ C++ lmdbxxដើម្បីកាត់ចេញអថេរដែលមានគុណលក្ខណៈនេះ និងនៅក្នុងវា។

មូលដ្ឋានទិន្នន័យ

មូលដ្ឋានទិន្នន័យគឺជាឧទាហរណ៍ B-tree ដាច់ដោយឡែកដែលយើងបានពិភាក្សាខាងលើ។ ការបើករបស់វាកើតឡើងនៅក្នុងប្រតិបត្តិការ ដែលវាហាក់ដូចជាចម្លែកបន្តិចនៅពេលដំបូង។

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. គាំទ្រលក្ខណៈសម្បត្តិមូលដ្ឋានទាំងអស់។ ទឹកអាស៊ីដ៖ អាតូមិច ភាពស៊ីសង្វាក់ ភាពឯកោ និងភាពជឿជាក់។ ខ្ញុំមិនអាចជួយបានទេប៉ុន្តែចំណាំថាមានកំហុសទាក់ទងនឹងភាពធន់នៅលើ macOS និង iOS ដែលត្រូវបានជួសជុលនៅក្នុង MDBX ។ អ្នកអាចអានបន្ថែមនៅក្នុងពួកគេ។ README.
2. វិធីសាស្រ្តនៃការអានច្រើនត្រូវបានពិពណ៌នាដោយគ្រោងការណ៍ "អ្នកសរសេរតែមួយ / អ្នកអានច្រើន" ។ អ្នកនិពន្ធរារាំងគ្នា ប៉ុន្តែកុំរារាំងអ្នកអាន។ អ្នកអានមិនរារាំងអ្នកនិពន្ធឬគ្នាទៅវិញទៅមកទេ។
3. ការគាំទ្រសម្រាប់ប្រតិបត្តិការដែលជាប់គាំង។
4. ការគាំទ្រពហុកំណែ។

Multiversion នៅក្នុង 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 ហើយមើលថាមានអ្វីកើតឡើង។

Multiversion នាំមកនូវអត្ថប្រយោជន៍ដ៏អស្ចារ្យដល់ជីវិតរបស់អ្នកអភិវឌ្ឍន៍ iOS ។ ដោយប្រើលក្ខណៈសម្បត្តិនេះ អ្នកអាចកែតម្រូវអត្រាអាប់ដេតនៃប្រភពទិន្នន័យបានយ៉ាងងាយស្រួល និងដោយធម្មជាតិ ដោយផ្អែកលើការពិចារណាលើបទពិសោធន៍របស់អ្នកប្រើប្រាស់។ ជាឧទាហរណ៍ ចូរយើងយកលក្ខណៈពិសេសមួយរបស់កម្មវិធី Mail.ru Cloud ដូចជាការផ្ទុកមាតិកាដោយស្វ័យប្រវត្តិពីវិចិត្រសាលប្រព័ន្ធផ្សព្វផ្សាយប្រព័ន្ធ។ ជាមួយនឹងការតភ្ជាប់ដ៏ល្អ អតិថិជនអាចបន្ថែមរូបថតជាច្រើនក្នុងមួយវិនាទីទៅកាន់ម៉ាស៊ីនមេ។ ប្រសិនបើអ្នកធ្វើបច្ចុប្បន្នភាពបន្ទាប់ពីការទាញយកនីមួយៗ UICollectionView ជាមួយនឹងមាតិកាមេឌៀនៅក្នុងពពករបស់អ្នកប្រើ អ្នកអាចភ្លេចអំពី 60 fps និងការរមូរដោយរលូនក្នុងអំឡុងពេលដំណើរការនេះ។ ដើម្បីទប់ស្កាត់ការអាប់ដេតអេក្រង់ញឹកញាប់ អ្នកត្រូវកំណត់អត្រានៃការផ្លាស់ប្តូរទិន្នន័យនៅក្នុងមូលដ្ឋាន UICollectionViewDataSource.

ប្រសិនបើមូលដ្ឋានទិន្នន័យមិនគាំទ្រការបំប្លែងច្រើន ហើយអនុញ្ញាតឱ្យអ្នកធ្វើការតែជាមួយស្ថានភាពបច្ចុប្បន្នប៉ុណ្ណោះ នោះដើម្បីបង្កើតរូបថតដែលមានស្ថេរភាពពេលវេលានៃទិន្នន័យ អ្នកត្រូវចម្លងវាទៅរចនាសម្ព័ន្ធទិន្នន័យក្នុងអង្គចងចាំមួយចំនួន ឬទៅតារាងបណ្តោះអាសន្ន។ វិធីសាស្រ្តណាមួយទាំងនេះមានតម្លៃថ្លៃណាស់។ នៅក្នុងករណីនៃការផ្ទុកក្នុងអង្គចងចាំ យើងទទួលបានការចំណាយទាំងនៅក្នុងអង្គចងចាំ ដែលបណ្តាលមកពីការរក្សាទុកវត្ថុដែលបានសាងសង់ និងទាន់ពេលវេលា ដែលទាក់ទងនឹងការបំប្លែង ORM ដែលលែងត្រូវការតទៅទៀត។ សម្រាប់តារាងបណ្តោះអាសន្ន នេះគឺជាការរីករាយដែលមានតម្លៃថ្លៃជាងនេះ ដែលធ្វើឱ្យយល់បានតែក្នុងករណីដែលមិនសំខាន់។

ដំណោះស្រាយពហុបំរែបំរួលរបស់ LMDB ដោះស្រាយបញ្ហានៃការរក្សាប្រភពទិន្នន័យដែលមានស្ថេរភាពនៅក្នុងវិធីដ៏ឆើតឆាយបំផុត។ វាគ្រប់គ្រាន់ហើយក្នុងការបើកប្រតិបត្តិការ និង voila - រហូតដល់យើងបញ្ចប់វា សំណុំទិន្នន័យត្រូវបានធានាថានឹងត្រូវបានជួសជុល។ តក្កវិជ្ជាសម្រាប់ល្បឿនអាប់ដេតរបស់វាឥឡូវនេះគឺស្ថិតនៅក្នុងដៃនៃស្រទាប់បទបង្ហាញទាំងស្រុង ដោយមិនមានធនធានសំខាន់ៗលើសលុបនោះទេ។

ទស្សន៍ទ្រនិច

ទស្សន៍ទ្រនិចផ្តល់យន្តការសម្រាប់ការធ្វើឡើងវិញតាមលំដាប់លើគូតម្លៃគន្លឹះតាមរយៈការឆ្លងកាត់មែកធាង B ។ បើគ្មានពួកវាទេ វានឹងមិនអាចទៅរួចទេក្នុងការធ្វើគំរូតារាងប្រកបដោយប្រសិទ្ធភាពនៅក្នុងមូលដ្ឋានទិន្នន័យ ដែលឥឡូវនេះយើងងាកទៅរក។

៤.២. គំរូតារាង

ទ្រព្យសម្បត្តិនៃការបញ្ជាទិញគន្លឹះអនុញ្ញាតឱ្យអ្នកបង្កើតអរូបីកម្រិតខ្ពស់ដូចជាតារាងនៅលើកំពូលនៃ abstractions មូលដ្ឋាន។ ចូរយើងពិចារណាដំណើរការនេះដោយប្រើឧទាហរណ៍នៃតារាងចម្បងរបស់ម៉ាស៊ីនភ្ញៀវពពក ដែលផ្ទុកព័ត៌មានអំពីឯកសារ និងថតរបស់អ្នកប្រើប្រាស់ទាំងអស់។

គ្រោងការណ៍តារាង

សេណារីយ៉ូទូទៅមួយ ដែលរចនាសម្ព័នតារាងជាមួយមែកធាងថតគួរតែត្រូវបានកែសម្រួលគឺការជ្រើសរើសធាតុទាំងអស់ដែលមាននៅក្នុងថតដែលបានផ្តល់ឱ្យ។ គំរូអង្គការទិន្នន័យដ៏ល្អសម្រាប់សំណួរប្រកបដោយប្រសិទ្ធភាពនៃប្រភេទនេះគឺ បញ្ជីជាប់គ្នា។. ដើម្បីអនុវត្តវានៅលើកំពូលនៃការផ្ទុកតម្លៃសោរ វាចាំបាច់ក្នុងការតម្រៀបសោនៃឯកសារ និងថតតាមរបៀបដែលពួកវាត្រូវបានដាក់ជាក្រុមដោយផ្អែកលើសមាជិកភាពរបស់ពួកគេនៅក្នុងថតមេ។ លើសពីនេះទៀត ដើម្បីបង្ហាញមាតិកានៃថតក្នុងទម្រង់ដែលធ្លាប់ស្គាល់ចំពោះអ្នកប្រើប្រាស់វីនដូ (ថតដំបូង បន្ទាប់មកឯកសារ ទាំងពីរត្រូវបានតម្រៀបតាមអក្ខរក្រម) ចាំបាច់ត្រូវបញ្ចូលវាលបន្ថែមដែលត្រូវគ្នានៅក្នុងសោ។

រូបភាពខាងក្រោមបង្ហាញពីរបៀប ដោយផ្អែកលើកិច្ចការនៅដៃ តំណាងនៃគ្រាប់ចុចក្នុងទម្រង់នៃអារេបៃអាចមើលទៅដូច។ បៃ​ដែល​មាន​អ្នក​កំណត់​អត្តសញ្ញាណ​នៃ​ថត​មេ (ក្រហម) ត្រូវ​បាន​ដាក់​ជា​មុន បន្ទាប់​មក​ជាមួយ​ប្រភេទ (បៃតង) និង​នៅ​កន្ទុយ​ជាមួយ​ឈ្មោះ (ខៀវ)។​ ដោយ​ត្រូវ​បាន​តម្រៀប​តាម​លំនាំដើម​អ្នក​ប្រៀបធៀប LMDB តាម​លំដាប់ lexicographical ពួក​វា​ត្រូវ​បាន​តម្រៀប​ក្នុង របៀបដែលត្រូវការ។ ការឆ្លងកាត់គ្រាប់ចុចជាបន្តបន្ទាប់ជាមួយនឹងបុព្វបទពណ៌ក្រហមដូចគ្នាផ្តល់ឱ្យយើងនូវតម្លៃដែលពាក់ព័ន្ធរបស់ពួកគេតាមលំដាប់ដែលពួកគេគួរតែត្រូវបានបង្ហាញនៅក្នុងចំណុចប្រទាក់អ្នកប្រើ (នៅខាងស្តាំ) ដោយមិនចាំបាច់ត្រូវការដំណើរការក្រោយបន្ថែម។

សៀរៀលគ្រាប់ចុច និងតម្លៃ

វិធីសាស្រ្តជាច្រើនសម្រាប់ការដាក់សៀរៀលវត្ថុត្រូវបានបង្កើតឡើងនៅលើពិភពលោក។ ដោយសារយើងមិនមានតម្រូវការផ្សេងទៀតក្រៅពីល្បឿន យើងបានជ្រើសរើសលឿនបំផុតដែលអាចធ្វើទៅបានសម្រាប់ខ្លួនយើង - កន្លែងចោលនៃអង្គចងចាំដែលកាន់កាប់ដោយឧទាហរណ៍នៃរចនាសម្ព័ន្ធភាសា 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
    };
}

នៅក្នុងជំពូកទី 1 ស្តីពីលក្ខណៈវិនិច្ឆ័យនៃការជ្រើសរើសមូលដ្ឋានទិន្នន័យ ខ្ញុំបានលើកឡើងអំពីការបង្រួមអប្បបរមានៃការបែងចែកថាមវន្តនៅក្នុងប្រតិបត្តិការ 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
    };
}

ជាលទ្ធផលនៃការ refactoring យើងទទួលបានការសន្សំដ៏សំខាន់នៅក្នុងចន្លោះដែលកាន់កាប់ដោយសោ។ ទោះ​ជា​យ៉ាង​ណា​ដោយ​សារ​តែ​វិស័យ​បច្ចេក​ទេស nameLengthឧបករណ៍ប្រៀបធៀបប្រព័ន្ធគោលពីរលំនាំដើមមិនសមរម្យសម្រាប់ការប្រៀបធៀបគន្លឹះទៀតទេ។ ប្រសិនបើយើងមិនជំនួសវាដោយខ្លួនយើងទេ នោះប្រវែងនៃឈ្មោះនឹងជាកត្តាអាទិភាពខ្ពស់ក្នុងការតម្រៀបជាងឈ្មោះខ្លួនឯង។

LMDB អនុញ្ញាតឱ្យមូលដ្ឋានទិន្នន័យនីមួយៗមានមុខងារប្រៀបធៀបគន្លឹះផ្ទាល់ខ្លួន។ នេះត្រូវបានធ្វើដោយប្រើមុខងារ mdb_set_compare យ៉ាងតឹងរឹងមុនពេលបើក។ សម្រាប់ហេតុផលជាក់ស្តែង វាមិនអាចផ្លាស់ប្តូរបានពេញមួយជីវិតនៃមូលដ្ឋានទិន្នន័យ។ អ្នកប្រៀបធៀបទទួលបានកូនសោពីរក្នុងទម្រង់ប្រព័ន្ធគោលពីរជាការបញ្ចូល ហើយនៅលទ្ធផលវាបង្ហាញលទ្ធផលប្រៀបធៀប៖ តិចជាង (-1) ធំជាង (1) ឬស្មើនឹង (0)។ Pseudocode សម្រាប់ 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 ធ្វើការយ៉ាងខ្លាំងជាមួយនឹងសោនៃកំណត់ត្រាដែលបានរក្សាទុក។ ការប្រៀបធៀបរបស់ពួកគេជាមួយគ្នាទៅវិញទៅមកកើតឡើងនៅក្នុងក្របខ័ណ្ឌនៃប្រតិបត្តិការដែលបានអនុវត្តណាមួយ ហើយដំណើរការនៃដំណោះស្រាយទាំងមូលអាស្រ័យលើល្បឿនរបស់អ្នកប្រៀបធៀប។ នៅក្នុងពិភពដ៏ល្អមួយ ឧបករណ៍ប្រៀបធៀបប្រព័ន្ធគោលពីរលំនាំដើមគួរតែគ្រប់គ្រាន់ដើម្បីប្រៀបធៀបសោ ប៉ុន្តែប្រសិនបើអ្នកត្រូវប្រើផ្ទាល់ខ្លួនរបស់អ្នក នោះនីតិវិធីសម្រាប់ deserializing keys នៅក្នុងវាគួរតែលឿនតាមដែលអាចធ្វើទៅបាន។

មូលដ្ឋានទិន្នន័យមិនចាប់អារម្មណ៍ជាពិសេសចំពោះផ្នែកតម្លៃនៃកំណត់ត្រា (តម្លៃ) ទេ។ ការបំប្លែងរបស់វាពីតំណាងបៃទៅវត្ថុកើតឡើងតែនៅពេលដែលវាត្រូវបានទាមទាររួចហើយដោយកូដកម្មវិធី ឧទាហរណ៍ ដើម្បីបង្ហាញវានៅលើអេក្រង់។ ដោយសារវាកើតឡើងកម្រណាស់ តម្រូវការល្បឿនសម្រាប់នីតិវិធីនេះគឺមិនសូវសំខាន់ទេ ហើយនៅក្នុងការអនុវត្តរបស់វា យើងមានសេរីភាពច្រើនក្នុងការផ្តោតលើភាពងាយស្រួល។ ឧទាហរណ៍ ដើម្បីភ្ជាប់ទិន្នន័យមេតាជាស៊េរីអំពីឯកសារដែលមិនទាន់បានទាញយក យើងប្រើ NSKeyedArchiver.

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

ទោះយ៉ាងណាក៏ដោយ មានពេលខ្លះដែលការអនុវត្តនៅតែសំខាន់។ ជាឧទាហរណ៍ នៅពេលរក្សាទុកឯកសារ metainformation អំពីរចនាសម្ព័ន្ធឯកសារនៃពពកអ្នកប្រើប្រាស់ យើងប្រើអង្គចងចាំដូចគ្នានៃវត្ថុ។ ការបន្លិចនៃភារកិច្ចនៃការបង្កើតតំណាងសៀរៀលនៃពួកវាគឺការពិតដែលថាធាតុនៃថតត្រូវបានយកគំរូតាមឋានានុក្រមនៃថ្នាក់។

ដើម្បីអនុវត្តវានៅក្នុងភាសា 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-tree ដែលវត្ថុមួយមានទីតាំងនៅ អរគុណចំពោះគោលការណ៍ចម្លងលើការសរសេរ នៅតែមិនផ្លាស់ប្តូរដរាបណាពួកវាត្រូវបានយោងដោយប្រតិបត្តិការយ៉ាងហោចណាស់មួយ។ ក្នុងពេលជាមួយគ្នានេះ ដរាបណាប្រតិបត្តិការចុងក្រោយដែលភ្ជាប់ជាមួយពួកគេបានបញ្ចប់ ទំព័រអាចត្រូវបានប្រើប្រាស់ឡើងវិញសម្រាប់ទិន្នន័យថ្មី។ ប្រសិនបើវាចាំបាច់សម្រាប់វត្ថុដើម្បីរស់រានមានជីវិតពីប្រតិបត្តិការដែលបានបង្កើត នោះពួកគេនៅតែត្រូវចម្លង។
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 បែបនេះដែលពួកគេត្រូវបានបញ្ជាដោយលេខសម្គាល់នៃថតមេ។ ដូច្នេះ តាមបច្ចេកទេស ភារកិច្ចនៃការទាញយកមាតិកានៃថតមួយចុះមកដើម្បីដាក់ទស្សន៍ទ្រនិចនៅលើព្រំដែនខាងលើនៃក្រុមកូនសោដែលមានបុព្វបទដែលបានផ្តល់ឱ្យ ហើយបន្ទាប់មកបន្តទៅព្រំដែនខាងក្រោម។

ព្រំដែនខាងលើអាចត្រូវបានរកឃើញដោយផ្ទាល់ដោយការស្វែងរកតាមលំដាប់លំដោយ។ ដើម្បីធ្វើដូច្នេះ ទស្សន៍ទ្រនិចត្រូវបានដាក់នៅដើមបញ្ជីកូនសោទាំងមូលនៅក្នុងមូលដ្ឋានទិន្នន័យ ហើយត្រូវបានបង្កើនបន្ថែមទៀតរហូតដល់កូនសោដែលមានលេខសម្គាល់នៃថតមេលេចឡើងនៅខាងក្រោមវា។ វិធីសាស្រ្តនេះមាន 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 យើង​មិន​ត្រឹម​តែ​ទទួល​បាន​គន្លឹះ​ប៉ុណ្ណោះ​ទេ ប៉ុន្តែ​ក៏​តម្លៃ​ផង​ដែរ។ ប្រសិនបើដើម្បីបំពេញលក្ខខណ្ឌនៃគំរូ អ្នកត្រូវពិនិត្យមើល ក្នុងចំណោមរបស់ផ្សេងទៀត វាលពីផ្នែកតម្លៃនៃកំណត់ត្រា នោះពួកវាអាចចូលដំណើរការបានដោយមិនមានកាយវិការបន្ថែម។

៤.៣. គំរូទំនាក់ទំនងរវាងតារាង

មកដល់ពេលនេះ យើងបានគ្រប់គ្រងដើម្បីពិចារណាគ្រប់ទិដ្ឋភាពទាំងអស់នៃការរចនា និងធ្វើការជាមួយមូលដ្ឋានទិន្នន័យតារាងតែមួយ។ យើង​អាច​និយាយ​បាន​ថា តារាង​មួយ​គឺ​ជា​សំណុំ​នៃ​កំណត់ត្រា​ដែល​បាន​តម្រៀប​ដែល​មាន​ប្រភេទ​ដូចគ្នា​នៃ​គូ​តម្លៃ​គន្លឹះ។ ប្រសិនបើអ្នកបង្ហាញកូនសោជាចតុកោណកែង និងតម្លៃដែលពាក់ព័ន្ធជា parallelepiped អ្នកទទួលបានដ្យាក្រាមដែលមើលឃើញនៃមូលដ្ឋានទិន្នន័យ។

'' '"

ទោះជាយ៉ាងណាក៏ដោយ នៅក្នុងជីវិតពិត វាកម្រនឹងអាចទទួលបានដោយការបង្ហូរឈាមតិចតួចណាស់។ ជាញឹកញាប់នៅក្នុងមូលដ្ឋានទិន្នន័យ វាត្រូវបានទាមទារ ទីមួយមានតារាងជាច្រើន ហើយទីពីរ ដើម្បីធ្វើការជ្រើសរើសនៅក្នុងពួកវាតាមលំដាប់ខុសពីគន្លឹះចម្បង។ ផ្នែកចុងក្រោយនេះត្រូវបានឧទ្ទិសដល់បញ្ហានៃការបង្កើត និងការភ្ជាប់គ្នាទៅវិញទៅមក។

តារាងសន្ទស្សន៍

កម្មវិធីពពកមានផ្នែក "វិចិត្រសាល" ។ វាបង្ហាញមាតិកាមេឌៀពីពពកទាំងមូល តម្រៀបតាមកាលបរិច្ឆេទ។ ដើម្បី​អនុវត្ត​ជម្រើស​បែប​នេះ​ឱ្យ​បាន​ល្អ​ប្រសើរ ​នៅ​ជាប់​តារាង​មេ អ្នក​ត្រូវ​បង្កើត​មួយ​ទៀត​ជាមួយ​នឹង​ប្រភេទ​សោថ្មី។ ពួកវានឹងមានវាលមួយដែលមានកាលបរិច្ឆេទដែលឯកសារត្រូវបានបង្កើត ដែលនឹងដើរតួជាលក្ខណៈវិនិច្ឆ័យតម្រៀបចម្បង។ ដោយសារគ្រាប់ចុចថ្មីយោងទិន្នន័យដូចគ្នានឹងគ្រាប់ចុចនៅក្នុងតារាងមេ ពួកវាត្រូវបានគេហៅថា index keys ។ នៅក្នុងរូបភាពខាងក្រោមពួកគេត្រូវបានបន្លិចជាពណ៌ទឹកក្រូច។

ដើម្បីបំបែកសោនៃតារាងផ្សេងគ្នាពីគ្នាទៅវិញទៅមកនៅក្នុងមូលដ្ឋានទិន្នន័យតែមួយ តារាងទីវាលបច្ចេកទេសបន្ថែមមួយត្រូវបានបន្ថែមទៅពួកវាទាំងអស់។ ដោយធ្វើឱ្យវាជាអាទិភាពខ្ពស់បំផុតសម្រាប់ការតម្រៀប យើងនឹងសម្រេចបាននូវការដាក់ជាក្រុមនៃកូនសោជាមុនដោយតារាង និងក្នុងតារាង - យោងទៅតាមច្បាប់របស់យើងផ្ទាល់។

គន្លឹះលិបិក្រមយោងទិន្នន័យដូចគ្នាទៅនឹងគន្លឹះចម្បង។ ការអនុវត្តដោយត្រង់នៃអចលនទ្រព្យនេះតាមរយៈការភ្ជាប់ជាមួយវានូវច្បាប់ចម្លងនៃផ្នែកតម្លៃនៃសោចម្បងគឺមិនល្អបំផុតតាមទស្សនៈជាច្រើន៖

1. បើនិយាយពីទំហំផ្ទុកទិន្នន័យមេតាអាចសម្បូរបែប។
2. តាមទស្សនៈនៃការអនុវត្ត ចាប់តាំងពីពេលធ្វើបច្ចុប្បន្នភាពទិន្នន័យមេតានៃថ្នាំង អ្នកនឹងត្រូវសរសេរវាឡើងវិញដោយប្រើគ្រាប់ចុចពីរ។
3. តាមទស្សនៈនៃការគាំទ្រកូដ ប្រសិនបើយើងភ្លេចធ្វើបច្ចុប្បន្នភាពទិន្នន័យសម្រាប់សោណាមួយនោះ យើងនឹងទទួលបានកំហុសដ៏កម្រនៃភាពមិនស៊ីសង្វាក់គ្នានៃទិន្នន័យនៅក្នុងកន្លែងផ្ទុក។

បន្ទាប់យើងនឹងពិចារណាពីរបៀបលុបបំបាត់ចំណុចខ្វះខាតទាំងនេះ។

ការរៀបចំទំនាក់ទំនងរវាងតារាង

លំនាំគឺសមល្អសម្រាប់ការភ្ជាប់តារាងលិបិក្រមជាមួយតារាងមេ "គន្លឹះជាតម្លៃ". ដូចដែលឈ្មោះរបស់វាបានបង្ហាញ ផ្នែកតម្លៃនៃកំណត់ត្រាលិបិក្រមគឺជាច្បាប់ចម្លងនៃតម្លៃសោចម្បង។ វិធីសាស្រ្តនេះលុបបំបាត់គុណវិបត្តិទាំងអស់ដែលបានរៀបរាប់ខាងលើដែលទាក់ទងនឹងការរក្សាទុកច្បាប់ចម្លងនៃផ្នែកតម្លៃនៃកំណត់ត្រាបឋម។ ការចំណាយតែមួយគត់គឺថាដើម្បីទទួលបានតម្លៃដោយ index key អ្នកត្រូវធ្វើ 2 queries ទៅកាន់ database ជំនួសឱ្យមួយ។ តាមគ្រោងការណ៍ គ្រោងការណ៍មូលដ្ឋានទិន្នន័យលទ្ធផលមើលទៅដូចនេះ។

គំរូមួយផ្សេងទៀតសម្រាប់ការរៀបចំទំនាក់ទំនងរវាងតារាងគឺ "សោ​មិន​ប្រើ​ប្រាស់". ខ្លឹមសាររបស់វាគឺការបន្ថែមគុណលក្ខណៈបន្ថែមទៅលើសោ ដែលមិនចាំបាច់សម្រាប់ការតម្រៀបទេ ប៉ុន្តែសម្រាប់ការបង្កើតសោដែលពាក់ព័ន្ធឡើងវិញ។ នៅក្នុងកម្មវិធី Mail.ru Cloud មានឧទាហរណ៍ជាក់ស្តែងនៃការប្រើប្រាស់របស់វា ដើម្បីជៀសវាងការជ្រៀតចូលទៅក្នុងជ្រៅ។ បរិបទនៃក្របខ័ណ្ឌ iOS ជាក់លាក់ ខ្ញុំនឹងផ្តល់ការប្រឌិតមួយ ប៉ុន្តែជាឧទាហរណ៍ច្បាស់ជាង។

Cloud mobile clients មានទំព័រដែលបង្ហាញឯកសារ និងថតទាំងអស់ដែលអ្នកប្រើប្រាស់បានចែករំលែកជាមួយមនុស្សផ្សេងទៀត។ ដោយសារមានឯកសារបែបនេះតិចតួច ហើយមានព័ត៌មានជាក់លាក់ជាច្រើនប្រភេទផ្សេងៗគ្នាអំពីការផ្សព្វផ្សាយដែលទាក់ទងនឹងពួកគេ (អ្នកដែលត្រូវបានផ្តល់សិទ្ធិចូលប្រើប្រាស់ ដោយមានសិទ្ធិអ្វី។ល។) វានឹងមិនសមហេតុផលក្នុងបន្ទុកផ្នែកតម្លៃនៃ កត់ត្រានៅក្នុងតារាងចម្បងជាមួយវា។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើអ្នកចង់បង្ហាញឯកសារបែបនេះក្រៅបណ្តាញ អ្នកនៅតែត្រូវរក្សាទុកវានៅកន្លែងណាមួយ។ ដំណោះស្រាយធម្មជាតិគឺបង្កើតតារាងដាច់ដោយឡែកសម្រាប់វា។ នៅក្នុងដ្យាក្រាមខាងក្រោម កូនសោរបស់វាត្រូវបានបញ្ចូលដោយអក្សរ "P" ហើយកន្លែងដាក់ "propname" អាចត្រូវបានជំនួសដោយតម្លៃជាក់លាក់ជាង "ព័ត៌មានសាធារណៈ"។​

រាល់ទិន្នន័យមេតាតែមួយគត់ សម្រាប់ជាប្រយោជន៍នៃការរក្សាទុកដែលតារាងថ្មីត្រូវបានបង្កើតឡើង ត្រូវបានដាក់ក្នុងផ្នែកតម្លៃនៃកំណត់ត្រា។ ក្នុងពេលជាមួយគ្នានេះ អ្នកមិនចង់ចម្លងទិន្នន័យអំពីឯកសារ និងថតឯកសារដែលត្រូវបានរក្សាទុកក្នុងតារាងមេរួចហើយនោះទេ។ ជំនួសមកវិញ ទិន្នន័យដែលលែងត្រូវការតទៅទៀតត្រូវបានបន្ថែមទៅគ្រាប់ចុច “P” ក្នុងទម្រង់នៃវាល “លេខសម្គាល់ថ្នាំង” និង “ត្រាពេលវេលា”។ សូមអរគុណដល់ពួកគេ អ្នកអាចបង្កើតកូនសោលិបិក្រមមួយ ដែលអ្នកអាចទទួលបានកូនសោចម្បង ដែលទីបំផុតអ្នកអាចទទួលបានទិន្នន័យមេតារបស់ថ្នាំង។

សេចក្តីសន្និដ្ឋាន

យើងវាយតម្លៃលទ្ធផលនៃការអនុវត្ត LMDB ជាវិជ្ជមាន។ បន្ទាប់ពីវា ចំនួននៃការបង្កកកម្មវិធីបានថយចុះ 30%។

លទ្ធផល​នៃ​ការងារ​ដែល​បាន​ធ្វើ​បាន​រំលេច​ឡើង​លើស​ពី​ក្រុម iOS។ បច្ចុប្បន្ននេះ ផ្នែក "ឯកសារ" សំខាន់មួយនៅក្នុងកម្មវិធី Android ក៏បានប្តូរទៅប្រើ LMDB ហើយផ្នែកផ្សេងទៀតកំពុងដំណើរការ។ ភាសា C ដែល​រក្សាទុក​តម្លៃ​ត្រូវ​បាន​អនុវត្ត គឺជា​ជំនួយ​ដ៏​ល្អ​ក្នុង​ការ​បង្កើត​ក្របខណ្ឌ​កម្មវិធី​ដំបូង​ជុំវិញ​វា​ឆ្លងវេទិកា​ក្នុង C++។ ម៉ាស៊ីនបង្កើតកូដត្រូវបានប្រើដើម្បីភ្ជាប់បណ្ណាល័យ C++ លទ្ធផលយ៉ាងរលូនជាមួយនឹងកូដវេទិកានៅក្នុង Objective-C និង Kotlin ឌីជីនី ពី Dropbox ប៉ុន្តែនោះជារឿងខុសគ្នាទាំងស្រុង។

ប្រភព: www.habr.com