2019 ခုနှစ် ဆောင်းဦးတွင်၊ Mail.ru Cloud iOS အဖွဲ့တွင် ကြာရှည်စွာ စောင့်မျှော်ခဲ့သော ဖြစ်ရပ်တစ်ခု ဖြစ်ပွားခဲ့သည်။ အပလီကေးရှင်းအခြေအနေ၏ မြဲမြံစွာသိုလှောင်မှုအတွက် အဓိကဒေတာဘေ့စ်သည် မိုဘိုင်းလောကအတွက် အလွန်ထူးခြားဆန်းပြားလာသည်။ Lightning Memory-Mapped Database (LMDB)။ ဖြတ်တောက်မှုအောက်တွင်၊ အပိုင်းလေးပိုင်းဖြင့် အသေးစိတ်ပြန်လည်သုံးသပ်ရန် သင့်အာရုံစိုက်မှုကို ဖိတ်ခေါ်ပါသည်။ ဦးစွာ၊ ဤကဲ့သို့သောအသေးအဖွဲမဟုတ်သောနှင့် ခက်ခဲသောရွေးချယ်မှုအတွက် အကြောင်းရင်းများကို ဆွေးနွေးကြပါစို့။ ထို့နောက် LMDB ဗိသုကာ၏ အလယ်ဗဟိုတွင်ရှိသော ဝေလငါးသုံးကောင်၏ ထည့်သွင်းစဉ်းစားခြင်းသို့ ဆက်သွားကြပါစို့- memory-mapped files, B+ tree, copy-on-write approach, transactional and multiversioning ကို အကောင်အထည်ဖော်ရန်။ နောက်ဆုံးအနေနဲ့၊ အချိုပွဲအတွက် - လက်တွေ့ကျတဲ့အပိုင်း။ ၎င်းတွင်၊ အဆင့်နိမ့်သော့တန်ဖိုး API ၏ထိပ်ရှိ အညွှန်းတစ်ခုအပါအဝင် ဇယားများစွာပါရှိသော အခြေခံ schema ကို ဒီဇိုင်းရေးဆွဲပုံနှင့် အကောင်အထည်ဖော်ပုံကို ကြည့်ရှုပါမည်။

အကြောင်းအရာ

1. အကောင်အထည်ဖော်မှု Motivation
2. LMDB နေရာချထားခြင်း။
3. ဝေလငါး LMDB သုံးကောင်
   3.1 ။ ဝေလငါး #၁။ Memory-mapping ဖိုင်များ
   3.2 ။ ဝေလငါး #၂။ B+-သစ်ပင်
   3.3 ။ ဝေလငါး #၃။ copy-on-write
4. သော့တန်ဖိုး API ၏ထိပ်တွင် ဒေတာအစီအစဉ်တစ်ခုကို ဒီဇိုင်းဆွဲခြင်း။
   4.1 ။ အခြေခံ abstractions
   4.2 ။ Table Modeling
   4.3 ။ ဇယားများအကြား ဆက်ဆံရေးကို ပုံဖော်ခြင်း။

1. အကောင်အထည်ဖော်မှု စေ့ဆော်မှု

တစ်နှစ်လျှင်တစ်ကြိမ်၊ 2015 ခုနှစ်တွင် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏အပလီကေးရှင်း၏အင်တာဖေ့စ်သည် မည်မျှကြာကြာ နှေးကွေးနေမည်ကို ဂရုပြုခဲ့ပါသည်။ ဒါကိုပဲ ငါတို့လုပ်ခဲ့တာမဟုတ်ဘူး။ တစ်ခါတစ်ရံတွင် အပလီကေးရှင်းသည် အသုံးပြုသူ၏လုပ်ဆောင်ချက်များကို တုံ့ပြန်မှုရပ်တန့်သွားသည်- ခလုတ်များကိုမနှိပ်ရ၊ စာရင်းများမရွှေ့ခြင်းစသည်တို့နှင့် ပတ်သက်၍ ကျွန်ုပ်တို့တွင် တိုင်ကြားမှုများ ပိုများလာပါသည်။ တိုင်းတာမှုစက်ပြင်များအကြောင်း ပြောတယ်။ AvitoTech တွင်၊ ထို့ကြောင့် ဤနေရာတွင် ကျွန်ုပ်သည် နံပါတ်များကိုသာ ပေးပါသည်။

တိုင်းတာမှုရလဒ်များသည် ကျွန်ုပ်တို့အတွက် အေးမြသောရေချိုးမှုဖြစ်လာခဲ့သည်။ အေးခဲခြင်းကြောင့် ဖြစ်ပေါ်လာသော ပြဿနာများသည် အခြားမည်သည့်အရာများထက်မဆို ပိုမိုများပြားကြောင်း တွေ့ရှိရပါသည်။ အကယ်၍ ဤအချက်ကို သဘောမပေါက်မီ၊ အရည်အသွေး၏ ပင်မနည်းပညာဆိုင်ရာ ညွှန်ပြချက်သည် ပျက်စီးမှု ကင်းမည်ဆိုပါက၊ ထို့နောက် အာရုံစိုက်ပြီးနောက် ပြောင်းကာ freeze free ပေါ်မှာ။

ဆောက်ပြီးမှ အေးခဲနေသော ဒက်ရှ်ဘုတ် ပြီးလျှင်၊ အရေအတွက် и အရည်အသွေး ၎င်းတို့၏အကြောင်းရင်းများကိုခွဲခြမ်းစိတ်ဖြာခြင်း, အဓိကရန်သူရှင်းလင်းလာသည် - အပလီကေးရှင်း၏ပင်မချည်တွင်လုပ်ဆောင်နေသောအကြီးစားစီးပွားရေးယုတ္တိဗေဒ။ ဤအရှက်ကွဲမှုကို သဘာဝအလျောက် တုံ့ပြန်မှုမှာ ၎င်းအား အလုပ်လမ်းကြောင်းထဲသို့ တွန်းပို့လိုသော ဆန္ဒဖြစ်သည်။ ဤပြဿနာ၏စနစ်တကျဖြေရှင်းချက်အတွက်၊ ကျွန်ုပ်တို့သည် ပေါ့ပါးသောသရုပ်ဆောင်များကိုအခြေခံ၍ ကြိုးမျိုးစုံတည်ဆောက်မှုပုံစံကို အသုံးပြုခဲ့သည်။ iOS လောကအတွက် သူမကို လိုက်လျောညီထွေဖြစ်အောင် လုပ်ဆောင်ပေးခဲ့တယ်။ ကြိုးနှစ်ချောင်း စုပေါင်း twitter နှင့် Habre ၏ဆောင်းပါး. လက်ရှိဇာတ်လမ်း၏တစ်စိတ်တစ်ပိုင်းအနေဖြင့်၊ ဒေတာဘေ့စ်ရွေးချယ်မှုအပေါ် လွှမ်းမိုးခဲ့သော ဆုံးဖြတ်ချက်၏ ရှုထောင့်များကို အလေးပေးဖော်ပြလိုပါသည်။

စနစ်အဖွဲ့အစည်း၏ ဇာတ်ဆောင်ပုံစံက Multithreading သည် ၎င်း၏ဒုတိယအနှစ်သာရဖြစ်လာသည်ဟု ယူဆသည်။ ၎င်းတွင်ရှိသော အရာဝတ္ထုများသည် ချည်စည်းမျဉ်းများကို ဖြတ်ကျော်ရသလိုမျိုး၊ ပြီးတော့ သူတို့က ဒါကို တစ်ခါတလေနဲ့ တချို့နေရာတွေမှာ မလုပ်တတ်ပေမယ့် အမြဲလိုလို နေရာတိုင်းလိုလို လုပ်တယ်။

ဒေတာဘေ့စ်သည် တင်ပြထားသော ပုံကြမ်းတွင် အုတ်မြစ်ချသော အစိတ်အပိုင်းများထဲမှ တစ်ခုဖြစ်သည်။ ၎င်း၏ အဓိကတာဝန်မှာ မက်ခရိုပုံစံတစ်ခုကို အကောင်အထည်ဖော်ရန်ဖြစ်သည်။ မျှဝေထားသောဒေတာဘေ့စ်. အကယ်၍ လုပ်ငန်းလောကတွင် ဝန်ဆောင်မှုများအကြား ဒေတာထပ်တူပြုခြင်းကို စုစည်းရန် အသုံးပြုပါက၊ သရုပ်ဆောင်ဗိသုကာတစ်ခု၏ အခြေအနေတွင်၊ threads များအကြား ဒေတာကို အသုံးပြုသည်။ ထို့ကြောင့်၊ အနည်းငယ်မျှသောအခက်အခဲများကိုပင်မဖြစ်စေဘဲ Multi-threaded ပတ်ဝန်းကျင်တွင်အလုပ်လုပ်သောထိုကဲ့သို့သောဒေတာဘေ့စ်ကိုကျွန်ုပ်တို့လိုအပ်သည်။ အထူးသဖြင့်၊ ၎င်းမှရရှိသော အရာဝတ္ထုများသည် အနည်းဆုံး ချည်မျှင်ဘေးကင်းရမည်ဖြစ်ပြီး၊ အကောင်းဆုံးအားဖြင့် လုံးဝမပြောင်းလဲနိုင်ဟု ဆိုလိုသည်။ သင်သိသည့်အတိုင်း၊ နောက်ပိုင်းတွင် စွမ်းဆောင်ရည်အပေါ် အကျိုးရှိသောအကျိုးသက်ရောက်မှုရှိသော မည်သည့်သော့အမျိုးအစားကိုမျှ မသုံးဘဲ ချည်မျှင်များစွာမှ တစ်ပြိုင်နက်အသုံးပြုနိုင်ပါသည်။

ဒေတာဘေ့စ်ရွေးချယ်မှုကို လွှမ်းမိုးသည့် ဒုတိယအရေးကြီးသောအချက်မှာ ကျွန်ုပ်တို့၏ cloud API ဖြစ်သည်။ တစ်ပြိုင်တည်းလုပ်ဆောင်ခြင်းအတွက် git ချဉ်းကပ်မှုမှ လှုံ့ဆော်မှုခံခဲ့ရသည်။ သူ့လိုပဲ ကျွန်တော်တို့ ရည်ရွယ်ပါတယ်။ အော့ဖ်လိုင်း ပထမ APIcloud သုံးစွဲသူများအတွက် သင့်လျော်သည်ထက် ပိုပုံပေါ်သည်။ ၎င်းတို့သည် cloud ၏အခြေအနေအပြည့်အစုံကို တစ်ကြိမ်သာထုတ်ပစ်မည်ဟု ယူဆရပြီး ဖြစ်ရပ်အများစုတွင် တစ်ပြိုင်တည်းလုပ်ဆောင်ခြင်းသည် လှိမ့်ပြောင်းမှုများမှတစ်ဆင့် ဖြစ်ပေါ်မည်ဖြစ်သည်။ ဖြစ်ချင်တော့၊ ဒီဖြစ်နိုင်ခြေဟာ သီအိုရီဇုန်ထဲမှာပဲရှိပါသေးတယ်၊ လက်တွေ့မှာတော့ clients တွေက patch နဲ့ ဘယ်လိုအလုပ်လုပ်ရမလဲဆိုတာ မလေ့လာခဲ့ကြပါဘူး။ ဤအတွက် ရည်ရွယ်ချက်များစွာရှိပါသည်၊ နိဒါန်းကိုနှောင့်နှေးစေရန်အတွက်၊ ကျွန်ုပ်တို့သည် ကွင်းပိတ်များမှ ထွက်ခွာပါမည်။ ယခု ပို၍စိတ်ဝင်စားစရာကောင်းသည်မှာ API က "A" နှင့်၎င်း၏စားသုံးသူမှ "B" ဟုမပြောသောအခါဘာဖြစ်လာသည်နှင့် ပတ်သက်၍ သင်ခန်းစာ၏သင်ယူစရာရလဒ်များဖြစ်သည်။

ထို့ကြောင့် git သည် pull command ကိုလုပ်ဆောင်သောအခါတွင်၊ local snapshot တစ်ခုတွင် patches များကိုအသုံးပြုမည့်အစား၊ ၎င်း၏ full state ကို server တစ်ခုနှင့် full state နှိုင်းယှဉ်မည်ဆိုလျှင်၊ synchronization ကိုမည်သို့မျှမျှတစွာတိကျမှန်ကန်သောစိတ်ကူးတစ်ခုရရှိလိမ့်မည်၊ cloud clients များတွင် ဖြစ်ပေါ်သည်။ ၎င်း၏ အကောင်အထည်ဖော်မှုအတွက် ၎င်းသည် ဆာဗာနှင့် ဒေသတွင်းဖိုင်များအားလုံးကို meta-information ဖြင့် Memory အတွင်း DOM သစ်ပင်နှစ်ပင်ခွဲဝေရန် လိုအပ်ကြောင်း ခန့်မှန်းရလွယ်ကူသည်။ အကယ်၍ အသုံးပြုသူတစ်ဦးသည် cloud တွင် ဖိုင်ပေါင်း 500 သိမ်းဆည်းထားပါက ၎င်းကို synchronize ပြုလုပ်ရန် node 1 သန်းဖြင့် သစ်ပင်နှစ်ခုကို ပြန်လည်ဖန်တီးကာ ဖျက်ဆီးရန် လိုအပ်ပါသည်။ သို့သော် node တစ်ခုစီသည် အရာဝတ္တုများ၏ ဂရပ်များပါရှိသော အစုလိုက်တစ်ခုဖြစ်သည်။ ဤအချက်တွင်၊ ပရိုဖိုင်းရလဒ်များကို မျှော်လင့်ထားသည်။ ပေါင်းစည်းခြင်း အယ်လဂိုရီသမ်ကို ထည့်သွင်းစဉ်းစားခြင်းမပြုဘဲ သေးငယ်သော အရာဝတ္ထု အများအပြားကို ဖျက်ဆီးခြင်း လုပ်ငန်းစဉ်သည် တစ်ပြားတစ်ချပ်မျှ ကုန်ကျသည်။ အခြေခံ ထပ်တူပြုခြင်း လုပ်ဆောင်ချက်ကို အများအပြားတွင် ထည့်သွင်းထားခြင်းကြောင့် အခြေအနေမှာ ပိုမိုဆိုးရွားလာပါသည်။ အသုံးပြုသူ scripts များ။ ရလဒ်အနေဖြင့်၊ ဒေတာဘေ့စ်တစ်ခုရွေးချယ်ရာတွင် ဒုတိယအရေးကြီးသောစံသတ်မှတ်ချက်ဖြစ်သည့် အရာဝတ္ထုများကို ရွေ့လျားခွဲဝေခြင်းမပြုဘဲ CRUD လုပ်ဆောင်ချက်များကို အကောင်အထည်ဖော်နိုင်မှုဖြစ်သည်။

အခြားလိုအပ်ချက်များသည် ရိုးရာနည်းများဖြစ်ပြီး ၎င်းတို့၏စာရင်းအပြည့်အစုံမှာ အောက်ပါအတိုင်းဖြစ်သည်။

1. ချည်တွယ်။
2. အမျိုးမျိုးလုပ်ဆောင်ခြင်း။ threads များကြားသာမက ပင်မအပလီကေးရှင်းနှင့် iOS extension များကြားတွင်လည်း တူညီသောဒေတာဘေ့စ်ဥပမာကို အသုံးပြုလိုသောဆန္ဒဖြင့် ညွှန်ကြားထားသည်။
3. မပြောင်းလဲနိုင်သော အရာများအဖြစ် သိမ်းဆည်းထားသော အရာများကို ကိုယ်စားပြုနိုင်စွမ်း
4. CRUD လုပ်ငန်းများအတွင်း ဒိုင်းနမစ်ခွဲဝေမှု မရှိခြင်း။
5. အခြေခံပိုင်ဆိုင်မှုများအတွက် ငွေပေးငွေယူပံ့ပိုးမှု အက်ဆစ်အဓိကစကားလုံးများ- အနုမြူစွမ်းအား၊ ညီညွတ်မှု၊ အထီးကျန်မှုနှင့် ယုံကြည်စိတ်ချရမှု။
6. အရှိန်အဟုန်တွင် ရေပန်းအစားဆုံးကိစ္စများ။

ဤလိုအပ်ချက်များနှင့်အတူ SQLite သည် ကောင်းမွန်သောရွေးချယ်မှုတစ်ခုအဖြစ် ရှိနေသေးသည်။ သို့သော် အခြားရွေးချယ်စရာများကို လေ့လာခြင်း၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့် ကျွန်တော်သည် စာအုပ်တစ်အုပ်ကို တွေ့ရှိခဲ့သည်။ "LevelDB ဖြင့်စတင်ခြင်း". သူမ၏ခေါင်းဆောင်မှုအောက်တွင်၊ တကယ့် cloud အခြေအနေများတွင် မတူညီသောဒေတာဘေ့စ်များနှင့် အလုပ်၏အမြန်နှုန်းကို နှိုင်းယှဉ်သည့်စံညွှန်းတစ်ခုကို ရေးသားထားသည်။ ရလဒ်သည် အပြင်းထန်ဆုံးမျှော်လင့်ချက်များကို ကျော်လွန်သွားခဲ့သည်။ ရေပန်းအစားဆုံး ကိစ္စများတွင် - ဖိုင်အားလုံး၏ စီထားသောစာရင်းတွင် ကာဆာတစ်ခုရယူခြင်းနှင့် ပေးထားသောလမ်းညွှန်တစ်ခုအတွက် ဖိုင်အားလုံး၏စာရင်းကို စီထားခြင်း - LMDB သည် SQLite ထက် 10 ဆပိုမိုမြန်ဆန်လာသည်။ ရွေးချယ်မှုမှာ သိသာထင်ရှားလာသည်။

2. LMDB နေရာချထားခြင်း။

LMDB သည် ဒေတာဘေ့စ်များ၏ အခြေခံအကျဆုံး အလွှာ - သိုလှောင်မှုကို အကောင်အထည်ဖော်သည့် အလွန်သေးငယ်သော (၁၀K လိုင်းများ) စာကြည့်တိုက်တစ်ခုဖြစ်သည်။

