Alternative Databases (အခြား database နည်းလမ်းများ)

A3.4.1: Outline the different types of databases as approaches to storing data (NoSQL, cloud, spatial, in-memory).
မြန်မာလို: ဒေတာ သိမ်းဆည်းဖို့ နည်းလမ်းတွေအဖြစ် database (ဒေတာ သိမ်းဆည်းတဲ့ စနစ်) အမျိုးအစား အမျိုးမျိုးကို outline (အကျဉ်းချုပ် ဖော်ပြ) လုပ်နိုင်ရပါမယ်: NoSQL (ပုံသေ table ပုံစံ မသုံးတဲ့ database)၊ cloud (provider တစ်ခုရဲ့ server တွေပေါ်မှာ run ပြီး network ကနေ သုံးရတဲ့ database)၊ spatial (တည်နေရာနဲ့ ပုံသဏ္ဌာန် ဒေတာအတွက် database) နဲ့ in-memory (ဒေတာကို RAM ထဲမှာ ထားတဲ့ database)။

ဒီစာမျက်နှာက HL အဆင့်မှာပဲ အကဲဖြတ် စစ်ဆေးတဲ့ အကြောင်းအရာ ဖြစ်ပါတယ်။ SL (Standard Level) နဲ့ HL (Higher Level) ဆိုတာ IB Computer Science (နိုင်ငံတကာ ကျောင်းတွေမှာ သင်တဲ့ ကွန်ပျူတာသိပ္ပံ သင်ရိုး) သင်တန်းရဲ့ အဆင့်နှစ်ဆင့်ဖြစ်ပြီး HL အပိုင်းတွေက ပိုနက်နက်ရှိုင်းရှိုင်း လေ့လာရတဲ့ အပိုင်းတွေပါ။

အဓိက အယူအဆများ

Relational Model အစား တခြား နည်းလမ်းတွေ ဘာကြောင့် ရှိသလဲ

Relational model (ဒေတာကို ချိတ်ဆက်ထားတဲ့ table တွေထဲမှာ သိမ်းတဲ့ ပုံစံ) ကို အများအားဖြင့် ရွေးကြတာ အကြောင်းကောင်းတွေ ရှိလို့ပါ: အစွမ်းထက်တဲ့ query (database ထဲက ဒေတာကို ရှာ၊ ပြင်ဖို့ ပေးတဲ့ အမိန့်) တွေ၊ သေချာ စမ်းသပ်ပြီးသား tool တွေ၊ relational database (table တွေ ချိတ်ဆက်ထားတဲ့ database) စနစ် အများစုက ပေးတဲ့ ACID (transaction တစ်ခုရဲ့ အာမခံချက် လေးခု) ဆိုတဲ့ ခိုင်မာတဲ့ အာမခံချက်တွေနဲ့ ဒီ model ကို ဆယ်စုနှစ်ချီ run လာခဲ့တဲ့ အတွေ့အကြုံ ရှိပါတယ်။ ACID ဆိုတာ Transactions and Views အပိုင်းမှာ လေ့လာခဲ့တဲ့ atomicity (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ်)၊ consistency (မှန်ကန်တဲ့ အခြေအနေကနေ မှန်ကန်တဲ့ အခြေအနေကိုပဲ ပြောင်းခြင်း)၊ isolation (တစ်ပြိုင်နက် run နေတဲ့ transaction တွေ အချင်းချင်း မနှောင့်ယှက်ခြင်း) နဲ့ durability (commit လုပ်ပြီးရင် ဒေတာ မပျောက်တော့ခြင်း) တို့ပါ။ ဒါပေမယ့် relational model က workload (database တစ်ခု ကိုင်တွယ်ရတဲ့ အလုပ်ရဲ့ အမျိုးအစားနဲ့ ပမာဏ) တိုင်းနဲ့ မကိုက်ညီပါဘူး။ အဖွဲ့အစည်းတွေ တခြား နည်းလမ်းတွေကို စဉ်းစားလာစေတဲ့ ဖိအား လေးခု ရှိပါတယ်:

  1. Scale (ဒေတာနဲ့ အလုပ် ပမာဏ ကြီးထွားမှု)။ ဒေတာ ဒါမှမဟုတ် write (ဒေတာ ရေးခြင်း) အရေအတွက်က server (တခြား ကွန်ပျူတာတွေကို ဝန်ဆောင်မှု ပေးတဲ့ ကွန်ပျူတာ) တစ်လုံးအတွက် များလွန်းလာတဲ့အခါ ဒေတာကို server အများကြီးပေါ်မှာ ခွဲဖြန့်ထားရပါတယ်။ အဲဒီ server အားလုံးကြားမှာ join (ဆက်စပ်တဲ့ table တွေကို ပေါင်းပြီး ဒေတာ ယူခြင်း) တွေနဲ့ ACID အာမခံချက်တွေ ဆက်အလုပ်လုပ်နေအောင် ထိန်းဖို့ ညှိနှိုင်းမှု အများကြီး လိုပါတယ်။ ဒါကြောင့် စနစ်က တစ်စက္ကန့်မှာ write ဘယ်နှစ်ကြိမ် ကိုင်တွယ်နိုင်လဲ ဆိုတာ ကန့်သတ်ခံရနိုင်ပါတယ်။
  2. ဒေတာရဲ့ ပုံသဏ္ဌာန်။ Field (record တစ်ခုထဲက အချက်အလက် တစ်ကွက်) တွေ တစ်ခုနဲ့ တစ်ခု မတူကြတဲ့ document (field တွေနဲ့ သူတို့ရဲ့ တန်ဖိုးတွေ စုထားတဲ့ ဒေတာ တစ်ခု) တွေ၊ လူတွေနဲ့ သူတို့ အချင်းချင်း ချိတ်ဆက်မှုတွေ၊ ပထဝီ ပုံသဏ္ဌာန်တွေ၊ sensor (ပတ်ဝန်းကျင် အပြောင်းအလဲကို ထောက်လှမ်းတဲ့ ကိရိယာ) တွေက အဆက်မပြတ် ပို့နေတဲ့ တိုင်းတာချက်တွေနဲ့ machine learning (ဒေတာကနေ သင်ယူတဲ့ စနစ်) model တွေ သုံးတဲ့ ဂဏန်း စာရင်းရှည်တွေ (vector) က row (အလျားလိုက် အတန်း) နဲ့ column (ဒေါင်လိုက် ကော်လံ) ပါတဲ့ table (database ထဲက ဇယား) တွေထဲကို သပ်သပ်ရပ်ရပ် မဝင်ပါဘူး။
  3. Latency (တောင်းဆိုမှုနဲ့ တုံ့ပြန်မှုကြား နှောင့်နှေးချိန်)။ တချို့ application တွေမှာ read (ဒေတာ ဖတ်ခြင်း) တစ်ခုစီကို millisecond (တစ်စက္ကန့်ရဲ့ တစ်ထောင်ပုံ တစ်ပုံ) တစ်ခုထက် နည်းတဲ့ အချိန်အတွင်း ဖြေပေးဖို့ လိုပါတယ်: real-time bidding (ဝဘ်စာမျက်နှာ တစ်ခု ပွင့်လာနေတုန်းမှာပဲ ကြော်ငြာနေရာအတွက် အလိုအလျောက် လုပ်တဲ့ လေလံပွဲ)၊ multiplayer game (လူအများ အတူ ကစားတဲ့ game) တွေနဲ့ ကတ်နဲ့ ငွေပေးချေမှုတွေ ဖြစ်နေတုန်းမှာပဲ လိမ်လည်မှု ဟုတ်မဟုတ် စစ်ဆေးခြင်း တို့ပါ။ Disk (ကွန်ပျူတာရဲ့ storage) ကနေ ဖတ်ရတဲ့ relational database က အဲဒီလောက် မြန်မြန် ဖြေဖို့ ခက်နိုင်ပါတယ်။
  4. လည်ပတ်ရ ရိုးရှင်းမှု။ အဖွဲ့ငယ်လေး တစ်ဖွဲ့က server တွေကို ကိုယ်တိုင် စီမံမယ့်အစား cloud provider (cloud ဝန်ဆောင်မှု ပေးတဲ့ ကုမ္ပဏီ) ကို ငွေပေးပြီး database ကို run ခိုင်းတာကို ပိုသဘောကျနိုင်ပါတယ်။

သိထားသင့်တဲ့ အခြား နည်းလမ်း လေးခု ရှိပါတယ်: NoSQL၊ cloud၊ spatial နဲ့ in-memory database တွေပါ။ ဒီလေးခုက database တစ်ခုရဲ့ မတူတဲ့ အချက်တွေကို ဖော်ပြတာပါ:

  • NoSQL က data model (ဒေတာ ဖွဲ့စည်းပုံ ပုံစံ) ကို ဖော်ပြပါတယ်: ဒေတာကို ချိတ်ဆက်ထားတဲ့ table တွေထဲမှာ မထားတဲ့အခါ ဘယ်လို စုစည်းထားလဲ ဆိုတာပါ။
  • Cloud က database ကို ဘယ်မှာ run လဲ နဲ့ ဘယ်သူ ထိန်းသိမ်းလဲ ဆိုတာကို ဖော်ပြပါတယ်။
  • Spatial က ဒေတာ အမျိုးအစား ကို ဖော်ပြပါတယ်: တည်နေရာတွေ၊ ပုံသဏ္ဌာန်တွေနဲ့ အဲဒါတွေအကြောင်း မေးတဲ့ မေးခွန်းတွေပါ။
  • In-memory က လက်ရှိ သုံးနေတဲ့ ဒေတာကို ဘယ်မှာ ထားလဲ ဆိုတာကို ဖော်ပြပါတယ်: disk ပေါ်မှာ မဟုတ်ဘဲ RAM (ပါဝါပိတ်ရင် ပျောက်တဲ့ အဓိက memory) ထဲမှာပါ။

ဒါကြောင့် database တစ်ခုက နည်းလမ်း တစ်ခုထက် ပိုပြီး ပါဝင်နိုင်ပါတယ်။ ဥပမာ PostGIS extension (PostgreSQL ကို spatial လုပ်ဆောင်ချက်တွေ ထပ်ပေးတဲ့ အပိုထည့် အစိတ်အပိုင်း) ပါတဲ့ PostgreSQL က relational လည်း ဖြစ်၊ spatial လည်း ဖြစ်ပါတယ်။ ပြီးတော့ cloud provider က အဲဒါကို managed service (provider က ကိုယ့်အစား run ပေး၊ ထိန်းသိမ်းပေးတဲ့ ဝန်ဆောင်မှု) အဖြစ် run ပေးရင် cloud database လည်း ဖြစ်ပါတယ်။ လုပ်ငန်း မှတ်တမ်းတွေအတွက်တော့ relational database တွေကိုပဲ အများအားဖြင့် ဆက်ရွေးကြပါတယ်။ Server တစ်လုံးရဲ့ disk ပေါ်က relational database နဲ့ workload က သိပ်မကိုက်ညီတဲ့ နေရာတွေမှာ ဒီနည်းလမ်း တစ်ခုစီက အထောက်အကူ ဖြစ်ပါတယ်။

