Select နှင့် Disk ကြားရှိ Cache Layer သုံးခု

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

SELECT Query သည် သင့်လျှောက်လွှာကို ချန်ထားခဲ့သည့်အခိုက်အတန့်တွင် ဘာဖြစ်သွားသနည်း။

သင့်အပလီကေးရှင်းမှ SELECT query ကို ပေးပို့လိုက်သည့်အခိုက်၊ developer အများစုသည် မည်သည့်အခါမှ စစ်ဆေးခြင်းမရှိသည့် ပိုက်လိုင်းတစ်ခုသို့ ရောက်ရှိလာပါသည်။ ဒေတာဘေ့စ်အင်ဂျင်သည် I/O တစ်စုံတစ်ရာမဖြစ်ပေါ်မီ တောင်းဆိုချက်ကို ကြားဖြတ်ပြီး SQL အား အတွင်းပိုင်းလုပ်ဆောင်မှုအစီအစဉ်အဖြစ် ပိုင်းခြားကာ ၎င်း၏ပထမကာကွယ်ရေးစာကြောင်းကို ချက်ခြင်းအကြံပေးသည်- မေးမြန်းမှုရလဒ် ကက်ရှ်။ တူညီသောဘောင်များပါသော တူညီသောမေးခွန်းတစ်ခုကို မကြာသေးမီက လုပ်ဆောင်ခဲ့ပါက၊ အင်ဂျင်သည် ဒေတာစာမျက်နှာတစ်ခုတည်းကို မထိဘဲ သိမ်းဆည်းထားသော ရလဒ်တစ်ခုအား ပြန်ပေးနိုင်သည်။ ၎င်းကို တစ်ခါတစ်ရံတွင် query cache သို့မဟုတ် ရလဒ် cache ဟုခေါ်ပြီး၊ ခွဲခြမ်းစိတ်ဖြာမှု ဒက်ရှ်ဘုတ်များနှင့် အစီရင်ခံခြင်း မော်ဂျူးများကဲ့သို့ — မြင့်မားသော၊ ရေးထားမှုနည်းပါးသော အလုပ်များပေါ်တွင် — ၎င်းသည် ဒစ်ခ်အများစုကို လုံးလုံးလျားလျား ဖယ်ရှားပစ်နိုင်သည်။

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

Buffer Pool ဆိုတာ ဘာလဲ ၊ ဘာကြောင့် မင်းထင်တာထက် ပိုအရေးကြီးတာလဲ။

ဒုတိယ ကက်ရှ် အလွှာ — နှင့် ထုတ်လုပ်မှု စနစ်များတွင် အရေးအကြီးဆုံးဟု ဆိုရမည် ဖြစ်သည် — သည် ကြားခံ ရေကူးကန် (MySQL ရှိ InnoDB ကြားခံ ပေါင်းကူး ဟုခေါ်သော PostgreSQL တွင် မျှဝေထားသော ကြားခံ ဟုခေါ်သည်)။ ၎င်းသည် မကြာသေးမီက ဝင်ရောက်ကြည့်ရှုထားသော ဒေတာစာမျက်နှာများကို ထိန်းထားရန် ဒေတာဘေ့စ်အင်ဂျင်အသုံးပြုသည့် RAM ၏ ဒေသတစ်ခုဖြစ်သည်။ ရလဒ် ကက်ရှ်မှ မေးမြန်းမှု မပြုလုပ်နိုင်သောအခါ၊ အင်ဂျင်သည် လိုအပ်သော ဒေတာစာမျက်နှာများကို မည်သည့်ဒစ်ဖတ်ခြင်းကိုမျှ မထုတ်ပြန်မီ ကြားခံရေကန်တွင် နေထိုင်နေပြီလားဟု စစ်ဆေးပါသည်။

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

သော့ထိုးထွင်းသိမြင်မှု- OLTP လုပ်ငန်းခွင်အများစုတွင်၊ အရွယ်အစားကောင်းမွန်သော ကြားခံအစုသည် ဒေတာဖတ်ရှုမှုအားလုံး၏ 95-99% ကို RAM မှ လုပ်ဆောင်ပေးသည်ဟု ဆိုလိုသည်။ မကြာခဏထိတွေ့မေးမြန်းသည့် သင့်ဒေတာ၏အပိုင်းခွဲ—အလုပ်လုပ်သည့်အစုံ—သည် စုစုပေါင်းဒေတာဘေ့စ်အရွယ်အစားထက် များစွာသေးငယ်လေ့ရှိသည်။ သင်၏အလုပ်အစုံနှင့် ကိုက်ညီစေရန် သင်၏ကြားခံရေကူးကန်ကို အရွယ်အစားသတ်မှတ်ခြင်းသည် သင်လုပ်ဆောင်နိုင်သည့် တစ်ခုတည်းသော အမြင့်ဆုံးပြန်ချိန်ညှိခြင်းလုပ်ဆောင်ချက်ဖြစ်သည်။

