လွယ်လွယ်ပြောရရင် Database Sharding ဆိုတာ database တစ်ခုတည်းမှာ ဒေတာ အများကြီး သိမ်းရင် လေးလာလို့၊ ဒေတာကို အပိုင်းပိုင်းခွဲပြီး server အများကြီးပေါ် ဖြန့်သိမ်းတဲ့ နည်းလမ်းပါ။
Facebook, Shopee လို app တွေမှာ user သန်းပေါင်းများစွာ ရှိတယ်။ user အားလုံးရဲ့ data ကို server တစ်လုံးတည်းမှာ သိမ်းထားရင် တစ်နေ့ server က မခံနိုင်တော့ဘူး။ စာအုပ်စင် တစ်စင်တည်းမှာ စာအုပ် တစ်သိန်းထည့်သလို — စင်က ပြိုကျသွားမှာပဲ။ Sharding က စာအုပ်စင်ကို ဆယ်စင်ခွဲပြီး စာအုပ်တွေကို ခွဲထည့်သလိုပဲ။
စာကြည့်တိုက်နဲ့ နှိုင်းကြည့်မယ်
စာကြည့်တိုက် တစ်ခုမှာ စာအုပ် တစ်သန်း ရှိတယ်ဆိုပါစို့။ စာအုပ်တိုင်းကို အခန်းတစ်ခန်းတည်းမှာ ရှာရရင် စာကြည့်တိုက်မှူးက တစ်နေ့လုံး ရှာနေရမယ်။
ဒါကြောင့် စာအုပ်တွေကို အမျိုးအစားအလိုက် အခန်းတွေ ခွဲတယ်။ A–F အခန်း၊ G–M အခန်း၊ N–Z အခန်းဆိုပြီး။ စာဖတ်သူက “M” နဲ့ စတဲ့ စာရေးဆရာရဲ့ စာအုပ်ကို လိုချင်ရင် G–M အခန်းကိုပဲ သွားရတယ်။ တခြားအခန်းတွေကို ရှာစရာ မလိုဘူး။ အခန်းတွေ များလေ ရှာရတာ မြန်လေပဲ။
Database Sharding ကလည်း အဲဒီလိုပဲ။ user data ကို shard လို့ခေါ်တဲ့ အပိုင်းတွေခွဲပြီး server တစ်ခုစီမှာ သိမ်းတယ်။
ဘယ်လို ခွဲသလဲ? — Shard Key
ခွဲဖို့ စည်းမျဉ်း တစ်ခု လိုတယ်။ ဒါကို Shard Key လို့ ခေါ်တယ်။
User ID အလိုက် ခွဲတာ — ID 1–100000 က shard ၁၊ 100001–200000 က shard ၂။ အရိုးရှင်းဆုံး နည်းပါ။
ဒေသအလိုက် ခွဲတာ — မြန်မာက user တွေက အာရှစင် server မှာ၊ ဥရောပက user တွေက ဥရောပ server မှာ။ user နဲ့ နီးတဲ့ server က မြန်မြန် တုံ့ပြန်တယ်။
Hash အလိုက် ခွဲတာ — user ID ကို hash function နဲ့ တွက်ပြီး ဘယ် shard မှာ သိမ်းမလဲဆိုတာ ဆုံးဖြတ်တာ။ data က shard တိုင်းမှာ ညီညီမျှမျှ ဖြန့်သွားတယ်။
Shard Key ရွေးတာ အရေးအကြီးဆုံးပါ။ key ကို မှားရွေးရင် data အားလုံးက shard တစ်ခုတည်းမှာ စုသွားပြီး တခြား shard တွေက အားနေမယ်။ ဒါကို Hot Shard ပြဿနာ လို့ ခေါ်တယ်။ ဥပမာ နာမည်ကြီး celebrity တစ်ယောက်ရဲ့ follower တွေအားလုံးက shard တစ်ခုတည်းမှာ ရှိရင် အဲဒီ shard က ဝန်ပိသွားမယ်။
Sharding ရဲ့ အားသာချက်
မြန်တယ် — query တစ်ခုက shard တစ်ခုတည်းကိုပဲ သွားမေးရလို့ ရှာစရာ data နည်းသွားတယ်။
ကြီးထွားလို့ ရတယ် — user များလာရင် shard အသစ် ထပ်ထည့်ရုံပဲ။ server တစ်လုံးကို အကြီးကြီး ဝယ်စရာ မလိုဘူး။
တစ်ခုပျက်လည်း ကျန်တာတွေ အလုပ်လုပ်တယ် — shard တစ်ခု ကျသွားလည်း တခြား shard တွေက ဆက်အလုပ်လုပ်နေတယ်။
Sharding ရဲ့ ခက်ခဲချက်
ဒါပေမယ့် အလကား မရဘူး။ ခက်ခဲတာတွေလည်း ရှိတယ်။
Join လုပ်ရ ခက်တယ် — shard နှစ်ခုမှာ ရှိတဲ့ table နှစ်ခုကို ဆက်ပြီး မေးချင်ရင် ရှုပ်သွားတယ်။
Transaction ခက်တယ် — shard နှစ်ခုလုံးမှာ တစ်ပြိုင်နက် ပြောင်းလဲရတဲ့ အလုပ်ဆိုရင် တစ်ဖက်က အောင်ပြီး တစ်ဖက်က ကျရင် ဒုက္ခရောက်တယ်။
ပြန်ပေါင်းရ ခက်တယ် — အရင်က shard တွေခွဲထားတဲ့ data ကို ပြန်ပေါင်းချင်ရင် အလုပ်ကြီးတယ်။
ခွဲတာ ပြန်ပြင်ရ ခက်တယ် — shard key ကို နောက်မှ ပြောင်းချင်ရင် data အကုန်လုံးကို ပြန်ဖြန့်ရတယ်။
ဘယ်အချိန်မှ Sharding လုပ်သင့်လဲ?
အရေးကြီးတဲ့ စည်းမျဉ်းတစ်ခုရှိတယ် — အစကတည်းက sharding မလုပ်ပါနဲ့။
App အသေးလေးမှာ database တစ်လုံးတည်းနဲ့ လုံလောက်တယ်။ Index ကောင်းကောင်း သုံးတာ၊ query ကို ပြင်တာ၊ cache ထည့်တာနဲ့ အတော်အတန် အထိ ခံနိုင်တယ်။ user သန်းချီများလာပြီး server တစ်လုံးက တကယ် မခံနိုင်တော့မှ sharding ကို စဉ်းစားပါ။ အစောကြီး shard လုပ်ရင် ရှုပ်ထွေးမှုကိုပဲ အလကား ဝယ်မိသလို ဖြစ်သွားမယ်။
ဒါကြောင့် developer တွေက “shard later, not sooner” လို့ ပြောကြတယ်။
Database ကြီးလာရင် ခွဲရမယ်။ ဒါပေမယ့် ခွဲတာ စောလွန်းရင် ဒုက္ခရောက်တယ်၊ နောက်ကျလွန်းရင်လည်း server ပြိုကျတယ်။ အချိန်မှန်မှန်မှာ ခွဲတတ်တာကပဲ system ကြီးတွေကို ရှင်သန်စေတာပါ။ 🙂
