Apr 5, 2026
Applications မှာ သုံးလာတဲ့သူများလာတာနဲ့အမြဲ scale လုပ်ဖို့ လိုအပ်လာတယ်။ Scaling လုပ်ရင်ဘာကောင်းမှုတွေရှိလဲ။ ၁။ system ရဲ့ reliability နဲ့ availability ကိုမြင့်စေတယ်။ ၂။ response လုပ်တဲ့ခါ performance ကောင်းစေတယ်။ ၃။ storage နဲ့ data များပြားလာမှုကို အထောက်အကူလုပ်ပေးတယ်။
Applications မှာ သုံးလာတဲ့သူများလာတာနဲ့အမြဲ scale လုပ်ဖို့ လိုအပ်လာတယ်။ Scaling လုပ်ရင်ဘာကောင်းမှုတွေရှိလဲ။
၁။ system ရဲ့ reliability နဲ့ availability ကိုမြင့်စေတယ်။
၂။ response လုပ်တဲ့ခါ performance ကောင်းစေတယ်။
၃။ storage နဲ့ data များပြားလာမှုကို အထောက်အကူလုပ်ပေးတယ်။
System Design မှာ Vertical Scaling နဲ့ Horizontal Scaling ဆိုပြီးနည်းလမ်းနှစ်မျိုးရှိတယ်။
Vertical Scaling
Scaling up လို့လည်း ခေါ်တယ်။ ဥပမာ - ကိုယ်သုံးနေတဲ့ VM ( virtual machine ) မှာ နဂိုက memory 8GB နဲ့ 4vCPUs နဲ့ ဖွင့်ထားတယ်။ သုံးတဲ့သူတွေများလာတော့ CPU နဲ့ RAM ရဲ့ utilization က 95% လောက်ရှိလာတယ်ဆိုပါစို့။ အဲ့ချိန်မှာ CPU ကို 8vCPU ထိထက်တိုးပြီး RAM ကို 16 GB ထိထက်တိုးတယ်။ အဲ့ဒီလိုနည်းလမ်းကို vertical scaling လို့ခေါ်တယ််။ ကိုယ့်အိမ်မှာ ရှိတဲ့ PC က game အသစ်ဆော့ဖို့ မနိုင်တော့လို့ ဒီထက်ပိုကောင်းတဲ့ CPU နဲ့ RAM ကိုပြောင်းသုံးတလိုပါဘဲ။ ပိုကောင်းတဲ့ Hardware size တွေ တိုးလိုက်တာကိုဆိုလိုပါတယ်။
Vertical Scaling ရဲ့ အားသာချက်
၁။ Implement လုပ်ဖို့ လွယ်ကူတယ်။ Hardware size ကို မြင့်တင်လိုက်ရုံဘဲ။
၂။ ထိန်းသိမ်းရတာ လွယ်တယ်။ မြင့်တင်လိုက်တဲ့ VM ကို manage လုပ်ရုံဘဲ။
၃။ short term မှာ cost က effective ဖြစ်ပြီး predictable ဖြစ်တယ်။
Vertical Scaling ရဲ့ အားနည်းချက်
၁။ Hardware size ဟာ limit ရှိတယ်။ အမြင့်ဆုံး hardware size ထက်ကျော်ပြီး scale လုပ်လို့မရဘူး။
၂။ VM တစ်ခု down သွားရင် ( hack ခံရရင်) အကုန်လုံး down ဖြစ်တယ်။ Single Point of Failure လို့ခေါ်တယ်။
၃။ Scaling up လုပ်တဲ့အခါ machine ကို restart နဲ့ replace လုပ်ရလို့ downtime ရှိတယ်။
Vertical Scaling Tools နဲ့ services များ
၁။ AWS EC2 Instance Resize
၂။ AWS RDS
၃။ Azure VM Resize
၄။ Google Cloud Machine Types
၅။ Kubernetes Vertical Pod AutoScaler
Horizontal Scaling
Scaling Out လို့လည်းခေါ်တယ်။ server တစ်ခုကိုဘဲ hardware မြင့်တင်တာမဟုတ်ဘဲ နဲ့ နောက်ထက်တူတဲ့ servers တွေပြန်ပေါင်းထည့်ပြီး traffic တွေကို load balancer နဲ့ ဖြန့်ဝေ (distribute) တာကိုခေါ်တယ်။ ဥပမာ - နဂိုရှိတဲ့ 8 core server ကို နောက်ထက် သုံးခုလောက် replicate လုပ်ပြီး အရှေ့မှာ load balancer proxy နဲ့ traffic တွေ ဖြန့်ဝေတာ။
Horizontal Scaling ရဲ့ အားသာချက်
၁။ Availability မြင့်တင်ပေးတယ်။ server တစ်ခု down ရင်လည်း နောက်ထက် ရှိနေတဲ့ servers နဲ့ handle လုပ်နိုင်တယ်။ Fault tolerance ကိုမြင့်တင်ပေးတယ်လို့ခေါ်တယ်။
၂။ limit မရှိဘဲ ကိုယ် လိုတလောက် servers ထည့်လို့ရတယ်။
၃။ server တစ်ခုတည်းက ဘဲ handle ရတာမဟုတ်လို့ overall performance မြင့်တင်ပေးတယ်။
Horizontal Scaling ရဲ့ အားနည်းချက်
၁။ distribution လုပ်ဖို့ complex ဖြစ်တယ်။ stateful applications တွေဖြစ်တဲ့ database servers တွေမှာ ပိုခက်ခဲတယ်။ ဥပမာ - database sharding လုပ်တဲ့ ခါ joins နဲ့ rebalance လုပ်ဖို့ complex ဖြစ်တယ်။
၂။ nodes တွေ consistent ဖြစ်ဖြစ်နဲ့ Maintain လုပ်ဖို့ ခက်ခဲတယ်။ synchronization, replication တွေထည့်စဉ်းစားရတယ်။
၃။ အစမှာ စျေးများတယ်။ network services တွေ orchestration tools (e.g Kubernetes , Ansible) တွေသုံးရတယ်။
Horizontal Scaling Tools နဲ့ services များ
၁။ AWS Elastic load balancer
၂။ Nginx
၃။ HAProxy
၄။ Cloudflare Load Balancer
၅။ Google Cloud Run
၆။ Kubernetes
၇။ Google GKE
၈။ AWS EKS
Scaling approaches ရွေးတဲ့ခါ ကိုယ့်ရဲ့ budget နဲ့ business goals တွေကိုထည်းသွင်းစဉ်းစားရပါတယ်။ organizations အများစုက hybrid approach ကိုသုံးကြတယ်။
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 နည်းလမ်းတစ်ခုစီကိုပုံနှင့်တကွဖတ်နိုင်ပါတယ်။ ...