အထက်ဖော်ပြပါ ပုံကြမ်းတွင် LMDB နှင့် ပို၍ပင်အဆင့်မြင့်သော အဆင့်များကို အကောင်အထည်ဖော်ပေးသည့် SQLite နှင့် နှိုင်းယှဉ်ခြင်းသည် ယေဘုယျအားဖြင့် Core Data နှင့် SQLite ထက် ပိုမှန်မည်မဟုတ်ကြောင်း ပြသသည်။ BerkeleyDB၊ LevelDB၊ Sophia၊ RocksDB စသည်ဖြင့် တူညီသော သိုလှောင်မှုအင်ဂျင်များကို တူညီသော ပြိုင်ဘက်များအဖြစ် ကိုးကားခြင်းသည် ပို၍တရားမျှတပေလိမ့်မည်။ LMDB သည် SQLite အတွက် သိုလှောင်မှုအင်ဂျင် အစိတ်အပိုင်းတစ်ခုအဖြစ် လုပ်ဆောင်သည့် ဖွံ့ဖြိုးတိုးတက်မှုများပင် ရှိပါသည်။ 2012 ခုနှစ်မှာ ပထမဆုံး စမ်းသပ်မှုပါ။ သုံးစွဲခဲ့သည်။ ရေးသားသူ LMDB Howard Chu ၊. ရလဒ်များကို OSS ဝါသနာအိုးများက ကောက်ယူပြီး ၎င်း၏ရှေ့မှောက်တွင် ၎င်း၏လုပ်ဆောင်မှုကို အံ့သြဖွယ်ကောင်းလောက်အောင် အံ့သြဖွယ်ကောင်းလောက်အောင် ဖြစ်လာခဲ့သည်။ LumoSQL. 2020 ခုနှစ် ဇန်နဝါရီလတွင် ဤပရောဂျက်ကို ရေးသားသူမှာ Den Shearer ဖြစ်သည်။ တင်ပြသည်။ ၎င်းသည် LinuxConfAu တွင်ဖြစ်သည်။

LMDB ၏အဓိကအသုံးပြုမှုသည် application databases အတွက်အင်ဂျင်တစ်ခုဖြစ်သည်။ စာကြည့်တိုက်သည် ဆော့ဖ်ဝဲရေးသားသူများအတွက် ၎င်း၏ပုံပန်းသဏ္ဍာန်ကို ပေးဆောင်ပါသည်။ OpenLDAP၎င်းတို့၏ ပရောဂျက်၏ အခြေခံအဖြစ် BerkeleyDB အား ပြင်းပြင်းထန်ထန် မကျေနပ်ခဲ့ကြပါ။ နှိမ့်ချသော စာကြည့်တိုက်မှ တွန်းထုတ်လိုက်သည်။ breeHoward Chu သည် ကျွန်ုပ်တို့ခေတ်၏ ရေပန်းအစားဆုံး အခြားရွေးချယ်စရာများထဲမှ တစ်ခုကို ဖန်တီးနိုင်ခဲ့သည်။ သူသည် ဤဇာတ်လမ်းအတွက် အလွန်ကောင်းမွန်သော အစီရင်ခံစာအပြင် LMDB ၏ အတွင်းပိုင်း ဖွဲ့စည်းပုံကိုလည်း မြှုပ်နှံထားသည်။ "The Lightning Memory-mapped Database". Leonid Yuriev (aka yeo) Highload 2015 တွင် သူ၏ဟောပြောချက်တွင် Positive Technologies မှ "LMDB အင်ဂျင်သည် အထူးချန်ပီယံဖြစ်သည်". ၎င်းတွင် ReOpenLDAP ကို ​​အကောင်အထည် ဖော်ရန် အလားတူတာဝန်တစ်ရပ်တွင် LMDB အကြောင်း ဆွေးနွေးခဲ့ပြီး LevelDB သည် နှိုင်းယှဉ်ဝေဖန်မှုများကို ခံခဲ့ရပြီးဖြစ်သည်။ အကောင်အထည်ဖော်မှု၏ရလဒ်အနေဖြင့် Positive Technologies သည် တက်တက်ကြွကြွ ဖွံ့ဖြိုးတိုးတက်နေသော လမ်းခွဲတစ်ခုကိုပင် ရရှိခဲ့ပါသည်။ MDBX အလွန်အရသာရှိသောအင်္ဂါရပ်များ၊ ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်မှုများနှင့် အမှားပြင်ဆင်ချက်များ.

LMDB ကို သိုလှောင်မှုအဖြစ်လည်း မကြာခဏအသုံးပြုသည်။ ဥပမာအားဖြင့်၊ Mozilla Firefox ဘရောက်ဆာ ရွေးချယ်ခဲ့သည်။ လိုအပ်ချက်များစွာအတွက် ၎င်းသည် ဗားရှင်း 9 မှစတင်၍ Xcode ဖြစ်သည်။ နှစ်သက်သည်။ အညွှန်းများကိုသိမ်းဆည်းရန် ၎င်း၏ SQLite။

အင်ဂျင်သည် မိုဘိုင်းဖွံ့ဖြိုးတိုးတက်ရေးလောကတွင် ဖမ်းစားနိုင်ခဲ့သည်။ ၎င်း၏အသုံးပြုမှုခြေရာများဖြစ်နိုင်သည်။ найти Telegram အတွက် iOS client တွင်။ LinkedIn သည် ခြေတစ်လှမ်းထပ်ပြီး LMDB ကို ၎င်း၏ပြည်တွင်းဖြစ်ဒေတာ သိုလှောင်မှုဘောင်ဖြစ်သည့် Rocket Data အတွက် မူရင်းသိုလှောင်မှုအဖြစ် ရွေးချယ်ခဲ့သည်။ ပြောတယ်။ 2016 ခုနှစ် ဆောင်းပါးတစ်ပုဒ်တွင်

LMDB သည် Oracle ၏ထိန်းချုပ်မှုအောက်တွင်အကူးအပြောင်းပြီးနောက် BerkeleyDB မှထားခဲ့သောနေရောင်အောက်တွင်နေရာတစ်ခုအတွက်အောင်မြင်စွာတိုက်ပွဲဝင်နေသည်။ စာကြည့်တိုက်သည် ၎င်း၏ကိုယ်ပိုင်အမျိုးအစားနှင့် နှိုင်းယှဉ်လျှင်ပင် ၎င်း၏မြန်နှုန်းနှင့် ယုံကြည်စိတ်ချရမှုအတွက် နှစ်သက်သည်။ သင်သိသည့်အတိုင်း၊ အခမဲ့နေ့လည်စာများမရှိပါ၊ LMDB နှင့် SQLite ကိုရွေးချယ်ရာတွင်သင်ရင်ဆိုင်ရမည့်အပေးအယူကိုအလေးပေးဖော်ပြလိုပါသည်။ အထက်ဖော်ပြပါ ပုံကြမ်းသည် တိုးမြှင့်ထားသော မြန်နှုန်းကို မည်သို့အောင်မြင်ကြောင်း ရှင်းလင်းစွာ ပြသထားသည်။ ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် disk သိုလှောင်မှုအပေါ်ရှိ နောက်ထပ် abstraction အလွှာများအတွက် မပေးချေပါ။ ဟုတ်ပါတယ်၊ ကောင်းမွန်တဲ့ ဗိသုကာလက်ရာတစ်ခုမှာ၊ အဲဒါတွေမပါဘဲ သင်မလုပ်နိုင်သေးဘဲ၊ သူတို့က အပလီကေးရှင်းကုဒ်မှာ မလွှဲမရှောင်သာ ပေါ်လာလိမ့်မယ်၊ ဒါပေမယ့် သူတို့က ပိုပါးသွားလိမ့်မယ်။ ၎င်းတို့တွင် သီးခြား အပလီကေးရှင်းတစ်ခုမှ မလိုအပ်သော အင်္ဂါရပ်များ ဥပမာ SQL ဘာသာစကားရှိ မေးမြန်းချက်များအတွက် ပံ့ပိုးမှု ရှိမည်မဟုတ်ပါ။ ဒုတိယအနေဖြင့်၊ ၎င်းသည် disk သိုလှောင်မှုတောင်းဆိုမှုများအတွက် application လည်ပတ်မှုမြေပုံကိုအကောင်းဆုံးအကောင်အထည်ဖော်ရန်ဖြစ်နိုင်သည်။ SQLite ဆိုရင် ငါ့အလုပ်၌ ပျမ်းမျှအပလီကေးရှင်းတစ်ခု၏ ပျမ်းမျှလိုအပ်ချက်များမှ လာသည်၊ ထို့နောက် အက်ပလီကေးရှင်းထုတ်လုပ်သူအနေဖြင့် သင်သည် ပင်မဝန်ဆောင်မှုအခြေအနေများကို ကောင်းစွာသဘောပေါက်ပါသည်။ ပိုမိုထိရောက်သောဖြေရှင်းချက်တစ်ခုအတွက်၊ ကနဦးဖြေရှင်းချက်၏ဖွံ့ဖြိုးတိုးတက်မှုနှင့် ၎င်း၏နောက်ဆက်တွဲပံ့ပိုးမှုနှစ်ခုစလုံးအတွက် တိုးမြှင့်စျေးနှုန်းတစ်ခုပေးဆောင်ရမည်ဖြစ်သည်။

3. ဝေလငါး LMDB သုံးကောင်

ငှက်မျက်လုံး မြင်ကွင်းကနေ LMDB ကို ကြည့်ပြီး၊ ပိုပြီး နက်ရှိုင်းဖို့ အချိန်တန်ပါပြီ။ နောက်အပိုင်းသုံးပိုင်းကို သိုလှောင်မှုဗိသုကာကျသည့် အဓိကဝေလငါးများ၏ ခွဲခြမ်းစိတ်ဖြာမှုတွင် အာရုံစိုက်သွားပါမည်-

1. ဒစ်ခ်နှင့်လုပ်ဆောင်ရန်နှင့် အတွင်းဒေတာတည်ဆောက်ပုံများကို တစ်ပြိုင်တည်းလုပ်ဆောင်ရန် ယန္တရားတစ်ခုအနေဖြင့် မန်မိုရီ-မြေပုံပြုလုပ်ထားသော ဖိုင်များ။
2. B+-tree သည် သိမ်းဆည်းထားသော ဒေတာဖွဲ့စည်းပုံ၏ အဖွဲ့အစည်းတစ်ခုဖြစ်သည်။
3. ACID အရောင်းအ၀ယ်ဆိုင်ရာ ဂုဏ်သတ္တိများနှင့် ဗားရှင်းများစွာကို ပံ့ပိုးပေးရန်အတွက် ချဉ်းကပ်မှုတစ်ခုအနေဖြင့် ကူးယူရေးသားခြင်း။

၃.၁။ ဝေလငါး #၁။ Memory-mapping ဖိုင်များ

Memory-mapped ဖိုင်များသည် repository အမည်ဖြင့်ပင် ပေါ်လာသည့် အရေးကြီးသော ဗိသုကာဒြပ်စင်တစ်ခုဖြစ်သည်။ သိမ်းဆည်းထားသော အချက်အလက်များသို့ ကက်ရှ်ချခြင်းနှင့် တစ်ပြိုင်တည်းဝင်ရောက်ခြင်းဆိုင်ရာ ပြဿနာများသည် လည်ပတ်မှုစနစ်၏ ကရုဏာဖြင့် လုံးလုံးလျားလျားဖြစ်သည်။ LMDB တွင် မည်သည့် ကက်ရှ်များ မပါဝင်ပါ။ မြေပုံဆွဲထားသောဖိုင်များမှ ဒေတာများကို တိုက်ရိုက်ဖတ်ရှုခြင်းဖြင့် အင်ဂျင်ကို အကောင်အထည်ဖော်ရာတွင် ထောင့်များစွာကို ဖြတ်တောက်နိုင်သောကြောင့် ဤသည်မှာ စာရေးသူ၏ သတိရှိဆုံးဖြတ်ချက်တစ်ခုဖြစ်သည်။ အောက်တွင်ဖော်ပြထားသည်မှာ ၎င်းတို့ထဲမှအချို့၏ ပြီးပြည့်စုံသောစာရင်းနှင့် ဝေးကွာသည်။

1. လုပ်ငန်းစဉ်များစွာမှ ၎င်းနှင့်အလုပ်လုပ်သောအခါ သိုလှောင်မှုတွင် ဒေတာ၏ညီညွတ်မှုကို ထိန်းသိမ်းခြင်းသည် လည်ပတ်မှုစနစ်၏တာဝန်ဖြစ်လာသည်။ နောက်အပိုင်းမှာတော့ ဒီစက်ပြင်ဆရာကို ပုံတွေနဲ့ အသေးစိတ် ဆွေးနွေးထားပါတယ်။
2. ကက်ရှ်များမရှိခြင်းသည် တက်ကြွသောခွဲဝေပေးမှုများနှင့် ဆက်စပ်နေသော overhead ၏ LMDB ကို လုံးဝသက်သာစေသည်။ လက်တွေ့တွင် ဒေတာဖတ်ခြင်းသည် ညွှန်ပြချက်ကို virtual memory တွင် မှန်ကန်သောလိပ်စာသို့ သတ်မှတ်ပေးခြင်းဖြစ်ပြီး နောက်ထပ်ဘာမျှမရှိပါ။ စိတ်ကူးယဉ်ဟန်တူသော်လည်း repository source တွင် calloc ခေါ်ဆိုမှုများအားလုံးကို repository configuration function တွင် စုစည်းထားသည်။
3. ကက်ရှ်များမရှိခြင်းသည် ၎င်းတို့ကိုဝင်ရောက်ကြည့်ရှုရန် ထပ်တူပြုခြင်းနှင့်ဆက်စပ်သောသော့ခလောက်များမရှိခြင်းကိုဆိုလိုသည်။ တစ်ချိန်တည်းမှာ မထင်သလို ကိန်းဂဏန်းတစ်ခု တည်ရှိနိုင်သည့် စာဖတ်သူများသည် ဒေတာသို့သွားရာလမ်းတွင် mutex တစ်ခုတည်းနှင့် မတွေ့ရပါ။ ထို့အတွက်ကြောင့် ဖတ်ရှုမှုအမြန်နှုန်းသည် CPU အရေအတွက်အရ စံပြမျဉ်းအတိုင်း ချဲ့ထွင်နိုင်စွမ်းရှိသည်။ LMDB တွင်၊ ပြုပြင်မွမ်းမံမှုများသာ လုပ်ဆောင်ချက်များကို ထပ်တူပြုပါသည်။ တစ်ကြိမ်လျှင် စာရေးဆရာတစ်ယောက်သာ ရှိနိုင်သည်။
4. caching နှင့် synchronization logic သည် အနည်းဆုံး ကုဒ်ကို ကြိုးမျိုးစုံပတ်ဝန်း ကျင်တွင် အလုပ်လုပ်ခြင်းနှင့် ဆက်စပ်နေသော အလွန်ရှုပ်ထွေးသော အမှားအမျိုးအစားမှ ကုဒ်ကို သိမ်းဆည်းပါသည်။ Usenix OSDI 2014 ကွန်ဖရင့်တွင် စိတ်ဝင်စားစရာကောင်းသော ဒေတာဘေ့စ်လေ့လာမှုနှစ်ခုရှိခဲ့သည်။ "ဖိုင်စနစ်အားလုံးသည် ညီမျှစွာဖန်တီးထားခြင်းမဟုတ်ပါ- ပျက်စီးမှု-ကိုက်ညီသော အပလီကေးရှင်းများကို ဖန်တီးခြင်း၏ ရှုပ်ထွေးမှုအပေါ်" и ပျော်ရွှင်မှုနှင့် အကျိုးအမြတ်အတွက် ဒေတာဘေ့စ်များကို ညှဉ်းပန်းနှိပ်စက်ခြင်း။. ၎င်းတို့ထံမှ သင်သည် LMDB ၏ မကြုံစဖူး ယုံကြည်စိတ်ချရမှုနှင့် တူညီသော SQLite ထက်သာလွန်သော အရောင်းအ၀ယ်များ၏ ACID ဂုဏ်သတ္တိများကို ချို့ယွင်းချက်မရှိနီးပါး အကောင်အထည်ဖော်မှု နှစ်ခုလုံးဆိုင်ရာ အချက်အလက်များကို သင်ရနိုင်သည်။
5. LMDB ၏ အနည်းငယ်မျှသာလွန်ဆန်မှုသည် ၎င်း၏ကုဒ်များ၏ စက်ကိုယ်စားပြုမှုကို ရလဒ်အမြန်နှုန်းလက္ခဏာများနှင့်အတူ ပရိုဆက်ဆာ၏ L1 cache တွင် လုံးလုံးလျားလျားထားရှိနိုင်စေပါသည်။

ကံမကောင်းစွာပဲ၊ iOS တွင် Memory-mapped ဖိုင်များသည် ကျွန်ုပ်တို့နှစ်သက်သလောက် နှင်းဆီပန်းများမဟုတ်ပေ။ ၎င်းတို့နှင့် ဆက်စပ်နေသော အားနည်းချက်များကို ပိုမိုသတိရှိစွာ ပြောဆိုရန်၊ လည်ပတ်မှုစနစ်များတွင် ဤယန္တရားအား အကောင်အထည်ဖော်ခြင်းအတွက် ယေဘူယျအခြေခံမူများကို ပြန်လည်သတိရရန် လိုအပ်ပါသည်။

မန်မိုရီမြေပုံပြုလုပ်ထားသော ဖိုင်များအကြောင်း အထွေထွေအချက်အလက်

လည်ပတ်နိုင်သော အပလီကေးရှင်းတစ်ခုစီနှင့်၊ လည်ပတ်မှုစနစ်သည် လုပ်ငန်းစဉ်ဟုခေါ်သော အရာတစ်ခုနှင့် ဆက်စပ်သည်။ လုပ်ငန်းစဉ်တစ်ခုစီသည် အလုပ်လုပ်ရန် လိုအပ်သည့်အရာအားလုံးကို နေရာချပေးသည့် ဆက်စပ်နေသော လိပ်စာများအကွာအဝေးကို ခွဲဝေပေးထားသည်။ အနိမ့်ဆုံးလိပ်စာများတွင် ကုဒ်နှင့် hardcoded data နှင့် အရင်းအမြစ်များပါသည့် အပိုင်းများပါရှိသည်။ နောက်တစ်ခုကတော့ အမှိုက်ပုံလို့ လူသိများတဲ့ ဒိုင်းနမစ်လိပ်စာနေရာရဲ့ အထက်-ကြီးထွားလာတဲ့ ဘလောက်တစ်ခု ပေါ်လာပါတယ်။ ၎င်းတွင် ပရိုဂရမ်၏ လုပ်ဆောင်မှုအတွင်း ပေါ်လာသည့် အရာများ၏ လိပ်စာများ ပါဝင်သည်။ ထိပ်တွင် အပလီကေးရှင်း stack မှအသုံးပြုသော memory ဧရိယာ။ ကြီးထွားသည်ဖြစ်စေ ကျုံ့သည်ဖြစ်စေ တစ်နည်းအားဖြင့် ၎င်း၏အရွယ်အစားသည်လည်း တက်ကြွသောသဘောရှိသည်။ stack နှင့် heap သည် တစ်ခုနှင့်တစ်ခု တွန်းမနှောင့်ယှက်စေရန်၊ ၎င်းတို့ကို address space ၏ မတူညီသောအဆုံးများတွင် ပိုင်းခြားထားသည်။ အပေါ်နှင့်အောက်ခြေတွင် dynamic section နှစ်ခုကြားတွင် အပေါက်တစ်ခုရှိသည်။ ဤအလယ်အလတ်အပိုင်းရှိ လိပ်စာများကို လည်ပတ်မှုစနစ်က အမျိုးမျိုးသော ဖြစ်စဉ်တစ်ခုနှင့် ဆက်စပ်ရန် အသုံးပြုပါသည်။ အထူးသဖြင့်၊ ၎င်းသည် ဒစ်ခ်ပေါ်ရှိ ဖိုင်တစ်ခုသို့ စဉ်ဆက်မပြတ် လိပ်စာအချို့ကို မြေပုံဆွဲနိုင်သည်။ ထိုသို့သောဖိုင်ကို memory-mapped file ဟုခေါ်သည်။