NoSQL Databases (ပုံသေ table ပုံစံ မသုံးတဲ့ database များ)

NoSQL (“Not Only SQL” ဒါမှမဟုတ် “Non-SQL”၊ SQL ဆိုတာ relational database တွေကို query လုပ်တဲ့ language ပါ) ဆိုတာ ဝဘ်ဆိုက်ကြီးတွေရဲ့ အလွန်များတဲ့ ဒေတာ ပမာဏနဲ့ traffic (network ပေါ်က ဒေတာ အသွားအလာ) ကို ကိုင်တွယ်ဖို့ 2000 ပြည့်လွန်နှစ်များမှာ ပေါ်လာခဲ့တဲ့ non-relational (relational မဟုတ်တဲ့) database တွေကို ခေါ်တဲ့ အထွေထွေ နာမည်ပါ။ NoSQL က data model တစ်ခုတည်း မဟုတ်ပါဘူး: အဓိက family (အမျိုးအစား အုပ်စု) လေးခု ပါဝင်ပါတယ်။

အမျိုးအစား ဒေတာ သိမ်းပုံ အသုံးပြုပုံ ဥပမာ
Document (record တစ်ခုစီကို document တစ်ခုအဖြစ် သိမ်းတဲ့ အမျိုးအစား) (ဥပမာ MongoDB) Record (အချက်အလက် အများကြီး စုထားတဲ့ ဒေတာ တစ်ခု) တစ်ခုစီက JSON (ဒေတာကို နာမည်နဲ့ တန်ဖိုး တွဲပြီး စာသားနဲ့ ရေးတဲ့ စံ ပုံစံ) နဲ့ ဆင်တူတဲ့ document တစ်ခု ဖြစ်ပြီး item တစ်ခုအကြောင်း ဒေတာကို တစ်နေရာတည်းမှာ စုထားပါတယ်။ Document မှာ နာမည်ပေးထားတဲ့ field တွေနဲ့ သူတို့ရဲ့ တန်ဖိုးတွေ ပါပြီး တန်ဖိုးထဲမှာ list တွေနဲ့ nested (တစ်ခုထဲမှာ တစ်ခု) အပိုင်းတွေ ပါနိုင်ပါတယ်။ Document တစ်ခုစီမှာ မတူတဲ့ field တွေ ရှိနိုင်ပါတယ်။ ကုန်ပစ္စည်း စာရင်း (product catalogue) တွေနဲ့ item တစ်ခုစီမှာ ကိုယ်ပိုင် ဂုဏ်သတ္တိ အစု ရှိတဲ့ content management system (သတင်း ဝဘ်ဆိုက်နဲ့ တခြား ဝဘ်ဆိုက်တွေရဲ့ နောက်ကွယ်က software) တွေ
Key-value (key နဲ့ value တစ်တွဲချင်း သိမ်းတဲ့ အမျိုးအစား) (ဥပမာ Redis၊ DynamoDB) ရိုးရှင်းတဲ့ key -> value ရှာဖွေမှု ဖြစ်ပြီး အလွန်မြန်ပါတယ်။ အခြေခံ model မှာ value ကို သူ့ key (value ကို ပြန်ရှာဖို့ သုံးတဲ့ တန်ဖိုး) နဲ့ ရှာရပြီး တခြား နည်းလမ်း သိပ်မရှိပါဘူး။ တချို့ product တွေက ပိုပြီး ထည့်ပေးပါတယ်။ ဥပမာ DynamoDB က secondary index (key မဟုတ်တဲ့ field တွေနဲ့ ရှာနိုင်အောင် ထပ်ဆောက်ထားတဲ့ ရှာဖွေရေး ဖွဲ့စည်းပုံ) တွေကနေ တခြား field တွေနဲ့လည်း ရှာနိုင်ပါတယ်။ Session store (ဝဘ်ဆိုက်က ဝင်ကြည့်သူ တစ်ယောက်စီအကြောင်း ဝင်ကြည့်နေစဉ် မှတ်ထားတာတွေကို သိမ်းတဲ့ နေရာ) တွေ၊ shopping cart (online ဈေးဝယ် ခြင်းတောင်း) တွေ၊ server အများကြီးပေါ် ဖြန့်ထားတဲ့ cache (အမြန် ယူသုံးနိုင်ဖို့ သိမ်းထားတဲ့ ဒေတာ မိတ္တူ) တွေ
Column-family (ဆက်စပ်တဲ့ column တွေကို အုပ်စုဖွဲ့ သိမ်းတဲ့ အမျိုးအစား)၊ wide-column လို့လည်း ခေါ်ပါတယ် (ဥပမာ Cassandra၊ HBase) Row တစ်ခုစီမှာ key တစ်ခု ရှိပြီး ကိုယ်ပိုင် column အစု ရှိနိုင်ပါတယ်။ ဆက်စပ်တဲ့ column တွေကို column family တွေအဖြစ် အုပ်စုဖွဲ့ပြီး အတူတူ သိမ်းပါတယ်။ Row တွေကိုတော့ သူတို့ရဲ့ key အလိုက် စက် အများကြီးပေါ်မှာ ခွဲဖြန့်ထားပါတယ်။ Time-series ဒေတာ (ပုံမှန် အချိန်ခြားပြီး ယူထားတဲ့ တိုင်းတာချက်တွေ)၊ အလွန်ကြီးမားတဲ့ event log (ဖြစ်ခဲ့တာတွေကို အစဉ်လိုက် မှတ်ထားတဲ့ မှတ်တမ်း) တွေ၊ IoT (Internet of Things: အင်တာနက်နဲ့ ချိတ်ထားတဲ့ နေ့စဉ်သုံး စက်ပစ္စည်းတွေနဲ့ sensor တွေ) device တွေက ပို့တဲ့ တိုင်းတာချက်တွေ
Graph (အရာတွေနဲ့ သူတို့ကြား ဆက်နွယ်မှုတွေအဖြစ် သိမ်းတဲ့ အမျိုးအစား) (ဥပမာ Neo4j) ဒေတာကို node (အရာတွေ) နဲ့ edge (အရာတွေကြား ဆက်နွယ်မှုတွေ) အဖြစ် သိမ်းပါတယ်။ Query တွေက node တစ်ခုကနေ တစ်ခုကို ဆက်နွယ်မှုတွေအတိုင်း တိုက်ရိုက် လိုက်သွားပါတယ်။ Social network (လူမှု ကွန်ရက်) တွေ၊ အကြံပြုချက်တွေ (“သင် သိနိုင်တဲ့ လူများ”)၊ လိမ်လည်မှု ရှာဖွေခြင်း

ဒေတာ ပုံစံ ဘယ်လို ရှိလဲ။ ရွက်လှေ အသင်း တစ်ခုရဲ့ ဒေတာကို family သုံးမျိုးနဲ့ သိမ်းထားပုံကို ဒီမှာ ပြထားပါတယ်:

Document (one record, with a list and a nested part):
{
  "sailorId": "S-2417",
  "name": "Rania Sato",
  "boats": ["dinghy", "keelboat"],
  "certificates": {"powerboat": true, "firstAidUntil": "2027-03"}
}

Key-value pair (in the basic model, the value is found by its key):
Key:    session:9c41e2
Value:  {"sailorId": "S-2417", "expires": "2026-10-20T21:00"}

Graph (people and teams are nodes; the arrows are relationships):
(Rania) -[CREWS_WITH]-> (Tomás)
(Tomás) -[CREWS_WITH]-> (Yara)
(Rania) -[MEMBER_OF]-> (Saturday Race Team)

ပုံထဲက English စာတွေရဲ့ အဓိပ္ပာယ်: Document (record တစ်ခု၊ list တစ်ခုနဲ့ nested အပိုင်း တစ်ခု ပါ)၊ Key-value pair (အခြေခံ model မှာ value ကို သူ့ key နဲ့ ရှာ)၊ Graph (လူတွေနဲ့ အသင်းတွေက node တွေ၊ မြှားတွေက ဆက်နွယ်မှုတွေ)။ CREWS_WITH က “လှေ တစ်စင်းတည်းမှာ အတူ ရွက်လွှင့်တယ်”၊ MEMBER_OF က “အဖွဲ့ဝင် ဖြစ်တယ်” လို့ ဆိုလိုပါတယ်။

နောက်ထပ် ရွက်လှေသမား တစ်ယောက်ရဲ့ document မှာ မတူတဲ့ field တွေ ရှိနိုင်ပါတယ်။ “Rania နဲ့ အတူ ရွက်လွှင့်တဲ့သူတွေနဲ့ ဘယ်သူတွေ အတူ ရွက်လွှင့်လဲ” လို မေးခွန်းမျိုးကို ဖြေဖို့ graph ထဲက မြှားတွေအတိုင်း node တစ်ခုကနေ တစ်ခုကို လိုက်သွားပါတယ်။