Operating System Cache သည် RAM နှင့် Disk အကြား ကွာဟချက်ကို မည်သို့ဖြည့်ဆည်းပေးသနည်း။

ဒေတာဘေ့စ်၏ကိုယ်ပိုင်ကြားခံစုပေါင်း လွတ်သွားသည့်တိုင်၊ စစ်မှန်သောဒစ်ခ်ကိုဖတ်ရန်အတွက် စုံစမ်းမှုတစ်ခုအား မသတ်မှတ်ရသေးပါ။ လည်ပတ်မှုစနစ်သည် စာမျက်နှာ ကက်ရှ် (ဖိုင်စနစ် ကက်ရှ်ဟုလည်း ခေါ်သည်)၊ စက်ပစ္စည်းများကို ပိတ်ဆို့ရန် ဖတ်ပြီး စာရေးခြင်းကို ကြားခံလုပ်ဆောင်သည့် kernel စီမံခန့်ခွဲသည့် RAM ၏ ဒေသဖြစ်သည်။ ဒေတာဘေ့စ်အင်ဂျင်က ၎င်း၏ကြားခံစုပေါင်းမှ ပျက်ကွက်နေသည့် စာမျက်နှာတစ်ခုကို တောင်းဆိုသောအခါ၊ OS kernel သည် သိုလှောင်မှုထိန်းချုပ်သူထံသို့ ရုပ်ပိုင်းဆိုင်ရာ I/O အမိန့်ကို မထုတ်ပြန်မီ ၎င်း၏ကိုယ်ပိုင်စာမျက်နှာ cache ကို စစ်ဆေးသည်။

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

အလေ့အကျင့်တွင် စွမ်းဆောင်ရည်အရှိဆုံး အောင်ပွဲအတွက် မည်သည့် Cache Layer က တာဝန်ရှိသနည်း။

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

• မေးမြန်းမှုရလဒ် ကက်ရှ်- ဖတ်ရှုမှုပြင်းထန်သော၊ အများအားဖြင့် ပုံသေဒေတာအတွဲများ — စုံစမ်းမေးမြန်းချက်များအား အစီရင်ခံခြင်း၊ သိမ်းဆည်းထားသော ဒက်ရှ်ဘုတ်များ၊ အများသူငှာ အကြောင်းအရာအဆုံးမှတ်များအတွက် အမြင့်ဆုံးအကျိုးကျေးဇူးများ။ ရေးစရာ လေးလံသော ဇယားများတွင် အသုံးမဝင်ပါ။
• ဒေတာဘေ့စ်ကြားခံရေကန်- universal workhorse။ ထုတ်လုပ်မှုဒေတာဘေ့စ်ဆာဗာတိုင်းကို ဤနေရာတွင် ဦးစွာ ချိန်ညှိသင့်သည်။ ကျပန်းနှင့် ဆက်တိုက်ဝင်ရောက်မှုပုံစံများကို ထိရောက်စွာ ကိုင်တွယ်ပါ။
• OS စာမျက်နှာ ကက်ရှ်- ကြားခံစုပေါင်းကို အရွယ်အစား သေးငယ်သောအခါ ဘေးကင်းရေး အသားတင်ကို ပေးသည်။ ထို့အပြင် hot pages များကို ကြားခံရေကန်မှ နှင်ထုတ်မည့် စားပွဲကြီးများကို ဆက်တိုက်စကင်န်လုပ်ရာတွင်လည်း သိသိသာသာ ကူညီပေးပါသည်။
• သိုလှောင်မှု ထိန်းချုပ်ကိရိယာ ကက်ရှ် (ဟာ့ဒ်ဝဲ အလွှာ): စတုတ္ထ၊ မကြာခဏ သတိမမူမိသော အလွှာ — NVMe SSDs နှင့် RAID ထိန်းချုပ်ကိရိယာများသည် ဘက်ထရီ သို့မဟုတ် ကာပတ်စီတာ အရန်သိမ်းဆည်းမှုဖြင့် သင်္ဘောပေါ်တွင် စာရေးကက်ရှ်များကို ထိန်းသိမ်းထားသည်။ ၎င်းသည် fsync latency ကိုမသုံးဘဲ တာရှည်ခံမှုကို ကာကွယ်ပေးသည်။
• Application-layer cache ( Redis ၊ Memcached )- ဒေတာဘေ့စ်အပေါ်တွင် လုံးလုံးလျားလျား တည်ရှိပြီး ဒေတာဘေ့စ်ကို လုံးဝမထိမိစေရန် နံပါတ်စဉ်အလိုက် မေးမြန်းမှုရလဒ်များ သို့မဟုတ် တွက်ချက်ထားသော အရာဝတ္ထုများကို သိမ်းဆည်းနေသည် — ထောင်ပေါင်းများစွာသော ပြိုင်တူအသုံးပြုသူများကို ဝန်ဆောင်မှုပေးနေသော SaaS ပလပ်ဖောင်းများစွာအတွက် စံပြဖြစ်သည်။

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

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