လုပ်ငန်းစဉ်တစ်ခုအတွက် ခွဲဝေပေးထားသည့် လိပ်စာနေရာသည် ကြီးမားသည်။ သီအိုရီအရ၊ စနစ်၏ bitness ဖြင့်ဆုံးဖြတ်သည့် pointer ၏အရွယ်အစားဖြင့်သာ လိပ်စာအရေအတွက်ကို ကန့်သတ်ထားသည်။ အကယ်၍ ရုပ်ပိုင်းဆိုင်ရာမှတ်ဉာဏ်ကို 1-in-1 တွင် သတ်မှတ်ပေးခဲ့ပါက၊ ပထမလုပ်ငန်းစဉ်သည် RAM တစ်ခုလုံးကို စုပ်ယူသွားမည်ဖြစ်ပြီး Multitasking အတွက် မေးခွန်းထုတ်စရာမရှိပါ။

သို့သော်၊ ခေတ်မီလည်ပတ်မှုစနစ်များသည် သင်အလိုရှိသလောက် တစ်ချိန်တည်းတွင် လုပ်ဆောင်နိုင်သည်ဟူသော အတွေ့အကြုံမှ ကျွန်ုပ်တို့သိပါသည်။ ၎င်းတို့သည် စာရွက်ပေါ်တွင်သာ လုပ်ဆောင်ရန် မန်မိုရီအများအပြားကို ခွဲဝေချထားခြင်းကြောင့် ဖြစ်နိုင်သော်လည်း အမှန်တကယ်တွင် ၎င်းတို့သည် ဤနေရာနှင့် ယခုလက်ရှိ လိုအပ်နေသည့် ပင်မရုပ်ပိုင်းဆိုင်ရာမှတ်ဉာဏ်ထဲသို့ ၎င်းတို့ကို ထည့်သွင်းထားသည်။ ထို့ကြောင့် လုပ်ငန်းစဉ်နှင့် ဆက်စပ်နေသော memory ကို virtual ဟုခေါ်သည်။

လည်ပတ်မှုစနစ်သည် အချို့သောအရွယ်အစားရှိ စာမျက်နှာများအဖြစ် virtual နှင့် ရုပ်ပိုင်းဆိုင်ရာမှတ်ဉာဏ်ကို စုစည်းပေးသည်။ အချို့သော virtual memory ၏ စာမျက်နှာတစ်ခု တောင်းဆိုလာသည်နှင့်တပြိုင်နက်၊ လည်ပတ်မှုစနစ်သည် ၎င်းကို ရုပ်ပိုင်းဆိုင်ရာမှတ်ဉာဏ်တွင် ထည့်သွင်းပြီး ၎င်းတို့ကြားရှိ စာပေးစာယူကို အထူးဇယားတစ်ခုတွင် ချထားသည်။ အခမဲ့ slot များမရှိပါက၊ ယခင်က တင်ထားသော စာမျက်နှာများထဲမှ တစ်ခုကို disk သို့ ကူးယူပြီး တောင်းဆိုထားသော စာမျက်နှာသည် ၎င်းနေရာသို့ ရောက်သွားပါသည်။ မကြာမီ ကျွန်ုပ်တို့ပြန်သွားမည့် ဤလုပ်ငန်းစဉ်ကို swapping ဟုခေါ်သည်။ အောက်ဖော်ပြပါပုံသည် ဖြစ်စဉ်ကို သရုပ်ဖော်ထားသည်။ ၎င်းတွင် လိပ်စာ 0 ပါသော စာမျက်နှာ A ကို တင်ပြီး လိပ်စာ 4 ပါသော ပင်မမှတ်ဉာဏ်စာမျက်နှာတွင် ထားရှိခဲ့သည်။ ဤအချက်ကို ဆဲလ်နံပါတ် 0 ရှိ စာပေးစာယူဇယားတွင် ထင်ဟပ်ခဲ့သည်။

Memory-mapped ဖိုင်များဖြင့်၊ ဇာတ်လမ်းသည် အတူတူပင်ဖြစ်သည်။ ယုတ္တိဗေဒအရ၊ ၎င်းတို့ကို virtual address space တွင် စဉ်ဆက်မပြတ်နှင့် လုံးလုံးလျားလျား ထားရှိထားသည်။ သို့သော်၊ ၎င်းတို့သည် စာမျက်နှာတစ်ခုပြီးတစ်ခု ရူပမှတ်ဉာဏ်စာမျက်နှာသို့ ရောက်ရှိပြီး တောင်းဆိုမှုအရသာ ဖြစ်သည်။ ထိုစာမျက်နှာများကို မွမ်းမံပြင်ဆင်ခြင်းသည် ဒစ်ခ်ပေါ်ရှိ ဖိုင်နှင့် ထပ်တူပြုပါသည်။ ထို့ကြောင့် သင်သည် ဖိုင် I/O ကို လုပ်ဆောင်နိုင်ပြီး မန်မိုရီတွင် ဘိုက်များဖြင့် ရိုးရှင်းစွာ လုပ်ဆောင်နိုင်သည် - ပြောင်းလဲမှုအားလုံးကို operating system kernel မှ မူရင်းဖိုင်သို့ အလိုအလျောက် လွှဲပြောင်းပေးမည်ဖြစ်သည်။
​
အောက်ဖော်ပြပါပုံသည် မတူညီသောလုပ်ငန်းစဉ်များမှဒေတာဘေ့စ်နှင့်အလုပ်လုပ်သောအခါ LMDB သည် ၎င်း၏အခြေအနေကိုတစ်ပြိုင်တည်းလုပ်ဆောင်ပုံကို သရုပ်ပြသည်။ မတူညီသော လုပ်ငန်းစဉ်များ၏ virtual memory ကို တူညီသောဖိုင်တွင် မြေပုံဆွဲခြင်းဖြင့်၊ LMDB မှကြည့်ရှုသည့်နေရာဖြစ်သည့် ၎င်းတို့၏လိပ်စာနေရာလပ်တုံးအချို့ကို တစ်ခုနှင့်တစ်ခု အကူးအပြောင်းအချိန်ကိုက်လုပ်ဆောင်ရန် စနစ်အား ကျွန်ုပ်တို့က လိုအပ်ပါသည်။
​

အရေးကြီးသော ကွဲပြားချက်မှာ LMDB သည် ဒေတာဖိုင်ကို ရေးစနစ်ခေါ်ဆိုမှု ယန္တရားမှတစ်ဆင့် ပုံသေဖြင့် မွမ်းမံပြင်ဆင်ပြီး ဖိုင်ကိုယ်တိုင်က ဖတ်ရန်-သပ်သပ်မုဒ်တွင် ပြသခြင်းဖြစ်သည်။ ဤချဉ်းကပ်မှုတွင် အရေးကြီးသော သက်ရောက်မှု နှစ်ခုရှိသည်။

ပထမအကျိုးဆက်က လည်ပတ်မှုစနစ်အားလုံးမှာ ဖြစ်ရိုးဖြစ်စဉ်ပါ။ ၎င်း၏ အနှစ်သာရမှာ မှားယွင်းသော ကုဒ်ဖြင့် ဒေတာဘေ့စ်သို့ မရည်ရွယ်ဘဲ ပျက်စီးခြင်းမှ ကာကွယ်မှု ပေါင်းထည့်ရန် ဖြစ်သည်။ သင်သိသည့်အတိုင်း၊ လုပ်ငန်းစဉ်တစ်ခု၏ အကောင်အထည်ဖော်နိုင်သော ညွှန်ကြားချက်များသည် ၎င်း၏လိပ်စာနေရာရှိ မည်သည့်နေရာမှမဆို ဒေတာကို အခမဲ့ရယူနိုင်ပါသည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့မှတ်မိသလောက်၊ ဖတ်ရှုရေးမုဒ်တွင် ဖိုင်တစ်ခုပြသခြင်းသည် မည်သည့်ညွှန်ကြားချက်ကိုမဆို ၎င်းအပြင် ၎င်းကိုပြင်နိုင်သည်ဟု ဆိုလိုသည်။ အကယ်၍ သူမသည် ၎င်းကို မှားယွင်းစွာပြုလုပ်မိပါက၊ ဥပမာအားဖြင့်၊ နဂိုရှိမနေသော အညွှန်းတစ်ခုတွင် array element တစ်ခုကို အမှန်တကယ် overwrite လုပ်ပါက၊ ဤနည်းဖြင့် ၎င်းသည် database ဖောက်ပြန်ခြင်းသို့ ဦးတည်သွားစေမည့် ဤနည်းအားဖြင့် သူမသည် မြေပုံပေါ်တွင် ဖော်ပြထားသောဖိုင်ကို မတော်တဆ ပြောင်းလဲနိုင်သည်။ ဖိုင်ကို ဖတ်ရန်-သပ်သပ်မုဒ်တွင် ပြသပါက၊ ၎င်းနှင့်သက်ဆိုင်သည့် လိပ်စာနေရာအား ပြောင်းလဲရန် ကြိုးပမ်းခြင်းသည် အချက်ပြမှုဖြင့် ပရိုဂရမ် ပျက်စီးသွားမည်ဖြစ်သည်။ SIGSEGV၊ ဖိုင်သည် နဂိုအတိုင်း ရှိနေပါမည်။

ဒုတိယအကျိုးဆက်က iOS အတွက် သီးသန့်ဖြစ်နေပါပြီ။ စာရေးဆရာနှင့် အခြားသတင်းရင်းမြစ်များက ၎င်းကို အတိအလင်းဖော်ပြထားခြင်းမရှိသော်လည်း၊ ၎င်းမရှိဘဲ၊ LMDB သည် ဤမိုဘိုင်းလည်ပတ်မှုစနစ်တွင် လုပ်ဆောင်ရန် မသင့်လျော်ပါ။ နောက်အပိုင်းကိုတော့ ထည့်သွင်းစဉ်းစားထားပါတယ်။

iOS တွင် Memory-mapped ဖိုင်များ၏ အသေးစိတ်အချက်များ

2018 တွင် WWDC ၌ အံ့သြဖွယ်ကောင်းသော အစီရင်ခံစာတစ်ခု ရှိခဲ့သည်။ iOS Memory Deep Dive. iOS တွင် ရုပ်ပိုင်းဆိုင်ရာမှတ်ဉာဏ်တွင်ရှိသော စာမျက်နှာအားလုံးသည် ညစ်ပတ်ခြင်း၊ ဖိသိပ်ခြင်းနှင့် သန့်ရှင်းခြင်း အမျိုးအစား 3 မျိုးထဲမှ တစ်ခုဖြစ်ကြောင်း ၎င်းကဆိုသည်။

သန့်ရှင်းသောမှတ်ဉာဏ်သည် ရုပ်ပိုင်းဆိုင်ရာမှတ်ဉာဏ်မှ ဘေးကင်းစွာ ကူးပြောင်းနိုင်သော စာမျက်နှာများစုစည်းမှုဖြစ်သည်။ ၎င်းတို့ပါရှိသော ဒေတာများကို လိုအပ်သလို ၎င်းတို့၏ မူရင်းရင်းမြစ်များမှ ပြန်လည်ရယူနိုင်ပါသည်။ ဖတ်ရန်-သီးသန့် မမ်မိုရီ-ပုံဖော်ထားသော ဖိုင်များသည် ဤအမျိုးအစားတွင် ရှိသည်။ iOS သည် မမ်မိုရီမှ ဖိုင်တစ်ခုသို့ ပုံဖော်ထားသည့် စာမျက်နှာများကို အချိန်မရွေး လွှင့်တင်ရန် မကြောက်ပါ၊ ၎င်းတို့အား ဒစ်ခ်ပေါ်ရှိ ဖိုင်နှင့် တစ်ပြိုင်တည်းလုပ်ဆောင်ရန် အာမခံထားသောကြောင့် ဖြစ်သည်။
​
မွမ်းမံထားသော စာမျက်နှာအားလုံးသည် မူလနေရာ၌ ရှိနေသည်ဖြစ်စေ ညစ်ညမ်းသောမှတ်ဉာဏ်ထဲသို့ ရောက်သွားပါသည်။ အထူးသဖြင့်၊ ၎င်းတို့နှင့်ဆက်စပ်နေသည့် virtual memory သို့ စာရေးခြင်းဖြင့် ပြင်ဆင်ထားသော memory-mapped ဖိုင်များကို ဤနည်းဖြင့် အမျိုးအစားခွဲမည်ဖြစ်သည်။ အလံဖြင့် LMDB ကိုဖွင့်ခြင်း။ MDB_WRITEMAPအဲဒါကို ပြုပြင်ပြောင်းလဲပြီးရင် သင်ကိုယ်တိုင် မြင်နိုင်မှာပါ.

အပလီကေးရှင်းတစ်ခုသည် ရုပ်ပိုင်းဆိုင်ရာမှတ်ဉာဏ် အလွန်အကျွံယူလာသည်နှင့်တပြိုင်နက် iOS သည် ၎င်း၏ညစ်ပတ်သောစာမျက်နှာများကို ချုံ့သည်။ ညစ်ပတ်ပြီး ဖိသိပ်ထားသော စာမျက်နှာများမှ သိမ်းပိုက်ထားသော မမ်မိုရီအစုအဝေးသည် အပလီကေးရှင်း၏ မှတ်ဉာဏ်ခြေရာဟု ခေါ်သည်။ သတ်မှတ်ထားသော အတိုင်းအတာတစ်ခုတန်ဖိုးသို့ရောက်ရှိသောအခါ OOM လူသတ်စနစ် daemon သည် လုပ်ငန်းစဉ်အပြီးတွင် ထွက်ပေါ်လာပြီး ၎င်းအား အတင်းအကျပ်ပိတ်ပစ်လိုက်သည်။ ၎င်းသည် desktop လည်ပတ်မှုစနစ်များနှင့်နှိုင်းယှဉ်ပါက iOS ၏ထူးခြားချက်ဖြစ်သည်။ ဆန့်ကျင်ဘက်အနေနှင့်၊ စာမျက်နှာများကို ရုပ်ပိုင်းဆိုင်ရာမှတ်ဉာဏ်မှ ဒစ်ခ်သို့ လဲလှယ်ခြင်းဖြင့် မမ်မိုရီခြေရာကို လျှော့ချခြင်းအား iOS တွင် ပေးစွမ်းမည်မဟုတ်ပါ။ အကြောင်းအရင်းများကိုသာ ခန့်မှန်းနိုင်ပါသည်။ စာမျက်နှာများကို ဒစ်ခ်နှင့် နောက်သို့ အပြင်းအထန် ရွှေ့ရန် လုပ်ထုံးလုပ်နည်းသည် မိုဘိုင်းလ်စက်ပစ္စည်းများအတွက် စွမ်းအင်သုံးစွဲမှု လွန်ကဲသည် သို့မဟုတ် iOS သည် SSD drives တွင် ပြန်လည်ရေးသားသည့်ဆဲလ်များ၏ အရင်းအမြစ်ကို သိမ်းဆည်းပေးသည်၊ သို့မဟုတ် အရာအားလုံးသည် စနစ်၏ အလုံးစုံစွမ်းဆောင်မှုအပေါ် ဒီဇိုင်နာများက မကျေနပ်ဖြစ်နိုင်သည်။ အဆက်မပြတ်လဲလှယ်။ တတ်နိုင်သမျှတော့ အမှန်ပဲ ကျန်နေပါစေ။

အစောပိုင်းတွင် ဖော်ပြခဲ့ပြီးဖြစ်သော သတင်းကောင်းမှာ LMDB သည် ဖိုင်များကို ပုံသေဖြင့် အပ်ဒိတ်လုပ်ရန် mmap ယန္တရားကို အသုံးမပြုခြင်းကြောင့် ဖြစ်သည်။ ပြန်ဆိုထားသည့်ဒေတာကို iOS မှ သန့်ရှင်းသော မမ်မိုရီအဖြစ် ခွဲခြားသတ်မှတ်ထားပြီး မန်မိုရီခြေရာကို အထောက်အကူမပြုကြောင်း ၎င်းကဆိုသည်။ ၎င်းကို VM Tracker ဟုခေါ်သော Xcode ကိရိယာကို အသုံးပြု၍ စစ်ဆေးနိုင်သည်။ အောက်ဖော်ပြပါ ဖန်သားပြင်ဓာတ်ပုံသည် လည်ပတ်နေစဉ်အတွင်း iOS Cloud အပလီကေးရှင်း၏ virtual memory အခြေအနေကို ပြသသည်။ အစတွင်၊ ၎င်းတွင် LMDB ဖြစ်ရပ် ၂ ခုကို အစပြုခဲ့သည်။ ပထမတစ်ခုသည် ၎င်း၏ဖိုင်ကို virtual memory ၏ 2GiB နှင့် မြေပုံဆွဲရန် ခွင့်ပြုခဲ့ပြီး ဒုတိယမှာ 1MiB ဖြစ်သည်။ သိုလှောင်မှုနှစ်ခုလုံးသည် နေထိုင်သူမှတ်ဉာဏ်ပမာဏအချို့ကို သိမ်းပိုက်ထားသော်လည်း ၎င်းတို့နှစ်ခုလုံးသည် ညစ်ပတ်သည့်အရွယ်အစားကို မပါဝင်ပါ။

