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 နည်းလမ်းတစ်ခုစီကိုပုံနှင့်တကွဖတ်နိုင်ပါတယ်။
Range based Sharding
Data ကို range အလိုက်ဖြန့်ဝေတာ။ ဥပမာ - ပထမ server မှာ A ကနေ I အထိ နာမည်စတဲ့လူတွေရဲ့ data ကိုထည့်ပြီး ဒုတိယမှာ J ကနေ S အထိ ပြီးတော့ တတိယမှာ T ကနေ Zအထိပေါ့။ ဒီမှာဆိုရင် user ရဲ့ နာမည်ပေါ်မူတည်ပြီး shard key ထုတ်တယ်။ ဒီလိုလုပ်ခြင်း hot spots ခေါ် data မညီညာတာက်ို ဖြစ်စေနိုင်တယ်။
ဥပမာ - A ကနေ I မှာ user ၁ သိန်း လောက်ရှိပြီး J ကနေ S မှာ အယောက်၁၀၀ ဘဲဖြစ်နေတတ်တယ်။ resource တွေမသုံးရဘဲ idle ဖြစ်ပြီး waste ဖြစ်တယ်။
Directory-based Sharding
Directory လို့ပြောတဲ့အတိုင်း ဘယ် data က ဘယ် shard မှာ သိမ်းတယ် ဆိုတာကို redis လိုမျိုး cache layer နဲ့ lookup table လုပ်ထားတယ်။ အားသာချက်က data ကို ဘယ် shard မှာဖြစ်ဖြစ်ထည့်လို့ရတယ်။ lookup table မှာ record လုပ်ထားရင် အဆင်ပြေတယ်။
ဒီပင်မဲ့ latency အနည်းငယ်ပေးစပ်ရတယ်။ operations တိုင်းက lookup table ကို အမြဲကြည့်ရတယ်။ သာမန် app မှာတော့ မသိသာပင်မဲ့ high frequency application တွေမှာတော့ ပြသနာဘဲ။ နောက်တစ်ခု က directory down ရင် sharding အလုပ်မဖြစ်တော့ဘူး။
Geo sharding
နေရာအလိုက် data ကို ဖြန့်ဝေတာ။ စင်ကပူမှာရှိတဲ့သူတွေရဲ့ data ကို စင်ကပူမှာဘဲထားပြီး UK အတွက်ကလူတွေတော့ London က server မှာထားတာပေါ့။ shard key ကို နိုင်ငံ ဒါမှမဟုတ် မြို့ကို သက်မှတ်ပြီး user location အရ data ကိုဖြန့်ဝေတယ်။ legal ကြောင့်နဲ့ latency ကြောင့်ရော သုံးပါတယ်။
နည်းလမ်း ရွေးပြီးသွားပြီးရင်လည်း data သဘောတရား အရဆက်ပြောင်းနေမှာပါ။ data hotspots တွေ performance ပြသနာတွေရှိလာရင် အောက်ကအချက်တွေနဲ့ ပြန်ကောင်းအောင်လုပ်ရတယ် (optimize)။
၁။ Cardinality: ကိုယ်သုံးတဲ့ field ရဲ့ မတူညီတဲ့ value ကဘယ်လောက်ရှိလဲ။ ဥပမာ - order status ဆိုရင် active, inactive နဲ့ pending ရှိတယ်ဆိုရင် shard က သုံးခုထိဘဲ limit သွားမယ်။
၂။ Frequency: ကိုယ့်သုံးတဲ့ field က data cardinality ကောင်းနေပင်မဲ့ value က တစ်ခုဘဲ ထပ်တာများလာရင် လည်း တခြား field ကို သုံးရပါတယ်။ ဥပမာ - မြန်မာပြည်မှာကမြို့ကို shard key အနေသုံးလိုက်ဆိုပါစို့။ သုံးတဲ့ သူအများစုက ရန်ကုန်က ဘဲ ဖြစ်နေတော့ ရန်ကုန် shard မှာ data တွေများလာတယ်။
၃။ monotonic change: monotonic ဆိုတာ data က direction တစ်ခုဘဲသွားနေတာကိုဆိုလိုတယ်။ ဥပမာ - order အချိန်တွေ ၊ auto increment idတွေ။ အဲ့လို field ကို shard key အနေနဲ့ သုံးရင် အသစ်လာတဲ့ data တွေကဘဲ shard တစ်ခုရောက်နေတတ်တယ်။ ဥပမာ - order timestamp နဲ့လုပ်တယ်ဆိုရင် traffic workload တွေက နောက်ဆုံးလုပ်ထားတဲ့ shardမှာ ဘဲ ရောက်နေပြီး performance ကိုနောက်နှေးစေတယ်။
Conclusion
There is no one-solution-fits-all approach.
Sharding strategies တွေက သူ့လိုအပ်ချက်နဲ့သူရှိနေပြီး ကို့ရဲ့ database design အရ လိုရင် လိုအပ်တလိုသုံးရတယ်။ နည်းလမ်းမသုံးခင် problem ကို အရင်မြင်အောင်ကြည့်ပြီး ဘယ် approach ကသင့်တော်ပြီး ဘယ်လို ပေါင်းသုံးလို့ရတယ် ဆိုတာဆုံးဖြတ်ရပါတယ်။
ဒီလောက်ဆို database sharding ကို overview နားလည်မယ်လို့မျှော်လင့်ပါတယ်။
Apr 5, 2026
အရင် blog အဆက် ...
Applications မှာ သုံးလာတဲ့သူများလာတာနဲ့အမြဲ scale လုပ်ဖို့ လိုအပ်လာတယ်။ Scaling လုပ်ရင်ဘာကောင်းမှုတွေရှိလဲ။ ၁။ system ရဲ့ reliability နဲ့ availability ကိုမြင့်စေတယ်။ ၂။ response လုပ်တဲ့ခါ performance ကောင်းစေတယ်။ ၃။ storage နဲ့ data များပြားလာမှုကို အထောက်အကူလုပ်ပေးတယ်။ ...