Mythex အက်ပ်တိုင်းသည် ကိုယ်ပိုင် Database ရရှိသည်အကြောင်း

သင် Mythex တွင် တည်ဆောက်သော အက်ပ်သည် data သိမ်းရန် လိုအပ်သောအခါ (signup များ၊ booking များ၊ order များ) ထို project သည် ကိုယ်ပိုင် Postgres database ရရှိသည်။ Shared database ထဲရှိ table တစ်ခုမဟုတ်၊ တစ်ယောက်ယောက်၏ နံဘေးရှိ schema မဟုတ်ပါ: သီးခြား database ဖြစ်ပြီး လိုအပ်သည့်အချိန် ဖန်တီးကာ မည်သူမျှ မသုံးသောအခါ အိပ်ပျော်သည်။ ထိုသို့ တည်ဆောက်ခဲ့ရသော အကြောင်းရင်းနှင့် ကုန်ကျစရိတ်ကို ဤနေရာတွင် ရှင်းပြသည်။

သင်ရရှိသည်များ

"waitlist အီးမေးလ်များ သိမ်းပါ" သို့မဟုတ် "booking များ သိမ်းပါ" ဟု data တောင်းလျှင် သို့မဟုတ် /database command ကို သုံးလျှင် Mythex က:

• Project အတွက် သီးသန့် Postgres database တစ်ခု ဖန်တီးသည် (လက်ရှိ Postgres 17)၊
• ချိတ်ဆက်မှု အချက်အလက်များကို သင့် workspace နှင့် publish လုပ်ထားသော အက်ပ်သို့ environment variables အဖြစ် ထည့်သည်၊ ထို့ကြောင့် ကုဒ်တွင် ဘယ်တော့မှ မပေါ်ပါ၊ နှင့်
• Agent က table များ ဖန်တီးပြီး data ကို သင့်အတွက် ဖတ်ရေးနိုင်သည်။

Live preview နှင့် publish လုပ်ထားသော အက်ပ်သည် database တူတူကို သုံးသည်။ မေးမှုမရှိလျှင် ၅ မိနစ် idle ပြီးနောက် အိပ်ပျော်ပြီး နောက် query တွင် နိုးသည်။ Database အသစ်များသည် သေးငယ်စွာ စတင်ပြီး load အောက်တွင် ကြီးလာနိုင်သည်၊ runaway query မှ အကန့်အသတ်မရှိ ကြီးလာခြင်းကို ကာကွယ်ရန် ကန့်သတ်ချက်ရှိသည်။ database docs တွင် ပိုမိုရှိသည်။

ဘာကြောင့် shared database ကြီးတစ်ခု မသုံးသလဲ

Row တစ်ခုစီက မည်သည့် app ၏ ဖြစ်ကြောင်း ပြောသော column ပါသည့် shared database သည် ပိုစျေးသက်သာပြီး စီမံရ ပိုရိုးရှင်းသည်။ ကျွန်ုပ်တို့ အကြောင်းလေးခုကြောင့် ထိုနည်းလမ်းကို မရွေးခဲ့ပါ။

၁။ ယုံစရာ မလိုသော ခွဲခြားမှု

AI ရေးသော ကုဒ်သည် အမှားလုပ်တတ်သည်။ Shared database တွင် app တစ်ခု၏ query ထဲ WHERE app_id = … ပျောက်သွားလျှင် အခြား customer ၏ data ကို ဖတ်ခြင်း သို့မဟုတ် ရေးထပ်ခြင်း ဖြစ်နိုင်သည်။ Database တစ်ခုစီဖြင့် အခြား customer ၏ data ရောက်နိုင်သည့် နေရာ မရှိပါ — bug တစ်ခုသည် ကိုယ်ပိုင် app အတွင်း ကျန်ရစ်သည်။

၂။ Proprietary အလွှာ မဟုတ်ဘဲ တကယ့် Postgres

သင့်အက်ပ်သည် ပုံမှန် connection string ဖြင့် စံ Postgres နှင့် ဆက်သွယ်သည်။ Postgres နှင့် အလုပ်လုပ်သော library၊ ORM သို့မဟုတ် tool မည်သည်မဆို ဤနေရာတွင် အလုပ်လုပ်သည်။ အခြားနေရာတွင် run ရန် project ကို export လုပ်လျှင် Postgres database ကို မျှော်လင့်သည် — hosting provider အားလုံး ပေးနိုင်သည့် အရာဖြစ်ပြီး Mythex-specific API မဟုတ်ပါ။