NoSQL မှာ အများအားဖြင့် တွေ့ရတဲ့ လက္ခဏာများ:

  • Flexible schema (ပြောင်းလွယ်တဲ့ ဒေတာ ဖွဲ့စည်းပုံ)၊ NoSQL database အများအပြားမှာ: schema (ဒေတာရဲ့ ဖွဲ့စည်းပုံ) ကို ကြိုတင် ပုံသေ မသတ်မှတ်ထားပါဘူး။ Collection (table လိုမျိုး record တွေကို စုထားတဲ့ အုပ်စု) တစ်ခုတည်းထဲက record တွေမှာ မတူတဲ့ field တွေ ရှိနိုင်ပါတယ်။ ဒါက ဒေတာရဲ့ ပုံသဏ္ဌာန် မကြာခဏ ပြောင်းတဲ့အခါ အထောက်အကူ ဖြစ်ပါတယ်။ တချို့ product တွေကတော့ field တွေကို ကြိုတင် သတ်မှတ်ထားဆဲပါ၊ ဥပမာ Cassandra table တစ်ခုက column တစ်ခုစီနဲ့ သူ့ data type (ဒေတာ အမျိုးအစား) ကို ကြေညာထားပါတယ်။ တချို့ကတော့ record တစ်ခုစီရဲ့ field တွေကို စစ်ပေးတဲ့ စည်းမျဉ်းတွေ ထည့်ခွင့် ပေးပါတယ် (MongoDB)။
  • Horizontal scalability (server ပိုကြီးတာ တစ်လုံး ပြောင်းမယ့်အစား server တွေ ထပ်ထည့်ပြီး ကြီးထွားခြင်း): NoSQL database အများအပြားက ဒေတာကို သာမန် server အများကြီးပေါ်မှာ ခွဲဖြန့်ထားနိုင်အောင် ဒီဇိုင်းလုပ်ထားပြီး server တစ်လုံးစီက ဒေတာ တစ်စိတ်တစ်ပိုင်းကို သိမ်းပါတယ်။ ဒါကို sharding (row တွေကို server အများမှာ ခွဲသိမ်းခြင်း) လို့ ခေါ်ပါတယ်။
  • High write throughput (တစ်စက္ကန့်မှာ write အများကြီး လုပ်နိုင်ခြင်း): မြန်နှုန်းအတွက် ACID အာမခံချက် တချို့ကို လျှော့ပေးပြီး ရယူလေ့ ရှိပါတယ်။
  • Eventual consistency (နောက်ဆုံးမှာ မိတ္တူ အားလုံး ကိုက်ညီလာခြင်း)၊ အများအားဖြင့်: မိတ္တူ တိုင်း ချက်ချင်း တူညီသွားမယ့်အစား update (ပြင်ဆင်ချက်) တစ်ခုက တခြား မိတ္တူ (replica) တွေဆီ အချိန် အနည်းငယ် ကြာပြီးမှ ရောက်ပါတယ်။ အဲဒီ ကြာချိန်က များသောအားဖြင့် တိုပါတယ် (eventual consistency ကိုယ်တိုင်က အများဆုံး ကြာချိန်ကို မသတ်မှတ်ပါဘူး)။ Server တချို့ ပျက်နေချိန်မှာလည်း ဆက်အလုပ်လုပ်နိုင်တာနဲ့ ပေါင်းလိုက်ရင် ဒါက BASE model ဖြစ်ပါတယ်: Basically Available (server တချို့ ပျက်နေချိန်မှာလည်း စနစ်က ဆက်ဖြေပေးနေခြင်း)၊ Soft state (တခြား မိတ္တူတွေက update တွေကို နောက်ကွယ်မှာ ထည့်နေလို့ တောင်းဆိုချက် အသစ် မရောက်လာရင်တောင် မိတ္တူ တစ်ခုထဲက ဒေတာ ပြောင်းနိုင်ခြင်း) နဲ့ Eventually consistent (update တွေ ရပ်သွားတာနဲ့ မိတ္တူ အားလုံး တူညီလာခြင်း)။ Product အများအပြားက application ကို လိုအပ်တဲ့အခါ ပိုခိုင်မာတဲ့ consistency (မိတ္တူတွေ အချင်းချင်း ကိုက်ညီမှု) ကို တောင်းခွင့် ပေးပါတယ်။
  • အားလုံး မျှသုံးတဲ့ query language မရှိပါ: product တွေမှာ များသောအားဖြင့် ကိုယ်ပိုင် query language ဒါမှမဟုတ် API (program တစ်ခုက database နဲ့ ဆက်သွယ်ဖို့ သုံးတဲ့ command အစု) ရှိပါတယ်။ Graph database တွေမှာတော့ အခု စံ query language တစ်ခု ရှိပါပြီ: ISO (International Organization for Standardization၊ နိုင်ငံတကာ စံချိန်စံညွှန်း အဖွဲ့) က 2024 မှာ ထုတ်ပြန်ခဲ့တဲ့ GQL ပါ။

လက်ခံရမယ့် trade-off (တစ်ခု ရဖို့ တစ်ခု အလျှော့ပေးရတာ) များ:

  • Consistency အာမခံချက် ပိုအားနည်းရင် stale read (ဖတ်သူက တန်ဖိုး အဟောင်းကို ရသွားခြင်း) တွေ ဖြစ်နိုင်ပါတယ်။
  • Record အများကို တစ်ပြိုင်နက် ပြောင်းတဲ့ transaction (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ်တဲ့ database လုပ်ဆောင်ချက် အစု) တွေကို NoSQL စနစ် အများအပြားမှာ ကန့်သတ်ထားတယ်၊ ဒါမှမဟုတ် မပါပါဘူး။
  • Join နည်းပါတယ်: key-value နဲ့ column-family store တွေမှာ join မရှိတာ များပြီး document store တွေမှာ join အကန့်အသတ်နဲ့ပဲ ရှိပါတယ်။ ဒါကြောင့် ဒေတာကို မကြာခဏ denormalise (ဖတ်တာ မြန်အောင် ထပ်နေမှုကို တမင် ပြန်ထည့်ခြင်း) လုပ်ထားပါတယ်၊ ဆိုလိုတာက ဒေတာကို လိုအပ်တဲ့ record တိုင်းထဲ ကူးထည့်ထားတာပါ။ Graph database တွေကတော့ ခြွင်းချက်ပါ၊ ဘာလို့လဲဆိုတော့ ဆက်နွယ်မှုတွေအတိုင်း လိုက်သွားတာက သူတို့ကို တည်ဆောက်ထားတဲ့ ရည်ရွယ်ချက်ပဲ ဖြစ်လို့ပါ။

NoSQL သင့်တော်တဲ့ အခြေအနေများ: social media feed (social media ပေါ်က post စီးကြောင်း) တွေ၊ real-time analytics (ဒေတာ ရောက်လာသလို ချက်ချင်း ခွဲခြမ်းစိတ်ဖြာခြင်း)၊ IoT sensor တိုင်းတာချက် စီးကြောင်းတွေ၊ content catalogue တွေ၊ shopping cart တွေနဲ့ relational database ရဲ့ integrity စည်းမျဉ်းတွေ (ချိတ်ဆက်ထားတဲ့ ဒေတာ မှန်ကန်နေအောင် ထိန်းပေးတဲ့ key နဲ့ constraint တွေ) ထက် scale နဲ့ ပြောင်းလွယ်တဲ့ field တွေက ပိုအရေးကြီးတဲ့ တခြား workload တွေပါ။

NoSQL များသောအားဖြင့် မသင့်တော်တဲ့ အခြေအနေများ: financial ledger (ဝင်ငွေ၊ ထွက်ငွေ မှတ်တမ်း) တွေ၊ ကုန်ပစ္စည်း လက်ကျန် အရေအတွက်တွေနဲ့ ချိတ်ဆက်ထားတဲ့ record အများကို atomic (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ်) update လုပ်ဖို့ လိုတဲ့ တခြား ဒေတာတွေ၊ ဒါမှမဟုတ် သဘာဝအတိုင်း ဇယားပုံစံ ဖြစ်ပြီး ဖွဲ့စည်းပုံကို ကောင်းကောင်း နားလည်ထားတဲ့ ဒေတာတွေပါ။ အခု NoSQL database တချို့က record အများပေါ်မှာ transaction တွေကို ကန့်သတ်ချက်တွေနဲ့ ပေးပါတယ်၊ ဒါပေမယ့် အဲဒါကြောင့် သူတို့ကို ရွေးလေ့ မရှိပါဘူး။

Cloud Databases (provider ရဲ့ server တွေပေါ်မှာ run တဲ့ database များ)

Cloud database ဆိုတာ cloud provider ရဲ့ server တွေပေါ်မှာ run ပြီး network (ကွန်ရက်) ကနေ ချိတ်ဆက်သုံးရတဲ့ database ပါ။ နောက်ကွယ်က database က relational ဖြစ်ဖြစ်၊ NoSQL ဖြစ်ဖြစ် ဖြစ်နိုင်ပါတယ်။ “Cloud” ဆိုတဲ့ နာမည်က server တွေကို ဘယ်သူ run လဲ၊ ငွေ ဘယ်လို ပေးရလဲ ဆိုတာကို ပြောတာပါ။ Cloud database ကို run နည်း နှစ်မျိုး ရှိပါတယ်:

  • Self-managed (ကိုယ်တိုင် စီမံ): အဖွဲ့အစည်းက provider ဆီကနေ virtual machine (provider ရဲ့ hardware ပေါ်မှာ software နဲ့ အတုလုပ်ထားတဲ့ ကွန်ပျူတာ၊ ဒါက infrastructure as a service ပါ) တစ်လုံးကို ငှားပြီး အဲဒီပေါ်မှာ database ကို install လုပ်၊ run ပါတယ်။ Provider က hardware ကို ထိန်းသိမ်းပေးပါတယ်။ အဖွဲ့အစည်းကတော့ update တွေ install လုပ်တာ၊ backup (အရန် မိတ္တူ) တွေ လုပ်တာနဲ့ မြန်အောင် database ရဲ့ setting တွေကို ညှိတာတွေကို လုပ်ရပါတယ်။
  • Managed (provider က စီမံပေးတဲ့)၊ ဒါမှမဟုတ် database as a service (DBaaS): provider က database ကိုပါ run ပေးပါတယ်။ ဥပမာ Amazon Aurora၊ Azure Database for PostgreSQL၊ Google Cloud Spanner နဲ့ MongoDB Atlas တို့ပါ။ အောက်က လုပ်ဆောင်ချက်တွေက managed service တွေရဲ့ လုပ်ဆောင်ချက်တွေပါ။

အဓိက လုပ်ဆောင်ချက်များ:

  • ထိန်းသိမ်းစရာ နည်းခြင်း။ Provider က server တွေကို ပြင်ဆင်ပေး၊ update တွေ install လုပ်ပေး၊ backup လုပ်ပေး၊ တခြား server တွေပေါ်မှာ ဒေတာ မိတ္တူ ထားပေး၊ ပြဿနာ ရှိမရှိ စောင့်ကြည့်ပေးပြီး server တစ်လုံး ပျက်ရင် မိတ္တူ တစ်ခုဆီ ပြောင်းပေးပါတယ် (ဒါကို failover လို့ ခေါ်ပါတယ်)။ Customer ကတော့ schema နဲ့ query တွေပေါ်မှာ အာရုံစိုက် အလုပ်လုပ်ရပါတယ်။
  • Elastic scaling (လိုသလို ချဲ့၊ ချုံ့နိုင်ခြင်း)။ လိုအပ်ချက်အလိုက် capacity (ဆံ့နိုင်တဲ့ ပမာဏ) ကို တိုးလို့၊ လျှော့လို့ ရပါတယ်: ဒီလ သုံးသလောက် ပေးရပြီး လိုရင် နောက်လမှာ ပိုသုံးနိုင်ပါတယ်။
  • ပထဝီအနှံ့ ဖြန့်ထားခြင်း။ Region (ကမ္ဘာ့ အစိတ်အပိုင်း တစ်ခုမှာ ရှိတဲ့ data centre အုပ်စု) အများမှာ ထားတဲ့ replica တွေက ကမ္ဘာအနှံ့က user တွေကို read ပိုမြန်စေပြီး region တစ်ခု ပျက်ရင်လည်း ဝန်ဆောင်မှု ပြန်ကောင်းလာအောင် ကူညီပါတယ်။
  • Pay-as-you-go (သုံးသလောက် ပေးရတဲ့) ဈေးနှုန်း။ Customer က hardware ကို ကြိုဝယ်မယ့်အစား သုံးသလောက်ကို ပုံမှန် ငွေပေးချေပါတယ်။ ဒါက start-up (စတင်ခါစ ကုမ္ပဏီ) တွေနဲ့ ပြောင်းလဲနေတဲ့ workload တွေအတွက် သင့်တော်ပါတယ်။
  • လုံခြုံရေး လုပ်ဆောင်ချက်များ။ သိမ်းထားတဲ့ ဒေတာ (at rest) နဲ့ network ပေါ်မှာ သွားနေတဲ့ ဒေတာ (in transit) ကို encryption (ဒေတာကို ဖတ်မရအောင် ပြောင်းခြင်း) လုပ်တာ၊ user တစ်ယောက်ချင်းစီ ဘယ်သူလဲ ဆိုတာအပေါ် အခြေခံပြီး ဝင်ခွင့် ပေးတာနဲ့ audit log (ဘယ်သူ ဘာလုပ်ခဲ့လဲ မှတ်တမ်း) တွေ ရနိုင်ပါတယ်။ လုံခြုံရေးက တာဝန် ခွဲယူရတာပါ: provider က သူ့ အဆောက်အအုံတွေ၊ hardware နဲ့ ဝန်ဆောင်မှုကို ကာကွယ်ပြီး customer ကတော့ ဘယ်သူ ချိတ်ဆက်ခွင့် ရမလဲ၊ ဘယ် ဒေတာကို encrypt လုပ်မလဲ၊ network ကို ဘယ်လို setup လုပ်မလဲ ဆိုတာကို ဆက်ဆုံးဖြတ်ရပါတယ်။ အဲဒီ setting တွေမှာ အမှား တစ်ခုခု ရှိရင် ဒေတာ ပေါက်ကြားနိုင်ပါတယ်။