Mewayz သည် ဤဒဿနကို စိတ်ထဲတွင် အတိအကျ တည်ဆောက်ထားသည်။ သုံးစွဲသူပေါင်း 138,000 ကျော်ကို စွမ်းအားပေးသည့် ပေါင်းစပ်လုပ်ငန်း မော်ဂျူး 207 ခုဖြင့်၊ ပလပ်ဖောင်း၏ ဒေတာအလွှာကို ကက်ရှ်မှ ဖတ်ရှုမှု အများစုကို အသုံးပြုနိုင်စေရန် ဒီဇိုင်းထုတ်ထားသည် — တုံ့ပြန်မှုအချိန်ကို မြန်ဆန်စေပြီး သင် $19/လ စတင်ခြင်းအစီအစဉ် သို့မဟုတ် $49/လ ပရော်ဖက်ရှင်နယ်အဆင့်တွင် လုပ်ဆောင်နေသည်ဖြစ်စေ အခြေခံအဆောက်အအုံကုန်ကျစရိတ်ကို ခန့်မှန်းနိုင်ပါသည်။

အမေးများသောမေးခွန်းများ

မေးမြန်းမှု ကက်ရှ်ကို ပိတ်ထားခြင်းသည် ဒေတာဘေ့စ် စွမ်းဆောင်ရည်ကို အမြဲတမ်း တိုးတက်စေပါသလား။

အမြဲတမ်းမဟုတ်ပေမယ့် ရေးရတာ လေးလံတဲ့အလုပ်တွေအတွက်တော့ ထုံးစံအတိုင်းပါပဲ။ query cache သည် တစ်သမတ်တည်းဖြစ်တည်မှုကို ထိန်းသိမ်းရန် ကမ္ဘာလုံးဆိုင်ရာ mutex လိုအပ်သည်၊ ၎င်းသည် မြင့်မားသော တွဲဖက်မှုအောက်တွင် တစ်ဆို့သွားပါသည်။ MySQL 8.0 သည် ဤအကြောင်းကြောင့် query cache ကို လုံးဝဖယ်ရှားခဲ့သည်။ PostgreSQL သည် buffer pool နှင့် application-layer caching ကို အားကိုးပြီး built-in query cache ကို ဘယ်သောအခါမှ အကောင်အထည်မဖော်ခဲ့ပါ။ သင်၏ဖတ်ရန်စာရေးအချိုးသည် မြင့်မားပြီး သင့်မေးမြန်းချက်များသည် ထပ်ခါတလဲလဲဖြစ်နေပါက၊ query cache သည် အမှန်တကယ်အကျိုးအမြတ်များကို ပေးဆောင်နိုင်သည် — သို့မဟုတ်ပါက၊ ထိုချိန်ညှိအားထုတ်မှုကို ကြားခံရေကန်တွင် ရင်းနှီးမြှုပ်နှံပါ။

ကျွန်ုပ်၏ကြားခံရေကန်သည် အရွယ်အစားမှန်ကန်မှုရှိမရှိ မည်သို့သိနိုင်မည်နည်း။

