Jul 30, 2023
Dependency Injection (DI) ဆိုသည်မှာ object တစ်ခုက သူလိုအပ်သည့် object (တနည်းအားဖြင့် dependency) ကို ကိုယ်တိုင် ဖန်တီးစရာ မဟုတ်ဘဲ အခြား framework ကဖြစ်ဖြစ် container က ဖြစ်ဖြစ် create လုပ်ပေးခြင်းဘဲ ဖြစ်တယ်။
ပုံမန်တမန်ရိုး ကျဆိုရင် object တခုဟာ သူလိုအပ်သည့် object ကို ကို့ကို new keyword ဖြင့် ဖန်တီး (instantiate) ရပါတယ်။ ဥပမာ -
1//Without DI
2public class Car {
3 private Battery battery = new Battery();
4}ဤ code အတိုင်းဆိုရင် car ဆိုသည့် object ဟာ battery ကို သုံးချင်တော့ car manufacturer ကိုယ် တိုင်ကပြုလုပ် ရတယ်ပေါ့။ ခက်တာ ကဘာလည်းဆို battery က တစ်ခုခု ဖြစ်သွားရင် ဘယ် အခြား third-party မှ ရှာလို့မရဘဲ သူတို့ကိုသူတို့ ဘဲ create လုပ်နိုင်တော့ dependent အရမ်း ဖြစ်တာပေါ့။ Car manufacturer က သူတို့ battery တက်ဆင်တာကို သူတို့ ပင်ကို battery ဘဲ ဖြစ်ဖြစ် အခြား ထိုင်း က လာတဲ့ battery တရုတ်လာတဲ့ battery တွေကို လည်း အသုံးပြုနိုင်အောင်လုပ်ထားရင် battery က တစ်ခုခု ဖြစ်ရင် manufacturer ကိုရှာ နေစရာ မလိုတော့ဘဲ interdependence ဖြစ်သွားတာပေါ့။ အောက်ပါ code scenario မှာ တော့ constructor injection ကိုပြထားပါတယ်။
1//With DI
2public class Car {
3 private final Battery battery;
4//Constructor Injection
5public Car(Battery battery) { this.battery = battery; }
6public static void main(String[] args) {
7 Battery batteryFromChina = ChinaBattery.make();
8 Battery batteryFromThailand = ThailandBattery.make();
9 //Injection happens here
10 Car car = new Car(batteryFromChina);
11 }
12}ဤ code မှာဆိုရင် battery ဆိုသည့် object ဟာ အရင်ဆုံး manufacturer က create လုပ်ပီးမှ car ဆိုသည့် object ထဲသို့ inject လုပ်၍ အသုံးပြုနိုင်ပါတယ်။ battery က ထိုင်းက လုပ်တာဘဲဖြစ်ဖြစ် တရုတ်က လုပ်တာဘဲဖြစ်ဖြစ် ပူစရာမလိုတော့ဘဲ car က ကောက်သုံး လိုက်ရုံပါဘဲ။ ထို့အပြင် setter injection ကို အသုံးပြု၍လည်း car မှာ အသုံးပြုနိုင်ပါသေးတယ်။ setter injection ရဲ့ အားသာချက်ဟာ ဤ dependency အား လိုမှသာလျှင် inject လုပ်စရာလိုပါတယ်။ ဥပမာ - ဒီကားက မီးလုံးလိုလားပေါ့။ မလိုရင်ထည့်စရာမလိုတော့ဘူး။ အထက် example ဟာ ဥပမာပြခြင်းဘဲဖြစ်ပါတယ်။ real implementation မှာတော့ framework မှာရှိတဲ့ Injector ကနေတဆင့် object တွေ ကို inject လုပ်ပေးပါတယ်။ Dependency Injection ကို အသုံးပြုခြင်းအားဖြင့် ရနိုင်မည့် ကောင်းကျိုးတွေကတော့ - object တစ်ခုဟာ အသုံးပြုမည့် dependency ကို ဘယ်လို create လုပ်ရမယ်လို့ သိစရာမလိုပါ။ - အသုံးပြုနေတဲ့ object ကို ဘာမှ ပြောင်းနေစရာမလိုဘဲ၊ dependency တွေကို အပြောင်းအလဲပြုလုပ်နိုင်ပါတယ်။ - Testing အပိုင်းမှာ dependency တွေကို mock (အတု) လုပ်၍ test ရေးထားနိုင်တယ်။ စသည်တို့ဘဲဖြစ်ပါတယ်။ DI ကို အသုံးပြုရာ တွင် “Coding to interface, not implementing” ဆိုတဲ့ principle ကိုတော့ လိုက်နာ ရပါတယ်။ ဤ principle အကြောင်းကို နောက် blog မှာ example နဲ့ တကွ ရှင်းပြသွားပါမယ်ဗျာ။
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 နည်းလမ်းတစ်ခုစီကိုပုံနှင့်တကွဖတ်နိုင်ပါတယ်။ ...