Trade-off များ:

  • Vendor lock-in (provider တစ်ခုတည်းနဲ့ ချည်နှောင်ခံရခြင်း)။ Provider တစ်ခုမှာပဲ ရှိတဲ့ API တွေ၊ လုပ်ဆောင်ချက်တွေနဲ့ ဈေးနှုန်း ပုံစံတွေကြောင့် နောက်ပိုင်း တခြား provider ဆီ ပြောင်းရွှေ့ဖို့ ခက်ခဲပြီး ကုန်ကျစရိတ် များပါတယ်။
  • ထိန်းချုပ်ခွင့် နည်းခြင်း။ Managed service က များသောအားဖြင့် operating system (ကွန်ပျူတာကို စီမံတဲ့ အဓိက software) ကို ဝင်သုံးခွင့် မပေးပါဘူး။ ဒါကြောင့် customer က သူ့ setting တွေ၊ file system (file တွေကို disk ပေါ်မှာ စီစဉ် သိမ်းဆည်းတဲ့ စနစ်) တွေ ဒါမှမဟုတ် disk ပေါ်မှာ ဒေတာကို စီထားပုံကို ပြောင်းလို့ မရပါဘူး။
  • ထပ်ခါထပ်ခါ ကုန်ကျစရိတ်။ ဝယ်ရမယ့် hardware မရှိလို့ managed cloud database က အစမှာ ကုန်ကျစရိတ် နည်းနိုင်ပါတယ်။ ဒါပေမယ့် သုံးတာ များလာတာနဲ့အမျှ လစဉ် ငွေတောင်းခံလွှာ ကြီးလာနိုင်ပါတယ် (provider ရဲ့ network အပြင်ကို ပို့တဲ့ ဒေတာအတွက် ငွေ ထပ်ကောက်လေ့ ရှိပါတယ်)။
  • Network ကို မှီခိုရခြင်း။ Query တိုင်းက network ကနေ provider ဆီ သွားရပါတယ်။ ဒါက အဖွဲ့အစည်းရဲ့ ကိုယ်ပိုင် server တွေပေါ်မှာ ဆက်ရှိနေတဲ့ စနစ်တွေအတွက် ကြာချိန် တိုးစေပါတယ်။ ပြီးတော့ application နဲ့ cloud database ကြားက network ပျက်ရင် ဝန်ဆောင်မှု ရပ်သွားပါတယ်။
  • ဒေတာ တည်နေရာနဲ့ compliance (ဥပဒေနဲ့ စည်းမျဉ်းတွေကို လိုက်နာမှု)။ ဥပဒေတွေ ဒါမှမဟုတ် ကြီးကြပ်ရေး အဖွဲ့တွေက တချို့ ဒေတာ (ဥပမာ ကိုယ်ရေး၊ ကျန်းမာရေး ဒါမှမဟုတ် ငွေကြေး မှတ်တမ်းတွေ) ကို သတ်မှတ်ထားတဲ့ နိုင်ငံ ဒါမှမဟုတ် region တစ်ခုထဲမှာပဲ ထားဖို့နဲ့ စစ်ဆေးခွင့် ပေးဖို့ တောင်းဆိုနိုင်ပါတယ်။ Provider တွေက customer ကို region ရွေးခွင့် ပေးပါတယ်၊ ဒါပေမယ့် ဝန်ဆောင်မှုက ကိုယ့် စည်းမျဉ်းတွေနဲ့ ကိုက်ညီမကိုက်ညီ customer ကိုယ်တိုင် စစ်ရပါတယ်။

Cloud သင့်တော်တဲ့ အခြေအနေများ: SaaS (software as a service၊ အင်တာနက်ကနေ အသင့်သုံး software) start-up တွေ၊ ပြောင်းလဲနေတဲ့ workload တွေ၊ နိုင်ငံ အများအပြားမှာ ရှိတဲ့ user တွေနဲ့ (managed service နဲ့ဆိုရင်) database administrator (database ကို စီမံ ထိန်းသိမ်းတဲ့ ဝန်ထမ်း) မရှိတဲ့ အဖွဲ့တွေပါ။ အခု project အသစ် အများအပြားက cloud မှာ စတင်ကြပါတယ်။

Spatial Databases (တည်နေရာနဲ့ ပုံသဏ္ဌာန် ဒေတာအတွက် database များ)

Spatial database ကို ပထဝီ ဒေတာနဲ့ ဂျီသြမေတြီ ဒေတာ တွေ ဖြစ်တဲ့ point (အမှတ်)၊ line (မျဉ်း) နဲ့ polygon (အနား အများ ရှိတဲ့ ပိတ်ထားတဲ့ ပုံ) တွေကို သိမ်းဖို့နဲ့ အကွာအဝေး၊ ဧရိယာ၊ ထပ်နေမှု ဆိုင်ရာ မေးခွန်းတွေကို ဖြေဖို့ ဒီဇိုင်းလုပ်ထားပါတယ်။ ဥပမာ PostGIS (PostgreSQL အတွက် extension)၊ SpatiaLite (SQLite အတွက် extension) နဲ့ SQL Server နဲ့ MySQL ရဲ့ spatial data type တွေ ပါပါတယ်။

Spatial ဒေတာ ပုံစံများ:

  • Points: စာတိုက်ပုံး တစ်ခုရဲ့ တည်နေရာ ကိန်းဂဏန်းတွေ (latitude: မြောက်-တောင် တည်နေရာ၊ longitude: အရှေ့-အနောက် တည်နေရာ)။
  • Lines: လမ်း တစ်လမ်း၊ မြစ် တစ်စင်း၊ ခရီးလမ်းကြောင်း တစ်ခု။
  • Polygons: နိုင်ငံ တစ်ခုရဲ့ နယ်နိမိတ် အနားသတ်၊ ပစ္စည်း ပို့ဆောင်မယ့် ဇုန်၊ ရေလွှမ်းလွင်ပြင်။
  • Multi-geometries (ပုံ အများ ပေါင်းထားတဲ့ တန်ဖိုး): point၊ line ဒါမှမဟုတ် polygon အများကို တန်ဖိုး တစ်ခုတည်းအဖြစ် သိမ်းထားတာ၊ ဥပမာ ကျွန်း အများအပြားနဲ့ ဖွဲ့စည်းထားတဲ့ နိုင်ငံ တစ်ခု။

ပုံမှန် spatial operation (ဒေတာပေါ်မှာ လုပ်တဲ့ လုပ်ဆောင်ချက်) များ:

  • “ဒီလိပ်စာကနေ 1 km အတွင်းမှာ ရှိတဲ့ စာတိုက်ပုံး အားလုံးကို ရှာပါ။”
  • “ဒီ ပို့ဆောင်ရမယ့် လိပ်စာက ဇုန် B ထဲမှာ ကျလား။”
  • “ဒီခရိုင်ထဲက လမ်းတွေရဲ့ စုစုပေါင်း အရှည် ဘယ်လောက်လဲ။”
  • “မြစ်ရေ 2 မီတာ တက်လာရင် ဘယ် အဆောက်အအုံတွေ ရေလွှမ်းမလဲ။”

ဒီ query တွေမှာ တွက်ချက်မှု အများကြီး လိုပြီး spatial index မပါဘဲ တည်နေရာတွေကို ရိုးရိုး ဂဏန်းတွေအဖြစ်ပဲ သိမ်းထားတဲ့ database မှာ နှေးနိုင်ပါတယ်။ Spatial database တွေက R-tree (ပုံတွေကို ထောင့်မှန်စတုဂံ အဆင့်ဆင့်နဲ့ စုထားတဲ့ index) လို spatial index (ပုံသဏ္ဌာန်တွေကို သူတို့ ရှိတဲ့ နေရာအလိုက် ရှာပေးတဲ့ ဖွဲ့စည်းပုံ) တွေကို သုံးပါတယ်။ R-tree က နီးနေတဲ့ ပုံတွေကို ထောင့်မှန်စတုဂံတွေထဲ စုပြီး အဲဒီ ထောင့်မှန်စတုဂံတွေကို ပိုကြီးတဲ့ ထောင့်မှန်စတုဂံတွေထဲ ထပ်စုပါတယ်။ ဒါကြောင့် “ဒီအမှတ်နားမှာ ဘာရှိလဲ” query က အဲဒီအမှတ်နဲ့ နီးတဲ့ ပုံတွေကိုပဲ ကြည့်ရပါတယ်။ Product တိုင်းက R-tree ကို မသုံးပါဘူး: ဥပမာ SQL Server က နေရာကို cell (အကွက်) တွေနဲ့ ဇယားကွက် (grid) အဖြစ် ပိုင်းခြားပါတယ်။