ယခုအချိန်သည် သတင်းဆိုးအတွက် အချိန်ဖြစ်သည်။ 64-bit desktop လည်ပတ်မှုစနစ်များတွင် swap ယန္တရားကြောင့်၊ လုပ်ငန်းစဉ်တစ်ခုစီသည် hard disk ပေါ်ရှိ နေရာလွတ်များကို ၎င်း၏ ဖြစ်နိုင်ချေရှိသော swap များအတွက် ခွင့်ပြုပေးသည်နှင့်အမျှ လုပ်ငန်းစဉ်တစ်ခုစီသည် virtual address space များများယူနိုင်သည်။ iOS တွင် compression ဖြင့် swap ကို အစားထိုးခြင်းသည် သီအိုရီအရ အများဆုံးကို သိသိသာသာ လျှော့ချပေးပါသည်။ ယခု သက်ရှိ လုပ်ငန်းစဉ်များအားလုံးသည် ပင်မ (read RAM) မမ်မိုရီတွင် အံဝင်ခွင်ကျဖြစ်ရမည် ဖြစ်ပြီး အံမဝင်သော အရာများအားလုံးသည် အတင်းအကြပ် ရပ်စဲခြင်းခံရပါသည်။ အပေါ်မှာပြောခဲ့သလိုပါပဲ။ အစီရင်ခံစာနှင့် တရားဝင်စာရွက်စာတမ်း. အကျိုးဆက်အနေဖြင့်၊ iOS သည် mmap မှတစ်ဆင့် ခွဲဝေပေးရန်အတွက် ရနိုင်သော memory ပမာဏကို ပြင်းထန်စွာ ကန့်သတ်ထားသည်။ ဒီမှာ ဒီမှာ ဤစနစ်ခေါ်ဆိုမှုကို အသုံးပြု၍ မတူညီသောစက်ပစ္စည်းများတွင် ခွဲဝေချထားပေးနိုင်သည့် မမ်မိုရီပမာဏအပေါ် ကြီးမားသောကန့်သတ်ချက်များကို သင်ကြည့်ရှုနိုင်သည်။ ခေတ်အမီဆုံး စမတ်ဖုန်းမော်ဒယ်များတွင် iOS သည် 2 ဂစ်ဂါဘိုက်နှင့် iPad ၏ ထိပ်တန်းဗားရှင်းများတွင် 4 ဖြင့် အားကောင်းလာခဲ့သည်။ လက်တွေ့တွင်၊ အရာအားလုံးသည် အလွန်ဝမ်းနည်းစရာကောင်းသည့် အသက်အငယ်ဆုံး စက်ပစ္စည်းမော်ဒယ်များကို အာရုံစိုက်ရမည်ဖြစ်သည်။ ပိုဆိုးတာက VM Tracker မှာရှိတဲ့ အပလီကေးရှင်းရဲ့ မမ်မိုရီအခြေအနေကိုကြည့်ရင် LMDB ဟာ memory-mapping လုပ်ထားတဲ့ memory တစ်ခုတည်းနဲ့ ဝေးကွာနေတာကို တွေ့ရပါလိမ့်မယ်။ စနစ်ခွဲဝေပေးသူများ၊ အရင်းအမြစ်ဖိုင်များ၊ ရုပ်ပုံဘောင်များနှင့် အခြားသေးငယ်သော သားကောင်များမှ ကောင်းသောအတုံးများကို စားသုံးကြသည်။

Cloud တွင်စမ်းသပ်မှုများ၏ရလဒ်အနေဖြင့် LMDB မှခွဲဝေပေးသောမမ်မိုရီ၏အောက်ဖော်ပြပါအပေးအယူတန်ဖိုးများဖြစ်သည်- 384-bit စက်များအတွက် 32 megabytes နှင့် 768-bit များအတွက် 64 ဖြစ်သည်။ ဤအသံအတိုးအကျယ်ကို အသုံးပြုပြီးနောက်၊ ပြုပြင်မွမ်းမံသည့်လုပ်ဆောင်မှုများသည် ကုဒ်ဖြင့် ပြီးမြောက်သွားမည်ဖြစ်သည်။ MDB_MAP_FULL. ကျွန်ုပ်တို့၏စောင့်ကြည့်မှုတွင်ထိုကဲ့သို့သောအမှားများကိုကျွန်ုပ်တို့သတိပြုမိသော်လည်း၎င်းတို့သည်ဤအဆင့်တွင်လျစ်လျူရှုရန်လုံလောက်သောသေးငယ်သည်။

သိုလှောင်မှုအားဖြင့် မမ်မိုရီအလွန်အကျွံသုံးစွဲမှုအတွက် ထင်ရှားသောအကြောင်းအရင်းမှာ ကြာရှည်စွာ အရောင်းအဝယ်ဖြစ်နိုင်သည်။ ဤဖြစ်စဉ်နှစ်ခုသည် မည်သို့ဆက်စပ်သည်ကို နားလည်ရန်၊ ၎င်းသည် ကျန်ရှိသော LMDB ဝေလငါးနှစ်ကောင်ကို စဉ်းစားရန် ကူညီပေးပါလိမ့်မည်။

၃.၂။ ဝေလငါး #၂။ B+-သစ်ပင်

သော့တန်ဖိုးစတိုးတစ်ခု၏ထိပ်တွင် ဇယားများကိုအတုယူရန်၊ အောက်ပါလုပ်ဆောင်ချက်များသည် ၎င်း၏ API တွင် ရှိနေရမည်-

1. အစိတ်အပိုင်းအသစ်တစ်ခုကို ထည့်သွင်းခြင်း။
2. ပေးထားသောသော့ဖြင့် အစိတ်အပိုင်းတစ်ခုကို ရှာပါ။
3. အစိတ်အပိုင်းတစ်ခုကို ဖျက်ခြင်း။
4. ၎င်းတို့၏ အမျိုးအစားအစီအစဥ်အတိုင်း အဓိကကြားကာလများကို ထပ်လောင်းပါ။

လုပ်ဆောင်ချက် လေးခုစလုံးကို အလွယ်တကူ အကောင်အထည်ဖော်နိုင်သော အရိုးရှင်းဆုံး ဒေတာဖွဲ့စည်းပုံမှာ ဒွိရှာဖွေမှုသစ်ပင် ဖြစ်သည်။ ၎င်း၏ ဆုံမှတ်တစ်ခုစီသည် ကလေးကီးများ၏ အခွဲတစ်ခုလုံးကို အခွဲနှစ်ခုအဖြစ် ပိုင်းခြားထားသော သော့တစ်ခုဖြစ်သည်။ ဘယ်ဘက်တွင် မိဘထက်ငယ်သော၊ ညာဘက်တွင် ပိုကြီးသောအရာများဖြစ်သည်။ မှာယူထားသောသော့အစုံကိုရရှိခြင်းသည် ဂန္ထဝင်သစ်ပင်ဖြတ်သန်းမှုတစ်ခုမှတစ်ဆင့် အောင်မြင်သည်။

ဒွိသစ်ပင်များသည် ဒစ်ခ်ဒေတာဖွဲ့စည်းပုံကဲ့သို့ ထိရောက်မှုမဖြစ်စေရန် တားဆီးသည့် အခြေခံအားနည်းချက်နှစ်ခုရှိသည်။ ပထမအချက်မှာ ၎င်းတို့၏ လက်ကျန်ပမာဏကို ခန့်မှန်း၍မရနိုင်ပါ။ မတူညီသောအကိုင်းအခက်များ၏ အမြင့်သည် များစွာကွဲပြားနိုင်ပြီး ရှာဖွေမှု၏ အယ်လဂိုရီသမ်ရှုပ်ထွေးမှုကို သိသာထင်ရှားစွာ ဆိုးရွားစေသည့် သစ်ပင်များရရှိရန် အန္တရာယ်များစွာရှိပါသည်။ ဒုတိယအနေဖြင့်၊ node များကြားရှိ အပြန်အလှန်လင့်ခ်များ များပြားခြင်းသည် memory အတွင်းရှိ နေရာဒေသ၏ binary tree များကို ဆုံးရှုံးစေသည်။ အပိတ် node (၎င်းတို့ကြားရှိ လင့်ခ်များ၏ သတ်မှတ်ချက်အရ) ကို virtual memory ရှိ လုံးဝကွဲပြားခြားနားသော စာမျက်နှာများတွင် တည်ရှိနိုင်သည်။ အကျိုးဆက်အနေဖြင့် သစ်ပင်တစ်ပင်ရှိ အနီးနားရှိ ဆုံမှတ်များစွာကို ရိုးရှင်းစွာဖြတ်သန်းခြင်းသည်ပင် နှိုင်းယှဉ်နိုင်သော စာမျက်နှာအရေအတွက်ကို လည်ပတ်ရန် လိုအပ်ပါသည်။ ပရိုဆက်ဆာ ကက်ရှ်ရှိ စာမျက်နှာများကို အဆက်မပြတ် လှည့်ပတ်ခြင်းသည် စျေးမကြီးသောကြောင့် ဒွိသစ်ပင်များ၏ စွမ်းဆောင်ရည်ကို မန်မိုရီအတွင်း ဒေတာတည်ဆောက်ပုံအဖြစ် ကျွန်ုပ်တို့ပြောသည့်အခါတွင်ပင် ၎င်းသည် ပြဿနာတစ်ခုဖြစ်သည်။ ဒစ်ခ်မှ node ဆိုင်ရာ စာမျက်နှာများကို မကြာခဏ ပြုစုပျိုးထောင်သည့်အခါတွင်၊ အရာများသည် တကယ်ကို ဆိုးရွားသွားပါသည်။ စိတ်ပျက်ဖွယ်။

B-trees သည် ဒွိသစ်ပင်များ၏ ဆင့်ကဲဖြစ်စဉ်ဖြစ်ခြင်းကြောင့် ယခင်စာပိုဒ်တွင် ဖော်ပြထားသော ပြဿနာများကို ဖြေရှင်းပေးသည်။ ပထမဦးစွာ၊ သူတို့သည် မိမိကိုယ်ကို ဟန်ချက်ညီအောင် လုပ်ဆောင်ကြသည်။ ဒုတိယအနေဖြင့်၊ ၎င်းတို့၏ ဆုံမှတ်တစ်ခုစီသည် ကလေးသော့များကို 2 ပိုင်းမဟုတ်ပဲ M ခွဲ၍ ခွဲကာ M နံပါတ်သည် ရာဂဏန်း သို့မဟုတ် ထောင်ပေါင်းများစွာ၏ အစီအစဥ်အရ အတော်လေးကြီးမားနိုင်သည်။

ထို့ကြောင့်-

1. node တစ်ခုစီတွင် အမိန့်ပေးပြီးသားသော့များစွာရှိပြီး သစ်ပင်များသည် အလွန်နည်းပါးပါသည်။
2. တန်ဖိုးနီးစပ်သောသော့များသည် တစ်ခုနှင့်တစ်ခုအနီးနားရှိ node တစ်ခုပေါ်တွင် သဘာဝအတိုင်းတည်ရှိသောကြောင့် သစ်ပင်သည် မှတ်ဉာဏ်တွင် နေရာဒေသ၏ပိုင်ဆိုင်မှုကို ရရှိပါသည်။
3. ရှာဖွေမှုလုပ်ဆောင်မှုတစ်ခုအတွင်း သစ်ပင်ပေါ်မှဆင်းသည့်အခါ အကူးအပြောင်း node အရေအတွက်ကို လျှော့ချပေးသည်။
4. အကွာအဝေးမေးမြန်းချက်များအတွက် ပစ်မှတ်နံပါတ်များကို လျှော့ချပေးသည်

LMDB သည် ဒေတာသိမ်းဆည်းရန် B+ tree ဟုခေါ်သော B-tree အမျိုးအစားကို အသုံးပြုသည်။ အထက်ဖော်ပြပါ ပုံတွင် ၎င်းတွင်ပါဝင်သော node အမျိုးအစားသုံးမျိုးကို ပြသသည်-

1. ထိပ်မှာအမြစ်။ ၎င်းသည် repository တစ်ခုအတွင်းရှိ database တစ်ခု၏သဘောတရားထက် ဘာမှမပိုပါ။ LMDB instance တစ်ခုအတွင်း၊ သင်သည် မြေပုံဆွဲထားသော virtual address space ကိုမျှဝေသည့် databases များစွာကို ဖန်တီးနိုင်သည်။ ၎င်းတို့တစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင်အမြစ်မှ စတင်သည်။
2. အနိမ့်ဆုံးအဆင့်မှာ အရွက် (အရွက်)။ ၎င်းတို့သည် ၎င်းတို့နှင့် ဒေတာဘေ့စ်တွင် သိမ်းဆည်းထားသော သော့တန်ဖိုးအတွဲများပါရှိသော ၎င်းတို့သာဖြစ်သည်။ စကားမစပ်၊ ဤသည်မှာ B+-trees ၏ထူးခြားချက်ဖြစ်သည်။ ပုံမှန် B-tree သည် အဆင့်အားလုံး၏ node များတွင် တန်ဖိုး-အစိတ်အပိုင်းများကို သိမ်းဆည်းထားပါက B+-variation သည် အနိမ့်ဆုံးတစ်ခုဖြစ်သည်။ ဤအချက်ကို ပြုပြင်ပြီးပါက အောက်ပါအတိုင်း LMDB တွင်အသုံးပြုသောသစ်ပင်၏ အမျိုးအစားခွဲကို ရိုးရိုး B-tree ဟုခေါ်ဆိုပါမည်။
3. အမြစ်နှင့် အရွက်ကြားတွင် လမ်းကြောင်းပြခြင်း (အကိုင်းအခက်) များပါရှိသော 0 သို့မဟုတ် ထို့ထက်ပိုသော နည်းပညာအဆင့်များ ရှိပါသည်။ သူတို့၏တာဝန်မှာ အရွက်များကြားတွင် သော့တွဲများကို ခွဲဝေရန်ဖြစ်သည်။

ရုပ်ပိုင်းအရ၊ node များသည် ကြိုတင်သတ်မှတ်ထားသော အရှည်တစ်ခု၏ မှတ်ဉာဏ်တုံးများဖြစ်သည်။ ၎င်းတို့၏ အရွယ်အစားသည် အထက်တွင်ပြောခဲ့သည့် လည်ပတ်မှုစနစ်ရှိ မမ်မိုရီစာမျက်နှာများ၏ အရွယ်အစားတစ်ခုဖြစ်သည်။ node ဖွဲ့စည်းပုံကို အောက်မှာ ပြထားပါတယ်။ ခေါင်းစီးတွင် meta-information ပါ၀င်သည်၊ ဥပမာအားဖြင့် အထင်ရှားဆုံးမှာ checksum ဖြစ်သည်။ ဒေတာပါရှိသောဆဲလ်များနှင့်အတူ အော့ဖ်ဆက်များအကြောင်း အချက်အလက်များပါရှိသည်။ ဒေတာ၏အခန်းကဏ္ဍသည် သော့များဖြစ်နိုင်သည်၊ အကယ်၍ ကျွန်ုပ်တို့သည် လမ်းကြောင်းပြခြင်းဆိုင်ရာ ဆုံမှတ်များအကြောင်းပြောနေလျှင် သို့မဟုတ် အရွက်အတွက် သော့တန်ဖိုးအတွဲများ တစ်ခုလုံးကို အလုပ်ထဲတွင် စာမျက်နှာများ၏ တည်ဆောက်ပုံအကြောင်း ပိုမိုဖတ်ရှုနိုင်ပါသည်။ "စွမ်းဆောင်ရည်မြင့်သော့-တန်ဖိုးဆိုင်များကို အကဲဖြတ်ခြင်း".

စာမျက်နှာ node များ၏ အတွင်းပိုင်း အကြောင်းအရာများကို ကိုင်တွယ်ဖြေရှင်းပြီးနောက်၊ ကျွန်ုပ်တို့သည် LMDB B-tree ကို အောက်ပါပုံစံဖြင့် ရိုးရှင်းသောနည်းလမ်းဖြင့် ထပ်မံကိုယ်စားပြုပါမည်။

node ပါသည့် စာမျက်နှာများကို ဒစ်ခ်ပေါ်တွင် စဉ်ဆက်မပြတ်စီစဉ်ထားသည်။ နံပါတ်ပိုမြင့်သော စာမျက်နှာများသည် ဖိုင်၏အဆုံးဆီသို့ ရောက်နေပါသည်။ မက်တာစာမျက်နှာ (meta page) တွင် သစ်ပင်အားလုံး၏ အမြစ်များကို ရှာဖွေရန် အသုံးပြုနိုင်သည့် အော့ဖ်ဆက်များအကြောင်း အချက်အလက် ပါရှိသည်။ ဖိုင်တစ်ခုကိုဖွင့်သောအခါ၊ LMDB သည် ဖိုင်စာမျက်နှာကို အဆုံးမှအစအထိ စာမျက်နှာတစ်ခုစီကို စကင်န်ဖတ်ကာ တရားဝင် meta စာမျက်နှာကို ရှာဖွေပြီး ၎င်းမှတစ်ဆင့် ရှိပြီးသားဒေတာဘေ့စ်များကို ရှာဖွေသည်။​

ယခု၊ ဒေတာအဖွဲ့အစည်း၏ယုတ္တိနှင့်ရုပ်ပိုင်းဆိုင်ရာဖွဲ့စည်းပုံဆိုင်ရာစိတ်ကူးတစ်ခုရှိလျှင် LMDB ၏တတိယဝေလငါးကိုစဉ်းစားရန်ဆက်လက်လုပ်ဆောင်နိုင်သည်။ သိုလှောင်မှုမွမ်းမံမှုများအားလုံးကို အရောင်းအ၀ယ်ပြုလုပ်ခြင်းနှင့် တစ်ခုနှင့်တစ်ခု သီးခြားခွဲထားခြင်းဖြင့် ဒေတာဘေ့စ်တစ်ခုလုံးကို မျိုးစုံဗားရှင်းအဖြစ်လည်း ပေးစွမ်းနိုင်မည်ဖြစ်သည်။

၃.၃။ ဝေလငါး #၃။ copy-on-write

B-tree လုပ်ဆောင်ချက်အချို့သည် ၎င်း၏ node များသို့ အပြောင်းအလဲများ ဆက်တိုက်ပြုလုပ်ခြင်း ပါဝင်သည်။ ဥပမာတစ်ခုသည် ၎င်း၏အမြင့်ဆုံးစွမ်းရည်သို့ရောက်ရှိပြီးသော node တစ်ခုသို့ သော့အသစ်တစ်ခုကို ပေါင်းထည့်ခြင်းဖြစ်သည်။ ဤကိစ္စတွင်၊ ပထမဦးစွာ၊ ၎င်းသည် node ကို နှစ်ပိုင်းခွဲရန်၊ ဒုတိယအနေဖြင့် ၎င်း၏ parent ရှိ spun off ကလေး node အသစ်သို့ လင့်ခ်တစ်ခုထည့်ရန် လိုအပ်ပါသည်။ ဤလုပ်ထုံးလုပ်နည်းသည် အလွန်အန္တရာယ်များသည်။ အကြောင်းတစ်ခုခုကြောင့် (ပျက်ကျခြင်း၊ ဓာတ်အားပြတ်တောက်ခြင်းစသည်ဖြင့်) စီးရီးမှ အပြောင်းအလဲများ၏ တစ်စိတ်တစ်ပိုင်းသာ ဖြစ်သွားပါက၊ သစ်ပင်သည် မကိုက်ညီသော အခြေအနေတွင် ရှိနေပါမည်။

