Mar 22, 2026
အရင်က application ကို တခြားသူတွေအသုံးပြုနိုင်အောင် server တွေကို companies ကိုယ်တိုင် host ရပါတယ်။ အဲ့ကနေ configuration ရှုပ်ထွေးမှုနဲ့ maintenance အတွက်အချိန်မကုန်ရအောင် cloud ဆိုတဲ့ concept ထွက်ခဲ့တယ်။ cloud ဆိုတာ အဆင့်သင့် အသုံးပြုရတဲ့ server တွေများစွာ စုစီထားတဲ့နေရာပါ (infrastructure)။ အဲ့ကမှ private နဲ့ public cloud ဆိုပြီးရှိတယ်။ private ဆိုတဲ့အတိုင်း private cloud က infrastructure တစ်ခုလုံးကို organization တစ်ခုတည်းအတွက်လုပ်ပေးထားတဲ့နေရာပေါ့။ Public cloud ကလူတွေအများ share သုံးတဲ့ infrastructure ဖြစ်တယ်။
VPC ကို အဓိကအသုံးပြုတာ က public cloud ပါ (private cloud မှာလည်းသုံးပါတယ် သုံးပုံတော့မတူပါဘူး) ။ ကိုယ်တိုင်ဆောက်တဲ့ infrastructure (on-premise) မှာဆိုရင် network router တွေမှာ subnet configure လုပ်ရတယ်။ ပြီးရင် firewall box နဲ့ inbound outbound rules တွေသတ်မှတ်တယ်။
ဒါတွေအကုန်လုံးဟာ တကယ် routerစက် (physical machine) မှာလုပ်ရပါတယ်။ cloud မှာ အဲ့လို security isolation ရအောင် VPC ကလုပ်ဆောင်ပေးတယ်။ virtual လို့ပြောတဲ့အတိုင်းဘဲ logically network router တွေအတိုင်း လုပ်ဆောင်ပေးထားတယ် (network layer abstraction)။ ဒါပင်မဲ့ VPC မှာရေးလိုက်တဲ့ subnet တွေက physical router မှာသွားမရေးပါဘူး။ (ပြောချင်တာ VPC က physical router နဲ့ logically တူပင်မဲ့ physically မတူဘူး) VPC network မှာရှိတဲ့ subnet နဲ့ firewall rules တွေဟာ SDN ခေါ် software-defined network stack နဲ့ distributed system ပေါ်မှာ virtually route လုပ်ပေးတယ်။ GCP မှာဆို Andromeda ကိုသုံးတယ်။ AWS တော့ disclose မလုပ်ဘူး။
VPC ကို အဓိက သုံးရခြင်းအကြောင်းကတော့ security နဲ့ control ပါ။
ခင်ဗျားရဲ့ instances (VM) ကို public ကနေ တိုင်ရိုက် access လုပ်နိုင်တာဟာ မလုံခြုပါဘူး။ load balancer ကနေမှ တဆင့်ဘဲ VM စီကို data communication လုပ်နိုင်အောင် VPC နဲ့ တားရပါတယ်။ Database လည်း အဲ့လိုဘဲ သတ်မှတ်ထားတဲ့ VM ကဘဲ အသုံးပြုလို့ရအောင် control နိုင်တယ်။ VM ကနေလည်း ဘယ် IP ကဘဲ လက်ခံမယ်ဆိုတာ VPC ကြောင့်သတ်မှတ်လိို့ရတယ် (security group in AWS, ingress egress in GCP).
ဒီလောက်ဆို VPC overview ကိုနားလည်မယ်လို့မျှော်လင်ပါတယ်။ cloud provider မှာ တကယ်စမ်းကြည့်ရင်းနဲ့ ပိုရင်းနှီးပြီး secure ပြီးတဲ့ infrastructure ကိုလုပ်နိုင်လာမှာပါ။
Apr 15, 2026
ကျွန်တော် တို့ project စလုပ်တဲ့ချိန်မှာ database server instance တစ်ခုတည်းနဲ့တင် လုံလောက်ပါတယ် (ဥပမာ - ကိုယ့် company အတွက် internal tools တွေ ၊ hobby project တွေပေါ့) ။ ကြာလာတာနဲ့ data size က ကြီးလာတော့ performance ကျလို့ cache layer (e.g Redis) ထည့်ပြီး fix လုပ်နိုင်တယ်။ ဒါပင်မဲ့ database server instance တစ်ခုကိုဘဲသုံးနေရင် (vertical scaling လုပ်မယ်ဆိုရင်) အရင် blog က ပြောတဲ့ အတိုင်း hardware limit ကိုထိလာတယ်။ ဥပမာအနေနဲ့ data intensive ဖြစ်တဲ့ application တွေပြောရရင် bus ticket application တွေ၊ ordering system တွေပါ။ ...
ထို့ကြောင့် data size ကြီးလာပြီး request တွေများလာတာနဲ့ အမြဲ horizontal scaling strategies တွေကို သုံးလာရတယ်။ ...
အသုံးများတဲ့ Database Horizontal scaling strategies နှစ်မျိုးရှိပါတယ်။ ...
၁။ Sharding ...
Write (data ကို အပြောင်းအလဲလုပ်တာ) နဲ့ read (data ဖတ်တာ) ကို servers တွေက တစ်ခုနဲ့တစ်ခုပေါ်မမှီခိုဘဲ request traffic တွေကို ဖြန့်ဝေတာ (distribute) ...
၂။ Read replicas ...
Write ကို primary server တစ်ခုကနေ handle လုပ်ပြီး read operation ကို replica လို့ခေါ်တဲ့primary database ရဲ့ copies အများကြီးတွေစီကို ဖြန့်ဝေပေးတာ။ ...
ဒီမှာတော့ database Sharding အကြောင်းရှင်းပြသွားပါမယ်။ ...
ခုနက scaling ပြသနာနဲ့ ကြည့်ရအောင်။ bus ticket application ကို သုံးလာတဲ့သူများလာတယ်ဆိုပါစို့။ data တွေက database တစ်ခုမှာဘဲ စုပြီးရှိလာရင်း traffic များလာတာနဲ့အမျှ query time တွေကြာလာတယ်။ data storage တွေပြည့်လာတယ်။ vertical scaling approach နဲ့ ဖြေရှင်းနိုင်ပင်မဲ့ အပေါ်ကပြောတဲ့ ပြသနာတွေရှိတယ်။ အဲ့ဒီကြီးမားနေတဲ့ database တစ်ခုလုံးကို ခွဲခြမ်းစိတ်ဖြာပြီး ထိန်းသိမ်းရလွယ်တဲ့ အစိတ်အပိုင်းတွေကို shard လို့ခေါ်တယ်။ shard တစ်ခုချင်းစီက database server instance အသီးသီးမှာရှိတယ်။ တစ်နေရာမှာဘဲ မစုနေလို့ workload တွေကို ကောင်းကောင်းဖြန့်ဝေနိုင်တယ်။ ...
ဘယ်လိုခွဲခြမ်းစိတ်ဖြာ (sharding) တာလဲ? ...
Data တွေဟာ shard key အလိုက် group လုပ်ပြီးခွဲတယ်။ shard key တွေက ခင်ဗျားရဲ့ database ထဲက column တစ်ခု ဒါမှ မဟုတ် တစ်ထက်ပိုပြီး ပေါ်မူတည်နေတယ်။ ဥပမာ - ticket id , user id , order number တွေ။ ဒါမှ မဟုတ် approach အရ ဘယ် column မှ မမူတည်ဘဲ unique generated key တွေနဲ့လည်း သုံးလို့ရတယ်။ အဲ့ဒီ shard key တွေကို database တစ်ခုထဲမှာ သိမ်းပြီး data request လာတဲ့ချိန် routing လုပ်တဲ့နေရာမှာသုံးတယ်။ routing ကို load balancer ဒါမှမဟုတ် proxy တစ်ခုကနေ shard key အရသက်ဆိုင်တဲ့ shard (database server) စီကို direct လုပ်ပေးတယ်။ ဒါမဲ့ မဟုတ် GCP documentation အရ multi-player game တို့ high performance real time application (e.g trading system) တွေမှာဆိုရင် application ရဲ့ code မှာတင် shard key ကိုဆုံးဖြတ်တယ်။ ...
လူသိများပြီး အသုံးများတဲ့ sharding နည်းလမ်းတစ်ခုစီကိုပုံနှင့်တကွဖတ်နိုင်ပါတယ်။ ...