အသုံးများတဲ့ နေရာများ:

  • GIS application တွေ (geographic information system: ပထဝီ ဒေတာကို သိမ်းဆည်း၊ ခွဲခြမ်းစိတ်ဖြာပြီး မြေပုံ ဆွဲပေးတဲ့ software)
  • ခရီးသည် တစ်ယောက်ချင်းစီကို အနီးဆုံး အားနေတဲ့ ယာဉ်မောင်းနဲ့ တွဲပေးတဲ့ ride-hailing app (ဖုန်းကနေ ကား ခေါ်တဲ့ app) တွေ
  • ပစ္စည်း ပို့ဆောင်ရေးနဲ့ logistics (ကုန်စည် စီးဆင်းမှု စီမံခန့်ခွဲရေး): ပို့ဆောင်ရမယ့် လမ်းကြောင်းတွေကို စီစဉ်ခြင်း
  • မြေပုံနဲ့ လမ်းညွှန် (ဥပမာ Google Maps နဲ့ OpenStreetMap)
  • မြို့ပြ စီမံကိန်း ရေးဆွဲခြင်း၊ ပတ်ဝန်းကျင် စောင့်ကြည့်ခြင်းနဲ့ အိမ်ခြံမြေ ရှာဖွေခြင်း

In-Memory Databases (ဒေတာကို RAM ထဲမှာ ထားတဲ့ database များ)

In-memory database (IMDB) က သူ့ရဲ့ working data (run နေစဉ် ဖတ်ပြီး ပြောင်းနေတဲ့ ဒေတာ) အားလုံးကို disk ပေါ်မှာ မဟုတ်ဘဲ RAM ထဲမှာ ထားပါတယ်။ ဥပမာ Redis၊ Memcached (cache အဖြစ် သုံးပါတယ်)၊ SAP HANA (လုပ်ငန်း တစ်ခုရဲ့ transaction တွေအတွက် အဓိက database အဖြစ် သုံးပါတယ်) နဲ့ kdb+ (ရှယ်ယာ ဈေးနှုန်းလို အချိန်အလိုက် မှတ်တမ်းတင်ထားတဲ့ ငွေကြေး ဒေတာအတွက် သုံးပါတယ်) တို့ပါ။

ဘာကြောင့် မြန်လဲ: RAM ကနေ ဖတ်တာက microsecond (တစ်စက္ကန့်ရဲ့ တစ်သန်းပုံ တစ်ပုံ) ရဲ့ ဆယ်ပုံ တစ်ပုံလောက် ကြာပါတယ်။ SSD (ရွေ့လျားတဲ့ အစိတ်အပိုင်း မပါတဲ့ သိုလှောင်စက်) ကနေ random read (ကျပန်း နေရာက ဖတ်ခြင်း) တစ်ခုက microsecond ဆယ်ဂဏန်းကနေ ရာဂဏန်းအထိ ကြာပြီး hard disk (လည်နေတဲ့ သံလိုက်ပြား သုံးတဲ့ သိုလှောင်စက်) ကနေ ဖတ်ရင် millisecond အနည်းငယ် ကြာပါတယ်။ ဒါတွေက ပုံမှန် ကိန်းဂဏန်းတွေဖြစ်ပြီး hardware ပေါ်မူတည်ပြီး ကွာနိုင်ပါတယ်။ ဒါကြောင့် RAM ကနေ ဖတ်တာ တစ်ကြိမ်က disk ဆီ သွားဖတ်ရတာထက် အဆ ရာနဲ့ချီကနေ သောင်းနဲ့ချီအထိ ပိုမြန်နိုင်ပါတယ်။ Query တစ်ခုလုံးအတွက်ဆိုရင်တော့ ကွာခြားချက်က များသောအားဖြင့် ပိုနည်းပါတယ်၊ ဘာလို့လဲဆိုတော့ disk-based database (disk ပေါ်မှာ ဒေတာ သိမ်းတဲ့ database) က အသုံးအများဆုံး ဒေတာကို RAM ထဲက cache မှာ ထားလို့ပါ။ အကျိုးကျေးဇူး အများစုက write တွေကနေ လာနိုင်ပါတယ်: ပြောင်းလဲမှု တစ်ခုစီကို အတည်မပြုခင် disk ထဲ ရေးအောင် setting မလုပ်ထားရင် in-memory database က ပြောင်းလဲမှု သိမ်းတိုင်း disk ကို မစောင့်ပါဘူး။ ပြီးတော့ RAM အတွက် ဒီဇိုင်းလုပ်ထားတဲ့ data structure (ဒေတာ သိမ်းဆည်းပုံ) တွေကိုလည်း သုံးပါတယ်။

လျှော့ပေးရတဲ့ အရာများ:

  • Gigabyte တစ်ခုစာ ဈေးနှုန်းအရ RAM က disk ထက် အများကြီး ပိုဈေးကြီးပါတယ်။ Working data က အဖွဲ့အစည်း တတ်နိုင်တဲ့ RAM ပမာဏထဲမှာ ဆံ့ရပါမယ်။
  • Persistence (ပါဝါပိတ်ထားချိန်မှာလည်း ဒေတာကို ဆက်ရှိနေအောင် ထိန်းထားခြင်း) က ပိုခက်ပါတယ်။ ပါဝါပြတ်ရင် RAM ထဲက ဒေတာ ပျောက်သွားလို့ လက်တွေ့ စနစ်တွေမှာ သုံးတဲ့ in-memory database တွေက ဒေတာကို တခြား နည်းတွေနဲ့လည်း သိမ်းထားပါတယ်: disk ပေါ်မှာ သိမ်းထားတဲ့ snapshot (တစ်ချိန်ချိန်က အခြေအနေကို အတိအကျ မှတ်တမ်းတင်ထားခြင်း) တွေ၊ disk ပေါ်က ပြောင်းလဲမှု log တစ်ခု ဒါမှမဟုတ် တခြား server တွေပေါ်က မိတ္တူတွေပါ။ Disk ထဲ ရေးတာ ပိုခဏခဏ ဖြစ်လေ ဒေတာ ပိုလုံခြုံလေ၊ write တွေ ပိုနှေးလေ ဖြစ်ပါတယ်။ Redis လို product တစ်ခုကို disk-based database တွေလိုပဲ ပြောင်းလဲမှု တိုင်းကို အတည်မပြုခင် disk ထဲ ရေးအောင် setting လုပ်လို့ ရပါတယ်၊ ဒါပေမယ့် မြန်နှုန်း အများကြီး ဆုံးရှုံးရပါတယ်။
  • ဆံ့နိုင်တဲ့ ပမာဏ ကန့်သတ်ချက် ရှိပါတယ်: ဒေတာကို စက် အများပေါ်မှာ ခွဲဖြန့်ထားတာ မဟုတ်ရင် စက် တစ်လုံးရဲ့ RAM ပမာဏအထိပဲ ဆံ့ပါတယ်။ အဲဒီလို စက် အများ ပေါင်းထားတာကို cluster (အတူ အလုပ်လုပ်တဲ့ စက်အုပ်စု) လို့ ခေါ်ပြီး run ရတာ ပိုရှုပ်ထွေးပါတယ်။

In-memory သင့်တော်တဲ့ အခြေအနေများ:

  • ပိုနှေးတဲ့ database တွေရဲ့ ရှေ့မှာ ထားတဲ့ cache တွေ (Redis က လူသိများတဲ့ ဥပမာပါ)။
  • Real-time analytics: ချက်ချင်း update ဖြစ်နေတဲ့ dashboard (အချက်အလက် အနှစ်ချုပ် ပြတဲ့ မျက်နှာပြင်) တွေ။
  • Multiplayer game state (game ရဲ့ လက်ရှိ အခြေအနေ): ကစားသမား တစ်ယောက်ချင်းစီ ဘယ်မှာ ရှိလဲ၊ ဘာတွေ ကိုင်ထားလဲ ဆိုတာ၊ တစ်စက္ကန့်မှာ အကြိမ်ကြိမ် ပြောင်းနေပါတယ်။
  • High-frequency trading (ကွန်ပျူတာတွေက ရှယ်ယာတွေကို တစ်စက္ကန့်မှာ အကြိမ်ကြိမ် အလိုအလျောက် ဝယ်ရောင်းခြင်း)၊ microsecond အနည်းငယ် နှောင့်နှေးတာတောင် အရေးကြီးတဲ့ နေရာ။
  • Session storage: ခဏပဲ ထားရတဲ့ ဒေတာကို အသေးလေးတွေ အများကြီး ဖတ်၊ ရေး လုပ်ရတဲ့ နေရာ။

လက်တွေ့မှာ စနစ် အများအပြားက relational database ရဲ့ ရှေ့မှာ in-memory cache (Redis လို) တစ်ခုကို သုံးကြပါတယ်: cache က မြန်နှုန်းအတွက် အဖတ်အများဆုံး ဒေတာရဲ့ မိတ္တူတွေကို ထားပြီး relational database ကတော့ durability နဲ့ ပိုစုံလင်တဲ့ query တွေနဲ့အတူ ဒေတာ အားလုံးကို ထိန်းထားပါတယ်။

နည်းလမ်း လေးခုကို နှိုင်းယှဉ်ခြင်း

နည်းလမ်း အကောင်းဆုံး လုပ်နိုင်တာ အားအနည်းဆုံး အချက် ပုံမှန် အသုံးပြုတဲ့ အခြေအနေများ
NoSQL Product အများအပြားမှာ: horizontal scale၊ flexible schema၊ high write throughput Record အများပေါ်က အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ်တဲ့ transaction တွေနဲ့ ကြိုမစီစဉ်ထားတဲ့ report အသစ်တွေအတွက် join တွေမှာ အားနည်းလေ့ ရှိပါတယ် Social media၊ IoT၊ real-time analytics၊ content စနစ်တွေ
Managed cloud ကိုယ့်အစား database ကို run ပေးခြင်း၊ elastic scale၊ region အများမှာ မိတ္တူ ထားခြင်း Vendor lock-in ကို ရှောင်ခြင်း၊ ရေရှည် ကုန်ကျစရိတ်ကို ကြိုခန့်မှန်းနိုင်ခြင်း၊ setting တွေကို အသေးစိတ် ထိန်းချုပ်ခြင်း SaaS app တွေ၊ ပြောင်းလဲနေတဲ့ workload တွေ၊ နိုင်ငံ အများအပြားက user တွေ
Spatial တည်နေရာ၊ အကွာအဝေးနဲ့ ပုံသဏ္ဌာန် ဆိုင်ရာ မေးခွန်းတွေ တည်နေရာ ဒေတာ မပါတဲ့ အလုပ်တွေ၊ အဲဒီမှာ spatial လုပ်ဆောင်ချက်တွေက ဘာမှ အကျိုးမပြုပါဘူး GIS၊ မြေပုံ၊ logistics၊ ခရီးသည်နဲ့ ယာဉ်မောင်း တွဲပေးခြင်း
In-memory အလွန်နည်းတဲ့ latency၊ read နဲ့ write နှုန်း အလွန်မြင့်ခြင်း RAM ထက် ကြီးတဲ့ ဒေတာ အစုတွေ၊ မြန်နှုန်း မကျဘဲ တင်းကျပ်တဲ့ durability Caching၊ real-time analytics၊ game၊ ငွေကြေး