ဒေတာဘေ့စ်အမှား-ခံနိုင်ရည်ရှိအောင်ပြုလုပ်ခြင်းအတွက် သမားရိုးကျဖြေရှင်းချက်တစ်ခုမှာ B-tree ဘေးတွင် ရေးမှတ်ထားသော မှတ်တမ်း (WAL) ဟုလည်း ခေါ်သော ဒစ်ခ်အခြေခံဒေတာတည်ဆောက်ပုံ၊ ငွေပေးငွေယူမှတ်တမ်းကို ထပ်ထည့်ရန်ဖြစ်သည်။ ၎င်းသည် B-tree ကိုယ်တိုင်မွမ်းမံပြင်ဆင်ခြင်းမပြုမီ၊ ရည်ရွယ်ထားသည့်လုပ်ဆောင်ချက်ကို အတိအကျရေးသားထားသည့် ဖိုင်တစ်ခုဖြစ်သည်။ ထို့ကြောင့်၊ ကိုယ်တိုင်စစ်ဆေးနေစဉ်အတွင်း ဒေတာပျက်စီးမှုကို တွေ့ရှိပါက၊ ဒေတာဘေ့စ်သည် မှတ်တမ်းကို ကိုယ်တိုင်ရှင်းလင်းရန် တိုင်ပင်ဆွေးနွေးသည်။

LMDB သည် copy-on-write ဟုခေါ်သော ၎င်း၏ အမှားခံနိုင်မှု ယန္တရားအဖြစ် မတူညီသောနည်းလမ်းကို ရွေးချယ်ခဲ့သည်။ ၎င်း၏ အနှစ်သာရမှာ ရှိပြီးသား စာမျက်နှာတစ်ခုပေါ်ရှိ ဒေတာကို မွမ်းမံခြင်းအစား ၎င်းကို လုံးလုံးလျားလျား ကူးယူပြီး မိတ္တူထဲတွင် ရှိပြီးသား ပြုပြင်မွမ်းမံမှုများအားလုံးကို ပြုလုပ်ခြင်း ဖြစ်သည်။

ထို့အပြင်၊ အပ်ဒိတ်လုပ်ထားသောဒေတာကိုရရှိနိုင်စေရန်အတွက်၊ ၎င်းနှင့်ဆက်စပ်သော parent node တွင် နောက်ဆုံးပေါ်ဖြစ်နေသော node သို့ လင့်ခ်ကိုပြောင်းရန် လိုအပ်ပါသည်။ ၎င်းကို ပြုပြင်ရန် လိုအပ်သောကြောင့်၊ ၎င်းကိုလည်း ကြိုတင် ကူးယူထားသည်။ လုပ်ငန်းစဉ်သည် အမြစ်အထိ တကျော့ပြန် လည်ပတ်နေပါသည်။ မက်တာစာမျက်နှာရှိ ဒေတာသည် ပြောင်းလဲရန် နောက်ဆုံးဖြစ်သည်။

အပ်ဒိတ်လုပ်ထုံးလုပ်နည်းအတွင်း လုပ်ငန်းစဉ် ရုတ်တရက်ပျက်သွားပါက၊ မက်တာစာမျက်နှာအသစ်ကို ဖန်တီးမည်မဟုတ်ပါ၊ သို့မဟုတ် အဆုံးအထိ ဒစ်ခ်သို့ စာရေးမည်မဟုတ်ပါ၊ နှင့် ၎င်း၏ checksum သည် မှားယွင်းနေလိမ့်မည်။ ဤကိစ္စရပ်နှစ်ခုတွင် စာမျက်နှာအသစ်များသည် လက်လှမ်းမမီနိုင်ဖြစ်ကာ အဟောင်းများကို ထိခိုက်စေမည်မဟုတ်ပါ။ ၎င်းသည် ဒေတာညီညွတ်မှုကို ထိန်းသိမ်းရန် LMDB အတွက် ရှေ့မှတ်တိုင်ကို ရေးသားရန် လိုအပ်မှုကို ဖယ်ရှားပေးပါသည်။ အထက်တွင်ဖော်ပြထားသော ဒစ်ခ်ပေါ်ရှိ ဒေတာသိုလှောင်မှုဖွဲ့စည်းပုံသည် အမှန်တကယ်အားဖြင့် ၎င်း၏လုပ်ဆောင်ချက်ကို တစ်ပြိုင်နက်လုပ်ဆောင်သည်။ တိကျပြတ်သားသော ငွေပေးငွေယူမှတ်တမ်းမရှိခြင်းသည် မြင့်မားသောဒေတာဖတ်ရှုခြင်းမြန်နှုန်းကို ပံ့ပိုးပေးသည့် LMDB ၏အင်္ဂါရပ်များထဲမှတစ်ခုဖြစ်သည်။

append-only B-tree ဟုခေါ်သော ရလဒ်တည်ဆောက်မှုသည် သဘာဝအားဖြင့် ငွေပေးငွေယူ သီးခြားခွဲထုတ်ခြင်းနှင့် ဗားရှင်းများစွာကို ပံ့ပိုးပေးသည်။ LMDB တွင်၊ ဖွင့်ထားသော ငွေပေးငွေယူတစ်ခုစီတွင် ၎င်းနှင့်ဆက်စပ်နေသည့် နောက်ဆုံးပေါ်သစ်ပင်အမြစ်တစ်ခုရှိသည်။ ငွေပေးငွေယူမပြီးသရွေ့၊ ၎င်းနှင့်ဆက်စပ်နေသောသစ်ပင်၏စာမျက်နှာများကိုဒေတာဗားရှင်းအသစ်အတွက်ဘယ်တော့မှပြောင်းလဲမည်မဟုတ်ပါ သို့မဟုတ် ပြန်လည်အသုံးပြုမည်မဟုတ်ပါ။ ထို့ကြောင့်၊ သင်သည် သက်ဆိုင်ရာဒေတာအစုံဖြင့် အတိအကျကြိုက်သရွေ့ သင်အလုပ်လုပ်နိုင်သည် သိုလှောင်မှုအား တက်ကြွစွာ အပ်ဒိတ်လုပ်နေဆဲဖြစ်သော်လည်း ယခုအချိန်တွင် ငွေပေးငွေယူဖွင့်သည့်အချိန်။ ဤသည်မှာ LMDB ကို ကျွန်ုပ်တို့ချစ်မြတ်နိုးသောသူများအတွက် စံပြဒေတာရင်းမြစ်ဖြစ်စေရန် ဘက်စုံပြောင်းလဲခြင်း၏ အနှစ်သာရဖြစ်သည်။ UICollectionView. ငွေပေးငွေယူတစ်ခုဖွင့်ပြီးပါက၊ သင်သည် အပလီကေးရှင်း၏မှတ်ဉာဏ်ခြေရာကို တိုးမြှင့်ရန် မလိုအပ်ဘဲ၊ လက်ရှိဒေတာကို မမ်မိုရီဖွဲ့စည်းပုံသို့ အလျင်အမြန်ထုတ်ကာ ဘာမှမကျန်တော့မည်ကို ကြောက်ရွံ့နေပါသည်။ ဤအင်္ဂါရပ်သည် LMDB ကို တူညီသော SQLite နှင့် ခွဲခြားပေးသည်၊ ထိုကဲ့သို့သော စုစုပေါင်းအထီးကျန်မှုကို ဝါကြွား၍မရပါ။ နောက်ပိုင်းတွင် ငွေပေးငွေယူ နှစ်ခုကို ဖွင့်ပြီး ၎င်းတို့ထဲမှ တစ်ခုအတွင်း မှတ်တမ်းတစ်ခုကို ဖျက်လိုက်ခြင်းဖြင့် တူညီသော မှတ်တမ်းကို ဒုတိယ ကျန်တစ်ခုအတွင်း မရနိုင်တော့ပါ။

အကြွေစေ့၏လှန်သောဘေးသည် virtual memory ၏သုံးစွဲမှုသိသိသာသာမြင့်မားနိုင်ချေရှိသည်။ ဒေတာဘေ့စ်၏ ကွဲပြားသောဗားရှင်းများကို ကြည့်ရှုနေသည့် ဒေတာဘေ့စ်၏ ကွဲပြားသောဗားရှင်းများကို ကြည့်ရှုသည့် ဖွင့်ဖတ်ထားသော အရောင်းအ၀ယ်လုပ်ငန်း 3 ခုဖြင့် တစ်ချိန်တည်းတွင် မွမ်းမံပြင်ဆင်ပါက ဒေတာဘေ့စ်ဖွဲ့စည်းပုံကို ဆလိုက်ဖြင့် ပြသထားသည်။ LMDB သည် အမှန်တကယ် ငွေပေးငွေယူများနှင့် ဆက်စပ်နေသည့် အမြစ်များမှ လက်လှမ်းမီနိုင်သည့် ဆုံမှတ်များကို ပြန်လည်အသုံးမပြုနိုင်သောကြောင့် သိုလှောင်မှုတွင် ရွေးချယ်စရာမရှိတော့ဘဲ မန်မိုရီတွင် နောက်ထပ်လေးခုမြောက် အမြစ်ကို ခွဲဝေပေးကာ ၎င်းအောက်တွင် ပြုပြင်ထားသော စာမျက်နှာများကို တစ်ဖန်ပြန်ပွားရန်။

ဤနေရာတွင် မန်မိုရီမြေပုံပြုလုပ်ထားသော ဖိုင်များပေါ်ရှိ ကဏ္ဍကို ပြန်လည်သိမ်းဆည်းရန် မလိုအပ်ပါ။ ၎င်းသည် အပလီကေးရှင်း၏ မှတ်ဉာဏ်ခြေရာကို အထောက်အကူမပြုသောကြောင့် virtual memory ၏ ထပ်လောင်းသုံးစွဲမှုသည် ကျွန်ုပ်တို့ကို များစွာအနှောက်အယှက်မဖြစ်သင့်ပေ။ သို့သော်လည်း၊ တစ်ချိန်တည်းတွင်၊ iOS သည် ၎င်းအား ခွဲဝေရာတွင် အလွန်တွန့်တိုတတ်ကြောင်း မှတ်သားထားပြီး၊ ကျွန်ုပ်တို့သည် ဆာဗာ သို့မဟုတ် ဒက်စ်တော့တွင် 1 terabyte LMDB ဒေသကို သခင်၏ပခုံးမှ ပံ့ပိုးပေးနိုင်ပြီး ဤအင်္ဂါရပ်နှင့်ပတ်သက်၍ လုံးဝမစဉ်းစားပါ။ ဖြစ်နိုင်လျှင် အရောင်းအဝယ်၏ သက်တမ်းကို တတ်နိုင်သမျှ တိုအောင် ထားရန် ကြိုးစားသင့်သည်။

4. သော့တန်ဖိုး API ၏ထိပ်တွင် ဒေတာအစီအစဉ်တစ်ခုကို ဒီဇိုင်းဆွဲခြင်း။

LMDB မှ ပံ့ပိုးပေးထားသော အခြေခံ abstractions များကို ကြည့်ခြင်းဖြင့် API ကို ခွဲခြမ်းစိပ်ဖြာကြည့်ကြပါစို့။ ပတ်ဝန်းကျင်နှင့် ဒေတာဘေ့စ်များ၊ သော့များနှင့် တန်ဖိုးများ၊

ကုဒ်စာရင်းများအကြောင်း မှတ်ချက်

LMDB အများသူငှာ API အတွင်းရှိ လုပ်ဆောင်ချက်များအားလုံးကို အမှားကုဒ်ပုံစံဖြင့် ၎င်းတို့၏အလုပ်၏ရလဒ်ကို ပြန်ပေးသည်၊ သို့သော် နောက်ဆက်တွဲစာရင်းများအားလုံးကို တိကျသေချာစေရန်အတွက် ၎င်း၏စစ်ဆေးမှုကို ချန်လှပ်ထားသည်။ လက်တွေ့တွင်၊ ကျွန်ုပ်တို့သည် repository နှင့် အပြန်အလှန်တုံ့ပြန်ရန်အတွက် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ကုဒ်ကို အသုံးပြုပါသည်။ အမဲချိတ် C++ ထုပ်ပိုးမှုများ lmdbxxC++ ခြွင်းချက်အဖြစ် errors များပေါ်လာသည်။

LMDB ကို iOS သို့မဟုတ် macOS ပရောဂျက်သို့ ချိတ်ဆက်ရန် အမြန်ဆုံးနည်းလမ်းအနေဖြင့် ကျွန်ုပ်၏ CocoaPod ကို ကမ်းလှမ်းပါသည်။ POSLMDB.

၄.၁။ အခြေခံ abstractions

ပတ်ဝန်းကျင်

ဖွဲ့စည်းပုံမှာ 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 အပလီကေးရှင်းတွင်၊ ကျွန်ုပ်တို့သည် ဘောင်နှစ်ခုသာရှိသော မူရင်းတန်ဖိုးများကို ပြောင်းလဲခဲ့သည်။

ပထမတစ်ခုသည် သိုလှောင်ဖိုင်ကို မြေပုံဆွဲထားသည့် virtual address space ၏ အရွယ်အစားဖြစ်သည်။ ကံမကောင်းစွာဖြင့်၊ စက်ပစ္စည်းတစ်ခုတည်းတွင်ပင်၊ သတ်မှတ်ထားသောတန်ဖိုးသည် လည်ပတ်မှုတစ်ခုမှတစ်ခုသို့ သိသိသာသာကွဲပြားနိုင်သည်။ iOS ၏ ဤအင်္ဂါရပ်ကို ထည့်သွင်းစဉ်းစားရန်၊ ကျွန်ုပ်တို့သည် သိုလှောင်မှု အများဆုံးပမာဏကို ဒိုင်းနမစ်နည်းဖြင့် ရွေးချယ်ပါသည်။ အချို့သောတန်ဖိုးမှ စတင်၍ လုပ်ဆောင်မှုအထိ ဆက်တိုက် တစ်ဝက်စီ ခွဲသွားပါသည်။ mdb_env_open မှလွဲ၍ အခြားရလဒ်တစ်ခု ပြန်လာမည်မဟုတ်ပါ။ ENOMEM. သီအိုရီအရ၊ ဆန့်ကျင်ဘက်နည်းလမ်းတစ်ခုရှိသည် - ဦးစွာပထမဦးစွာ Memory အနိမ့်ဆုံးကို အင်ဂျင်သို့ခွဲဝေပေးပြီး အမှားများကိုလက်ခံရရှိသောအခါ၊ MDB_MAP_FULLတိုးမြှင့်လိုက်ပါ။ သို့သော် ၎င်းသည် ပို၍ ဆူးဖြစ်သည်။ အကြောင်းရင်းမှာ လုပ်ဆောင်ချက်ကို အသုံးပြု၍ မှတ်ဉာဏ်ပြန်လည်ပုံဖော်ခြင်းအတွက် လုပ်ငန်းစဉ်ဖြစ်သည်။ mdb_env_set_map_size အစောပိုင်းအင်ဂျင်မှ လက်ခံရရှိထားသော အရာများ (ကာဆာများ၊ အရောင်းအ၀ယ်များ၊ သော့များနှင့် တန်ဖိုးများ) အားလုံးကို ပျက်ပြယ်စေသည်။ ကုဒ်ရှိ အဖြစ်အပျက်များ၏ အလှည့်အပြောင်းအတွက် စာရင်းကိုင်ခြင်းသည် ၎င်း၏ သိသာထင်ရှားသော ရှုပ်ထွေးမှုကို ဦးတည်စေသည်။ မည်သို့ပင်ဆိုစေကာမူ၊ virtual memory သည် သင့်အတွက် လွန်စွာနှစ်သက်ပါက၊ ၎င်းသည် ရှေ့ဆက်သွားမည့် လမ်းဆုံလမ်းခွကို ကြည့်ရန် အကြောင်းပြချက်တစ်ခုဖြစ်နိုင်သည်။ MDBXကြေညာထားသောအင်္ဂါရပ်များကြားတွင် "အလိုအလျောက်ပျံတက်သောဒေတာဘေ့စ်အရွယ်အစားချိန်ညှိမှု" ပါရှိသည်။

ဒုတိယဘောင်၊ ကျွန်ုပ်တို့နှင့်မကိုက်ညီသော မူရင်းတန်ဖိုးသည် thread လုံခြုံမှုရှိစေရန် စက်ပိုင်းဆိုင်ရာများကို ထိန်းညှိပေးပါသည်။ ကံမကောင်းစွာဖြင့်၊ အနည်းဆုံး iOS 10 တွင် thread local storage support တွင် ပြဿနာများရှိသည်။ ဤအကြောင်းကြောင့်၊ အထက်နမူနာတွင်၊ repository ကို အလံဖြင့် ဖွင့်ထားသည်။ MDB_NOTLS. ထို့အပြင် လိုအပ်သည်။ အမဲချိတ် C++ ထုပ်ပိုးခြင်း။ lmdbxxဤ attribute နှင့် variable များကိုဖြတ်ရန်။

ဒေတာဘေ့စ

ဒေတာဘေ့စ်သည် အထက်တွင်ပြောခဲ့သည့် 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 တွင် ငွေပေးငွေယူတစ်ခုသည် သီးခြားဒေတာဘေ့စ်တစ်ခုမဟုတ်ဘဲ သိုလှောင်မှုတစ်ခုဖြစ်သည်။ ဤသဘောတရားသည် မတူညီသောဒေတာဘေ့စ်များတွင်ရှိသော entities များပေါ်တွင် atomic operations များကိုလုပ်ဆောင်နိုင်စေပါသည်။ သီအိုရီအရ၊ ၎င်းသည် မတူညီသောဒေတာဘေ့စ်ပုံစံဖြင့် ဇယားများကို မော်ဒယ်ပြုလုပ်ရန် ဖြစ်နိုင်ခြေကို ပွင့်စေသည်၊ သို့သော် တစ်ချိန်က အောက်တွင် အသေးစိတ်ဖော်ပြထားသော အခြားနည်းလမ်းကို ကျွန်ုပ်သွားခဲ့သည်။

သော့များနှင့်တန်ဖိုးများ

ဖွဲ့စည်းပုံမှာ MDB_val သော့နှင့်တန်ဖိုး နှစ်ခုလုံး၏ သဘောတရားကို မော်ဒယ်များ။ repository သည် ၎င်းတို့၏ semantics နှင့် ပတ်သက်၍ မသိပါ။ သူမအတွက်၊ ကွဲပြားသောအရာသည် ပေးထားသောအရွယ်အစားရှိ bytes ၏ array တစ်ခုမျှသာဖြစ်သည်။ အများဆုံးသော့အရွယ်အစားမှာ 512 bytes ဖြစ်သည်။

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

စတိုးဆိုင်သည် သော့များကို ငယ်စဉ်လိုက် စီရန် နှိုင်းယှဉ်ကိရိယာကို အသုံးပြုသည်။ ၎င်းကို သင့်ကိုယ်ပိုင်ဖြင့် အစားထိုးခြင်းမပြုပါက၊ ၎င်းတို့ကို အဘိဓာန်အစီအစဥ်ဖြင့် byte-by-byte အမျိုးအစားခွဲပေးသည့် default ကို အသုံးပြုမည်ဖြစ်သည်။

အရောင်းအဝယ်