၃။ အက်ပ်တစ်ခုစီ လိုအပ်သည့် ပုံစံဖြင့် ပုံဖော်နိုင်သည်

အက်ပ်တစ်ခုက time slot များပေါ်တွင် unique constraint ပါသော bookings table လိုချင်သည်၊ နောက်တစ်ခုက ကုန်ပစ္စည်းများအပေါ် full-text search လိုချင်သည်။ ကိုယ်ပိုင် database ရှိသဖြင့် အက်ပ်တစ်ခုစီ၏ schema နှင့် migration များသည် ကိုယ်ပိုင်ဖြစ်သည်။ အနိမ့်ဆုံး ဘုံဒီဇိုင်းသို့ ကိုက်ညီရန် မလိုပါ။

၄။ ကုန်ကျစရိတ်သည် အသုံးပြုမှုကို လိုက်သည်

Database တစ်ခုစီ သီးခြား အိပ်ပျော်သဖြင့် အသုံးမပြုသော အက်ပ်သည် ကုန်ကျစရိတ် နည်းပါးသည်၊ အလုပ်များသော အက်ပ်၏ ကုန်ကျစရိတ်သည် ကိုယ်ပိုင် လိုင်းအဖြစ် မြင်ရသည်။ Publish လုပ်ထားသော database အသုံးပြုမှုကို database က အမှန်တကယ် တိုင်းတာထားသည့်အပေါ် အခြေခံ၍ ငွေရှင်းသည် (ထိုငွေရှင်းပုံ)။

Trade-off များ

ဤဒီဇိုင်းသည် အခမဲ့ မဟုတ်ပါ:

• Cold start။ အိပ်နေသော database သည် ငြိမ်သက်ပြီးနောက် ပထမ query တွင် နိုးရန် အချိန်အနည်းငယ် ကြာသည်။ အများစု အက်ပ်များအတွက် သိသာထင်ရှားမှု နည်းသည်၊ မည်သည့်အချိန်မဆို ချက်ချင်း ဖြေရမည့် အက်ပ်အတွက်မူ စဉ်းစားရမည့်အရာ ဖြစ်သည်။
• နိုးနေစဉ် ကုန်ကျစရိတ်။ အရာတစ်ခုခုက query လုပ်နေသရွေ့ database သည် နိုးနေသည်။ စက္ကန့်အနည်းငယ်တိုင်း database ကို poll လုပ်သော အက်ပ်သည် တစ်နေ့တာလုံး နိုးနေစေပြီး on-demand query လုပ်သော အက်ပ်ထက် ပိုကုန်သည်။ သင်ထင်ထားသည်ထက် အသုံးပြုမှု မြင့်နေလျှင် ဤအကြောင်းကြောင့် ဖြစ်နိုင်သည် — AI ကို poll ရပ်ပြီး လိုအပ်သောအခါ data ဖတ်ရန် ပြောပါ။
• ကျွန်ုပ်တို့အတွက် ပိုမို အပိုင်းများ။ Database ထောင်ပေါင်းများစွာ ဖန်တီး၊ ခြေရာခံ၊ သန့်ရှင်းရေးလုပ်ရန် တစ်ခုထက် ပို အလုပ်ရှိသည်။ ထိုအလုပ်သည် ကျွန်ုပ်တို့၏ တာဝန်ဖြစ်ပြီး သင့်တာဝန် မဟုတ်ပါ။

Database အသစ်ဖြစ်လျှင်

Database ဆိုသည်မှာ အက်ပ်က မှတ်ထားရန် လိုအပ်သည်များကို သိမ်းရာနေရာ ဖြစ်သည်။ အယူအဆ အသစ်ဖြစ်လျှင် database ဆိုသည်မှာ ဘာလဲ နှင့် Postgres ဆိုသည်မှာ ဘာလဲ မှ စတင်ပါ။ Data သိမ်းသော အရာကို တည်ဆောက်ရန် အဆင်သင့်ဖြစ်သည့်အခါ AI ဖြင့် အက်ပ်တည်ဆောက်နည်း သည် ထည့်သွင်းပုံကို လမ်းညွှန်ပေးသည်။