ဒီနည်းလမ်းတွေကို ပေါင်းသုံးလို့ ရပါတယ်။ စနစ် တစ်ခုက အဓိက လုပ်ငန်း မှတ်တမ်းတွေအတွက် relational database၊ cache အဖြစ် Redis (in-memory)၊ user တွေ ရေးတဲ့ content အတွက် NoSQL document store နဲ့ တည်နေရာ လုပ်ဆောင်ချက်တွေအတွက် spatial extension ကို သုံးနိုင်ပြီး အဲဒါ အားလုံးကို cloud platform ပေါ်မှာ run နိုင်ပါတယ်။

အဆင့်ဆင့် ရှင်းပြထားတဲ့ ဥပမာများ

ဥပမာ 1: သင့်တော်တဲ့ နည်းလမ်းကို ရွေးခြင်း

Start-up တစ်ခုက အစားအသောက် ပို့ဆောင်ရေး app တစ်ခု တည်ဆောက်နေပြီး စနစ်ရဲ့ အပိုင်း လေးပိုင်းအတွက် နည်းပညာတွေ ရွေးရပါမယ်။ အပိုင်း တစ်ခုစီနဲ့ ဘယ် database နည်းလမ်းက ကိုက်ညီလဲ။

စနစ်ရဲ့ အပိုင်း အသင့်တော်ဆုံး အကြောင်းပြချက်
Customer ရဲ့ order တွေ၊ ငွေပေးချေမှုတွေနဲ့ ငွေပြန်အမ်းမှုတွေ Relational (cloud ပေါ်မှာ host လုပ်ထား) တင်းကျပ်တဲ့ consistency နဲ့ row အများကို တစ်ပြိုင်နက် ပြောင်းတဲ့ transaction တွေက မရှိမဖြစ် လိုအပ်ပါတယ်။ ACID transaction တွေ ပါတဲ့ relational database ကို ပုံမှန် ရွေးကြပါတယ်။
Customer ကို ပြမယ့် စားသောက်ဆိုင်တွေ: ပို့ဆောင်ရမယ့် လိပ်စာကနေ 3 km အတွင်းက ဆိုင်တွေ Spatial (များသောအားဖြင့် PostGIS extension အဖြစ်) မြေပုံပေါ်က point တွေအကြောင်း အကွာအဝေး မေးခွန်းပါ။ Spatial function တွေနဲ့ spatial index က မြန်မြန် ဖြေပေးနိုင်ပါတယ်။
User ရဲ့ session state (ဝင်သုံးနေစဉ် အခြေအနေ)၊ shopping cart၊ လက်ရှိ preference (ကြိုက်နှစ်သက်ရာ setting) တွေ In-memory (Redis) ခဏပဲ ထားပြီး အလွန် ခဏခဏ ဖတ်၊ ရေး လုပ်ရတဲ့ ဒေတာပါ။ ပျောက်သွားရင် customer တွေ sign in ပြန်ဝင်ရတာ ဒါမှမဟုတ် cart ကို ပြန်ဖြည့်ရတာ ဖြစ်နိုင်လို့ သိမ်းထားတဲ့ preference လို အရေးကြီးတဲ့ အရာမှန်သမျှကို durable database (ဒေတာ မပျောက်အောင် သိမ်းတဲ့ database) မှာလည်း ထားပါတယ်။
စာသား၊ ဓာတ်ပုံ၊ အဆင့်သတ်မှတ်ချက်နဲ့ ဆိုင်ရဲ့ ပြန်စာတွေလို အမျိုးမျိုး ပါတဲ့ user review (သုံးသပ်ချက်) တွေ NoSQL document (MongoDB) Review တစ်ခုနဲ့ တစ်ခု field တွေ မတူပါဘူး။ Flexible schema ကြောင့် field အမျိုးအစား အသစ် ပေါ်လာတိုင်း table ဒီဇိုင်းကို ပြင်စရာ မလိုပါဘူး။

ဒီလို app တစ်ခုက workload တစ်ခုစီနဲ့ ကိုက်တဲ့ database ကို ရွေးပြီး နည်းလမ်း အများကို ပေါင်းသုံးပါတယ်: order နဲ့ ငွေပေးချေမှုတွေအတွက် relational၊ session ဒေတာအတွက် in-memory စသဖြင့်ပါ။ အဲဒါ အားလုံးကို managed cloud service တွေအဖြစ် run နိုင်ပါတယ်။ Database တစ်ခု ထပ်ထည့်တိုင်း setup လုပ်ရ၊ ထိန်းသိမ်းရတဲ့ အလုပ်လည်း တိုးလာလို့ တိကျတဲ့ လိုအပ်ချက် တစ်ခုကို ဖြည့်ဆည်းပေးမှသာ ထပ်ထည့်ပါ။

ဥပမာ 2: Spatial Query တစ်ခုကို စကားလုံးတွေနဲ့ ရှင်းပြခြင်း

မြို့ တစ်မြို့က ဘယ်ကျောင်းကမဆို 200 မီတာ အတွင်းမှာ ရှိတဲ့ မီးသတ် ရေပိုက်ခေါင်း (fire hydrant) အားလုံးကို ရှာချင်ပါတယ်။ Spatial database ပေါ်မှာ query က ဒီလို ဖြစ်နိုင်ပါတယ်:

SELECT Hydrant.HydrantID, Hydrant.Location
FROM   Hydrant
WHERE  EXISTS (
         SELECT 1 FROM School
         WHERE  ST_DWithin(Hydrant.Location, School.Boundary, 200)
       );

(ST_DWithin က “သတ်မှတ်ထားတဲ့ အကွာအဝေး အတွင်းမှာ ရှိလား” လို့ ဆိုလိုတဲ့ PostGIS function ပါ။ တည်နေရာတွေကို PostGIS ရဲ့ geography type (latitude နဲ့ longitude နဲ့ ဖော်ပြတဲ့ ကမ္ဘာ့ မျက်နှာပြင်ပေါ်က နေရာတွေ) အဖြစ် သိမ်းထားရင် အကွာအဝေးကို မီတာနဲ့ တိုင်းပါတယ်။ EXISTS က သူ့ ကွင်းထဲက query က row အနည်းဆုံး တစ်ခု တွေ့ရင် true ဖြစ်ပါတယ်: ဒီမှာဆိုရင် ရေပိုက်ခေါင်းကနေ 200 မီတာ အတွင်းမှာ ကျောင်း အနည်းဆုံး တစ်ကျောင်း ရှိတာပါ။) Spatial index ကြောင့် DBMS (database management system၊ database ကို စီမံတဲ့ software) က ဝေးလွန်းနေတာ ထင်ရှားတဲ့ ရေပိုက်ခေါင်းတွေကို ကျော်ပြီး ကျောင်း နားက ရေပိုက်ခေါင်းတွေကိုပဲ ကြည့်နိုင်ပါတယ်။ တည်နေရာတွေပေါ်မှာ index မရှိတဲ့ database ကတော့ ရေပိုက်ခေါင်း တိုင်းကို စစ်ရပါလိမ့်မယ်။

ဥပမာ 3: Cache Pattern (cache ကို သုံးတဲ့ ပုံစံ)

သတင်း ဝဘ်ဆိုက် တစ်ခုက တစ်နာရီမှာ ဝင်ကြည့်သူ သန်းချီကို homepage တစ်ခုတည်း ပြပါတယ်။ ဆောင်းပါးတွေက ပြောင်းခဲပါတယ်။ ဝင်ကြည့်သူ တိုင်းအတွက် စာမျက်နှာ တစ်ခုစီကို relational database ကနေ တည်ဆောက်ရရင် database မှာ ဝန် ပိလွန်းသွားပါလိမ့်မယ်။

ပုံမှန် ဖြေရှင်းနည်းကတော့ in-memory cache ပါ။ စာမျက်နှာက cache ထဲမှာ ရှိပြီးသား ဆိုရင် request (တောင်းဆိုချက်) က hit (လိုတဲ့ ဒေတာ cache ထဲမှာ ရှိခြင်း) ဖြစ်ပြီး မရှိရင် miss (လိုတဲ့ ဒေတာ cache ထဲမှာ မရှိခြင်း) ဖြစ်ပါတယ်:

Request -> [Cache check]
              |
              if hit  -> return cached version (<1 ms)
              if miss -> query relational DB -> cache result -> return

ပုံထဲက စာတွေရဲ့ အဓိပ္ပာယ်: Request ရောက်လာရင် Cache check (cache ထဲမှာ ရှိမရှိ စစ်) လုပ်ပါတယ်။ if hit ဆိုရင် cache ထဲက version ကို ပြန်ပေးပါတယ် (1 ms မပြည့်ခင်)။ if miss ဆိုရင် relational database ကို query လုပ်၊ ရလဒ်ကို cache ထဲ ထည့်ပြီးမှ ပြန်ပေးပါတယ်။

ဒီလိုဆိုရင် relational database က ဆောင်းပါး တစ်ခုစီကို တစ်နာရီမှာ သန်းချီ ကိုင်တွယ်ရမယ့်အစား တစ်မိနစ်မှာ တစ်ကြိမ်လောက်ပဲ ကိုင်တွယ်ရပါတယ်။ Cache ထဲက မိတ္တူ တစ်ခုစီကို သက်တမ်းကုန်ချိန် တစ်ခု သတ်မှတ်ထားတာ၊ ဒါမှမဟုတ် ဆောင်းပါး ပြောင်းတဲ့အခါ ဖယ်ထုတ်တာကြောင့် စာဖတ်သူတွေက version အဟောင်းကို ကြာကြာ မမြင်ရပါဘူး။ RAM ကနေ ဖတ်တာ မြန်လို့ cache က in-memory ဖြစ်ပါတယ်။ Cache က ဖြေပေးလိုက်တဲ့ request တိုင်းက database ကိုင်တွယ်စရာ မလိုတော့တဲ့ request ပါ။

Quick Check (အမြန် စစ်ဆေးမေးခွန်း)

Q1. ဘယ် workload က NoSQL database နဲ့ အကိုက်ညီဆုံးလဲ။

Q2. "user ရဲ့ လက်ရှိ တည်နေရာကနေ 5 ကီလိုမီတာ အတွင်းက လျှပ်စစ်ကား အားသွင်းစခန်း အားလုံးကို ရှာပါ" ဆိုတဲ့ query အတွက် ဘယ် database အမျိုးအစားက အသင့်တော်ဆုံးလဲ။

Q3. Disk-based database နဲ့ နှိုင်းယှဉ်ရင် in-memory database ရဲ့ အဓိက အားသာချက်က ဘာလဲ။

Q4. Managed cloud database ကို အကောင်းဆုံး ဖော်ပြထားတာက ဘယ်ဟာလဲ။