ငွေပေးငွေယူစက်ကို အသေးစိတ်ဖော်ပြထားပါသည်။ ယခင်အခန်းထို့ကြောင့် ဤနေရာတွင် ၎င်းတို့၏ အဓိက ဂုဏ်သတ္တိများကို စာကြောင်းတိုဖြင့် ပြန်ပြောပါမည်။

1. အခြေခံဂုဏ်သတ္တိအားလုံးအတွက် ပံ့ပိုးမှု အက်ဆစ်အဓိကစကားလုံးများ- အနုမြူစွမ်းအား၊ ညီညွတ်မှု၊ အထီးကျန်မှုနှင့် ယုံကြည်စိတ်ချရမှု။ macOS နှင့် iOS တွင် တာရှည်ခံမှုအရ MDBX တွင် ချွတ်ယွင်းချက်တစ်ခု ရှိနေသည်ကို သတိပြုပါ။ ၎င်းတို့၏ တွင် ပိုမိုဖတ်ရှုနိုင်ပါသည်။ README.
2. Multithreading အတွက်ချဉ်းကပ်ပုံကို "စာရေးသူ/စာဖတ်သူအများအပြား" အစီအစဉ်ဖြင့် ဖော်ပြပါသည်။ စာရေးဆရာတွေက တစ်ယောက်ကိုတစ်ယောက် ပိတ်ဆို့ထားပေမယ့် စာဖတ်သူတွေကိုတော့ မပိတ်ပင်ပါဘူး။ စာဖတ်သူများသည် စာရေးဆရာများ သို့မဟုတ် အချင်းချင်း မပိတ်ပင်ကြပါ။
3. အသိုက်အဝန်း အရောင်းအ၀ယ်များအတွက် ပံ့ပိုးမှု။
4. Multiversion ပံ့ပိုးမှု။

LMDB တွင် Multiversioning သည် အလွန်ကောင်းမွန်သောကြောင့် ၎င်းကို လက်တွေ့တွင် ပြသလိုပါသည်။ အောက်ဖော်ပြပါကုဒ်သည် ငွေပေးငွေယူတစ်ခုစီသည် ၎င်း၏ဖွင့်ချိန်တွင် သက်ဆိုင်ရာဒေတာဘေ့စ်ဗားရှင်းနှင့် အတိအကျအလုပ်လုပ်ကြောင်း၊ နောက်ဆက်တွဲပြောင်းလဲမှုများအားလုံးမှ လုံးဝခွဲထုတ်ထားကြောင်း ဖော်ပြသည်။ repository ကို အစပြုပြီး ၎င်းတွင် စစ်ဆေးမှုမှတ်တမ်းကို ထည့်ခြင်းသည် စိတ်ဝင်စားစရာမရှိသောကြောင့် ဤဓလေ့ထုံးတမ်းများကို spoiler အောက်တွင် ချန်ထားခဲ့သည်။

စာမေးပွဲဝင်ရောက်မှုကို ထည့်သွင်းခြင်း။

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 developer တစ်ဦး၏ဘဝအတွက် အလွန်ကောင်းမွန်သော အကျိုးကျေးဇူးများကို ယူဆောင်လာပါသည်။ ဤပိုင်ဆိုင်မှုကိုအသုံးပြုခြင်းဖြင့် သုံးစွဲသူအတွေ့အကြုံထည့်သွင်းစဉ်းစားမှုများအပေါ်အခြေခံ၍ မျက်နှာပြင်ပုံစံများအတွက် ဒေတာရင်းမြစ်အပ်ဒိတ်နှုန်းကို အလွယ်တကူနှင့် သဘာဝအတိုင်း ချိန်ညှိနိုင်ပါသည်။ ဥပမာအားဖြင့်၊ စနစ်မီဒီယာပြခန်းမှ အကြောင်းအရာများကို အလိုအလျောက်တင်ခြင်းအဖြစ် Mail.ru Cloud အပလီကေးရှင်း၏ အင်္ဂါရပ်ကို ယူကြပါစို့။ ကောင်းမွန်သောချိတ်ဆက်မှုဖြင့်၊ client သည် တစ်စက္ကန့်လျှင် ဓာတ်ပုံများစွာကို ဆာဗာသို့ထည့်နိုင်သည်။ ဒေါင်းလုဒ်တစ်ခုစီပြီးရင် update လုပ်ပါ။ UICollectionView အသုံးပြုသူ၏ cloud တွင် မီဒီယာအကြောင်းအရာဖြင့်၊ သင်သည် 60 fps ခန့်ကို မေ့လျော့နိုင်ပြီး ဤလုပ်ငန်းစဉ်အတွင်း ချောမွေ့စွာ လှိမ့်နိုင်သည်။ မကြာခဏ မျက်နှာပြင် အပ်ဒိတ်များကို ကာကွယ်ရန်၊ အခြေခံတွင် ဒေတာပြောင်းလဲမှုနှုန်းကို တစ်နည်းနည်းဖြင့် ကန့်သတ်ရန် လိုအပ်သည်။ UICollectionViewDataSource.

ဒေတာဘေ့စ်သည် မျိုးစုံကွဲပြားခြင်းကို ပံ့ပိုးမပေးဘဲ လက်ရှိအခြေအနေနှင့်သာ အလုပ်လုပ်ရန် ခွင့်ပြုပါက၊ အချိန်တည်ငြိမ်သောဒေတာလျှပ်တစ်ပြက်တစ်ခုကို ဖန်တီးရန်၊ ၎င်းကို မမ်မိုရီအတွင်းဒေတာတည်ဆောက်ပုံ သို့မဟုတ် ယာယီဇယားတစ်ခုသို့ ကူးယူရန် လိုအပ်သည်။ ဒီနည်းလမ်းတွေက အရမ်းစျေးကြီးတယ်။ မမ်မိုရီသိုလှောင်မှုကိစ္စတွင်၊ တည်ဆောက်ထားသော အရာဝတ္ထုများကို သိမ်းဆည်းခြင်းကြောင့် ဖြစ်ပေါ်လာသော မမ်မိုရီကုန်ကျစရိတ်နှင့် ORM အသွင်ပြောင်းမှုများနှင့် ဆက်စပ်နေသော အချိန်ကုန်ကျစရိတ် နှစ်ခုလုံးကို ရရှိပါသည်။ ယာယီစားပွဲအတွက်၊ ဤအရာသည် အသေးအဖွဲမဟုတ်သော ကိစ္စများတွင်သာ အဓိပ္ပါယ်ရှိစေသည့် ပိုစျေးကြီးသော ပျော်ရွှင်မှုတစ်ခုဖြစ်သည်။

Multiversioning LMDB သည် အလွန်ပြေပြစ်သောနည်းဖြင့် တည်ငြိမ်သောဒေတာရင်းမြစ်ကို ထိန်းသိမ်းခြင်းပြဿနာကို ဖြေရှင်းပေးသည်။ ငွေပေးငွေယူတစ်ခုဖွင့်ရုံနဲ့ လုံလောက်ပါပြီ - ကျွန်ုပ်တို့ ၎င်းကို ပြီးမြောက်သည်အထိ ဒေတာအစုံကို ပြုပြင်ရန် အာမခံပါသည်။ ၎င်း၏ အပ်ဒိတ်နှုန်း၏ ယုတ္တိယုတ္တိသည် ယခုအခါတွင် သိသာထင်ရှားသော အရင်းအမြစ်များထက် ကျော်လွန်ခြင်းမရှိသော တင်ပြမှုအလွှာ၏ လက်ထဲတွင် လုံးလုံးလျားလျား ရှိနေပါသည်။

ကာဆာများ

Cursors များသည် B-tree ကိုဖြတ်ကာ သော့တန်ဖိုးအတွဲများပေါ်တွင် စနစ်တကျ ထပ်လောင်းခြင်းအတွက် ယန္တရားတစ်ခု ပေးပါသည်။ ၎င်းတို့မပါဘဲ၊ ယခုကျွန်ုပ်တို့ပြောင်းထားသောဒေတာဘေ့စ်ရှိဇယားများကိုထိရောက်စွာပုံစံပြရန်မဖြစ်နိုင်ပါ။

၄.၂။ Table Modeling

အဓိက မှာကြားခြင်း ပိုင်ဆိုင်မှုသည် အခြေခံ abstraction များ၏ ထိပ်ရှိ ဇယားကဲ့သို့သော ထိပ်တန်းအဆင့် abstraction တစ်ခုကို တည်ဆောက်နိုင်စေပါသည်။ အသုံးပြုသူ၏ ဖိုင်များနှင့် ဖိုင်တွဲများအားလုံးကို ကက်ရှ်လုပ်ထားသည့် cloud client ၏ ပင်မဇယားနမူနာတွင် ဤလုပ်ငန်းစဉ်ကို သုံးသပ်ကြည့်ကြပါစို့။

ဇယားဇယား

ဖိုင်တွဲသစ်ပင်ပါသည့် ဇယားတစ်ခု၏ ဖွဲ့စည်းပုံကို ထက်မြက်စေသည့် ဘုံအခြေအနေများထဲမှတစ်ခုမှာ ပေးထားသောလမ်းညွှန်တစ်ခုအတွင်း၌ရှိသော အစိတ်အပိုင်းအားလုံးကို ရွေးချယ်ရန်ဖြစ်သည်။ ဤကဲ့သို့သော ထိရောက်သောမေးမြန်းမှုများအတွက် ကောင်းသောဒေတာအဖွဲ့အစည်းပုံစံတစ်ခုသည် ကပ်လျက်စာရင်း. ၎င်းကို သော့တန်ဖိုးသိုလှောင်မှု၏ထိပ်တွင် အကောင်အထည်ဖော်ရန်၊ ၎င်းကို ပင်မလမ်းညွှန်နှင့်သက်ဆိုင်သည့်အပေါ်အခြေခံ၍ ၎င်းတို့အုပ်စုဖွဲ့ထားသည့်ပုံစံဖြင့် ဖိုင်များနှင့် ဖိုင်တွဲများ၏သော့များကို စီရန် လိုအပ်သည်။ ထို့အပြင်၊ Windows အသုံးပြုသူနှင့်ရင်းနှီးသောပုံစံဖြင့် directory ၏အကြောင်းအရာများကိုပြသရန်အတွက် (ဖိုင်တွဲများကို ဦးစွာပထမ၊ ထို့နောက်ဖိုင်များ၊ နှစ်ခုလုံးကိုအက္ခရာစဉ်အလိုက်စီထားသည်) သော့တွင်သက်ဆိုင်ရာအပိုအကွက်များကိုထည့်သွင်းရန်လိုအပ်သည်။

အောက်ဖော်ပြပါပုံသည် အလုပ်အပေါ်အခြေခံ၍ bytes ၏ array တစ်ခုအနေဖြင့် သော့များ၏ကိုယ်စားပြုပုံသည် မည်သို့ပုံသဏ္ဍန်ရှိသည်ကိုပြသထားသည်။ ပထမဦးစွာ၊ ပင်မလမ်းညွှန်အမှတ်အသား (အနီရောင်) ပါသည့် ဘိုက်များကို ထားရှိပြီးနောက် အမျိုးအစား (အစိမ်း) နှင့် အမည် (အပြာ) တို့၏ အမြီးတွင် ရှိနှင့်ပြီးသားဖြစ်သည်။ ပုံသေ LMDB နှိုင်းယှဉ်လေ့လာသူကို အဘိဓာန်အစီအစဥ်ဖြင့် စီခွဲထားခြင်းဖြစ်ပြီး ၎င်းတို့ကို စီစဥ်ထားသည်။ လိုအပ်သောနည်းလမ်း။ တူညီသောအနီရောင်ရှေ့ဆက်ဖြင့် ဆင့်ကဲဖြတ်သွားသောသော့များသည် အသုံးပြုသူအင်တာဖေ့စ် (ညာဘက်) တွင် ၎င်းတို့ကိုပြသသင့်သည့်အစီအစဥ်အဖြစ် ၎င်းတို့နှင့်ဆက်စပ်နေသောတန်ဖိုးများကို ကျွန်ုပ်တို့အား ပေးဆောင်သည်။

သော့များနှင့်တန်ဖိုးများကို နံပါတ်စဉ်သတ်မှတ်ခြင်း။

ကမ္ဘာတစ်ဝှမ်းရှိ အရာဝတ္ထုများကို အမှတ်စဉ်ပြုလုပ်ရန် နည်းလမ်းများစွာရှိသည်။ ကျွန်ုပ်တို့တွင် မြန်နှုန်းမှလွဲ၍ အခြားလိုအပ်ချက်မရှိသောကြောင့်၊ ကျွန်ုပ်တို့ကိုယ်တိုင်အတွက် ဖြစ်နိုင်သမျှအမြန်ဆုံးတစ်ခုကို C ဘာသာစကားတည်ဆောက်ပုံမှ သိမ်းပိုက်ထားသော မမ်မိုရီအမှိုက်ပုံတစ်ပုံအား ရွေးချယ်ခဲ့သည်။ ထို့ကြောင့်၊ လမ်းညွှန်ဒြပ်စင်တစ်ခု၏သော့ကို အောက်ပါဖွဲ့စည်းပုံဖြင့် စံနမူနာယူနိုင်ပါသည်။ NodeKey.

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

ကယ်တင်ရန် NodeKey storage ထဲမှာ အရာဝတ္ထုတွေ လိုအပ်တယ်။ MDB_val ဖွဲ့စည်းပုံ၏အစ၏လိပ်စာတွင် အချက်အလက်ကို pointer အား နေရာချပြီး ၎င်းတို့၏အရွယ်အစားကို function ဖြင့် တွက်ချက်ပါ။ sizeof.

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

ဒေတာဘေ့စ်ရွေးချယ်မှုစံနှုန်းများဆိုင်ရာ ပထမအခန်းတွင်၊ CRUD လုပ်ဆောင်ချက်များ၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် အရေးကြီးသောရွေးချယ်မှုဆိုင်ရာအချက်တစ်ခုအနေဖြင့် ဒိုင်နမစ်ခွဲဝေချထားမှုများကို လျှော့ချရန် ဖော်ပြထားပါသည်။ လုပ်ဆောင်ချက်ကုဒ် serialize LMDB တွင် မှတ်တမ်းအသစ်များကို ဒေတာဘေ့စ်ထဲသို့ ထည့်သွင်းသည့်အခါ ၎င်းတို့ကို လုံးလုံးလျားလျား ရှောင်ရှားနိုင်ပုံကို ပြသထားသည်။ ဆာဗာမှ ဝင်လာသော ဘိုက်များ၏ အခင်းအကျင်းကို ပထမဦးစွာ stack တည်ဆောက်ပုံများအဖြစ် ပြောင်းလဲပြီးနောက် ၎င်းတို့ကို သိုလှောင်ခန်းထဲသို့ အသေးအဖွဲလေး စွန့်ပစ်သွားပါသည်။ LMDB တွင် တက်ကြွသော ခွဲဝေချထားမှုများလည်း မရှိသောကြောင့်၊ သင်သည် iOS ၏ စံနှုန်းများဖြင့် အံ့မခန်း အခြေအနေကို ရနိုင်သည် - ကွန်ရက်မှ ဒစ်ခ်အထိ ဒေတာနှင့် အလုပ်လုပ်ရန် stack memory ကိုသာ အသုံးပြုပါ။

ဒွိနှိုင်းစာဖြင့် သော့များမှာယူခြင်း။

သော့အမှာစာ ဆက်စပ်မှုကို နှိုင်းယှဉ်ခြင်းဟုခေါ်သော အထူးလုပ်ဆောင်မှုတစ်ခုက ပေးဆောင်သည်။ အင်ဂျင်သည် ၎င်းတို့ပါရှိသော bytes များ၏ semantics အကြောင်း ဘာမျှမသိသောကြောင့်၊ မူရင်း နှိုင်းယှဉ်သူသည် ၎င်းတို့၏ byte-by-byte နှိုင်းယှဉ်မှုကို အသုံးပြုကာ သော့များကို အဘိဓာန်အစီအစဥ်အတိုင်း စီစဉ်ရန်မှတပါး ရွေးချယ်စရာမရှိပေ။ အဆောက်အဦများကို စီစဉ်ရန် ၎င်းကိုအသုံးပြုခြင်းသည် ထွင်းထုထားသော ပုဆိန်ဖြင့် မုတ်ဆိတ်ရိတ်ခြင်းနှင့်တူသည်။ သို့သော် ရိုးရှင်းသောကိစ္စများတွင် ဤနည်းလမ်းကို ကျွန်ုပ်လက်ခံနိုင်ဖွယ်ရှိသည်။ အခြားရွေးချယ်စရာကို အောက်တွင်ဖော်ပြထားသော်လည်း ဤနေရာတွင် လမ်းတစ်လျှောက်တွင် ပြန့်ကျဲနေသော ဂျုတ်အချို့ကို မှတ်သားထားပါမည်။

ပထမဆုံး သတိထားရမည့်အချက်မှာ မူလဒေတာအမျိုးအစားများ၏ မှတ်ဉာဏ်ကို ကိုယ်စားပြုခြင်းပင်ဖြစ်သည်။ ထို့ကြောင့် Apple စက်များအားလုံးတွင် ကိန်းပြည့်ကိန်းရှင်များကို ဖော်မတ်ဖြင့် သိမ်းဆည်းထားသည်။ Little Endian ပါ. ဆိုလိုသည်မှာ သိသာထင်ရှားသော အနည်းဆုံး byte သည် ဘယ်ဘက်တွင် ရှိနေမည်ဖြစ်ပြီး ၎င်းတို့၏ byte-by-byte နှိုင်းယှဉ်မှုကို အသုံးပြု၍ ကိန်းပြည့်များကို စီရန် လုပ်နိုင်မည်မဟုတ်ပေ။ ဥပမာအားဖြင့်၊ 0 မှ 511 မှ နံပါတ်များကို တွဲလုပ်ရန် ကြိုးစားခြင်းသည် အောက်ပါရလဒ်ကို ရရှိစေမည်ဖြစ်သည်။

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

