လွယ်လွယ်ပြောရရင် NoSQL ဆိုတာ ဇယားပုံစံ မဟုတ်ဘဲ တခြားပုံစံနဲ့ ဒေတာ သိမ်းတဲ့ Database အမျိုးအစားပါ။ SQL Database က Excel ဇယားလို အတန်းလိုက် အကော်လံလိုက် သိမ်းတယ် ဆိုရင် NoSQL က ပစ္စည်းတွေကို Label ကပ်ပြီး အိတ်ထဲ ထည့်ထားသလိုပါ။ ဇယားပုံစံ အတိအကျ မလိုတဲ့ ဒေတာတွေအတွက် NoSQL က ပိုအဆင်ပြေပါတယ်။
ကျွန်တော် ဒါကို ဗီရိုနဲ့ ဥပမာပေးချင်တယ်။ SQL Database က အံဆွဲတွေ ခွဲထားတဲ့ ဗီရိုပါ။ အကျီ အံဆွဲ၊ ဘောင်းဘီ အံဆွဲ၊ ခြေအိတ် အံဆွဲ ဆိုပြီး နေရာတိုင်းကို ကြိုသတ်မှတ်ထားတယ်။ အရာတိုင်း သူ့နေရာနဲ့သူ ရှိတယ်၊ ရှာရလွယ်တယ်။ ဒါပေမယ့် ဗီရိုထဲ ထည့်ချင်တဲ့ ပစ္စည်းက အံဆွဲနဲ့ မကိုက်ရင် ဒုက္ခရောက်ပြီ။ NoSQL ကကျတော့ အိတ်ကြီးတွေ အများကြီးပါ။ အိတ်တစ်လုံးမှာ Label ကပ်ထားတယ် — “ဆောင်းရာသီ အဝတ်အစား”၊ “အားကစား ပစ္စည်း” ဆိုပြီး။ အိတ်ထဲမှာ ဘာထည့်ထည့် ရတယ်၊ အသစ်ထပ်ထည့်ချင်ရင်လည်း အိတ်အသစ် တစ်လုံး ထပ်ယူရုံပါပဲ။
NoSQL အမျိုးအစား ၄ မျိုး
NoSQL ဆိုတာ တစ်ခုတည်း မဟုတ်ပါဘူး။ ဒေတာ သိမ်းတဲ့ ပုံစံကွဲတဲ့ အမျိုးအစား ၄ မျိုး ရှိပါတယ်။
Document Database — MongoDB, CouchDB တို့ပါ။ ဒေတာကို JSON နဲ့ တူတဲ့ Document အဖြစ် သိမ်းပါတယ်။ ဥပမာ User တစ်ယောက်ရဲ့ အချက်အလက်အကုန်လုံးကို Document တစ်ခုတည်းမှာ ထည့်ထားလို့ရတယ်။ နာမည်၊ အီးမေးလ်၊ လိပ်စာ၊ ဝယ်ခဲ့တဲ့ ပစ္စည်းတွေ အားလုံးကို တစ်နေရာတည်း တွေ့ရတယ်။
Key-Value Database — Redis, DynamoDB တို့ပါ။ Dictionary လိုပါပဲ။ Key တစ်ခုနဲ့ Value တစ်ခု တွဲထားတယ်။ “user:1001” ဆိုတဲ့ Key ကို ပေးလိုက်တာနဲ့ အဲဒီ User ရဲ့ ဒေတာ ချက်ချင်း ပြန်ရတယ်။ Cache လုပ်ဖို့နဲ့ Session သိမ်းဖို့မှာ အရမ်း မြန်ပါတယ်။
Wide-Column Database — Cassandra, HBase တို့ပါ။ ဒေတာ အများကြီးကို အကော်လံအကျယ်ကြီးနဲ့ သိမ်းတယ်။ Facebook, Netflix တို့လို ဒေတာ ဘီလီယံချီ ရှိတဲ့ ကုမ္ပဏီတွေ သုံးပါတယ်။
Graph Database — Neo4j တို့ပါ။ ဒေတာတွေ ဘယ်လို ဆက်စပ်နေလဲ ဆိုတာကို အဓိကထားတယ်။ “ဒီလူက ဘယ်သူ့ရဲ့ သူငယ်ချင်းလဲ” “ဒီလမ်းက ဘယ်မြို့ကို ဆက်လဲ” ဆိုတဲ့ မေးခွန်းမျိုးတွေမှာ အရမ်း ကောင်းပါတယ်။
MongoDB နဲ့ ဥပမာ
MongoDB က အခုခေတ် အသုံးအများဆုံး NoSQL Database ပါ။ SQL မှာ User တစ်ယောက်ရဲ့ ဒေတာကို Table ၃ ခု ၄ ခုမှာ ခွဲသိမ်းရတယ် ဆိုရင် MongoDB မှာတော့ Document တစ်ခုတည်းမှာ အကုန်ထည့်ထားလို့ရတယ်။
{
"name": "Min SiThu",
"email": "alex@minsithu.org",
"city": "Bangkok",
"orders": ["Book", "Keyboard", "Mouse"]
}
ဒီ Document ကို မြင်တာနဲ့ User အကြောင်း အကုန်လုံး သိရတယ်။ Field အသစ် ထပ်ထည့်ချင်ရင်လည်း Table ကို ပြင်စရာ မလိုဘူး။ Document ထဲမှာ “phone”: “0812345678” ဆိုပြီး တစ်ကြောင်းပဲ ထပ်ထည့်လိုက်ရုံပါ။ SQL မှာတော့ Column အသစ် ထည့်ရမယ်၊ Table တစ်ခုလုံးကို ပြန်စစ်ရမယ်ပေါ့။
ဘယ်အချိန်မှာ NoSQL သုံးသင့်လဲ?
NoSQL က အကုန်လုံးအတွက် အကောင်းဆုံး မဟုတ်ပါဘူး။ သုံးသင့်တဲ့ အချိန်နဲ့ မသုံးသင့်တဲ့ အချိန် ရှိပါတယ်။
NoSQL သုံးသင့်တဲ့အခါ
ဒေတာ ပုံစံ မတည်ငြိမ်တဲ့အခါ — App အသစ်မှာ Field တွေ ခဏခဏ ပြောင်းနေရင် NoSQL က ပိုလွတ်လပ်ပါတယ်။
ဒေတာ အများကြီး မြန်မြန် သိမ်းရတဲ့အခါ — တစ်စက္ကန့်ကို ဒေတာ ထောင်ချီ ဝင်လာတဲ့ Game Score၊ IoT Sensor ဒေတာမျိုးမှာ NoSQL က ပိုကောင်းပါတယ်။
Server အများကြီးကို ဖြန့်ပြီး သိမ်းချင်တဲ့အခါ — NoSQL က အစကတည်းက Server အများကြီးမှာ ခွဲသိမ်းဖို့ ဒီဇိုင်းလုပ်ထားတာပါ။
SQL ပိုကောင်းတဲ့အခါ
ငွေကြေးနဲ့ ပတ်သက်တဲ့အခါ — ဘဏ်အကောင့်၊ ငွေလွှဲတာမျိုးမှာ ဒေတာ တစ်လုံးမှ မမှားရပါဘူး။ SQL ရဲ့ ACID စနစ်က ဒီအတွက် အကောင်းဆုံးပါ။
ဒေတာတွေ အချင်းချင်း ဆက်စပ်မှု ရှုပ်တဲ့အခါ — ဥပမာ ကျောင်းမှာ ကျောင်းသား၊ ဆရာ၊ အတန်း၊ ဘာသာရပ် ဆက်စပ်မှုမျိုးမှာ SQL က ပိုရှင်းပါတယ်။
Report တွေ ခဏခဏ ထုတ်ရတဲ့အခါ — “ဒီလ ဘယ်မြို့က ဘယ်လောက် ရောင်းရလဲ” ဆိုတဲ့ မေးခွန်းမျိုးမှာ SQL က ပိုအဆင်ပြေပါတယ်။
ကျွန်တော်ကိုယ်တိုင်ကတော့ ဒီလို မှတ်ထားပါတယ်။ ဒေတာ ပုံစံ တိကျပြီး မှန်ကန်မှု အရေးကြီးရင် SQL၊ ဒေတာ ပုံစံ ပြောင်းလဲနေပြီး အများကြီး မြန်မြန် သိမ်းရရင် NoSQL။ ကုမ္ပဏီကြီးတွေတောင် နှစ်မျိုးလုံးကို တွဲသုံးကြပါတယ်။ ဥပမာ User အကောင့်နဲ့ ငွေပေးချေမှုကို SQL နဲ့ သိမ်းပြီး User ရဲ့ လုပ်ဆောင်ချက် မှတ်တမ်းတွေကို NoSQL နဲ့ သိမ်းတာမျိုးပါ။
ဒါကြောင့် NoSQL နဲ့ SQL က ပြိုင်ဘက်တွေ မဟုတ်ပါဘူး။ ကိရိယာ နှစ်မျိုးပါ။ ဝက်အူလှည့်နဲ့ တူက ဘာကောင်းလဲ မေးသလို မဟုတ်ပါဘူး။ အလုပ်နဲ့ ကိုက်တဲ့ ကိရိယာကို ရွေးသုံးတတ်ဖို့ပဲ လိုပါတယ်။ 🙂
—