Q5. NoSQL၊ cloud၊ spatial နဲ့ in-memory database တွေထဲက ရွေးချယ်ခြင်းအကြောင်း ဘယ်ဖော်ပြချက်က အမှန်ကန်ဆုံးလဲ။

ကိုက်ညီတဲ့ နည်းလမ်းကို တွဲပါ

အခြေအနေ တစ်ခုစီအတွက် အကိုက်ညီဆုံး database နည်းလမ်းကို ရွေးပါ။

အကွက် တစ်ခုစီမှာ ဒီစကားလုံး လေးလုံးထဲက တစ်လုံးကို ပြထားတဲ့အတိုင်း English လို အတိအကျ ရိုက်ထည့်ပါ (in-memory မှာ hyphen (-) ပါပါတယ်): NoSQL၊ cloud၊ spatial၊ in-memory။

အခြေအနေအကိုက်ညီဆုံး
Multiplayer online game တစ်ခုက ကစားသမားတွေရဲ့ တည်နေရာနဲ့ inventory (ကိုင်ထားတဲ့ ပစ္စည်း စာရင်း) တွေကို တစ်စက္ကန့်မှာ အကြိမ် ထောင်ချီ update လုပ်ရပြီး read ဒါမှမဟုတ် write တစ်ခုစီကို millisecond တစ်ခု မပြည့်ခင် ဖြေပေးရပါမယ်။
နိုင်ငံတော် မြေပုံ ရေးဆွဲရေး အဖွဲ့ တစ်ခုက ပေးထားတဲ့ polygon တစ်ခုကို ဖြတ်စီးတဲ့ မြစ် အားလုံးကို ရှာရပါမယ်။
SaaS start-up တစ်ခုက database administrator မငှားဘဲ relational database တစ်ခု setup လုပ်ချင်ပြီး user အရေအတွက် များလာတာနဲ့အမျှ database က အလိုအလျောက် ကြီးထွားလာစေချင်ပါတယ်။
Social media platform တစ်ခုက ဖွဲ့စည်းပုံ မတူတဲ့ user post တွေ (စာသား၊ ပုံ၊ မဲစစ်တမ်း၊ ထည့်ထားတဲ့ ဗီဒီယို) ကို server အများကြီးပေါ် ဖြန့်ပြီး high write throughput နဲ့ သိမ်းရပါမယ်။
Web app တစ်ခုက စာမျက်နှာ ကြည့်တိုင်း နှေးတဲ့ အဓိက database ကို query မလုပ်ရအောင် မြန်တဲ့ cache တစ်ခု လိုပါတယ်။

Fill in the Blanks (ကွက်လပ် ဖြည့်ခြင်း)

ကွက်လပ်ပါတဲ့ စာကြောင်းတွေက English နဲ့ ဖြစ်ပြီး ကွက်လပ်တွေကိုလည်း English လို ရိုက်ထည့်ရပါမယ်။ FOUR ALTERNATIVE DATABASE APPROACHES က “အခြား database နည်းလမ်း လေးခု” လို့ ဆိုလိုတဲ့ ခေါင်းစဉ်ပါ။ စာကြောင်းတွေရဲ့ အဓိပ္ပာယ်က အောက်ပါအတိုင်းပါ:

  • …… database က horizontal scalability၊ flexible schema နဲ့ high write throughput ရဖို့ relational လုပ်ဆောင်ချက် တချို့ (join တွေ၊ တင်းကျပ်တဲ့ consistency) ကို လျှော့ပေးလေ့ ရှိပါတယ်။ ဥပမာ: MongoDB၊ Cassandra၊ Redis (key-value)။
  • Managed …… database ကို ပြင်ပ provider (AWS၊ Google Cloud ဒါမှမဟုတ် Azure လို) က host လုပ်ပြီး run ပေးပါတယ်။ Elastic scaling နဲ့ pay-as-you-go ဈေးနှုန်း ပေးပါတယ်။
  • …… database က ဂျီသြမေတြီ ဒေတာ (point၊ line၊ polygon) တွေကို သိမ်းပြီး “5 km အတွင်း” ဒါမှမဟုတ် “ဒီ polygon ကို အတွင်းမှာ ပါဝင်လား” လို query တွေကို ပံ့ပိုးပါတယ်။
  • …… database က working data ကို disk ပေါ်မှာ မဟုတ်ဘဲ RAM ထဲမှာ သိမ်းလို့ throughput မြင့်တဲ့ workload တွေအတွက် latency အလွန် နည်းပါတယ်။

ဖော်ပြချက်တွေကို ပြည့်စုံအောင် ကွက်လပ်တွေ ဖြည့်ပါ။

FOUR ALTERNATIVE DATABASE APPROACHES
====================================
A  database often trades some relational features (joins, strict
consistency) for horizontal scalability, flexible schemas and high
write throughput. Examples: MongoDB, Cassandra, Redis (key-value).

A managed  database is hosted and run by a third-party
provider (such as AWS, Google Cloud or Azure), offering elastic scaling
and pay-as-you-go pricing.

A  database stores geometric data (points, lines, polygons)
and supports queries like "within 5 km of" or "contains this polygon".

An  database stores its working data in RAM rather than
on disk, giving very low latency for high-throughput workloads.

Spot the Error (အမှား ရှာခြင်း)

ကျောင်းသား တစ်ယောက်က အခြား database နည်းလမ်းတွေအကြောင်း ပြန်လေ့ကျင့်ဖို့ မှတ်စု ရေးထားပါတယ်။ Line တစ်ကြောင်း မှားနေပါတယ်။ အမှားပါတဲ့ line ကို ရွေးပါ၊ ပြီးရင် မှန်ကန်တဲ့ ပြင်နည်းကို ရွေးပါ။

1NoSQL: often a flexible schema, horizontal scale and weaker ACID guarantees 2Managed cloud: run by a provider, elastic scaling, pay-as-you-go 3Spatial: stores geometric data (points, lines, polygons) and supports geographic queries 4In-memory: stores data on a special type of SSD called 'in-memory storage' 5A modern system often combines several approaches rather than picking one

Line တွေရဲ့ အဓိပ္ပာယ်: (1) NoSQL: များသောအားဖြင့် flexible schema၊ horizontal scale နဲ့ ပိုအားနည်းတဲ့ ACID အာမခံချက်တွေ၊ (2) Managed cloud: provider က run ပေး၊ elastic scaling၊ pay-as-you-go၊ (3) Spatial: ဂျီသြမေတြီ ဒေတာ (point၊ line၊ polygon) တွေကို သိမ်းပြီး ပထဝီ query တွေကို ပံ့ပိုး၊ (4) In-memory: 'in-memory storage' လို့ ခေါ်တဲ့ အထူး SSD အမျိုးအစား ပေါ်မှာ ဒေတာ သိမ်း၊ (5) ခေတ်သစ် စနစ်တွေက နည်းလမ်း တစ်ခုတည်း ရွေးမယ့်အစား နည်းလမ်း အများကို မကြာခဏ ပေါင်းသုံး။

Line 4 အတွက် မှန်ကန်တဲ့ ပြင်နည်းကို ရွေးပါ:

နည်းလမ်းကို ခွဲခြား သတ်မှတ်ပါ

မြို့တော် ကောင်စီ တစ်ခုက ကျောင်း တစ်ကျောင်းစီရဲ့ catchment area (ကျောင်းက လက်ခံတဲ့ ကျောင်းသားတွေ နေထိုင်ရာ နယ်မြေ) နဲ့ ယာဉ်အသွားအလာ နည်းအောင် သတ်မှတ်ထားတဲ့ ဇုန် အသစ် တစ်ခုကို မြေပုံပေါ်မှာ polygon တွေအဖြစ် သိမ်းထားပါတယ်။ Catchment area တစ်ခုစီရဲ့ ဘယ်နှစ် စတုရန်းမီတာက အဲဒီ ဇုန်ထဲ ကျနေလဲ သိချင်ပါတယ်။ ဒီအတွက် ဘယ် database နည်းလမ်းက အသင့်တော်ဆုံးလဲ။

နည်းလမ်းရဲ့ နာမည်ကို English လို ရိုက်ထည့်ပါ (ဥပမာ NoSQL)။

Online လေလံ ဝဘ်ဆိုက် တစ်ခုက item တိုင်းရဲ့ လက်ရှိ အမြင့်ဆုံး လေလံဈေးကို ပြပါတယ်။ လေလံရဲ့ နောက်ဆုံး မိနစ်မှာ လေလံဈေးက တစ်စက္ကန့်မှာ အကြိမ်ကြိမ် ပြောင်းနိုင်ပြီး screen ထောင်ချီက အဲဒါကို ဖတ်ပါတယ်။ Screen တစ်ခုစီက millisecond တစ်ခု မပြည့်ခင် အဖြေ လိုပါတယ်။ လေလံဈေး တိုင်းကို ဝဘ်ဆိုက်ရဲ့ အဓိက database မှာလည်း သိမ်းထားပါတယ်။ အဲဒီ screen တွေအတွက် လက်ရှိ အမြင့်ဆုံး လေလံဈေးတွေကို ထားဖို့ ဘယ် database နည်းလမ်းက အသင့်တော်ဆုံးလဲ။

နည်းလမ်းရဲ့ နာမည်ကို English လို ရိုက်ထည့်ပါ။

Practice Exercises (လေ့ကျင့်ခန်းများ)

[4 marks] လို mark allocation (မေးခွန်း တစ်ခုစီအတွက် ပေးတဲ့ အမှတ်) တွေက IB Computer Science စာမေးပွဲ ပုံစံအတိုင်း ပေးထားတာပါ၊ ဥပမာ [4 marks] ဆိုတာ 4 မှတ်ပါ။ IB သင်တန်း မတက်တဲ့သူတွေကတော့ အဖြေ ဘယ်လောက် အသေးစိတ် ရေးရမလဲ ချိန်ကြည့်ဖို့ လမ်းညွှန်အဖြစ် သုံးနိုင်ပါတယ်။

