database တွေကို အမှန်တကယ် သုံးတဲ့အတိုင်း ငွေရှင်းခြင်း

Mythex app တိုင်း data သိမ်းဖို့ လိုတဲ့ app တိုင်းက ကိုယ်ပိုင် Postgres database တစ်ခု ရပါတယ်။ publish app ရဲ့ database သုံးစွဲမှုက build လုပ်တဲ့ credit balance ထဲကပဲ ထွက်ပါတယ်။ စက်တင်ဘာ နောက်ပိုင်းအထိ ကျွန်ုပ်တို့ က ၎င်းသုံးစွဲမှုကို app ရဲ့ server ဘယ်လောက်ကြာ run ခဲ့လဲ ဆိုတာနဲ့ ခန့်မှန်း ခဲ့ပါတယ်။ ခန့်မှန်းချက်က အရေးကြီးတဲ့ နည်းနဲ့ မှားနေတာကို တွေ့ခဲ့ပြီး အစားထိုးလိုက်ပါတယ်။ ယခု database တစ်ခုစီကို provider က တိုင်းတာထားတဲ့ compute အပေါ် မူတည်ပြီး ပြီးဆုံးသွားတဲ့ နာရီတစ်ခုချင်းစီအလိုက် ငွေရှင်းပါတယ်။ နာရီတစ်ခုကို တစ်ကြိမ်သာ ကောက်ခံနိုင်ပါတယ်။

database တွေ ဘယ်လို အလုပ်လုပ်လဲ

database တစ်ခုစီက scale to zero လုပ်တဲ့ serverless Postgres ပေါ်မှာ run ပါတယ်။ ဆိုလိုတာက အချိန်အနည်းငယ် idle ဖြစ်ရင် အိပ်ပြီး query လာတဲ့အခါ နိုးပါတယ်။ နိုးနေချိန်မှာ load အလိုက် compute ကို တိုးလျော့နိုင်ပါတယ်။ ဒါက "app တစ်ခုအတွက် database တစ်ခု" ကို တတ်နိုင်စေတာပါ၊ အက်ပ်အများစုက အချိန်အများစု တိတ်ဆိတ်နေတာမို့ အိပ်နေတဲ့ database က ကုန်ကျစရိတ် နည်းပါတယ်။

ဒါဆိုရင် database ရဲ့ ကုန်ကျစရိတ်က အပြင်ကနေ မြင်လို့မရတဲ့ အချက်နှစ်ခုပေါ် မူတည်ပါတယ်: နိုးနေတဲ့ ကာလ ဘယ်လောက်ရှည်လဲ နဲ့ နိုးနေချိန်မှာ ဘယ်လောက်ကြီးလဲ။

ခန့်မှန်းချက်က ဘာမှားခဲ့လဲ

ကျွန်ုပ်တို့ မူလ meter က ယူဆချက် တစ်ခု ပြုလုပ်ထားခဲ့ပါတယ်။ publish app ရဲ့ server run နေတဲ့ နာရီတိုင်းအတွက် အသေးဆုံး compute အရွယ်နဲ့ database ကို ငွေယူတာပါ။

အဲဒါက အချက်သုံးချက်ကြောင့် မှားပါတယ်:

1. အရွယ်အစား မှား။ database တွေက ခန့်မှန်းထားတာထက် default အရွယ် ကြီးတဲ့အဆင့်မှာ run နေခဲ့ပါတယ်။
2. Database တွေ autoscale လုပ်တယ်။ load အောက်မှာ ကြီးလာပြီး ခန့်မှန်းချက်က ဘယ်တော့မှ မမြင်ခဲ့ပါဘူး။
3. Database တွေက app server ကို မလိုက်ပါဘူး။ database က ဘာမဆို query လုပ်နေလို့ နိုးနေပါတယ် — app, scheduled job, သို့မဟုတ် script poll လုပ်တာ — app ရဲ့ server run နေခဲ့လား မနေခဲ့လားနဲ့ မဆိုင်ပါ။

အသားတင် ရလဒ်: ခန့်မှန်းချက်က အသုံးပြုသူတွေကို database တွေ တကယ် ကုန်ကျတဲ့ ကုန်ကျစရိတ်၏ ထက်ဝက်ခန့်သာ ငွေယူခဲ့ပါတယ်။ ဒါက ကျွန်ုပ်တို့အတွက် ရေရှည် မတည်တံ့နိုင်ပါ၊ ထို့အပြင် app ထဲက usage ဂဏန်းတွေက လူတွေ ထင်တဲ့ အဓိပ္ပါယ် မရှိခဲ့ပါဘူး။

ခန့်မှန်းတာ အစား တိုင်းတာခြင်း

database provider က project တစ်ခုစီရဲ့ compute-unit-seconds per hour ကို report လုပ်ပါတယ်။ ဆိုလိုတာက အမှန်တကယ် သုံးထားတဲ့ compute ပမာဏ၊ အရွယ်အစား အပါအဝင် ဖြစ်ပါတယ်။ ဒါကြောင့် meter က အခု အောက်ပါအတိုင်း အလုပ်လုပ်ပါတယ်:

1. database ပါတဲ့ publish app တိုင်းအတွက် app live ဖြစ်ခဲ့တဲ့အချိန်ကစပြီး ပြီးဆုံးသွားတဲ့ finished နာရီတိုင်းရဲ့ တိုင်းတာထားတဲ့ သုံးစွဲမှုကို ယူပါတယ်။
2. အဲဒီ သုံးစွဲမှုကို provider ရဲ့ စျေးနှုန်းနဲ့ ကုန်ကျစရိတ် ပြောင်းပြီး plan ရဲ့ နှုန်းကို ထည့်ကာ app ပိုင်ရှင်ရဲ့ credits ကို ကောက်ခံပါတယ်။
3. ဝန်ဆောင်မှု restart နေချိန်တွင် လွတ်သွားတဲ့ နာရီများ နောက်မှ ငွေရှင်းရန် နောက်ကြည့်ပြီး တစ်ရက်အထိ ပြန်စစ်ပါတယ်။

သိုလှောင်မှုကို အရွယ်အစားအလိုက် သီးခြား ငွေရှင်းပါတယ်၊ ဘာလို့လဲဆိုတော့ activity အပေါ် မမှီခိုလို့ပါ။

နာရီတစ်ခုကို နှစ်ကြိမ် မကောက်ပါ

server တစ်ခုထက်ပို run ပြီး crash ဖြစ်ပြီး retry လုပ်နိုင်တဲ့ billing meter က နှစ်ကြိမ် မကောက်ဖို့ သတိထားရပါတယ်။ database နာရီတစ်ခုစီကို ငွေမကောက်ခင် ကိုယ်ပိုင် database row ထဲမှာ claim လုပ်ပါတယ်၊ (database, hour) အတွဲမှာ uniqueness constraint ရှိပါတယ်။ server နှစ်ခု သို့မဟုတ် retry တစ်ခုက နာရီတူကို ငွေရှင်းဖို့ ကြိုးစားရင် claim တစ်ခုတည်းသာ အောင်ပါတယ်။

ရှားပါးတဲ့ ပျက်ကွက်မှု အခြေအနေအတွက် ရည်ရွယ်ချက်ရှိရှိ ရွေးချယ်ထားပါတယ်: နာရီကို claim လုပ်ပြီး ကောက်ခံခြင်း ကြား မှာ process crash ဖြစ်ရင် ထိုနာရီက claim ထားပြီး မကောက်ရသေးဘဲ ကျန်ပါမယ်။ ရှားပါးတဲ့ crash မှာ ဝင်ငွေအနည်းငယ် ဆုံးရှုံးတာက လူတစ်ယောက်ကို နှစ်ကြိမ် ငွေယူတာထက် ပိုကောင်းပါတယ်။

measured billing ဖွင့်တဲ့အခါ နောက် full နာရီကစပါတယ်။ အဲဒီ နာရီများ ရှေ့ကို ဟောင်း ခန့်မှန်းချက်က ငွေကောက်ပြီးသားဖြစ်ပြီး၊ ထိုအချိန်ကို တိုင်းတာထားတဲ့ data နဲ့ ပြန်ကောက်ရင် နှစ်ခါ ကောက်မိမှာ ဖြစ်ပါတယ်။

build လုပ်တဲ့သူတွေအတွက် ဘာဆိုလိုလဲ

• သင့် database ဘေလ်က သင့် database ဘာလုပ်ခဲ့လဲ ကို ပြပါတယ်။ ရံဖန်ရံခါသာ သုံးတဲ့ app က ကုန်ကျစရိတ် နည်းပါတယ်၊ database ကို အဆက်မပြတ် query လုပ်တဲ့ app က သူ့ကို နိုးထားပြီး ပိုကုန်ပါမယ်။
• အကြီးဆုံး လက်ကိုင်ချိန်ညှိချက်က သင့် app က database ကို ဘယ်လို သုံးလဲ ပါ။ database ကို စက္ကန့်ပိုင်း poll လုပ်ရင် ၂၄ နာရီလုံး နိုးထားပါလိမ့်မယ်။ AI ကို ဒေတာ လိုတဲ့အခါ fetch ခိုင်းတာ၊ သို့မဟုတ် cache လုပ်တာက database ကို အိပ်ခွင့်ပေးပါတယ်။ database ဆိုတာ ဘာလဲ လမ်းညွှန်က အခြေခံကို ရှင်းပြပါတယ်။
• Pro plan တွေက hosting, database နဲ့ storage အတွက် Free နှုန်း၏ ထက်ဝက် ပေးပါတယ်။ အသေးစိတ်ကို credits docs မှာ ရှိပါတယ်။

ကျွန်ုပ်တို့ ရလိုက်တဲ့ သင်ခန်းစာများ

• အသုံးပြုမှုအပေါ် မူတည်တဲ့ ကုန်ကျစရိတ် ခန့်မှန်းချက်များ လွဲချော်တတ်ပါတယ်။ upstream provider က ဘာ သုံးခဲ့လဲ ပြောနိုင်ရင် အဲဒါပေါ် ငွေရှင်းပါ။
• ကောက်ခံတဲ့ အသေးဆုံး ယူနစ်မှာ billing ကို idempotent လုပ်ပါ။ ကျွန်ုပ်တို့အတွက် database နာရီတစ်ခုပါ။
• ပျက်ကွက်ရမယ်ဆိုရင် ဖောက်သည်ဘက်က ပြီးပြတ်အောင် ပျက်ပါ။