ဤပြဿနာကိုဖြေရှင်းရန်၊ ကိန်းပြည့်များကို byte နှိုင်းယှဉ်ကိရိယာအတွက် သင့်လျော်သောဖော်မတ်တွင် သော့ထဲတွင် သိမ်းဆည်းထားရပါမည်။ မိသားစုမှ လုပ်ဆောင်ချက်များသည် လိုအပ်သော အသွင်ပြောင်းမှုကို ဆောင်ရွက်နိုင်ရန် ကူညီပေးပါမည်။ hton* (အထူးသဖြင့် htons ဥပမာအားဖြင့် double-byte နံပါတ်များအတွက်။

ပရိုဂရမ်းမင်းတွင် စာကြောင်းများကို ကိုယ်စားပြုသည့်ဖော်မတ်သည် သင်သိသည့်အတိုင်း တစ်ခုလုံးဖြစ်သည်။ ပုံပြင်. strings များ၏ semantics နှင့် memory တွင် ၎င်းတို့ကို ကိုယ်စားပြုရန် အသုံးပြုသည့် encoding သည် စာလုံးတစ်ခုလျှင် byte တစ်ခုထက်ပို၍ ရှိနေနိုင်သည်ဆိုပါက၊ default comparator ကိုအသုံးပြုခြင်းအယူအဆကို ချက်ချင်းစွန့်လွှတ်ခြင်းသည် ပိုကောင်းပါသည်။

ဒုတိယအချက်ကတော့ သတိထားရမယ့်အချက်ပါ။ ချိန်ညှိမှုအခြေခံမူများ struct field compiler ။ ၎င်းတို့ကြောင့်၊ အမှိုက်တန်ဖိုးများပါရှိသော ဘိုက်များကို အကွက်များကြားတွင် မှတ်ဉာဏ်တွင် ဖွဲ့နိုင်ပြီး ဘိုက်အမျိုးအစားခွဲခြင်းကို ချိုးဖျက်သွားမည်ဖြစ်သည်။ အမှိုက်များကို ဖယ်ရှားရန်၊ ကွက်လပ်များကို တင်းကြပ်စွာ သတ်မှတ်ထားသော အစီအစဥ်အတိုင်း ကြေညာရမည်ဖြစ်ပြီး၊ ချိန်ညှိမှု စည်းမျဉ်းများကို မှတ်သားထားရန်၊ သို့မဟုတ် ဖွဲ့စည်းတည်ဆောက်ပုံကြေညာခြင်းတွင် အရည်အချင်းကို အသုံးပြုပါ။ packed.

ပြင်ပ နှိုင်းယှဥ်စနစ်မှ အဓိက မှာယူခြင်း။

အဓိက နှိုင်းယှဥ်ဂျစ်သည် ဒွိနှိုင်းယှဥ်အတွက် ရှုပ်ထွေးလွန်းနေပါသည်။ အကြောင်းရင်းများစွာထဲမှတစ်ခုမှာ အဆောက်အဦအတွင်း နည်းပညာနယ်ပယ်များ ရှိနေခြင်းပင်ဖြစ်သည်။ လမ်းညွှန်ဒြပ်စင်တစ်ခုအတွက် ကျွန်ုပ်တို့နှင့်ရင်းနှီးပြီးသားသော့တစ်ခု၏နမူနာတွင် ၎င်းတို့၏ဖြစ်ပျက်မှုကို ဖော်ပြပါမည်။

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

၎င်း၏ရိုးရှင်းမှုအတွက်၊ ကိစ္စအများစုတွင် ၎င်းသည် မှတ်ဉာဏ်အလွန်အကျွံသုံးစွဲသည်။ ပျမ်းမျှဖိုင်နှင့် ဖိုင်တွဲအမည်များသည် စာလုံးရေ 256-20 ထက်မပိုသော်လည်း ခေါင်းစဉ်ကြားခံသည် 30 bytes ဖြစ်သည်။

စံချိန်တစ်ခု၏အရွယ်အစားကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန် စံနည်းစနစ်တစ်ခုသည် အမှန်တကယ်အရွယ်အစားနှင့်ကိုက်ညီစေရန် ၎င်းကို "ဖြတ်" ရန်ဖြစ်သည်။ ၎င်း၏ အနှစ်သာရမှာ တည်ဆောက်ပုံအဆုံးတွင် ကွဲပြားနိုင်သော အလျားအကွက်များအားလုံး၏ အကြောင်းအရာများကို ကြားခံတစ်ခုတွင် သိမ်းဆည်းထားပြီး ၎င်းတို့၏ အလျားများကို သီးခြားကိန်းရှင်များတွင် သိမ်းဆည်းထားသည်။ ဤချဉ်းကပ်မှုနှင့်အညီ အဓိကအချက်မှာ၊ 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 သည် ဒေတာဘေ့စ်တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင်သော့နှိုင်းယှဉ်မှုလုပ်ဆောင်ချက်ကို ခွင့်ပြုထားသည်။ ၎င်းသည် function ကိုအသုံးပြုပြီးလုပ်ဆောင်သည်။ mdb_set_compare မဖွင့်ခင် တိတိကျကျ သိသာထင်ရှားသောအကြောင်းပြချက်များအတွက်၊ ဒေတာဘေ့စ်တစ်ခုသည် ၎င်း၏သက်တမ်းတစ်လျှောက်လုံး ပြောင်းလဲ၍မရပါ။ input တွင်၊ နှိုင်းယှဉ်သူသည် binary ဖော်မတ်ဖြင့် သော့နှစ်ခုကို လက်ခံရရှိပြီး output တွင် ၎င်းသည် နှိုင်းယှဉ်မှု၏ရလဒ်ကို ပြန်ပေးသည်- (-1) ထက်နည်းသော၊ (1) ထက်ကြီးသော သို့မဟုတ် ညီမျှခြင်း (0)။ Pseudocode for 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 // ...
}​

ဒေတာဘေ့စ်ရှိ သော့များအားလုံးသည် အမျိုးအစားတူသရွေ့ ၎င်းတို့၏ byte ကိုယ်စားပြုမှုကို သော့၏ အသုံးချဖွဲ့စည်းပုံအမျိုးအစားသို့ ချွင်းချက်မရှိ ချွင်းချက်မရှိ ချွင်းချက်မရှိ ချရန်မှာ တရားဝင်ဖြစ်သည်။ ဤနေရာတွင် ကွဲပြားချက်တစ်ခုရှိသည်၊ သို့သော် ၎င်းကို "Reading Records" အပိုင်းခွဲတွင် အနည်းငယ်လျှော့ပြီး ဆွေးနွေးပါမည်။

တန်ဖိုးအမှတ်စဉ်

LMDB သည် သိမ်းဆည်းထားသော မှတ်တမ်းများ၏ သော့များဖြင့် အလွန်အမင်း ပြင်းပြင်းထန်ထန် လုပ်ဆောင်သည်။ ၎င်းတို့ကို မည်သည့် အသုံးချပလီကေးရှင်း လည်ပတ်မှုဘောင်အတွင်းမှ တစ်ခုနှင့်တစ်ခု နှိုင်းယှဉ်ထားပြီး ဖြေရှင်းချက်တစ်ခုလုံး၏ စွမ်းဆောင်ရည်သည် နှိုင်းယှဉ်သူ၏ အမြန်နှုန်းပေါ်တွင် မူတည်သည်။ စံပြကမ္ဘာတစ်ခုတွင်၊ ပုံသေ binary နှိုင်းယှဉ်သူသည် သော့များကို နှိုင်းယှဉ်ရန် လုံလောက်သင့်သည်၊ သို့သော် အကယ်၍ သင်သည် သင့်ကိုယ်ပိုင်ကို အမှန်တကယ်အသုံးပြုရမည်ဆိုလျှင် ၎င်းရှိသော့များကို ဖယ်ထုတ်ရန်အတွက် လုပ်ထုံးလုပ်နည်းသည် မြန်နိုင်သမျှမြန်သင့်သည်။

ဒေတာဘေ့စ်သည် မှတ်တမ်း၏တန်ဖိုး (တန်ဖိုး) ကို အထူးစိတ်မ၀င်စားပါ။ ၎င်း၏ byte ကိုယ်စားပြုမှုမှ အရာဝတ္ထုတစ်ခုသို့ ပြောင်းခြင်းသည် ဥပမာအားဖြင့် မျက်နှာပြင်ပေါ်တွင် ၎င်းကိုပြသရန် အပလီကေးရှင်းကုဒ်မှ လိုအပ်ပြီးမှသာ ဖြစ်ပေါ်ပါသည်။ ထိုသို့ဖြစ်ခဲသောကြောင့်၊ ဤလုပ်ထုံးလုပ်နည်း၏အမြန်နှုန်းအတွက် လိုအပ်ချက်များသည် အလွန်အရေးပါလှသည်မဟုတ်ပေ၊ ၎င်း၏အကောင်အထည်ဖော်မှုတွင် ကျွန်ုပ်တို့သည် ပိုမိုအဆင်ပြေစေရန်အတွက် ပိုမိုလွတ်လပ်စွာ အာရုံစိုက်နိုင်ကြပါသည်။ ဥပမာအားဖြင့်၊ ဒေါင်းလုဒ်မရသေးသောဖိုင်များအကြောင်း metadata များကို အမှတ်စဉ်ပြုလုပ်ရန်အတွက် ကျွန်ုပ်တို့အသုံးပြုသည် NSKeyedArchiver.

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

ဒါပေမယ့် စွမ်းဆောင်ရည်က အရေးကြီးတဲ့အချိန်တွေရှိတယ်။ ဥပမာအားဖြင့်၊ အသုံးပြုသူ cloud ၏ ဖိုင်တည်ဆောက်ပုံနှင့်ပတ်သက်သော မက်တာအချက်အလက်ကို သိမ်းဆည်းသောအခါ၊ ကျွန်ုပ်တို့သည် တူညီသော အရာဝတ္တုမှတ်ဉာဏ်ကို စွန့်ပစ်ခြင်းကို အသုံးပြုပါသည်။ ၎င်းတို့၏ အမှတ်စဉ်အလိုက် ကိုယ်စားပြုမှုကို ထုတ်ပေးခြင်းလုပ်ငန်း၏ အလေးပေးဖော်ပြချက်မှာ လမ်းညွှန်တစ်ခု၏ အစိတ်အပိုင်းများကို အတန်းလိုက် အဆင့်လိုက်ဖြင့် စံနမူနာယူထားသည့်အချက်ဖြစ်သည်။

၎င်းကို C ဘာသာစကားဖြင့် အကောင်အထည်ဖော်ရန်အတွက်၊ အမွေဆက်ခံသူ၏ သီးခြားနယ်ပယ်များကို သီးခြားဖွဲ့စည်းပုံများအဖြစ် ခွဲထုတ်ကာ အခြေခံတစ်ခုနှင့် ၎င်းတို့၏ ချိတ်ဆက်မှုကို ပြည်ထောင်စု အမျိုးအစား၏ နယ်ပယ်တစ်ခုမှတစ်ဆင့် သတ်မှတ်ထားသည်။ သမဂ္ဂ၏ တကယ့်အကြောင်းအရာကို အမျိုးအစားနည်းပညာဆိုင်ရာ ဂုဏ်ရည်တော်မှတစ်ဆင့် သတ်မှတ်ထားသည်။

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

မှတ်တမ်းများကို ထည့်သွင်းခြင်းနှင့် အပ်ဒိတ်လုပ်ခြင်း။

နံပါတ်စဉ်အလိုက် သော့နှင့်တန်ဖိုးကို စတိုးဆိုင်တွင် ထည့်နိုင်သည်။ ဤအတွက်၊ function ကိုအသုံးပြုသည်။ 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 ညွှန်ပြသူသည် အရာဝတ္တု၏ byte ကိုယ်စားပြုမှုကို ဒေတာဘေ့စ်တွင်သိမ်းဆည်းထားသည့် virtual memory လိပ်စာကို အတိအကျကြည့်ရှုသည်။ အမှန်တော့၊ ကျွန်ုပ်တို့သည် ဒေတာဖတ်ရှုခြင်း၏ အလွန်မြင့်မားသော မြန်နှုန်းကို ပံ့ပိုးပေးသည့် အခမဲ့နီးပါး ORM တစ်မျိုးကို ရရှိပါသည်။ ချဉ်းကပ်မှု၏ အလှတရားများနှင့်အတူ၊ ၎င်းနှင့်ဆက်စပ်နေသော အင်္ဂါရပ်များစွာကို မှတ်သားထားရန် လိုအပ်ပါသည်။

1. ဖတ်ရန်သာ အရောင်းအ၀ယ်ပြုလုပ်ခြင်းအတွက်၊ ငွေပေးငွေယူပိတ်ချိန်အထိသာ တန်ဖိုးတည်ဆောက်ပုံသို့ ညွှန်ပြချက်သည် မှန်ကန်ကြောင်း အာမခံပါသည်။ အစောပိုင်းတွင်ဖော်ပြခဲ့သည့်အတိုင်း၊ ကူးယူရေးသားခြင်းနိယာမကြောင့် အရာဝတ္ထုတည်ရှိသည့် B-tree ၏စာမျက်နှာများသည် ၎င်းတို့ကို အနည်းဆုံး ငွေပေးငွေယူတစ်ခုမှ ရည်ညွှန်းသရွေ့ မပြောင်းလဲပါ။ တစ်ချိန်တည်းမှာပင်၊ ၎င်းတို့နှင့် ဆက်စပ်နေသည့် နောက်ဆုံး ငွေပေးငွေယူ ပြီးသည်နှင့်၊ စာမျက်နှာများကို ဒေတာအသစ်အတွက် ပြန်သုံးနိုင်သည်။ ၎င်းတို့ကို ဖန်တီးထားသော အရောင်းအ၀ယ်လုပ်ငန်းမှ ရှင်သန်ရန် အရာဝတ္ထုများ လိုအပ်ပါက၊ ၎င်းတို့ကို ကူးယူထားရန် လိုအပ်ပါသည်။
2. ဖတ်ပြီးသော ငွေပေးငွေယူအတွက်၊ ရလဒ်ဖွဲ့စည်းပုံ-တန်ဖိုးသို့ ညွှန်ပြသည့်အချက်သည် ပထမမွမ်းမံခြင်းလုပ်ငန်းစဉ် (ဒေတာရေးသားခြင်း သို့မဟုတ် ဖျက်ခြင်း) မတိုင်မီအထိသာ အကျုံးဝင်မည်ဖြစ်သည်။
3. ဒါတောင် ဖွဲ့စည်းပုံ NodeValue ပြည့်စုံမှုမရှိသော်လည်း ဖြတ်တောက်ထားသည် (အပိုင်းခွဲ "ပြင်ပနှိုင်းယှဉ်သူမှ သော့များကို မှာယူခြင်း" ကိုကြည့်ပါ)၊ ညွှန်ပြချက်မှတစ်ဆင့်၊ သင်သည် ၎င်း၏အကွက်များကို အလွယ်တကူ ဝင်ရောက်နိုင်သည်။ အဓိကကတော့ အဲဒါကို နှောင့်ယှက်ဖို့ မဟုတ်ဘူး။
4. မည်သည့်အခြေအနေမျိုးတွင်မဆို လက်ခံရရှိသောညွှန်ပြချက်ဖြင့် ဖွဲ့စည်းတည်ဆောက်ပုံကို မွမ်းမံပြင်ဆင်နိုင်သည်။ ပြောင်းလဲမှုအားလုံးကို နည်းလမ်းဖြင့်သာ ပြုလုပ်ရပါမည်။ mdb_put. သို့သော်၊ ဤဖွဲ့စည်းပုံတည်ရှိရာ မန်မိုရီဧရိယာကို readonly mode တွင် ပုံဖော်ထားသောကြောင့် ၎င်းကိုပြုလုပ်လိုသည့်ဆန္ဒအားလုံးဖြင့် ၎င်းသည် အလုပ်မဖြစ်ပါ။
5. ဥပမာအားဖြင့်၊ လုပ်ဆောင်ချက်ကို အသုံးပြု၍ အများဆုံးသိုလှောင်မှုအရွယ်အစားကို တိုးမြှင့်ရန်အတွက် လုပ်ငန်းစဉ်တစ်ခု၏ လိပ်စာနေရာသို့ ဖိုင်တစ်ခုကို ပြန်လည်ပုံဖော်ပါ။ mdb_env_set_map_size ယေဘုယျအားဖြင့် ငွေပေးငွေယူများနှင့် ဆက်စပ်ပစ္စည်းများအားလုံးကို လုံးဝတရားဝင်စေပြီး အထူးသဖြင့် အရာဝတ္ထုများကို ဖတ်ရန် ညွှန်ပြသည်။

နောက်ဆုံးတွင်၊ နောက်ထပ်အင်္ဂါရပ်တစ်ခုသည် အလွန်ဆိုးသွမ်းလွန်းသဖြင့် ၎င်း၏အနှစ်သာရကို ထုတ်ဖော်ပြောဆိုခြင်းသည် နောက်ထပ်အချက်တစ်ခုတည်းနှင့် မကိုက်ညီပါ။ B-tree ၏အခန်းတွင်၊ မှတ်ဉာဏ်တွင်၎င်း၏စာမျက်နှာများ၏ဖွဲ့စည်းပုံပုံစံကိုငါပေးခဲ့သည်။ နံပါတ်စဉ်တပ်ထားသောဒေတာပါရှိသော ကြားခံ၏အစ၏လိပ်စာသည် လုံးဝထင်သလိုဖြစ်နိုင်သည်ဟူသောအချက်မှ ထွက်ပေါ်လာခြင်းဖြစ်သည်။ ထို့အတွက်ကြောင့် ၎င်းတို့အား ညွှန်ပြသည့် ဖွဲ့စည်းပုံတွင် ရရှိခဲ့သည်။ MDB_val ဖွဲ့စည်းပုံတစ်ခုသို့ ညွှန်ပြချက်တစ်ခုသို့ ကာစ်သည် ယေဘုယျအားဖြင့် ဟန်ချက်မညီပါ။ တစ်ချိန်တည်းမှာပင်၊ အချို့သောချစ်ပ်များ၏ဗိသုကာလက်ရာများသည် (iOS တွင်၊ ၎င်းသည် armv7 ဖြစ်သည်) သည် မည်သည့်ဒေတာ၏လိပ်စာသည် စက်စကားလုံးအရွယ်အစား၏ အကြိမ်ရေဖြစ်ရန် လိုအပ်သည် (armv7 အတွက်၊ ဒါက 32 bits)။ တနည်းအားဖြင့် အော်ပရေးရှင်းတစ်ခုလိုပါပဲ။ *(int *foo)0x800002 ၎င်းတို့အပေါ် လွတ်မြောက်ရန် ညီမျှပြီး စီရင်ချက်ဖြင့် သေဒဏ်ပေးသည်။ EXC_ARM_DA_ALIGN. ဒီလိုဝမ်းနည်းစရာကောင်းတဲ့ ကံကြမ္မာကို ရှောင်ဖို့ နည်းလမ်းနှစ်သွယ်ရှိပါတယ်။

ပထမတစ်ခုကတော့ အချက်အလက်တွေကို သိထားတဲ့-aligned structure ထဲကို ကူးယူဖို့ပါပဲ။ ဥပမာအားဖြင့်၊ စိတ်ကြိုက်နှိုင်းယှဉ်မှုတစ်ခုတွင်၊ ၎င်းကိုအောက်ပါအတိုင်းထင်ဟပ်စေမည်ဖြစ်သည်။

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 တွင် အလားတူအကျိုးသက်ရောက်မှုရှိနိုင်သည်။ အောင်မြင်ရန် ထုပ်ပိုးထားသော attribute ကိုအသုံးပြုပါ။ ၎င်းသည် ဖွဲ့စည်းပုံဖြင့် သိမ်းပိုက်ထားသော အာကာသကို ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ရာတွင်လည်း အထောက်အကူဖြစ်စေသည်ဟု ယူဆပါက၊ ဤနည်းလမ်းသည် ကျွန်ုပ်အတွက် ပိုကောင်းသည်ဟု ထင်ရသော်လည်း၊ приводит ဒေတာဝင်ရောက်လည်ပတ်မှုကုန်ကျစရိတ်ကို တိုးမြှင့်ရန်။

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