Core (အခြေခံ အဆင့်၊ HL)

  1. [Core] Alternative DBs (HL) [4 marks] ဒီစာမျက်နှာမှာ လေ့လာခဲ့တဲ့ အခြား database နည်းလမ်း လေးခု ဖြစ်တဲ့ NoSQL၊ cloud၊ spatial နဲ့ in-memory တစ်ခုစီရဲ့ အဓိပ္ပာယ်ကို Outline (အကျဉ်းချုပ် ဖော်ပြပါ)။

  2. [Core] Alternative DBs (HL) [2 marks] Start-up တစ်ခုက ယာဉ်တွေရဲ့ real-time (ချက်ချင်း ဆက်တိုက်) တည်နေရာတွေကို လမ်း network ပေါ်မှာ ပြပေးတဲ့ လမ်းညွှန် app တစ်ခု တည်ဆောက်နေပါတယ်။ အသင့်တော်ဆုံး database နည်းလမ်းကို Suggest (ဖြစ်နိုင်တဲ့ အဖြေ တစ်ခုကို အကြံပြုပါ) လုပ်ပြီး ကိုယ့် ရွေးချယ်မှုကို စာကြောင်း တစ်ကြောင်းနဲ့ justify (ဘာကြောင့် ရွေးတာလဲ အကြောင်းပြချက်နဲ့ ပြပါ) လုပ်ပါ။

  3. [Core] Alternative DBs (HL) [3 marks] မြို့တော် ကောင်စီ တစ်ခုက အများသုံး သောက်ရေ ပိုက်ခေါင်း တိုင်းရဲ့ တည်နေရာကို point အဖြစ်၊ ပန်းခြံ တိုင်းရဲ့ နယ်နိမိတ်ကို polygon အဖြစ် သိမ်းထားပါတယ်။ “ပန်းခြံ တစ်ခုစီထဲမှာ ရှိတဲ့ သောက်ရေ ပိုက်ခေါင်းတွေကို စာရင်းပြပါ” ဆိုတဲ့ query က သောက်ရေ ပိုက်ခေါင်း တစ်ခုစီရဲ့ latitude နဲ့ longitude ကို ရိုးရိုး ဂဏန်း column နှစ်ခုအဖြစ် သိမ်းထားတဲ့ database ထက် spatial database ပေါ်မှာ ဘာကြောင့် အများကြီး ပိုမြန်လဲ ဆိုတာကို Explain (ရှင်းပြပါ)။

Extension (တိုးချဲ့ အဆင့်၊ HL)

  1. [Extension] Alternative DBs (HL) [4 marks] တစ်ရက်ကို user post သန်းချီ သိမ်းရမယ့် စနစ် တစ်ခုအတွက် relational database အစား NoSQL database ကို ရွေးရင် ဖြစ်လာမယ့် အဓိက trade-off တွေကို Discuss (အမြင် အမျိုးမျိုးကို ချိန်ဆပြီး ဆွေးနွေးပါ)။

  2. [Extension] Alternative DBs (HL) [4 marks] In-memory database တွေက disk-based database တွေထက် ဘာကြောင့် အများကြီး ပိုမြန်လဲ Explain လုပ်ပြီး in-memory database သုံးရင် ပါလာတဲ့ trade-off နှစ်ခုကို identify (ဖြစ်နိုင်တဲ့ အဖြေတွေထဲက ရွေးပြီး ဖော်ပြပါ) လုပ်ပါ။

  3. [Extension] Alternative DBs (HL) [4 marks] SaaS start-up အသေး တစ်ခုရဲ့ relational data store (ဒေတာ သိမ်းဆည်းရာ) အတွက် cloud database သုံးတာရဲ့ အကျိုးကျေးဇူး နှစ်ခုနဲ့ အားနည်းချက် နှစ်ခုကို Explain လုပ်ပါ။

Challenge (စိန်ခေါ်မှု အဆင့်၊ HL)

  1. [Challenge] Alternative DBs (HL) [6 marks] ရေတက္ကစီ ကုမ္ပဏီ တစ်ခုက သူ့ရဲ့ booking (ကြိုတင် လက်မှတ် ဝယ်ယူခြင်း) app အတွက် ဒေတာကို စီစဉ်နေပါတယ်။ အောက်ပါတို့ကို ကိုင်တွယ်ရပါမယ်: (a) သူ့ လှေ 120 စင်း တစ်စင်းစီက 10 စက္ကန့်တိုင်း ပို့တဲ့ စက်ခေါင်း တိုင်းတာချက်တွေ၊ တစ်ခုစီ 2 KB လောက် ရှိပြီး ငါးနှစ် သိမ်းထားရကာ လှေကို ပြုပြင် ထိန်းသိမ်းတဲ့အခါ လှေ တစ်စင်းချင်းစီအလိုက် ဖတ်ပါတယ်၊ (b) ဆိပ်ခံ တံတား တိုင်းရဲ့ တည်နေရာနဲ့ ခရီးသည် တစ်ယောက်နဲ့ အနီးဆုံး ဆိပ်ခံ တံတား၊ (c) လှေ တစ်စင်းစီမှာ ကျန်တဲ့ ထိုင်ခုံ အရေအတွက်ကို app ထဲမှာ ချက်ချင်း ပြတဲ့ မျက်နှာပြင်၊ ခရီးသည် ထောင်ချီက ဖတ်ပြီး booking တစ်ခုစီနဲ့အတူ update ဖြစ်ပါတယ် (booking တွေကိုယ်တိုင်ကိုတော့ transaction တွေနဲ့အတူ သီးခြား relational database မှာ သိမ်းထားပါတယ်)။ ဒါ့အပြင် (d) ကုမ္ပဏီမှာ developer (software ရေးသူ) တစ်ယောက်ပဲ ရှိပြီး server ခန်း မရှိပါဘူး၊ နွေရာသီမှာ booking က ဆောင်းရာသီထက် ဆယ်ဆ များပါတယ်။ အပိုင်း တစ်ခုစီနဲ့ ဘယ် database နည်းလမ်း ကိုက်ညီလဲ Suggest လုပ်ပြီး ရွေးချယ်မှု တစ်ခုစီကို justify လုပ်ပါ။

  2. [Challenge] Alternative DBs (HL) [6 marks] စည်းမျဉ်း လိုက်နာရမှု တင်းကျပ်တဲ့ သက်တမ်းရင့် ငွေကြေး အဖွဲ့အစည်း တစ်ခုက သူ့ရဲ့ အဓိက transaction database ကို on-premises server (ကိုယ်ပိုင် အဆောက်အအုံထဲက server) တွေကနေ cloud provider ကြီး တစ်ခုဆီ ပြောင်းရွှေ့သင့်မသင့် Evaluate (အားသာချက်နဲ့ အားနည်းချက်တွေကို ချိန်ဆပြီး အကဲဖြတ်ပါ)။ အောက်ပါ အချက်တွေထဲက အနည်းဆုံး သုံးခုကို ထည့်ပြောပါ: control (ထိန်းချုပ်ခွင့်)၊ cost (ကုန်ကျစရိတ်)၊ latency၊ compliance၊ scalability (ဒေတာ များလာတဲ့အခါမှာလည်း ကောင်းကောင်း ဆက်အလုပ်လုပ်နိုင်မှု)၊ vendor lock-in။

IB CS ကျောင်းသားတွေအတွက် မှတ်ချက်: IB syllabus (သင်ရိုး) က ဒေတာ သိမ်းဆည်းဖို့ အခြား နည်းလမ်း လေးခုကို ဖော်ပြထားပါတယ်: NoSQL၊ cloud၊ spatial နဲ့ in-memory ပါ။ စာအုပ် အဟောင်း တချို့မှာ ဖော်ပြထားတဲ့ object-oriented၊ network နဲ့ multi-dimensional database တွေက အဲဒီထဲမှာ မပါပါဘူး။ ဒီနည်းလမ်း လေးခုအကြောင်း ရေးတဲ့အခါ လုပ်ဆောင်ချက် တစ်ခုစီကို အသုံးပြုပုံ တစ်ခုနဲ့ ချိတ်ပြီး ရေးပါ: ဘယ်နည်းလမ်းက ဘယ်စနစ်နဲ့ ကိုက်ညီလဲ၊ ဘာကြောင့်လဲ ဆိုတာ ပြောပါ။

ဆက်စပ် ခေါင်းစဉ်များ

  • အရင် လေ့လာထားရမယ့် ခေါင်းစဉ်: Transactions and Views: NoSQL database တွေက scale အတွက် မကြာခဏ လျှော့ပေးလေ့ရှိတဲ့ ACID အာမခံချက်တွေ။
  • ဆက်စပ် ခေါင်းစဉ်: Relational Database Fundamentals: အဲဒီမှာ ဖော်ပြထားတဲ့ ကန့်သတ်ချက်တွေက အခြား database တွေ ဖြေရှင်းပေးတဲ့ ဖိအားတွေပါ: rigid schema (ပုံသေ column အစု)၊ “big data” (အလွန်များပြားတဲ့ ဒေတာ) scale၊ hierarchical data (tree ဒါမှမဟုတ် network ပုံစံ ဖွဲ့စည်းထားတဲ့ ဒေတာ) နဲ့ impedance mismatch (program ထဲက object တွေနဲ့ table ထဲက row တွေကြား ကွာဟချက်)။
  • နောက်ထပ် လေ့လာမယ့် ခေါင်းစဉ် (HL): Data Warehouses: နေ့စဉ် transaction တွေအတွက် မဟုတ်ဘဲ ခွဲခြမ်းစိတ်ဖြာမှုနဲ့ report တွေအတွက် တည်ဆောက်ထားတဲ့ နောက်ထပ် ဒေတာ သိမ်းဆည်းနည်း။
  • နောက်ထပ် လေ့လာမယ့် ခေါင်းစဉ် (HL): Distributed Databases: database တစ်ခုကို စက် အများကြီးပေါ်မှာ ဘယ်လို ခွဲဖြန့်ထားလဲ ဆိုတာပါ၊ ဒီစာမျက်နှာက cloud နဲ့ NoSQL အယူအဆတွေအပေါ် ဆက်တည်ဆောက်ထားပါတယ်။
  • Hardware: Primary Memory နဲ့ Secondary Storage: RAM နဲ့ disk ကြားက ကုန်ကျစရိတ်နဲ့ မြန်နှုန်း ကွာခြားချက်ပါ၊ in-memory database တွေရဲ့ trade-off တွေရဲ့ နောက်ကွယ်က အကြောင်းရင်းပါ။
  • Hardware: Cloud Computing: SaaS၊ PaaS (app တင်ဖို့ အသင့်ပြင်ထားတဲ့ platform) နဲ့ IaaS (virtual machine နဲ့ storage ကို ငှားသုံးခြင်း) service model (ဝန်ဆောင်မှု ပုံစံ) တွေပါ၊ self-managed နဲ့ managed cloud database ကြား ကွာခြားချက်ကို ရှင်းပြပေးပါတယ်။

© EduCS.me. ကွန်ပျူတာသိပ္ပံ ပညာရေးအတွက် အရင်းအမြစ်တွေ စုထားတဲ့ နေရာပါ။ EduCS is an independent educational resource. It is not affiliated with, or endorsed by, the International Baccalaureate Organization. (EduCS ဟာ သီးခြား ပညာရေး အရင်းအမြစ်တစ်ခုပါ။ International Baccalaureate Organization နဲ့ ဆက်စပ်မှု မရှိသလို သူတို့ရဲ့ ထောက်ခံချက်လည်း မရှိပါဘူး။) ဆက်သွယ်ရန်

Just the Docs နဲ့ တည်ဆောက်ထားပါတယ်။