သင်၏ ကြားခံစုပေါင်း ပမာဏကို စောင့်ကြည့်ပါ- ဒစ်ခ်ဖတ်ရန် လိုအပ်သည့် စာမျက်နှာတောင်းဆိုမှုများနှင့် စာမျက်နှာတောင်းဆိုမှု ရာခိုင်နှုန်းများ။ OLTP workload တစ်ခုတွင် 95% အောက်ရှိ hit ratio သည် pool size ကိုတိုးရန် အချက်ပြမှုတစ်ခုဖြစ်သည်။ MySQL တွင်၊ အင်ဂျင် INNODB STATUS ကိုပြသပါ ကိုမေးမြန်းပြီး buffer pool hit rate ကိုကြည့်ပါ။ PostgreSQL တွင်၊ pg_statio_user_tables မြင်ကွင်းသည် ဒစ်ခ်မှဖတ်သည့် အစုအဝေးတုံးများကို ထုတ်ဖော်ပြသသည် သင်၏အလုပ်အစုံကို — သင်၏ဒေတာအစုံမဟုတ်ဘဲ — RAM တွင်နေထိုင်ရန် ရည်ရွယ်သည်။

ကက်ရှ်အလွှာများနှင့် ငှားရမ်းသူအများအပြား SaaS ယုံကြည်စိတ်ချရမှုကြား ဆက်စပ်မှုမှာ အဘယ်နည်း။

အိမ်ငှားများစွာရှိသော SaaS တွင်၊ ကက်ရှ်အလွှာများသည် အိမ်ငှားတစ်ဦး၏ လေးလံသောမေးမြန်းချက်ဝန်သည် အခြားအိမ်ငှားအားလုံးအတွက် စွမ်းဆောင်ရည်ကို ကျဆင်းစေသည့် "ဆူညံသော အိမ်နီးချင်း" ပြဿနာများကို တားဆီးထားသည်။ TTL-အခြေခံတရားမဝင်ခြင်းနှင့်အတူ ငှားရမ်းသူ-သတိပြုမိသော အပလီကေးရှင်းမှ ကက်ရှ်လုပ်ခြင်းသည် Redis တွင် ငှားရမ်းသူတစ်ဦးချင်းစီ၏ ပူနွေးသောဒေတာကို သိမ်းဆည်းထားပြီး အကောင့်ကြီးများမှ ကြားခံရေကန်ဖိအားကို သိသိသာသာလျှော့ချပေးသည်။ ဒေတာဘေ့စ်အဆင့် ချိတ်ဆက်မှုပေါင်းစည်းခြင်းသည် နွေးထွေးသော ကြားခံရေကန်နှင့် ပေါင်းစပ်ထားခြင်းက မည်သည့်အကောင့်မှ ဆက်တိုက်လုပ်ဆောင်မှုများသည် မျှဝေထားသော စာမျက်နှာများကို ကက်ရှ်မှ မဖယ်ရှားဘဲ ပလပ်ဖောင်းတစ်လျှောက် ကြာမြင့်ချိန်ထိခြင်းများကို ဖြစ်စေကြောင်း သေချာစေသည်။

ကက်ရှ်အလွှာများသည် ဒေတာဘေ့စ်အသေးအဖွဲမဟုတ်ပါ — ၎င်းတို့သည် စဉ်ဆက်မပြတ်အခြေခံအဆောက်အဦမီးငြိမ်းသတ်မှုလိုအပ်သည့်စကေးဖြင့် လျင်မြန်စွာနေနိုင်သော ပလပ်ဖောင်းများကို ပိုင်းခြားထားသည့် ဗိသုကာအခြေခံအုတ်မြစ်ဖြစ်သည်။ အကယ်၍ သင်သည် ဤဖြစ်ရပ်မှန်များအတွက် အကောင်းဆုံးပြင်ဆင်ပြီးသော ပလပ်ဖောင်းတစ်ခု လိုအပ်သည့် လုပ်ငန်းတစ်ခုကို တည်ဆောက်နေပါက၊ Mewayz ကို app.mewayz.com တွင် လေ့လာပါ — 207 modules၊ ပေါင်းစပ်ထားသော ပလပ်ဖောင်းတစ်ခု၊ သင်၏ပထမဆုံးအသုံးပြုသူမှ သိန်းတစ်ထောင်အထိ ယုံကြည်စိတ်ချစွာ လုပ်ဆောင်နိုင်ရန် တည်ဆောက်ထားသည်။