အပိုင်းအခြားမေးခွန်းများ

မှတ်တမ်းအုပ်စုတစ်စုကို ထပ်တလဲလဲပြုလုပ်ရန်၊ LMDB သည် cursor abstraction ကိုပေးသည်။ ကျွန်ုပ်တို့နှင့်ရင်းနှီးပြီးသား အသုံးပြုသူ cloud မက်တာဒေတာပါသည့် ဇယားတစ်ခု၏နမူနာကို အသုံးပြု၍ ၎င်းနှင့် မည်သို့လုပ်ဆောင်ရမည်ကို ကြည့်ကြပါစို့။

လမ်းညွှန်တစ်ခုရှိ ဖိုင်များစာရင်းကို ပြသခြင်း၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့်၊ ၎င်း၏ ကလေးဖိုင်များနှင့် ဖိုင်တွဲများ ဆက်စပ်နေသည့် သော့အားလုံးကို သင်ရှာဖွေရန် လိုအပ်သည်။ ယခင်အပိုင်းခွဲများတွင် ကျွန်ုပ်တို့သည် သော့များကို စီထားသည်။ NodeKey ထို့ကြောင့် ၎င်းတို့ကို ၎င်းတို့၏ ပင်မလမ်းညွှန် ID ဖြင့် ဦးစွာ အမိန့်ပေးသည်။ ထို့ကြောင့် နည်းပညာအရ၊ ဖိုင်တွဲတစ်ခု၏ အကြောင်းအရာများကို ရယူခြင်း၏တာဝန်မှာ ကီးအုပ်စု၏အပေါ်ပိုင်းဘောင်တွင် ကာဆာကို ပေးထားသည့်ရှေ့ဆက်တစ်ခုဖြင့် ကာဆာကို နေရာချကာ နောက်တွင် အောက်ဘက်နယ်နိမိတ်ကို ထပ်ကာထပ်ကာ ပြုလုပ်ခြင်းဖြစ်သည်။

စဉ်ဆက်မပြတ်ရှာဖွေခြင်းဖြင့် အထက်ပိုင်း "နဖူးပေါ်" ကို သင်တွေ့နိုင်သည်။ ထိုသို့လုပ်ဆောင်ရန်၊ ဒေတာဘေ့စ်ရှိ သော့များစာရင်းတစ်ခုလုံး၏အစတွင် ကာဆာကို ချထားပြီးနောက် ပင်မလမ်းညွှန်အမှတ်အသားပါသော သော့ကို ၎င်းအောက်တွင် ပေါ်လာသည်အထိ တိုးမြှင့်ထားသည်။ ဤချဉ်းကပ်မှုတွင် သိသာထင်ရှားသော အားနည်းချက် ၂ ခုရှိသည်။

1. ရှာဖွေမှု၏မျဉ်းဖြောင့်ရှုပ်ထွေးမှုသည် သင်သိသည့်အတိုင်းပင်၊ ယေဘုယျအားဖြင့် သစ်ပင်များနှင့် အထူးသဖြင့် B-tree တွင်၊ ၎င်းကို logarithmic အချိန်အတွင်း လုပ်ဆောင်နိုင်သည်။
2. အချည်းနှီးပါပဲ၊ လိုချင်တဲ့ စာမျက်နှာတွေထက် စာမျက်နှာအားလုံးကို ဖိုင်ကနေ ပင်မမှတ်ဉာဏ်ဆီ မြှင့်တင်ပေးတယ်၊ အလွန်စျေးကြီးတယ်။

ကံကောင်းထောက်မစွာ၊ LMDB API သည် cursor ကို အစပိုင်းတွင် နေရာချထားရန် ထိရောက်သောနည်းလမ်းကို ပံ့ပိုးပေးပါသည်။ ၎င်းကိုလုပ်ဆောင်ရန်၊ ကြားကာလ၏ အပေါ်ဘက်ဘောင်တွင်ရှိသော သော့ထက်နည်းသော သို့မဟုတ် ညီမျှသည်ဟုသိရသော သော့တစ်ခုဖွဲ့စည်းရန်လိုအပ်ပါသည်။ ဥပမာအားဖြင့်၊ အထက်ပုံတွင်ရှိသောစာရင်းနှင့်စပ်လျဉ်း၍ အကွက်ဖြစ်သည့် သော့တစ်ခုကို ကျွန်ုပ်တို့ပြုလုပ်နိုင်ပါသည်။ 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 ကို အသုံးပြု၍ ထပ်ခါထပ်ခါ ပြုလုပ်ခြင်း၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့် ကျွန်ုပ်တို့သည် သော့သာမက တန်ဖိုးကိုလည်း ရရှိပါသည်။ ရွေးချယ်မှုအခြေအနေများကို ဖြည့်ဆည်းရန်အတွက်၊ အခြားအရာများထဲမှ၊ မှတ်တမ်း၏တန်ဖိုး-အစိတ်အပိုင်းများမှ ကွက်လပ်များကို စစ်ဆေးရန် လိုအပ်ပါက၊ ၎င်းတို့သည် အပိုအမူအရာများမပါဘဲ ၎င်းတို့ကိုယ်တိုင် ဝင်ရောက်နိုင်မည်ဖြစ်သည်။

၄.၃။ ဇယားများကြား ဆက်ဆံရေးကို ပုံဖော်ခြင်း။

ယနေ့အထိ၊ ကျွန်ုပ်တို့သည် single-table database ဖြင့် ဒီဇိုင်းရေးဆွဲခြင်းနှင့် လုပ်ဆောင်ခြင်းဆိုင်ရာ ကဏ္ဍအားလုံးကို သုံးသပ်နိုင်ခဲ့သည်။ ဇယားတစ်ခုသည် အမျိုးအစားတူသော သော့တန်ဖိုးအတွဲများ ပါဝင်သော အမျိုးအစားခွဲထားသော မှတ်တမ်းအစုတစ်ခုဖြစ်သည်ဟု ကျွန်ုပ်တို့ပြောနိုင်သည်။ အကယ်၍ သင်သည် သော့ကို ထောင့်မှန်စတုဂံအဖြစ်နှင့် ၎င်း၏ဆက်စပ်တန်ဖိုးကို အကွက်တစ်ခုအဖြစ် ပြသပါက၊ သင်သည် ဒေတာဘေ့စ်၏ ရုပ်ပုံကားချပ်တစ်ခုကို သင်ရရှိမည်ဖြစ်သည်။

​

သို့သော် လက်တွေ့ဘဝတွင် ဤမျှလောက် သွေးနည်းနည်းဖြင့် ဖြတ်သန်းရန် မဖြစ်နိုင်ပေ။ ဒေတာဘေ့စ်တစ်ခုတွင် မကြာခဏဆိုသလို၊ ပထမဦးစွာ၊ ဇယားအများအပြားရှိရန်၊ ဒုတိယအချက်မှာမူလကီးနှင့်မတူသောအစီအစဥ်အရ ၎င်းတို့တွင်ရွေးချယ်မှုများကိုလုပ်ဆောင်ရန် လိုအပ်ပါသည်။ ဤနောက်ဆုံးအပိုင်းကို ၎င်းတို့၏ ဖန်တီးမှုနှင့် အပြန်အလှန်ချိတ်ဆက်မှုဆိုင်ရာ ပြဿနာများအတွက် အာရုံစိုက်ထားသည်။

အညွှန်းဇယားများ

cloud အက်ပ်တွင် "ပြခန်း" ကဏ္ဍတစ်ခု ရှိသည်။ ၎င်းသည် ရက်စွဲအလိုက်စီထားသော cloud တစ်ခုလုံးမှ မီဒီယာအကြောင်းအရာကို ပြသသည်။ ထိုသို့သောရွေးချယ်မှုကို အကောင်းဆုံးအကောင်အထည်ဖော်ရန်အတွက် ပင်မဇယားဘေးတွင်၊ သော့အမျိုးအစားအသစ်ဖြင့် နောက်ထပ်တစ်ခုကို ဖန်တီးရန် လိုအပ်ပါသည်။ ၎င်းတို့တွင် ဖိုင်ကိုဖန်တီးသည့်နေ့စွဲပါရှိသည့် အကွက်တစ်ခုပါရှိမည်ဖြစ်ပြီး၊ ၎င်းတွင် ပင်မတန်းစီခြင်းစံနှုန်းအဖြစ် လုပ်ဆောင်မည်ဖြစ်သည်။ သော့အသစ်များသည် အရင်းခံဇယားရှိ သော့များနှင့် တူညီသောဒေတာကို ရည်ညွှန်းသောကြောင့် ၎င်းတို့ကို အညွှန်းကီးများဟုခေါ်သည်။ ၎င်းတို့ကို အောက်ပါပုံတွင် လိမ္မော်ရောင်ဖြင့် မီးမောင်းထိုးပြထားသည်။

တူညီသောဒေတာဘေ့စ်အတွင်း မတူညီသောဇယားများ၏သော့များကို ခွဲထုတ်ရန်အတွက်၊ ၎င်းတို့အားလုံးတွင် အပိုနည်းပညာဆိုင်ရာနယ်ပယ် tableId ကို ထည့်သွင်းထားသည်။ စီစဥ်ခြင်းအတွက် အမြင့်ဆုံးဦးစားပေးအဖြစ် ပြုလုပ်ခြင်းဖြင့်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်စည်းမျဉ်းများနှင့်အညီ သော့များကို ဇယားများဖြင့် ဦးစွာအုပ်စုဖွဲ့ကာ ဇယားများအတွင်း၌ ရှိပြီးဖြစ်သည်။

အညွှန်းကီးသည် အဓိကသော့ကဲ့သို့ တူညီသောဒေတာကို ရည်ညွှန်းသည်။ ပင်မသော့၏တန်ဖိုး၏အစိတ်အပိုင်းတစ်ခုနှင့် ချိတ်ဆက်ခြင်းဖြင့် ဤပိုင်ဆိုင်မှု၏ ရိုးရှင်းသောအကောင်အထည်ဖော်မှုသည် တစ်ကြိမ်တည်းတွင် များစွာသောရှုထောင့်မှ အသင့်လျော်ဆုံးဖြစ်သည်-

1. အာကာသကို သိမ်းပိုက်ထားသည့် ရှုထောင့်မှကြည့်လျှင် မက်တာဒေတာသည် အလွန်ကြွယ်ဝနိုင်သည်။
2. စွမ်းဆောင်ရည်ရှုထောင့်မှနေ၍ node မက်တာဒေတာကို အပ်ဒိတ်လုပ်သောအခါတွင်၊ သင်သည် သော့နှစ်ခုကို ထပ်ရေးရမည်ဖြစ်ပါသည်။
3. ကုဒ်ပံ့ပိုးမှု၏ရှုထောင့်မှကြည့်လျှင်၊ ကျွန်ုပ်တို့သည် သော့တစ်ခုအတွက် ဒေတာကို မွမ်းမံရန်မေ့သွားပါက သိုလှောင်မှုတွင် ဒေတာမညီညွတ်မှု သိမ်မွေ့သော ချို့ယွင်းချက်တစ်ခု ရရှိမည်ဖြစ်သည်။

ဆက်လက်၍ ဤချို့ယွင်းချက်များကို မည်သို့ဖယ်ရှားရမည်ကို ကျွန်ုပ်တို့စဉ်းစားပါမည်။

ဇယားများအကြားဆက်ဆံရေးအဖွဲ့အစည်း

ပုံစံသည် အညွှန်းဇယားတစ်ခုကို ပင်မတစ်ခုနှင့် ချိတ်ဆက်ရန်အတွက် ကောင်းမွန်သင့်လျော်သည်။ "သော့တန်ဖိုးအတိုင်း". ၎င်း၏အမည်ဖော်ပြသည့်အတိုင်း အညွှန်းမှတ်တမ်း၏တန်ဖိုးသည် ပင်မသော့တန်ဖိုး၏မိတ္တူဖြစ်သည်။ ဤနည်းလမ်းသည် မူလမှတ်တမ်း၏ တန်ဖိုးအပိုင်းကို သိမ်းဆည်းခြင်းနှင့် ဆက်စပ်နေသော အထက်ဖော်ပြပါ အားနည်းချက်အားလုံးကို ဖယ်ရှားပေးပါသည်။ တစ်ခုတည်းသောအခကြေးငွေမှာ index key မှတန်ဖိုးကိုရယူရန်၊ တစ်ခုအစား database သို့ queries 2 ခုပြုလုပ်ရန်လိုအပ်ပါသည်။ ဇယားကွက်အရ ထွက်ပေါ်လာသော database schema မှာ အောက်ပါအတိုင်းဖြစ်သည်။

ဇယားများကြား ဆက်ဆံရေးကို စီစဉ်ခြင်းအတွက် နောက်ထပ်ပုံစံတစ်ခုဖြစ်သည်။ "မလိုတော့သောသော့". ၎င်း၏အနှစ်သာရမှာ အမျိုးအစားခွဲရန်မလိုအပ်ဘဲ ဆက်စပ်သော့ကိုပြန်လည်ဖန်တီးရန်အတွက် သော့အား ထပ်လောင်းဂုဏ်သတ္တိများထည့်ရန်ဖြစ်ပါသည်။သို့သော် Mail.ru Cloud အပလီကေးရှင်းတွင်၎င်း၏အသုံးပြုမှုအစစ်အမှန်ဥပမာများရှိပါသည်။ သတ်မှတ်ထားသော iOS မူဘောင်များ၏ ဆက်စပ်မှု၊ စိတ်ကူးယဉ်ဆန်သော၊ သို့သော် ပိုမိုနားလည်နိုင်သော ဥပမာတစ်ခုပေးပါမည်။

Cloud မိုဘိုင်း သုံးစွဲသူများတွင် အသုံးပြုသူ အခြားသူများနှင့် မျှဝေထားသည့် ဖိုင်များနှင့် ဖိုင်တွဲများအားလုံးကို ပြသသည့် စာမျက်နှာတစ်ခု ရှိသည်။ ထိုသို့သောဖိုင်များအတော်လေးနည်းပါးပြီး ၎င်းတို့နှင့်ဆက်စပ်နေသော လူသိရှင်ကြားဖော်ပြခြင်းဆိုင်ရာ တိကျသောအချက်အလက်များစွာရှိသောကြောင့် (မည်သူ့ကိုဝင်ရောက်ခွင့်၊ မည်သည့်အခွင့်အရေးများနှင့်အတူ)၊ ၎င်းကိုတန်ဖိုး၏အစိတ်အပိုင်းဖြင့်ဝန်ထုပ်ဝန်ပိုးဖြစ်စေမည်မဟုတ်ပါ။ ပင်မဇယားတွင်ပါဝင်မှု။ သို့သော်၊ သင်သည် ထိုကဲ့သို့သောဖိုင်များကို အော့ဖ်လိုင်းပြသလိုပါက၊ ၎င်းကို တစ်နေရာရာတွင် သိမ်းဆည်းထားရန် လိုအပ်သေးသည်။ သဘာဝဖြေရှင်းချက်တစ်ခုသည် ၎င်းအတွက် သီးခြားဇယားတစ်ခု ဖန်တီးရန်ဖြစ်သည်။ အောက်ဖော်ပြပါပုံတွင်၊ ၎င်း၏သော့ကို "P" ဖြင့်ရှေ့ဆက်ထားပြီး "propname" placeholder ကို ပိုမိုတိကျသောတန်ဖိုး "public info" ဖြင့် အစားထိုးနိုင်ပါသည်။

ဇယားအသစ်ကို ဖန်တီးခဲ့ခြင်းအတွက် ထူးခြားသော မက်တာဒေတာအားလုံးကို မှတ်တမ်း၏တန်ဖိုးသို့ ရွှေ့ထားသည်။ တစ်ချိန်တည်းမှာပင်၊ ပင်မဇယားတွင် သိမ်းဆည်းထားပြီးဖြစ်သော ဖိုင်များနှင့် ဖိုင်တွဲများအကြောင်း ဒေတာကို မပွားချင်ပါ။ ယင်းအစား၊ မလိုအပ်သောဒေတာကို "node ID" နှင့် "timestamp" အကွက်ပုံစံဖြင့် "P" သော့သို့ ပေါင်းထည့်သည်။ ၎င်းတို့အား ကျေးဇူးတင်စွာဖြင့်၊ သင်သည် အဓိကသော့ကို သင်ရနိုင်သဖြင့် အညွှန်းကီးတစ်ခုကို တည်ဆောက်နိုင်ပြီး၊ ယင်းဖြင့် နောက်ဆုံးတွင် node ၏ metadata ကို သင်ရနိုင်မည်ဖြစ်သည်။

နိဂုံး

ကျွန်ုပ်တို့သည် LMDB အကောင်အထည်ဖော်မှုရလဒ်များကို အပြုသဘောဖြင့် အကဲဖြတ်ပါသည်။ ၎င်းပြီးနောက်၊ အပလီကေးရှင်းအေးခဲခြင်းအရေအတွက် 30% လျော့ကျသွားသည်။

လုပ်ဆောင်ခဲ့သော ရလဒ်များသည် iOS အဖွဲ့အပြင်ဘက်တွင် တုံ့ပြန်မှုတစ်ခု တွေ့ရှိခဲ့သည်။ လောလောဆယ်တွင်၊ Android အပလီကေးရှင်းရှိ အဓိက "Files" ကဏ္ဍများထဲမှတစ်ခုသည် LMDB ကိုအသုံးပြုပြီး အခြားအပိုင်းများလည်း လုပ်ဆောင်နေပါသည်။ သော့တန်ဖိုး သိုလှောင်မှုကို အကောင်အထည် ဖော်သည့် C ဘာသာစကားသည် အက်ပ်လီကေးရှင်းကို C++ ဘာသာစကားဖြင့် ဖြတ်ကျော်သည့် ပလပ်ဖောင်းကို အစပိုင်းတွင် ပေါင်းစပ်ပြုလုပ်နိုင်ရန် အထောက်အကူကောင်းတစ်ခုဖြစ်သည်။ Objective-C နှင့် Kotlin ရှိ ပလက်ဖောင်းကုဒ်ဖြင့် ထွက်ပေါ်လာသော C ++ စာကြည့်တိုက်၏ ချောမွေ့စွာချိတ်ဆက်မှုအတွက်၊ ကုဒ်ထုတ်လုပ်သူအား အသုံးပြုခဲ့သည်။ Djinni Dropbox မှ၊ သို့သော် ၎င်းသည် အခြားဇာတ်လမ်းဖြစ်သည်။

source: www.habr.com