Distributed Databases (နေရာ အများမှာ ခွဲသိမ်းထားတဲ့ database များ)

A3.4.4: Describe the features of distributed databases.
မြန်မာလို: distributed database (နေရာ အများမှာ ခွဲသိမ်းထားတဲ့ database) တွေရဲ့ feature (အဓိက လက္ခဏာ) တွေကို describe (ဖော်ပြရှင်းပြ) လုပ်နိုင်ရပါမယ်။

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

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

Distributed Database ဆိုတာ ဘာလဲ

Distributed database (နေရာ အများမှာ ခွဲသိမ်းထားတဲ့ database) ဆိုတာ logical database တစ်ခုတည်း (သုံးစွဲသူတွေနဲ့ program တွေ သိနိုင်သလောက်ဆိုရင် database တစ်ခုတည်း) ဖြစ်ပြီး သူ့ထဲက ဒေတာတွေကို ရုပ်ပိုင်းဆိုင်ရာ စက် အများ ပေါ်မှာ ခွဲသိမ်းထားတဲ့ database ပါ။ အဲဒီ စက်တွေက data centre (server အများကြီး ထားတဲ့ အဆောက်အအုံ) အများမှာ ရှိလေ့ ရှိပြီး တစ်ခါတလေ တိုက် အများမှာ ရှိပါတယ်။ စက် တစ်လုံးချင်းကို node လို့ ခေါ်ပြီး node တွေ အားလုံး ပေါင်းပြီး cluster (အတူ အလုပ်လုပ်တဲ့ စက် အုပ်စု) ဖြစ်ပါတယ်။ သုံးစွဲသူက database တစ်ခုတည်းကိုပဲ မြင်ရပါတယ်၊ နောက်ကွယ်မှာတော့ DBMS (database ကို စီမံခန့်ခွဲတဲ့ software) က node အများကြီးကို ညှိနှိုင်း စီမံပေးပါတယ်။

ဒေတာကို စက် အများပေါ် ဖြန့်ထားရင် capacity (ဆံ့နိုင်တဲ့ ပမာဏ) တိုးနိုင်တယ်၊ စက် တစ်လုံး ပျက်သွားရင်လည်း ဝန်ဆောင်မှု ဆက် run နေအောင် ထားနိုင်တယ်၊ ဒေတာကို သုံးစွဲသူတွေနဲ့ ပိုနီးတဲ့ နေရာမှာ ထားနိုင်ပါတယ်။ ဒါပေမယ့် လုပ်ရမယ့် အလုပ်လည်း ပိုများလာပါတယ်: စက်တွေကို ညှိနှိုင်းရတယ်၊ စက်တိုင်းကို လုံခြုံအောင် ကာကွယ်ရတယ်၊ ထိန်းသိမ်းရမယ့် စက်လည်း ပိုများလာပါတယ်။

ဥပမာတွေကတော့ Google Spanner၊ Amazon DynamoDB၊ Apache Cassandra၊ CockroachDB နဲ့ ဒေတာကို server (တခြား ကွန်ပျူတာတွေကို ဝန်ဆောင်မှု ပေးတဲ့ ကွန်ပျူတာ) အများပေါ် ခွဲထားတဲ့အခါ MongoDB (sharded cluster) တို့ ဖြစ်ပါတယ်။ Cloud database ဝန်ဆောင်မှု အများအပြားကလည်း database တစ်ခုစီရဲ့ copy တွေကို data centre အများမှာ သိမ်းထားပါတယ်။

ဘာကြောင့် ဖြန့်ခွဲ သိမ်းတာလဲ

စက်ကြီး တစ်လုံးကနေ စက်သေး အများကြီးဆီ ပြောင်းရတဲ့ အဓိက အကြောင်းရင်း သုံးခု ရှိပါတယ်:

  1. Volume (ဒေတာ ပမာဏ)။ ရနိုင်တဲ့ အကြီးဆုံး စက် တစ်လုံးပေါ်မှာတောင် ဒေတာ မဆံ့တော့ရင် စက် အများပေါ် ခွဲသိမ်းရပါတယ်။
  2. Throughput။ Throughput ဆိုတာ စနစ် တစ်ခုက တစ်စက္ကန့်မှာ လုပ်နိုင်တဲ့ အလုပ် ပမာဏပါ။ တစ်စက္ကန့်ကို write (ဒေတာ ပြောင်းလဲမှု) သိန်းနဲ့ချီ ဝင်လာတဲ့ ဝဘ်ဆိုက် တစ်ခုမှာ အလုပ်တွေကို မီအောင် လုပ်ဖို့ စက် တစ်လုံးထက် ပိုလိုနိုင်လို့ အလုပ်ကို စက် အများပေါ် ဖြန့်ပေးပါတယ်။
  3. Geography (ပထဝီ တည်နေရာ)။ အကောင်းဆုံး network (ကွန်ရက်) ပေါ်မှာတောင် Tokyo က သုံးစွဲသူတွေအတွက် Frankfurt မှာ ရှိတဲ့ database က နှေးပါတယ်၊ ဘာလို့လဲဆိုတော့ signal တွေ တိုက်တွေကို ဖြတ်ဖို့ အချိန် ယူရလို့ပါ: optical fibre (အလင်းနဲ့ ဒေတာ ပို့တဲ့ ကြိုး) ထဲမှာ အလင်းက Tokyo ကနေ Frankfurt ကို သွားပြီး ပြန်လာဖို့ အနည်းဆုံး 90 millisecond (တစ်စက္ကန့်ရဲ့ တစ်ထောင်ပုံ တစ်ပုံ) ကြာပါတယ်၊ အဲဒီ ခရီးက 18,000 km ကျော် ဝေးပါတယ်။ သုံးစွဲသူ အုပ်စု တစ်ခုစီရဲ့ အနီးမှာ ဒေတာ copy တွေ ထားရင် သူတို့အတွက် ဒေတာ ဖတ်တာ အများကြီး ပိုမြန်လာပါတယ်။

ဒီလို လုပ်ရင် ပေးရတဲ့ တန်ဖိုးလည်း ရှိပါတယ်: row (အလျားလိုက် အတန်း) အများကို သုံးတဲ့ operation (ဒေတာပေါ်မှာ လုပ်တဲ့ လုပ်ဆောင်ချက်) တစ်ခုအတွက် အခု စက် အများ ပူးပေါင်း အလုပ်လုပ်ဖို့ လိုလာနိုင်ပါတယ်။ အဲဒါက အလုပ် တူတူကို စက် တစ်လုံးတည်းပေါ်မှာ လုပ်တာထက် ပိုခက်ပြီး ပိုနှေးပါတယ်။

ဖော်ပြရှင်းပြနိုင်ရမယ့် Feature ဆယ်ခု

IB syllabus (ဒီ site လက်ရှိ လိုက်နာနေတဲ့ IB Computer Science သင်ရိုး) က distributed database တွေရဲ့ feature ဆယ်ခုကို ဖော်ပြထားပါတယ်။ Feature တစ်ခုစီက မတူတဲ့ ပြဿနာ တစ်ခုကို ကိုယ်ပိုင် နည်းလမ်းနဲ့ ဖြေရှင်းပြီး ကိုယ်ပိုင် ကုန်ကျစရိတ်လည်း ရှိပါတယ်။ Transaction (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ်တဲ့ database လုပ်ဆောင်ချက် အစု) တစ်ခုက စက် အများပေါ်မှာ run တဲ့အခါ ACID (transaction တစ်ခုရဲ့ အာမခံချက် လေးခု) property တွေ ဘယ်လို သက်ရောက်လဲ ဆိုတာကိုလည်း syllabus က မေးပါတယ်။ အဲဒါကို feature ဆယ်ခု ပြီးတဲ့နောက် Node အများကြား ACID ရဲ့ အခန်းကဏ္ဍ အပိုင်းမှာ ရှင်းပြထားပါတယ်။

1. Concurrency Control (transaction တွေ တစ်ပြိုင်နက် မှန်ကန်စွာ run အောင် ထိန်းခြင်း)

Transaction အများကြီးက စက် အများကြီးပေါ်မှာ တစ်ပြိုင်နက် run နေပါတယ်။ Concurrency control က အဲဒီ transaction တွေ တစ်ခုရဲ့ ပြောင်းလဲမှုကို တစ်ခုက ဝင်မနှောင့်ယှက်အောင် တားပေးပါတယ်။ စက် တစ်လုံးတည်းပေါ်မှာဆိုရင် Transactions and Views မှာ လေ့လာခဲ့တဲ့ Isolation (တစ်ခုနဲ့ တစ်ခု သီးခြား ခွဲထားမှု) property ကို ပေးတာ concurrency control ပါပဲ။ အတင်းကျပ်ဆုံး isolation level (isolation ရဲ့ တင်းကျပ်မှု အဆင့်) ဖြစ်တဲ့ serialisable မှာ ရလဒ်က transaction တွေကို တစ်ခုပြီးမှ တစ်ခု run ခဲ့သလို ထွက်ပါတယ်။ စက် အများကြားမှာတော့ concurrency control က အောက်ပါ နည်းတွေကို သုံးပါတယ်:

  • Distributed lock များ: transaction တစ်ခုက သူသုံးတဲ့ node တိုင်းမှာ သူပြောင်းမယ့် row တွေကို lock (တခြား transaction တွေ မပြင်နိုင်အောင် ခဏ ပိတ်ထားခြင်း) လုပ်ပါတယ်။ တခြား transaction တွေက အဲဒီ lock တွေ ပြန်ဖွင့်ပေးတဲ့အထိ စောင့်ရပါတယ်။
  • Multi-version concurrency control (MVCC): row တစ်ခုစီက version အများကို သိမ်းထားပါတယ်။ ဒေတာ ဖတ်တဲ့ transaction က အချိန် တစ်ချိန်မှာ ရှိခဲ့တဲ့ အတိုင်း ဒေတာကို မြင်ရပါတယ် (snapshot: တစ်ချိန်ချိန်က အခြေအနေကို အတိအကျ မှတ်တမ်းတင်ထားခြင်း)။ ဒေတာ ရေးတဲ့ transaction ကတော့ တခြားသူ ဖတ်နေတဲ့ version ကို မပြောင်းဘဲ version အသစ် တစ်ခု ထပ်ထည့်ပါတယ်။
  • Timestamp ordering: transaction တစ်ခုစီကို timestamp (ဖြစ်ချိန်ကို ပြတဲ့ အချိန် အမှတ်အသား) တစ်ခု ပေးပြီး ဒေတာ တူတူကို သုံးတဲ့ transaction တွေကို timestamp အစဉ်အတိုင်း စီပါတယ်။ Timestamp တွေက node တွေ message တွေနဲ့ အတူ ပို့ပေးပြီး အချင်းချင်း ကိုက်ညီအောင် ထိန်းထားတဲ့ ရေတွက်စဉ် နံပါတ်တွေ (logical clock) ဖြစ်နိုင်သလို စက်တွေရဲ့ နာရီကနေ ဖတ်ယူတဲ့ အချိန်တွေလည်း ဖြစ်နိုင်ပါတယ်။ စက်တွေရဲ့ နာရီကို သုံးတဲ့ စနစ်က အဲဒီ နာရီတွေ မတူညီနိုင်တာကို ထည့်တွက်ရပါတယ် (“Distributed Database တွေကို ဘာက ခက်ခဲစေလဲ” အပိုင်းကို ကြည့်ပါ)။

စက်တွေကြား message တွေက ရောက်ဖို့ အချိန် ယူရပြီး နောက်ကျတာ၊ ပျောက်တာ၊ နှစ်ခါ ရောက်တာ ဖြစ်နိုင်လို့ စက် အများကြားမှာ concurrency control လုပ်ရတာ စက် တစ်လုံးတည်းမှာထက် ပိုခက်ပါတယ်။ Node မတူတဲ့ transaction နှစ်ခုက တစ်ခုကို တစ်ခု အပြန်အလှန် စောင့်နေတာ (deadlock: အချင်းချင်း စောင့်ရင်း ပိတ်မိနေခြင်း) လည်း ဖြစ်နိုင်ပြီး ဘယ် node တစ်ခုတည်းကမှ ဒါကို ကိုယ့်ဘာသာ မမြင်နိုင်ပါဘူး။ Node တိုင်းက lock manager (lock တွေကို ခွဲပေးတဲ့ program) တစ်ခုတည်းကို မေးရမယ်ဆိုရင် အဲဒီ manager က bottleneck (တခြား အရာအားလုံးကို ကြန့်ကြာစေတဲ့ နှေးတဲ့ နေရာ တစ်ခုတည်း) ဖြစ်လာနိုင်ပါတယ်။

2. Data Consistency (ဒေတာ copy တွေ အချင်းချင်း ကိုက်ညီမှု)

ဒေတာ တူတူကို စက် အများပေါ်မှာ သိမ်းထားတဲ့အခါ copy တွေ (replica: ဒေတာ မိတ္တူ) က အချင်းချင်း ကိုက်ညီရပါမယ်။ မကိုက်ညီရင် သုံးစွဲသူ နှစ်ယောက်က တစ်ချိန်တည်းမှာ မတူတဲ့ ကုန်ပစ္စည်း လက်ကျန် အရေအတွက် ဒါမှမဟုတ် ငွေလက်ကျန်တွေကို မြင်ရနိုင်ပြီး လူတွေက ခေတ်မမီတော့တဲ့ ဒေတာနဲ့ ဆုံးဖြတ်ချက် ချမိပါလိမ့်မယ်။ Replica တစ်ခုမှာ ပြောင်းလဲမှု ဖြစ်ရင် ကျန်တဲ့ replica တွေဆီ ရောက်ရပါမယ်။ အဓိက မေးခွန်းက ဘယ်အချိန် ရောက်ရမလဲ ဆိုတာပါ:

  • Strong consistency (ချက်ချင်း ကိုက်ညီမှု): ဘယ် replica က ဖြေဖြေ read (ဒေတာ တောင်းဆိုမှု) တိုင်းက commit (ပြောင်းလဲမှုကို အပြီးအတည် သိမ်းခြင်း) လုပ်ပြီးသား နောက်ဆုံး write ကို မြင်ရပါတယ်။ ဒါက အချိန် ကုန်ပါတယ်: operation တစ်ခုစီက replica အများကို စောင့်ရတယ်၊ ဒါမှမဟုတ် leader ကို ဖြတ်သွားရပါတယ် (အောက်မှာ ကြည့်ပါ)။
  • Eventual consistency (နောက်ဆုံးမှာ ကိုက်ညီလာမှု): replica တွေက ခဏတာ မကိုက်ညီဘဲ ရှိနိုင်ပါတယ်၊ write တွေ ရပ်သွားတာနဲ့ replica အားလုံးမှာ တန်ဖိုး တူတူ ဖြစ်လာပါတယ်။ အချိန် ကန့်သတ်ချက် မသတ်မှတ်ထားပေမယ့် network ပုံမှန် အလုပ်လုပ်နေရင် နောက်ကျချိန်က များသောအားဖြင့် တိုပါတယ်။ အနည်းငယ် ခေတ်မမီတဲ့ တန်ဖိုးကို ဖတ်မိရင်လည်း လက်ခံနိုင်တဲ့ နေရာတွေမှာ ကြီးမားတဲ့ စနစ် အများအပြားက ဒါကို သုံးပါတယ်။
  • Causal consistency (အကြောင်းနဲ့ အကျိုး အစဉ်အတိုင်း ကိုက်ညီမှု) က နှစ်ခုရဲ့ ကြားမှာ ရှိပါတယ်: တစ်ခုနဲ့ တစ်ခု မှီခိုနေတဲ့ ပြောင်းလဲမှုတွေ (ပြန်စာ တစ်စောင်နဲ့ အဲဒီ ပြန်စာက ဖြေတဲ့ message) က replica တိုင်းမှာ အစဉ် တူတူနဲ့ ပေါ်ပါတယ်။

Strong consistency ပေးနိုင်တဲ့ နည်း နှစ်နည်း။ ပထမ နည်းက တစ်ခုနဲ့ တစ်ခု ထပ်နေတဲ့ replica အုပ်စုတွေ (quorum) ကို သုံးပါတယ်။ ဒေတာ အပိုင်း တစ်ခုစီမှာ copy N ခု ရှိတယ်၊ write တစ်ခုကို replica W ခုမှာ ရောက်ပြီးမှ အတည်ပြုတယ်၊ read တစ်ခုက replica R ခုကို မေးပြီး အသစ်ဆုံး version ကို ယူတယ် ဆိုပါစို့။ R + W က N ထက် ကြီးရင် read က မေးတဲ့ replica တွေထဲမှာ အတည်ပြုပြီးသား နောက်ဆုံး write ရှိတဲ့ replica အနည်းဆုံး တစ်ခု အမြဲ ပါပါတယ်: copy သုံးခု ရှိရင် replica နှစ်ခု (အများစု) ဆီ ရောက်တဲ့ write တွေနဲ့ replica နှစ်ခုဆီ ရောက်တဲ့ read တွေက ဒီလို ထပ်နေပါတယ်။ ဒါက ရိုးရှင်းအောင် လုပ်ထားတဲ့ model ပါ။ ဒီ model က operation တွေ တစ်ခုပြီးမှ တစ်ခု ဖြစ်တယ် (write တစ်ခု မပြီးသေးခင် read မ run ဘူး)၊ write တိုင်းက replica W ခုဆီ ရောက်တယ် ဒါမှမဟုတ် ဘာမှ မကျန်ခဲ့ဘဲ ရှင်းရှင်းလင်းလင်း မအောင်မြင်ဘူး၊ version တွေကို အစဉ်လိုက် စီလို့ရတယ်လို့ ယူဆထားပါတယ်။ တကယ့် စနစ်တွေကတော့ ပိုခက်တဲ့ အခြေအနေတွေအတွက် စည်းမျဉ်းတွေ ထပ်ထည့်ပါတယ်၊ ဥပမာ မအောင်မြင်ခင် replica တချို့ဆီပဲ ရောက်သွားတဲ့ write၊ တစ်ချိန်တည်းမှာ ဖြစ်တဲ့ write နှစ်ခု၊ ဒါမှမဟုတ် ပျက်နေပြီးမှ ပြန်ပေါ်လာတဲ့ node။ ဥပမာ Cassandra က read တစ်ခုက ခေတ်မမီဘူးလို့ တွေ့တဲ့ ဘယ် replica ကိုမဆို အသစ်ဆုံး version ကို ကူးပေးပါတယ် (read repair: ဖတ်ရင်း ပြင်ပေးခြင်း)။ ဒုတိယ နည်းကတော့ write တိုင်းနဲ့ နောက်ဆုံး ဒေတာ ဖြစ်ရမယ့် read တိုင်းကို leader replica (အဲဒါတွေကို လက်ခံဖို့ ရွေးထားတဲ့ copy တစ်ခု) တစ်ခုတည်းဆီ ပို့တာပါ။ ဒီလိုဆိုရင် leader အသစ်က တာဝန် ယူပြီးတာနဲ့ leader အဟောင်း ဆက်မဖြေအောင်လည်း စနစ်က တားရပါတယ်။

Consistency ရဲ့ အဓိပ္ပာယ် နှစ်မျိုး။ ACID ထဲက C (Transactions and Views) က transaction တိုင်း ပြီးတဲ့အခါ database ကို မှန်ကန်တဲ့ အခြေအနေမှာ ထားခဲ့ရမယ်လို့ ဆိုလိုပါတယ်: စည်းမျဉ်းတိုင်းနဲ့ constraint (ဒေတာ လိုက်နာရမယ့် ကန့်သတ်ချက်) တိုင်း မှန်နေဆဲ ဖြစ်ရပါမယ်။ Distributed database မှာ data consistency ဆိုတာကတော့ ဒေတာ copy တွေ အချင်းချင်း ကိုက်ညီတာကို ဆိုလိုပါတယ်။ Distributed database မှာ နှစ်မျိုးလုံး လိုပါတယ်: node တိုင်းရဲ့ စည်းမျဉ်းတွေ မှန်နေရမယ်၊ copy တွေကလည်း အချင်းချင်း ကိုက်ညီရပါမယ်။

ဒုတိယ အဓိပ္ပာယ်က CAP theorem (CAP သီအိုရီ၊ အောက်က “Syllabus ထက် ကျော်လွန်တဲ့ အပိုင်း” မှာ ရှင်းပြထားပါတယ်) ထဲက အဓိပ္ပာယ်ပါ: node တွေကြားက network ပြတ်နေတုန်းမှာ distributed system (ကွန်ပျူတာ အများ ပေါင်းပြီး အလုပ်လုပ်တဲ့ စနစ်) တစ်ခုက သူဖြေတဲ့ read တိုင်း နောက်ဆုံး ဒေတာ ဖြစ်အောင် လုပ်နိုင်တယ်၊ ဒါမှမဟုတ် request (တောင်းဆိုမှု) တိုင်းကို ဆက်ဖြေနေနိုင်တယ်၊ ဒါပေမယ့် နှစ်ခုလုံး မရနိုင်ပါဘူး။

3. Partitioning (Sharding၊ database ကို အပိုင်းတွေ ခွဲသိမ်းခြင်း)

Partitioning (syllabus မှာ data partitioning လို့ ခေါ်ပါတယ်) က dataset (ဒေတာ အစုအဝေး) ကို စက်တွေပေါ်မှာ ခွဲပေးလို့ စက် တစ်လုံးစီမှာ ဒေတာရဲ့ အစိတ်အပိုင်း တစ်ခုပဲ ရှိပါတယ်။ အသုံးများတဲ့ နည်းတွေကတော့:

  • Hash partitioning: row ရဲ့ key (row တစ်ခုကို ခွဲခြား ရှာဖွေဖို့ သုံးတဲ့ တန်ဖိုး) ပေါ်မှာ hash function (key ကို ဂဏန်း တစ်ခုအဖြစ် ပြောင်းပေးတဲ့ မပြောင်းလဲတဲ့ ပုံသေနည်း) ကို သုံးပြီး ထွက်လာတဲ့ ရလဒ်က row ကို ဘယ်စက်မှာ သိမ်းမလဲ ဆုံးဖြတ်ပါတယ်။ ဒီနည်းက row တွေနဲ့ အလုပ်တွေကို များသောအားဖြင့် ညီညီမျှမျှ ဖြန့်ပေးပါတယ်။ ဒါပေမယ့် ဆက်တိုက် key တွေကို စက်တိုင်းပေါ် ပြန့်ကျဲသွားစေလို့ range query (member ID အတွဲ တစ်ခုလို ဆက်တိုက် ရှိနေတဲ့ key တွေကို database ဆီ တောင်းတဲ့ query) တွေက စက်တိုင်းကို မေးရပြီး အလုပ် ပိုများပါတယ်။
  • Range partitioning: row တွေကို key ရဲ့ အပိုင်းအခြားအလိုက် ခွဲပါတယ် (ဥပမာ MemberID 0 ကနေ 999 ကို စက် A ပေါ်မှာ၊ 1000 ကနေ 1999 ကို စက် B ပေါ်မှာ)။ Range query တစ်ခုက အဲဒီ အပိုင်းအခြားကို သိမ်းထားတဲ့ စက်တွေကိုပဲ မေးဖို့ လိုလို့ အလုပ် သက်သာပြီး များသောအားဖြင့် ပိုမြန်ပါတယ်။ ID နဲ့ ရက်စွဲလို တဖြည်းဖြည်း တိုးလာနေတဲ့ key တွေက row အသစ်တိုင်းကို နောက်ဆုံး အပိုင်းအခြားဆီ ပို့လို့ အဲဒီ အပိုင်းအခြားက “hot spot” (အလုပ် အများစုကို လုပ်နေရတဲ့ စက် တစ်လုံး) ဖြစ်လာနိုင်ပါတယ်။
  • Geographic partitioning: row တွေကို သုံးစွဲသူရဲ့ ဒေသအလိုက် ခွဲပါတယ် (အာရှက သုံးစွဲသူတွေကို အာရှက စက်တွေပေါ်မှာ)။ ဒါက အဲဒီ သုံးစွဲသူတွေအတွက် latency (တောင်းဆိုမှုနဲ့ တုံ့ပြန်မှုကြား နှောင့်နှေးချိန်) ကို လျှော့ပေးပေမယ့် ဒေသ အများကို ခြုံတဲ့ query တွေကိုတော့ ပိုနှေးစေပါတယ်။

Partition (ခွဲထားတဲ့ ဒေတာ အပိုင်း) အများက row တွေ လိုတဲ့ query တစ်ခု၊ ဥပမာ မတူတဲ့ ပုံစံနဲ့ partition လုပ်ထားတဲ့ table (database ထဲက ဇယား) နှစ်ခုကြားက JOIN တစ်ခုက စက်တွေကြား row တွေကို ပို့ရလို့ အဲဒီ query ကို စက် တစ်လုံးတည်းပေါ်မှာ run တာထက် များသောအားဖြင့် ပိုနှေးပါတယ်။ Distributed database မှာ schema design (database ဖွဲ့စည်းပုံ ဒီဇိုင်း) က ဆက်စပ်တဲ့ row တွေကို node တစ်ခုတည်းမှာ ထားပေးမယ့် partition key (row တစ်ခုကို ဘယ် node မှာ ထားမလဲ ဆိုတာကို သူ့တန်ဖိုးက ဆုံးဖြတ်တဲ့ column) ကို ရွေးတာပေါ် မူတည်လေ့ ရှိပါတယ်။

4. Security (လုံခြုံရေး)

Syllabus မှာ ဒီ feature ကို data security လို့ ခေါ်ပါတယ်။ Distributed database မှာ စက် တစ်လုံးတည်းသုံးတဲ့ database ထက် ကာကွယ်ရမယ့် အရာတွေ ပိုများပါတယ်: တစ်ယောက်ယောက်က node တွေကြားက network traffic (network ပေါ်က ဒေတာ အသွားအလာ) ကို ကြားဖြတ် ဖမ်းယူနိုင်တယ်၊ node တစ်ခုကို သိမ်းပိုက်လိုက်တဲ့ တိုက်ခိုက်သူက အဲဒီ node ရဲ့ ဒေတာကို ပေါက်ကြားစေနိုင်တယ်၊ မှားယွင်းစွာ သတ်မှတ်ထားတဲ့ replica တစ်ခုက ဘယ်သူမဆို ဝင်လို့ရတဲ့ public အင်တာနက်ပေါ်မှာ ပွင့်နေနိုင်ပါတယ်။ လုံခြုံရေး နည်းလမ်းတွေထဲမှာ ဒါတွေ ပါပါတယ်:

  • Encryption in transit: node တွေကြား ပို့နေတဲ့ ဒေတာကို encryption (ဒေတာကို ဖတ်မရအောင် ပြောင်းခြင်း) လုပ်ပါတယ်၊ များသောအားဖြင့် TLS (အင်တာနက် traffic ကို encrypt လုပ်တဲ့ protocol) ကို သုံးပါတယ်။
  • Encryption at rest: node တစ်ခုစီရဲ့ disk တွေပေါ်မှာ သိမ်းထားတဲ့ ဒေတာကို encrypt လုပ်ထားပါတယ်။
  • Per-node authentication (node တစ်ခုချင်းစီ တကယ် ဟုတ်မဟုတ် စစ်ခြင်း): node တစ်ခုစီက ကိုယ် ဘယ်သူလဲ ဆိုတာကို တခြား node တွေကို သက်သေပြပါတယ်။
  • Role-based access control (တာဝန်အလိုက် သုံးခွင့် ထိန်းချုပ်မှု): သုံးစွဲသူရဲ့ role (တာဝန်) က သူ ဘာကို ဖတ်ခွင့်၊ ပြင်ခွင့် ရှိလဲ ဆုံးဖြတ်ပြီး node တိုင်းမှာ စည်းမျဉ်း တူတူ သုံးပါတယ်။
  • Audit logging (စစ်ဆေးဖို့ မှတ်တမ်း ထားခြင်း): node တိုင်းမှာ စီမံခန့်ခွဲမှုဆိုင်ရာ လုပ်ဆောင်ချက် တိုင်း (ဥပမာ သုံးစွဲသူ တစ်ယောက်ရဲ့ ခွင့်ပြုချက်တွေကို ပြောင်းတာ) ကို မှတ်တမ်း တင်ထားပါတယ်။

Node တစ်ခု ဒါမှမဟုတ် ချိတ်ဆက်မှု link တစ်ခုမှာ အားနည်းချက် ရှိရင် စနစ် တစ်ခုလုံးကို အန္တရာယ် ဖြစ်စေနိုင်လို့ node တိုင်းမှာ ဒီ ကာကွယ်မှုတွေ လိုပါတယ်၊ သုံးစွဲသူတွေနဲ့ program တွေ အပြင်ကနေ ဝင်ချိတ်တဲ့ နေရာတွေမှာလည်း လိုပါတယ်။ ကိုယ်ရေး ကိုယ်တာ ဒေတာကို ဘယ်မှာ သိမ်းခွင့် ရှိလဲ ဆိုတာကိုလည်း ဥပဒေတွေက သတ်မှတ်နိုင်လို့ အဖွဲ့အစည်း တစ်ခုက နိုင်ငံ တစ်ခုစီရဲ့ ဒေတာကို အဲဒီ နိုင်ငံထဲက node တွေမှာ သိမ်းထားဖို့ လိုနိုင်ပါတယ်။

5. Distribution Transparency (ဖြန့်ခွဲထားမှုကို ဖုံးကွယ်ထားခြင်း)

သုံးစွဲသူတွေနဲ့ application (သုံးစွဲသူအတွက် ရေးထားတဲ့ software) တွေက distributed database ကို စက် တစ်လုံးပေါ်က database တစ်ခုတည်းလို သုံးနိုင်ရပါမယ်။ Distribution transparency ဆိုတာ ဒီ ရည်မှန်းချက်ပါ: DBMS က ဒေတာ ဖြန့်ခွဲထားတာကို ဖုံးကွယ်ထားလို့ ဒေတာကို ဘယ်လို ဖြန့်ထားထား query တူတူက အလုပ်လုပ်ပါတယ်။ (ဒီနေရာမှာ transparent ဆိုတာ မမြင်ရတာကို ဆိုလိုပါတယ်: သုံးစွဲသူတွေက ဖြန့်ခွဲထားတာကို သတိမထားမိပါဘူး။) ဒီမှာ အပိုင်း အများ ပါပါတယ်:

Transparency အမျိုးအစား ဖုံးကွယ်ထားတဲ့ အရာ
Location transparency Row ကို တကယ် သိမ်းထားတဲ့ ရုပ်ပိုင်းဆိုင်ရာ စက်က ဘယ်စက်လဲ ဆိုတာ (နောက် feature ကို ကြည့်ပါ)
Replication transparency Row က စက် အများပေါ်မှာ ရှိနေတာ
Partition transparency (fragmentation transparency လို့လည်း ခေါ်ပါတယ်) Table ကို စက်တွေပေါ် ခွဲထားတာ
Failure transparency Node တစ်ခု ပျက်သွားပြီး စနစ်က ပြန်ကောင်းလာတာ
Concurrency transparency Transaction အများကြီး တစ်ပြိုင်နက် run နေတာ

ဒါ မရှိရင် developer (software ရေးသူ) တိုင်းက မှန်ကန်တဲ့ query တစ်ခု မရေးခင် ဘယ် node မှာ ဘာရှိလဲ သိထားရပါလိမ့်မယ်။ ဒါ ရှိနေတာတောင် မြန်နှုန်းက ဒေတာ ရှိတဲ့ နေရာပေါ် မူတည်နေဆဲ ဖြစ်လို့ developer တွေက partition key တွေကို ဂရုတစိုက် ရွေးရဆဲပါ (Partitioning ကို ကြည့်ပါ)။

6. Location Transparency (ဒေတာ ရှိရာ နေရာကို ဖုံးကွယ်ထားခြင်း)

Location transparency ဆိုတာ distribution transparency ထဲက ဒေတာ သိမ်းထားတဲ့ နေရာကို ဖုံးကွယ်ပေးတဲ့ အပိုင်းပါ။ Query တစ်ခုက သူလိုချင်တဲ့ table နဲ့ row တွေကို နာမည် ဖော်ပြပါတယ်၊ အဲဒါတွေကို သိမ်းထားတဲ့ စက်၊ site (နေရာ) ဒါမှမဟုတ် network လိပ်စာကို မဖော်ပြပါဘူး။ DBMS က သူ့ catalogue (ဘယ် node မှာ ဘယ် partition ရှိလဲ ဆိုတဲ့ မှတ်တမ်း) ထဲမှာ နေရာကို ရှာပြီး request ကို အဲဒီကို ပို့ပါတယ်။

Application က SELECT * FROM Member WHERE MemberID = 1001; လို့ ရေးပြီး row ကို ပြန်ရပါတယ်၊ အဲဒီ row က Frankfurt က node 7 ပေါ်မှာ ရှိနေနေ၊ node 3 နဲ့ 14 ဆီ ကူးနေဆဲ ဖြစ်နေနေ အတူတူပါပဲ။ Application က node ကို နာမည် မဖော်ပြတဲ့အတွက် administrator (စနစ်ကို စီမံသူ) တွေက application ကို မပြင်ဘဲ node တွေကြား ဒေတာ ရွှေ့တာ၊ node အသစ် ထည့်တာ၊ ပျက်သွားတဲ့ node ကို အစားထိုးတာတွေ လုပ်နိုင်ပါတယ်။

7. Fault Tolerance (အစိတ်အပိုင်း ပျက်လည်း ဆက်အလုပ်လုပ်နိုင်မှု)

စက် 100 ပါတဲ့ cluster တစ်ခုမှာ စက် တစ်လုံး မဟုတ် တစ်လုံး တစ်ခါတလေ ပျက်တာ ပုံမှန်ပါပဲ။ Fault tolerance ဆိုတာ database ရဲ့ အစိတ်အပိုင်းတွေ ပျက်သွားတဲ့အခါမှာလည်း database က မှန်မှန်ကန်ကန် ဆက်အလုပ်လုပ်နေတာကို ဆိုလိုပါတယ်။ ဒါအတွက် သုံးတာတွေက:

  • Replication (ဒေတာ copy တွေကို နေရာ အများမှာ ထားခြင်း၊ နောက် feature) က ဒေတာ copy တွေကို ထားပေးလို့ node တစ်ခု ပျောက်သွားလည်း ဒေတာ ကျန်ပါတယ်။
  • Automatic failover (အလိုအလျောက် တာဝန်လွှဲယူခြင်း): partition တစ်ခုရဲ့ primary replica (အဲဒီ partition ရဲ့ ပြောင်းလဲမှုတွေကို လက်ခံတဲ့ copy) ပျက်သွားရင် နောက်ထပ် copy တစ်ခု (secondary) က အလိုအလျောက် တာဝန် ဆက်ယူပါတယ်။ ဒါ ဘယ်လောက် ကြာလဲ ဆိုတာ သုံးတဲ့ database software ပေါ် မူတည်ပြီး စက္ကန့် အနည်းငယ်ကနေ တစ်မိနစ်၊ နှစ်မိနစ်အထိ ကြာနိုင်ပါတယ်။ အဲဒီ အချိန်အတွင်း request တချို့ မအောင်မြင်နိုင်ပြီး application က အဲဒါတွေကို ပြန်ပို့ပါတယ်။
  • Quorum read နဲ့ write: write တစ်ခုကို သူ့ replica တွေရဲ့ အများစု (quorum) က သိမ်းပြီးမှသာ အတည်ပြုလို့ အဲဒီ replica တွေရဲ့ တစ်ဝက်အောက် ပျောက်သွားရင် အတည်ပြုပြီးသား write တစ်ခုမှ မပျောက်ပါဘူး။
  • Self-healing (ကိုယ့်ဘာသာ ပြန်ကောင်းအောင် လုပ်ခြင်း): node တစ်ခု ပျောက်နေတာကို cluster က သတိထားမိပြီး အဲဒီ node ရဲ့ partition တွေကို တခြား node တွေဆီ ရွှေ့ပါတယ်၊ partition တစ်ခုစီမှာ စီစဉ်ထားတဲ့ copy အရေအတွက် ပြန်ပြည့်တဲ့အထိ copy အသစ်တွေ လုပ်ပါတယ်။

Fault tolerance မရှိရင် hardware ပျက်တာ တစ်ခုက ဖောက်သည်တွေအတွက် ဝန်ဆောင်မှုကို ရပ်သွားစေနိုင်ပါတယ်။ ရှိရင်တော့ cluster ကြီး တစ်ခုက စက်တွေ ပျက်တာ၊ အစားထိုးတာကို ပုံမှန် လုပ်ငန်းလို လုပ်နိုင်ပြီး သုံးစွဲသူတွေက များသောအားဖြင့် ခဏ ရပ်သွားတာလောက်ပဲ သတိထားမိပါတယ်။ အဲဒီ ရပ်ချိန် ဘယ်လောက် ကြာလဲ ဆိုတာ ပျက်တာကို ဘယ်လောက် မြန်မြန် သိလဲ၊ တခြား node က ဘယ်လောက် မြန်မြန် တာဝန် ယူလဲ ဆိုတာပေါ် မူတည်ပါတယ်။ Fault tolerance က ပျက်သွားတဲ့ စက်တွေကနေ ကာကွယ်ပေးပါတယ်၊ အမှားတွေကိုတော့ ပြန်မပြင်ပေးပါဘူး။ မှားပြီး ဖျက်လိုက်တဲ့ row က copy တိုင်းမှာ ပျက်သွားလို့ backup (အရန် မိတ္တူ) တွေ လိုနေဆဲပါ။

8. Replication (ဒေတာ copy တွေကို နေရာ အများမှာ ထားခြင်း)

Replication က ဒေတာ တူတူရဲ့ copy အများကို မတူတဲ့ စက်တွေပေါ်မှာ သိမ်းပါတယ်။ Availability (ဝန်ဆောင်မှုက request တွေကို ဆက်ဖြေပေးနေခြင်း) နဲ့ fault tolerance နှစ်ခုလုံး replication ပေါ် မူတည်ပါတယ်:

  • Synchronous replication (တစ်ပြိုင်တည်း ကူးသိမ်းခြင်း): replica အားလုံး ဒါမှမဟုတ် အများစုက write တွေကို သိမ်းပြီးမှ commit လုပ်ပါတယ်။ အတည်ပြုပြီးသား write က primary ပျောက်သွားလည်း ကျန်ပါတယ်၊ ဒါပေမယ့် write တစ်ခုစီ ပိုကြာပါတယ်။ Read တွေကလည်း အများစုဆီ မရောက်ရင် ဒါမှမဟုတ် primary ဆီ မသွားရင် replica တစ်ခုက ဖတ်တဲ့ ဒေတာက ခေတ်မမီ ဖြစ်နေနိုင်ပါသေးတယ် (Data Consistency ကို ကြည့်ပါ)။
  • Asynchronous replication (နောက်မှ လိုက်ကူးသိမ်းခြင်း): write တွေက primary ပေါ်မှာ ချက်ချင်း commit ဖြစ်ပြီး replica တွေက ခဏကြာမှ လိုက်မီပါတယ်။ Write တစ်ခုစီ ပိုမြန်ပေမယ့် replica တွေ မရခင် primary ပျက်သွားရင် နောက်ဆုံး write တွေ ပျောက်သွားနိုင်ပါတယ်။
  • Read replica များ: read query တွေကို ဖြေပေးတဲ့ အပို copy တွေပါ၊ ဒါကြောင့် primary မှာ လုပ်ရမယ့် အလုပ် လျော့သွားပါတယ်။

အသုံးများတဲ့ setting ဖြစ်တဲ့ replication factor (ဒေတာ copy အရေအတွက်) 3 ဆိုတာ ဒေတာ အပိုင်း တစ်ခုစီကို node သုံးခုမှာ သိမ်းထားတာကို ဆိုလိုပါတယ်။ အဲဒီ node တွေထဲက နှစ်ခု တစ်ပြိုင်နက် ပျောက်သွားရင်တောင် copy တစ်ခု ကျန်ပါသေးတယ်၊ ဒါပေမယ့် နောက်ဆုံး ပြောင်းလဲမှုတွေက ပျောက်သွားတဲ့ node နှစ်ခုဆီပဲ ရောက်ခဲ့ရင် ကျန်တဲ့ copy မှာ အဲဒီ ပြောင်းလဲမှုတွေ မပါနိုင်ပါဘူး။

9. Scalability (ဒေတာ များလာတဲ့အခါမှာလည်း ကောင်းကောင်း ဆက်အလုပ်လုပ်နိုင်မှု)

Distributed database က ရှိပြီးသား စက်ကို ပိုကြီးတဲ့ စက်နဲ့ အစားထိုးတာ မဟုတ်ဘဲ စက် အသစ်တွေ ထပ်ထည့်ပြီး capacity တိုးပါတယ်။ Distributed system ကို ရွေးတဲ့ အဓိက အကြောင်းရင်း တစ်ခုက ဒါပါပဲ၊ scaling (စွမ်းရည် တိုးချဲ့ခြင်း) နှစ်မျိုးကြားက ကွာခြားချက်လည်း ဒါပါပဲ:

  • Horizontal scaling (scale out၊ စက် အရေအတွက် တိုးပြီး ချဲ့ခြင်း): node တွေ ထပ်ထည့်ပါတယ်။ Cluster က partition တချို့နဲ့ replica တချို့ကို node အသစ်တွေပေါ် ရွှေ့ပေးလို့ (rebalancing: ဝန်ကို ပြန်ညှိခြင်း) အလုပ်ကို စက် ပိုများများကြား ခွဲဝေ လုပ်ပါတယ်။ ဒေတာကို partition key နဲ့ ကောင်းကောင်း ခွဲလို့ရသရွေ့ စက် တစ်လုံးထက် အများကြီး ပိုချဲ့နိုင်ပါတယ်။
  • Vertical scaling (scale up၊ စက်ကို ပိုကြီးတဲ့ စက်နဲ့ လဲပြီး ချဲ့ခြင်း): node တစ်ခုကို ပိုကြီးတဲ့ node နဲ့ အစားထိုးပါတယ်။ ဒါက ရနိုင်တဲ့ အကြီးဆုံး စက်မှာ ရပ်သွားပါတယ်။

Scale out လုပ်တာမှာလည်း သူ့ ကုန်ကျစရိတ်တွေ ရှိပါတယ်: node တွေကြား ညှိနှိုင်းမှု ပိုလိုတယ်၊ node ထည့်တဲ့အခါ row တွေ ရွှေ့ရတယ်၊ အလွန် အသုံးများတဲ့ key တစ်ခု (ဥပမာ နာမည်ကြီး တစ်ယောက်ရဲ့ account) ကတော့ node ဘယ်လောက် ရှိရှိ node တစ်ခုတည်းမှာပဲ ရှိနေပါတယ်။ အစကတည်းက ဖြန့်ခွဲဖို့ ဒီဇိုင်းဆွဲထားတဲ့ application က scale out လုပ်ရ ပိုလွယ်ပါတယ်၊ စက် တစ်လုံးအတွက် တည်ဆောက်ထားတဲ့ application ကို distributed database ပေါ် ရွှေ့ရင်တော့ သူ့ query တွေနဲ့ transaction တွေကို ပြန်ပြင်ရေးရလေ့ ရှိပါတယ်။

10. Global Query Processing (node အများက ဒေတာကို query တစ်ခုတည်းအဖြစ် ဖြေပေးခြင်း)

Query တစ်ခုက node အများပေါ်မှာ ရှိတဲ့ ဒေတာကို လိုလေ့ ရှိပါတယ်။ Global query processing ဆိုတာ DBMS က အဲဒီ query ကို query တစ်ခုတည်းအဖြစ် ဖြေပေးပုံပါ:

  1. Coordinator (query ကို လက်ခံတဲ့ node) က query လိုတဲ့ partition တွေကို ဘယ် node တွေမှာ ရှိလဲ ရှာပါတယ်။
  2. Query ကို အဲဒီ node တစ်ခုစီအတွက် အပိုင်းတွေ ခွဲပေးလို့ node တစ်ခုစီက ကိုယ့် row တွေပေါ်မှာ အလုပ်လုပ်ပါတယ်။
  3. ရလဒ် အပိုင်းတွေကို ပေါင်းပြီး အဖြေ တစ်ခုတည်း ပြန်ပေးပါတယ်။

Network ကနေ ဒေတာ ပို့တာ နှေးလို့ coordinator က node တစ်ခုစီကို သူ့ row တွေ သိမ်းထားတဲ့ နေရာမှာပဲ ကိုယ့်အပိုင်း အလုပ်ကို လုပ်ခိုင်းပြီး row အားလုံးကို ပြန်ပို့မယ့်အစား ရလဒ် အသေးလေး တစ်ခုကိုပဲ ပြန်ပို့ခိုင်းပါတယ်။ Node တွေဆီက စုစုပေါင်း၊ အရေအတွက်၊ အငယ်ဆုံး တန်ဖိုး၊ အကြီးဆုံး တန်ဖိုးတွေကို တိုက်ရိုက် ပေါင်းစပ်လို့ ရပါတယ် (စုစုပေါင်းတွေကို ပေါင်း၊ အကြီးဆုံး တန်ဖိုးတွေထဲက အကြီးဆုံးကို ယူ)။ ပျမ်းမျှကိုတော့ ဒီလို ပေါင်းစပ်လို့ မရပါဘူး။ Node တစ်ခုမှာ ပျမ်းမျှ တက်ရောက်သူ 21 ယောက် ရှိတဲ့ အတန်း လေးကြိမ်ရဲ့ ဒေတာ ရှိပြီး နောက် node တစ်ခုမှာ ပျမ်းမျှ 13 ယောက် ရှိတဲ့ အတန်း နှစ်ကြိမ်ရဲ့ ဒေတာ ရှိရင် စုစုပေါင်း ပျမ်းမျှက (84 + 26) / 6 = 18.3 ဖြစ်ပါတယ်၊ 21 နဲ့ 13 ရဲ့ ပျမ်းမျှ ဖြစ်တဲ့ 17 မဟုတ်ပါဘူး။ ဒါကြောင့် coordinator က node တစ်ခုစီဆီကနေ ပေါင်းလဒ်နဲ့ အရေအတွက်ကို တောင်းပါတယ်။ Partition key ရဲ့ တန်ဖိုး အတိအကျ တစ်ခုကို ရှာတဲ့ query (ဥပမာ MemberID က partition key ဖြစ်တဲ့အခါ WHERE MemberID = 1001) ကတော့ အဲဒီ တန်ဖိုး ရှိတဲ့ partition တစ်ခုတည်းဆီ သွားနိုင်ပါတယ်။ Node ဘယ်နှစ်ခု ပါဝင်မလဲ ဆိုတာကတော့ read က replica ဘယ်နှစ်ခုဆီ ရောက်ရမလဲ ဆိုတာပေါ် မူတည်နေဆဲပါ၊ တန်ဖိုး အပိုင်းအခြား တစ်ခု၊ တန်ဖိုး စာရင်း တစ်ခု ဒါမှမဟုတ် join တစ်ခုကလည်း တခြား partition တွေကို လိုနိုင်ပါသေးတယ်။

Node အများကြား ACID ရဲ့ အခန်းကဏ္ဍ

Transaction တစ်ခုက node အများပေါ်က row တွေကို ပြောင်းနိုင်ပါတယ်: ဥပမာ booking (ကြိုတင် စာရင်းသွင်းမှု) တစ်ခုက မှတ်တမ်းက node တစ်ခုပေါ်မှာ ရှိတဲ့ အတန်း တစ်ခုမှာ နေရာ တစ်နေရာ ယူပြီး နောက် node တစ်ခုပေါ်က member ရဲ့ account ထဲကနေ ကြိုတင် ငွေပေးထားတဲ့ class credit (အတန်း တစ်ကြိမ် တက်ခွင့်) တစ်ခုကို နုတ်ပါတယ်။ Transactions and Views မှာ လေ့လာခဲ့တဲ့ ACID property တွေ ဆက်သက်ဆိုင်နေဆဲ ဖြစ်ပြီး property တစ်ခုစီအတွက် အခု node တွေ ပူးပေါင်း အလုပ်လုပ်ဖို့ လိုလာပါတယ်:

Property Node အများကြားမှာ
Atomicity (အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ်) Node တိုင်းက ကိုယ့်အပိုင်းကို commit လုပ်ရမယ်၊ ဒါမှမဟုတ် node တိုင်းက roll back (ပြောင်းလဲမှုတွေကို ပြန်ဖျက်ပြီး မူလအတိုင်း ပြန်ထားခြင်း) လုပ်ရမယ်။ Booking က node တစ်ခုမှာ နေရာကို ယူပြီး နောက် node မှာ credit ကို မထိဘဲ ထားခဲ့လို့ မရပါဘူး။ ဒါကို ပေးတဲ့ ပုံမှန် နည်းက two-phase commit (အဆင့် နှစ်ဆင့်နဲ့ commit လုပ်တဲ့ နည်း၊ အောက်မှာ ရှင်းပြထားပါတယ်) ပါ
Consistency (စည်းမျဉ်းတွေ မှန်နေဆဲ ဖြစ်ခြင်း) Transaction ပြီးတဲ့အခါ ဒေတာ လိုက်နာရမယ့် စည်းမျဉ်းတိုင်း မှန်နေဆဲ ဖြစ်ရပါမယ်၊ node အများပေါ်က ဒေတာ ပါဝင်တဲ့ စည်းမျဉ်းတွေလည်း ပါပါတယ် (ဥပမာ member တစ်ယောက်ရဲ့ booking တွေက ငွေပေးထားတဲ့ credit ထက် မပိုရပါဘူး)။ Node တစ်ခုစီက CHECK constraint တွေလို ကိုယ့် စည်းမျဉ်းတွေကို စစ်နိုင်ပါတယ်။ မတူတဲ့ node တွေပေါ်က ဒေတာကို ချိတ်ထားတဲ့ စည်းမျဉ်းကိုတော့ transaction ကိုယ်တိုင်က သူဖတ်ထားပြီး တခြား ပြောင်းလဲမှုတွေကနေ ကာကွယ်ထားတဲ့ ဒေတာကို သုံးပြီး စစ်ရပါတယ်
Isolation တစ်ပြိုင်နက် run နေတဲ့ transaction တွေက တစ်ခုရဲ့ တစ်ဝက်တစ်ပျက် အလုပ်ကို တစ်ခုက မမြင်ရပါဘူး၊ အတင်းကျပ်ဆုံး အဆင့်မှာ ရလဒ်က transaction တွေကို တစ်ခုချင်း run ခဲ့သလို ထွက်ပါတယ်။ ဒါကို ပေးတဲ့ နည်း တစ်ခုက node တစ်ခုစီက transaction တစ်ခုလုံး မပြီးမချင်း သူယူထားတဲ့ lock တွေကို ဆက်ကိုင်ထားတာပါ၊ တခြား စနစ်တွေကတော့ row တစ်ခုစီရဲ့ version အများကို သိမ်းထားပြီး commit မလုပ်ခင် အချင်းချင်း ပဋိပက္ခ (conflict) ရှိမရှိ စစ်ပါတယ်
Durability (commit ပြီးသား ပြောင်းလဲမှု မပျောက်ခြင်း) Node တစ်ခုစီက commit လုပ်ပြီးသား ပြောင်းလဲမှုတွေကို disk ပေါ် ရေးပါတယ်၊ စနစ် အများအပြားကလည်း အဲဒါတွေကို replica တွေဆီ ကူးပေးပါတယ်

Two-phase commit က အထင်ရှားဆုံး atomic commit protocol ပါ: node အများကြားမှာ transaction တစ်ခုကို အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ် ဖြစ်အောင် လုပ်တဲ့ ပုံမှန် နည်းလမ်းပါ။ Node တစ်ခုက coordinator (ညှိနှိုင်းပေးတဲ့ node) အဖြစ် လုပ်ပါတယ်:

  1. Prepare (vote၊ ပြင်ဆင်ပြီး မဲပေးခြင်း)။ Coordinator က node တစ်ခုစီကို transaction ထဲက သူ့အပိုင်းကို ပို့ပါတယ်။ Node တစ်ခုစီက ကိုယ့် ပြောင်းလဲမှုတွေကို လုပ်တယ်၊ ကိုယ့် စည်းမျဉ်းတွေကို စစ်တယ်၊ crash (ရုတ်တရက် ပျက်ပြီး ရပ်သွားခြင်း) ဖြစ်ပြီးနောက်မှာတောင် commit လုပ်နိုင်လောက်အောင် disk ပေါ်မှာ လုံလောက်အောင် ရေးထားတယ်၊ lock တွေကို ဆက်ကိုင်ထားတယ်၊ ပြီးရင် yes ဒါမှမဟုတ် no မဲပေးပါတယ်။
  2. Commit or roll back (commit ဒါမှမဟုတ် roll back လုပ်ခြင်း)။ Node တိုင်းက yes မဲပေးရင် coordinator က node တိုင်းကို commit လုပ်ခိုင်းပါတယ်။ Node တစ်ခုခုက no မဲပေးရင် ဒါမှမဟုတ် အချိန်မီ မဖြေရင် node တိုင်းကို roll back လုပ်ခိုင်းပါတယ်။

Two-phase commit က node တိုင်းကို ဆုံးဖြတ်ချက် တူတူ (commit ဒါမှမဟုတ် roll back) ပေးပါတယ်၊ ဒါက atomicity ပါ။ Consistency နဲ့ isolation ကိုတော့ သူ့ဘာသာ မပေးပါဘူး: အဲဒါတွေက transaction တစ်ခုစီ စစ်တဲ့ စည်းမျဉ်းတွေနဲ့ concurrency control ကနေ လာပါတယ်။

ပေးရတဲ့ တန်ဖိုးက စောင့်ရတာပါ။ Transaction တစ်ခုစီမှာ message အသွားအပြန် နှစ်ကြိမ် လိုပြီး yes မဲပေးပြီးသား node က ဆုံးဖြတ်ချက် ရောက်လာတဲ့အထိ သူ့ lock တွေကို ဆက်ကိုင်ထားရပါတယ်။ အဲဒီ အချိန်မှာ coordinator ပျက်သွားရင် node က coordinator ပြန်ကောင်းလာတဲ့အထိ စောင့်ရပါတယ်။ Distributed system အများအပြားက ဖြစ်နိုင်ရင် transaction တစ်ခုစီကို partition တစ်ခုတည်းအတွင်းမှာပဲ ထားတာ၊ ဒါမှမဟုတ် ACID အာမခံချက် တချို့ကို အလျှော့ပေးတာ (အောက်က BASE model) ရဲ့ အကြောင်းရင်း တစ်ခုက ဒါပါပဲ။

အကျဉ်းချုပ် ဇယား

Feature ပေးတဲ့ အကျိုး ပုံမှန် သုံးတဲ့ နည်းလမ်း
Concurrency control မတူတဲ့ node တွေပေါ်မှာ တစ်ပြိုင်နက် run နေတဲ့ transaction တွေ အချင်းချင်း မနှောင့်ယှက်ပါဘူး၊ အတင်းကျပ်ဆုံး အဆင့်မှာ ရလဒ်က တစ်ခုချင်း run ခဲ့သလို ထွက်ပါတယ် Distributed lock၊ MVCC၊ timestamp ordering
Data consistency ဒေတာ copy တွေ ကိုက်ညီပါတယ်၊ ချက်ချင်း (strong) ဒါမှမဟုတ် ခဏ နောက်ကျပြီးမှ (eventual) အများစု (quorum) read နဲ့ write၊ partition တစ်ခုစီအတွက် leader တစ်ခု၊ Paxos နဲ့ Raft လို consensus protocol တွေ (ပြောင်းလဲမှု တစ်ခုစီကို node တွေ သဘောတူနိုင်အောင် လုပ်တဲ့ စည်းမျဉ်းများ)
Partitioning Dataset ကို node တွေပေါ် ခွဲထားလို့ ဘယ်စက် တစ်လုံးကမှ ဒေတာ အားလုံးကို သိမ်းစရာ၊ စီမံစရာ မလိုပါဘူး Hash၊ range ဒါမှမဟုတ် geographic partitioning
Security Node တစ်ခုတည်း မဟုတ်ဘဲ cluster တစ်ခုလုံးကို ကာကွယ်ထားပါတယ် Node တွေကြား TLS၊ encryption at rest၊ role-based access control၊ audit log
Distribution transparency Application တွေက logical database တစ်ခုတည်းကို မြင်ရပါတယ် Node တွေ၊ copy တွေနဲ့ partition တွေကို ဖုံးကွယ်ထားတဲ့ routing layer (request တစ်ခုစီကို မှန်ကန်တဲ့ node တွေဆီ ပို့ပေးတဲ့ software)
Location transparency Query တွေက ဒေတာကို နာမည် ဖော်ပြပါတယ်၊ ဒေတာ သိမ်းထားတဲ့ စက်ကို မဖော်ပြပါဘူး ဘယ် node မှာ ဘယ် partition ရှိလဲ ဆိုတဲ့ catalogue
Fault tolerance Node တွေ ပျက်နေတုန်းမှာလည်း cluster က ဆက် run နေပါတယ် Replication၊ automatic failover နဲ့ self-healing
Replication ဒေတာ အပိုင်းတိုင်းရဲ့ copy အများ မတူတဲ့ node တွေပေါ်မှာ ရှိပါတယ် Synchronous ဒါမှမဟုတ် asynchronous replication၊ replication factor 3 က အသုံးများပါတယ်
Scalability Node တွေ ထပ်ထည့်ပြီး capacity တိုးပါတယ် Horizontal scaling၊ database ဆက် run နေတုန်းမှာပဲ ဒေတာကို node အသစ်တွေဆီ ရွှေ့ပါတယ်
Global query processing Node အများ လိုတဲ့ query ကို query တစ်ခုတည်းအဖြစ် ဖြေပေးပါတယ် Coordinator က query ကို ခွဲတယ်၊ အပိုင်းတွေကို node တွေပေါ်မှာ run တယ်၊ ရလဒ်တွေကို ပေါင်းတယ်

Syllabus ထက် ကျော်လွန်တဲ့ အပိုင်း: CAP Theorem (CAP သီအိုရီ)

(Syllabus ထက် ကျော်လွန်ပေမယ့် သိထားရင် အသုံးဝင်တဲ့ နောက်ခံ အကြောင်းအရာပါ။) CAP theorem (2000 ခုနှစ်မှာ Eric Brewer က တင်ပြခဲ့ပြီး 2002 ခုနှစ်မှာ Seth Gilbert နဲ့ Nancy Lynch က သက်သေပြခဲ့တဲ့ သီအိုရီ) က အာမခံချက် သုံးခုအကြောင်း ဖြစ်ပါတယ်:

  • Consistency (ကိုက်ညီမှု): read တိုင်းက နောက်ဆုံး write ကို မြင်ရပါတယ်။
  • Availability: အလုပ်လုပ်နေတဲ့ node ဆီ ရောက်တဲ့ request တိုင်းက “service unavailable” (ဝန်ဆောင်မှု မရနိုင်ပါ) လို error မဟုတ်ဘဲ အောင်မြင်တဲ့ response (တုံ့ပြန်ချက်) ကို ရပါတယ် (အဲဒီ response မှာ နောက်ဆုံး တန်ဖိုး ပါချင်မှ ပါပါမယ်)။
  • Partition tolerance (network ပြတ်နေလည်း ဆက်အလုပ်လုပ်နိုင်မှု): node တွေကြားက network link တွေ ပြတ်သွားရင်တောင် စနစ်က ဆက်အလုပ်လုပ်နေပါတယ်။ (ဒီနေရာမှာ partition ဆိုတာ ဒေတာရဲ့ အပိုင်း မဟုတ်ဘဲ node တွေကို အချင်းချင်း မဆက်သွယ်နိုင်တဲ့ အုပ်စုတွေအဖြစ် ခွဲပစ်လိုက်တဲ့ network ပြတ်တောက်မှုကို ဆိုလိုပါတယ်။)

ဒီ သီအိုရီကို “သုံးခုထဲက ကြိုက်တဲ့ နှစ်ခု ရွေးပါ” လို့ အကျဉ်းချုပ်လေ့ ရှိပေမယ့် ဒါက လွဲမှားစေပါတယ်။ Network ပြတ်တောက်မှုတွေ (partition) က ဒီဇိုင်းဆွဲသူ ရွေးရွေး မရွေးရွေး ဖြစ်တာမို့ network ကွဲနေတုန်း စနစ်က ဘာကို အလျှော့ပေးရမလဲ ဆိုတာကို သီအိုရီက ပြောတာပါ: read တိုင်းကို နောက်ဆုံး ဒေတာ ဖြစ်အောင် ထားနိုင်တယ် (consistency)၊ ဒါမှမဟုတ် request တိုင်းကို ဆက်ဖြေနေနိုင်တယ် (availability)၊ ဒါပေမယ့် နှစ်ခုလုံး မရပါဘူး။ Network အလုပ်လုပ်နေတဲ့အခါမှာတော့ စနစ်က နှစ်ခုလုံး ပေးနိုင်ပါတယ်။

ဘယ် distributed system ကြီးမှာမဆို network ပြတ်တောက်မှုတွေ ဖြစ်မယ်လို့ မျှော်လင့်ထားရလို့ ဒီဇိုင်းဆွဲသူတွေက ပြတ်တောက်တဲ့အခါ ဘာဖြစ်မလဲ ဆိုတာကို ကြိုတင် ဆုံးဖြတ်ထားပါတယ်။ CP စနစ်တွေ (partition ဖြစ်နေတုန်း consistency ကို ထိန်းထားတဲ့ စနစ်တွေ) မှာ ပြတ်တောက်မှုကြောင့် ကွဲသွားတဲ့ ဘက်ခြမ်းတွေထဲက နောက်ဆုံး ဒေတာနဲ့ မဖြေနိုင်တဲ့ ဘက်ခြမ်း မှန်သမျှက request တွေကို ငြင်းပါတယ်။ အသုံးများတဲ့ စည်းမျဉ်း တစ်ခုက node တွေရဲ့ အများစုကို ဆက်သွယ်နိုင်တဲ့ ဘက်ခြမ်းကပဲ write တွေကို လက်ခံတာပါ။ AP စနစ်တွေ (availability ကို ထိန်းထားတဲ့ စနစ်တွေ) ကတော့ ဆက်သွယ်နိုင်တဲ့ node တွေပေါ်မှာ write ကို လက်ခံပြီး ကွာခြားချက်တွေကို နောက်မှ ညှိပါတယ်။ NoSQL (ပုံသေ table ပုံစံ မသုံးတဲ့ database) တချို့၊ ဥပမာ Cassandra နဲ့ DynamoDB က ဒီလို အလုပ်လုပ်နိုင်ပါတယ်။

NoSQL database တချို့က တင်းကျပ်တဲ့ ACID အစား BASE model (Basically Available, Soft state, Eventually consistent: database က ဆက်ဖြေပေးနေပြီး copy တွေက တစ်ခုနဲ့ တစ်ခု ကိုက်ညီမလာခင် ခဏတာ ကွဲပြားနေနိုင်တယ်) ကို သုံးရတဲ့ အကြောင်းရင်းက ဒါပါပဲ။ ကမ္ဘာအနှံ့ ဖြန့်ထားတဲ့ စနစ်မှာ node တချို့ကို ဆက်သွယ်မရတိုင်း write တွေကို ငြင်းတာထက် write တွေကို လက်ခံပြီး copy တွေကို ခဏကြာမှ ကိုက်ညီလာအောင် ထားတာ (eventual consistency) က ပိုကောင်းတဲ့ trade-off (တစ်ခု ရဖို့ တစ်ခု အလျှော့ပေးရတာ) ဖြစ်လေ့ ရှိပါတယ်။ Eventual consistency ကို လက်ခံနိုင်မလား ဆိုတာ application က ဒေတာကို ဘယ်လို သုံးလဲ၊ တစ်ယောက်ယောက်က ခေတ်မမီတဲ့ တန်ဖိုးကို ဖတ်မိရင် ဘာမှားသွားမလဲ ဆိုတာပေါ် မူတည်ပါတယ်။

Distributed Database တွေကို ဘာက ခက်ခဲစေလဲ

Distributed database တွေကို run ရ ဘာကြောင့် ခက်လဲ ဆိုတာကို ပြဿနာ နှစ်ခုက ရှင်းပြပါတယ်:

  1. Network တွေ ပျက်တတ်တယ်။ Packet (network ပေါ် ပို့တဲ့ ဒေတာ အစိတ်အပိုင်းငယ်) တွေ ပျောက်တယ်၊ site တွေကြား link တွေ ပြတ်တယ်၊ transaction တစ်ခု လုပ်နေရင်း တစ်ဝက်မှာ node တစ်ခုကို ဆက်သွယ်လို့ မရတော့တာ ဖြစ်နိုင်ပါတယ်။ ဒီစာမျက်နှာက feature အများအပြားဟာ ဒီ ပြတ်တောက်မှုတွေ ကြားကပဲ ဆက်အလုပ်လုပ်နိုင်အောင် လုပ်တဲ့ နည်းလမ်းတွေပါ။
  2. စက် အမျိုးမျိုးက နာရီတွေ မတူညီကြဘူး။ NTP (Network Time Protocol: network ကနေ နာရီတွေကို ချိန်ပေးတဲ့ protocol) က အဆက်မပြတ် ပြင်ပေးနေတာတောင် စက် နှစ်လုံးရဲ့ နာရီတွေက millisecond နဲ့ချီပြီး ကွာသွားနိုင်ပါတယ်။ ဒါကြောင့် စက် တစ်လုံးထက် ပိုလာတာနဲ့ “ဘယ် write က အရင် ဖြစ်ခဲ့လဲ” ဆိုတာ ဖြေရခက်တဲ့ မေးခွန်း ဖြစ်လာပါတယ်။ စနစ် တချို့က logical timestamp (message တွေနဲ့ အတူ ပို့ပေးတဲ့ ရေတွက်စဉ် နံပါတ်) တွေကို သုံးပြီး နာရီကို အားကိုးတာကို ရှောင်ပါတယ်။ Google Spanner ကတော့ နာရီတွေကို အားကိုးပါတယ်၊ သူ့ data centre တွေထဲက GPS ဖမ်းစက်တွေနဲ့ atomic clock (အလွန် တိကျတဲ့ အဏုမြူ နာရီ) တွေကို သုံးပြီး အချိန် မသေချာမှုကို သေးသေးလေး (ယေဘုယျအားဖြင့် 10 millisecond အောက်) ဖြစ်အောင် ထိန်းထားပါတယ်၊ ပြီးတော့ အဲဒီလောက် အချိန် ကုန်သွားတဲ့အထိ စောင့်ပြီးမှ write တစ်ခုကို မြင်ရအောင် လုပ်ပါတယ်။

Distributed database တွေက သီးခြား ကျွမ်းကျင်မှု နယ်ပယ် တစ်ခု ဖြစ်နေတာနဲ့ အဖွဲ့ အများအပြားက စက် တစ်လုံးတည်းနဲ့ စပြီး လိုအပ်လာမှ ဒေတာကို ဖြန့်ခွဲတာက ဒီ ပြဿနာ နှစ်ခုကြောင့်ပါ။

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

ဥပမာ 1: Sharding Strategy (ဒေတာ ခွဲသိမ်းပုံ နည်းဗျူဟာ) ဒီဇိုင်းဆွဲခြင်း

ကမ္ဘာအနှံ့ သုံးတဲ့ ride-sharing app (ကား ခေါ်စီးတဲ့ app) တစ်ခုမှာ နိုင်ငံ 100 မှာ အကြမ်းဖျင်း ညီညီမျှမျှ ပြန့်နေတဲ့ သုံးစွဲသူ သန်း 50 ရှိပါတယ်။ User table ကို ဘယ်မှာ သိမ်းသင့်သလဲ။

ရွေးချယ်စရာ A: စက် တစ်လုံးတည်း။ ဒါက ရိုးရှင်းပေမယ့် server နဲ့ ဝေးတဲ့ သုံးစွဲသူတိုင်းက request တိုင်းအတွက် ပိုကြာကြာ စောင့်ရပါတယ် (Tokyo က သုံးစွဲသူတွေက Frankfurt ကို အသွားအပြန် တစ်ခေါက်စီအတွက် 200 ms လောက် စောင့်ရပါတယ်)၊ ပြီးတော့ အဲဒီ server တစ်လုံးတည်း ပျက်သွားရင် app က နေရာတိုင်းမှာ ရပ်သွားပါတယ်။

ရွေးချယ်စရာ B: UserID ပေါ်မှာ hash-partition လုပ်ပြီး node 50 ပေါ် ခွဲခြင်း။ ဒါက ဝန်ကို ညီညီမျှမျှ ဖြန့်ပေးပြီး သုံးစွဲသူ တစ်ယောက်စီရဲ့ row က partition တစ်ခုတည်းမှာပဲ ရှိပါတယ်။ ဒါပေမယ့် ခရီးသည် တစ်ယောက်ကို မြို့တူက ယာဉ်မောင်းတွေနဲ့ တွဲပေးဖို့ partition အများ လိုနိုင်ပြီး သုံးစွဲသူ အများစုရဲ့ ဒေတာက သူတို့နဲ့ ဝေးတဲ့ နေရာမှာ သိမ်းထားပါတယ်။

ရွေးချယ်စရာ C: သုံးစွဲသူရဲ့ မူလ ဒေသအလိုက် geographic partitioning၊ ဒေသ 8 ခု။ ဒေသ တစ်ခုစီမှာ ကိုယ်ပိုင် node အုပ်စု ရှိပြီး ဒေသရဲ့ ဒေတာ copy တွေကို ဒေသထဲမှာပဲ ထားပါတယ်။ အာရှက သုံးစွဲသူတွေကို အာရှက node တွေကနေ ဝန်ဆောင်မှု ပေးလို့ latency လျော့ပါတယ်၊ partition တွေကလည်း ခရီးစဉ်တွေကို တွဲပေးပုံနဲ့ ကိုက်ပါတယ် (ခရီးသည်နဲ့ ယာဉ်မောင်းတွေက များသောအားဖြင့် မြို့တူမှာ ရှိလို့ သူတို့ရဲ့ row တွေက ဒေသတူမှာ ရှိပါတယ်)။ ဒေသ အများကို ခြုံတဲ့ query တွေ ပိုနှေးတယ်၊ ဒေသ ကြီးတွေမှာ ဒေသ သေးတွေထက် node ပိုလိုတယ်၊ ခရီးသွားနေတဲ့ သုံးစွဲသူတွေကို သူတို့ မူလ ဒေသကနေပဲ ဝန်ဆောင်မှု ပေးပါတယ်။

ဒီ app ရဲ့ workload (အများဆုံး run တဲ့ query တွေ) အတွက် ရွေးချယ်စရာ C က အကိုက်ညီဆုံးပါ။ ဒီဇိုင်း ဆုံးဖြတ်ချက် (ဒေသအလိုက် partition လုပ်တာ) က အဲဒီ workload ကနေ လာတာ ဖြစ်ပြီး partition key ကို နောက်မှ ပြောင်းရင် ဒေတာ အများစုကို ရွှေ့ရပါလိမ့်မယ်။

ဥပမာ 2: Availability အတွက် Consistency ကို အလျှော့ပေးခြင်း

ကမ္ဘာအနှံ့ သုံးတဲ့ messaging app (စာတို ပို့တဲ့ app) တစ်ခုက သူ့ရဲ့ US နဲ့ EU data centre တွေကြားမှာ network partition (ချိတ်ဆက်မှု ပြတ်တောက်ခြင်း) ဖြစ်နေတုန်း ဘာဖြစ်မလဲ ဆုံးဖြတ်ရပါမယ်။ ရွေးချယ်စရာ နှစ်ခု ရှိပါတယ်:

Strong consistency (CP)။ EU ဘက်က US မှာ ရှိတဲ့ ဒေတာရဲ့ အဓိက copy ကို ဆက်သွယ်မရလို့ link ပြန်ရတဲ့အထိ message အသစ်တွေကို ငြင်းပါတယ်၊ နောက်ဆုံး စာ မှတ်တမ်း လိုတဲ့ request တွေကိုလည်း ငြင်းပါတယ်။ US ဘက်ကတော့ ဆက်အလုပ်လုပ်ပါတယ်။ EU သုံးစွဲသူတွေက “service unavailable” (ဝန်ဆောင်မှု မရနိုင်ပါ) ကို မြင်ရပါတယ်၊ link ပြန်ရတဲ့အခါ EU copy က လွတ်သွားတဲ့ message တွေကို လိုက်မီအောင် ယူပါတယ်။

Eventual consistency (AP)။ ဒေသ နှစ်ခုလုံးက message တွေကို ကိုယ့်ဒေသမှာပဲ လက်ခံပါတယ်။ Link ပြန်မရခင်အထိ ဒေသ နှစ်ခုက သုံးစွဲသူတွေက စကားဝိုင်း တစ်ခုကို မတူတဲ့ ပုံစံနဲ့ မြင်ရပါတယ်။ Message တွေကို ထပ်ထည့်တာပဲ ရှိလို့ နောက်မှ အစု နှစ်ခုကို ပေါင်းတဲ့အခါ message တိုင်း ကျန်ပါတယ်။

Messaging app အတွက်ဆိုရင် availability က consistency ထက် ပိုအရေးကြီးပါတယ်: သုံးစွဲသူတွေက message နည်းနည်း နောက်ကျ ရောက်တာကို လက်ခံပေမယ့် ဝန်ဆောင်မှုက သူတို့ message တွေကို ငြင်းရင် တခြား app ကို ပြောင်းသွားနိုင်ပါတယ်။ အဓိပ္ပာယ်ရှိတဲ့ ဒီဇိုင်းက eventual consistency နဲ့ AP ပါ။

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

ဥပမာ 3: Fault Tolerance အတွက် Replication

Harbour Run အားကစား ကလပ် ကွင်းဆက် လုပ်ငန်းက နေရာ တစ်ခုကနေ နိုင်ငံ အများမှာ နေရာ 200 အထိ ကြီးထွားလာပါတယ်။ အဖွဲ့ဝင်တွေ သုံးတဲ့ booking app က server တစ်လုံး ပျက်သွားရင်လည်း ဆက်အလုပ်လုပ်နေရပါမယ်။ အဖွဲ့က replication factor ကို 3 (booking တိုင်းအတွက် copy သုံးခု) လို့ သတ်မှတ်ပါတယ်:

flowchart LR
    P[("<b>Primary</b><br/>Bookings<br/>Dublin")] -->|replicate| R1[("<b>Replica 1</b><br/>Bookings<br/>Frankfurt")]
    P -->|replicate| R2[("<b>Replica 2</b><br/>Bookings<br/>Singapore")]
    classDef primary fill:#3DAA8A22,stroke:#3DAA8A,stroke-width:2px,color:#1f5d4a
    classDef replica fill:#61B0DD20,stroke:#61B0DD,color:#1a4f6e
    class P primary
    class R1,R2 replica

ပုံထဲမှာ Primary (အဓိက copy) က Dublin မှာ ရှိပြီး replicate (ကူးပေးခြင်း) မြှားတွေက booking တွေကို Frankfurt က Replica 1 နဲ့ Singapore က Replica 2 ဆီ ကူးပေးတာကို ပြပါတယ်။

Node သုံးခုထဲက အနည်းဆုံး နှစ်ခု (အများစု) က booking တစ်ခုကို သိမ်းပြီးတာနဲ့ အဲဒီ booking ကို အတည်ပြုပါတယ်။ Dublin က primary ပျက်သွားရင် Frankfurt က အလိုအလျောက် တာဝန် ယူပြီး အဖွဲ့ဝင်တွေက များသောအားဖြင့် ခဏ ရပ်သွားတာကို သတိထားမိပါတယ်။ အဲဒီ ရပ်ချိန် ဘယ်လောက် ကြာလဲ ဆိုတာ ပျက်တာကို ဘယ်လောက် မြန်မြန် သိလဲ၊ primary အသစ်ကို ဘယ်လောက် မြန်မြန် ရွေးလဲ ဆိုတာပေါ် မူတည်ပါတယ်။ Node သုံးခုထဲက နှစ်ခု တစ်ပြိုင်နက် ပျက်သွားရင် (တိုက် နှစ်တိုက်က မြို့ သုံးမြို့မှာ ရှိတဲ့ node တွေအတွက် ဖြစ်ခဲပါတယ်) ကျန်တဲ့ node က node အများစုကို ဆက်သွယ်လို့ မရလို့ node အနည်းဆုံး နှစ်ခုကို ပြန်ဆက်သွယ်နိုင်တဲ့အထိ booking အသစ်တွေ လက်ခံတာကို ရပ်ပါတယ်။ အဲဒီ အတောအတွင်း read တွေကို ဆက်ဖြေနေအောင် ကလပ် လုပ်ငန်းက သတ်မှတ်ထားပါတယ် (read-only mode: အဖွဲ့ဝင်တွေက ကိုယ့် booking တွေကို ကြည့်လို့ရပေမယ့် အသစ် လုပ်တာ၊ ပြင်တာ မလုပ်နိုင်ပါဘူး)၊ ဒါပေမယ့် အဲဒီ node မှာ နောက်ဆုံး booking တွေ မရောက်သေးတာ ဖြစ်နိုင်ပါတယ်။

Copy တွေက ဒေတာကို အတိုင်းအတာ မတူအောင် ကာကွယ်ပါတယ်။ အတည်ပြုပြီးသား booking တိုင်းက အနည်းဆုံး node နှစ်ခုပေါ်မှာ ရှိလို့ ဘယ် node တစ်ခုကို အပြီးအပိုင် ဆုံးရှုံးသွားလည်း အတည်ပြုပြီးသား booking တစ်ခုမှ မပျောက်ပါဘူး။ Node နှစ်ခုကို အပြီးအပိုင် ဆုံးရှုံးသွားရင် တတိယ node မှာ သူ လက်ခံရရှိထားတဲ့ ဒေတာ ကျန်နေသေးပေမယ့် အဲဒီ node နှစ်ခုဆီပဲ ရောက်ခဲ့တဲ့ booking အသစ်ကတော့ ပျောက်သွားပါတယ်။ Replication က အမှားတွေကိုလည်း မကာကွယ်ပေးပါဘူး: မှားပြီး ဖျက်လိုက်တဲ့ booking က copy တိုင်းမှာ ပျက်သွားလို့ ကလပ် လုပ်ငန်းက backup တွေကို ဆက်ထားပါတယ်။

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

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

Q2. Fault tolerance အတွက် ဒေတာ တူတူရဲ့ copy အများကို မတူတဲ့ node တွေပေါ်မှာ သိမ်းတဲ့ distributed database feature က ဘယ်ဟာလဲ။

Q3. Distributed database တစ်ခုက row ဘီလီယံ 100 ပါတဲ့ သူ့ UserActivity table ကို စက် 50 ပေါ် ခွဲလိုက်လို့ စက် တစ်လုံးစီမှာ row ဘီလီယံ 2 လောက် ရှိပါတယ်။ ဒါကို ဖော်ပြတဲ့ feature က ဘယ်ဟာလဲ။

Q4. ညတစ်ညအတွင်း database အဖွဲ့ တစ်ဖွဲ့က ကလပ် တစ်ခုရဲ့ Member row တွေကို server အဟောင်း တစ်လုံးကနေ server အသစ် နှစ်လုံးဆီ ရွှေ့လိုက်ပါတယ်။ နောက်တစ်နေ့ မနက်မှာ ကလပ်ရဲ့ booking app က code ဒါမှမဟုတ် setting ဘာမှ မပြောင်းဘဲ အရင်က query တွေအတိုင်း ပို့ပြီး ရလဒ် တူတူ ရပါတယ်။ ဒါကို ဖြစ်နိုင်စေတဲ့ feature က ဘယ်ဟာလဲ။

Q5. Traffic ဆယ်ဆ တိုးလာတဲ့အခါ စက် တစ်လုံးတည်းသုံး database နဲ့ နှိုင်းယှဉ်ရင် distributed database ရဲ့ အဓိက အားသာချက်က:

Q6. Write တွေ ရပ်သွားတာနဲ့ replica အားလုံးမှာ တန်ဖိုး တူတူ ဖြစ်လာမယ်လို့ ကတိပေးပေမယ့် read တိုင်းက နောက်ဆုံး write ကို ပြန်ပေးမယ်လို့ ကတိ မပေးတဲ့ consistency model က ဘယ်ဟာလဲ။

Feature ကို ကိုက်အောင် တွဲပါ

အခြေအနေ တစ်ခုစီက အတိုက်ရိုက်ဆုံး ပြနေတဲ့ feature ကို ရိုက်ထည့်ပါ။ အကွက် တစ်ခုစီမှာ အောက်က နာမည် ဆယ်ခုထဲက တစ်ခုကို ပြထားတဲ့ စာလုံးပေါင်းအတိုင်း English လို အတိအကျ ရိုက်ထည့်ပါ: concurrency control၊ data consistency၊ partitioning၊ security၊ distribution transparency၊ location transparency၊ fault tolerance၊ replication၊ scalability၊ global query processing။

အခြေအနေFeature
03:17 မှာ node တစ်ခု တုံ့ပြန်တာ ရပ်သွားပါတယ်။ စက္ကန့် အနည်းငယ်အတွင်း နောက် node တစ်ခုက သူ့အလုပ်ကို တာဝန် ယူလိုက်ပြီး booking ဝဘ်ဆိုက်က booking တွေကို ဆက်လက်ခံနေပါတယ်။
Brazil က ဖောက်သည်တွေကို São Paulo က node တွေပေါ်မှာ၊ Japan က ဖောက်သည်တွေကို Tokyo က node တွေပေါ်မှာ သိမ်းထားပါတယ်၊ node တစ်ခုစီမှာ ကိုယ့်နိုင်ငံက ဖောက်သည်တွေပဲ ရှိပါတယ်။
မန်နေဂျာ တစ်ယောက်က ဒီနှစ်ရဲ့ စုစုပေါင်း အရောင်းကို တောင်းပါတယ်။ Node 12 ခုလုံးက ကိုယ့်ဆီမှာ ရှိတဲ့ အရောင်းတွေကို ပေါင်းပြီး node တစ်ခုက စုစုပေါင်း 12 ခုကို အဖြေ တစ်ခုတည်းအဖြစ် ပေါင်းပါတယ်။
မှာယူမှု တိုင်းကို မတူတဲ့ node သုံးခုမှာ ရေးထားလို့ မှာယူမှု တစ်ခုစီရဲ့ copy သုံးခု ရှိပါတယ်။
ကြော်ငြာ campaign တစ်ခု ပြီးနောက် traffic သုံးဆ တိုးလာပါတယ်၊ operations အဖွဲ့က node အသစ် 20 ထပ်ထည့်ပြီး cluster က ဒေတာ တချို့ကို အဲဒီ node တွေပေါ် အလိုအလျောက် ရွှေ့ပါတယ်။
Node တွေကြား traffic အားလုံးကို TLS နဲ့ encrypt လုပ်ထားပြီး node တစ်ခုစီက ကိုယ်ပိုင် certificate (digital certificate: public key ကို ပိုင်ရှင်နဲ့ ချိတ်ပေးတဲ့ အီလက်ထရွန်နစ် စာရွက်) နဲ့ ကိုယ် ဘယ်သူလဲ ဆိုတာကို တခြား node တွေကို သက်သေပြပါတယ်။

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

Distributed database feature တွေနဲ့ transaction တွေအကြောင်း ဖော်ပြချက်ကို ပြည့်စုံအောင် ဖြည့်ပါ။ စာကြောင်းတွေက English လို ဖြစ်လို့ ကွက်လပ်တွေကို English စကားလုံးနဲ့ ရိုက်ထည့်ပါ:

DISTRIBUTED DATABASES
=====================
 splits the dataset across nodes so each one
holds only a portion. Sometimes called sharding.

 stores multiple copies of the same data on
different nodes, for fault tolerance and faster reads.

 hides the distribution from applications:
they see one logical database.

 keeps the cluster operating through node
failures, using automatic failover and replication.

 is the ability to handle more data and more
users; a distributed database usually gains it by adding nodes.

 makes a transaction that changes data on
several nodes all or nothing: every node votes, then every
node commits or every node rolls back.

စာကြောင်းတွေရဲ့ အဓိပ္ပာယ် (____ က ကွက်လပ်ပါ):
____ က dataset ကို node တွေပေါ် ခွဲပေးလို့ node တစ်ခုစီမှာ အစိတ်အပိုင်း တစ်ခုပဲ ရှိပါတယ်။ တစ်ခါတလေ sharding လို့လည်း ခေါ်ပါတယ်။
____ က ဒေတာ တူတူရဲ့ copy အများကို မတူတဲ့ node တွေပေါ်မှာ သိမ်းပါတယ်၊ fault tolerance အတွက်နဲ့ read တွေ ပိုမြန်အောင်ပါ။
____ က ဒေတာ ဖြန့်ခွဲထားတာကို application တွေဆီကနေ ဖုံးကွယ်ပေးပါတယ်: application တွေက logical database တစ်ခုတည်းကို မြင်ရပါတယ်။
____ က automatic failover နဲ့ replication ကို သုံးပြီး node တွေ ပျက်နေတုန်းမှာလည်း cluster ကို ဆက်အလုပ်လုပ်နေအောင် ထားပေးပါတယ်။
____ ဆိုတာ ဒေတာ ပိုများများနဲ့ သုံးစွဲသူ ပိုများများကို ကိုင်တွယ်နိုင်စွမ်းပါ၊ distributed database က များသောအားဖြင့် node တွေ ထပ်ထည့်ပြီး ဒါကို ရပါတယ်။
____ က node အများပေါ်က ဒေတာကို ပြောင်းတဲ့ transaction ကို အကုန်ဖြစ် ဒါမှမဟုတ် ဘာမှမဖြစ် ဖြစ်အောင် လုပ်ပေးပါတယ်: node တိုင်း မဲပေးပြီးနောက် node တိုင်းက commit လုပ်တယ်၊ ဒါမှမဟုတ် node တိုင်းက roll back လုပ်ပါတယ်။

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

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

1A distributed database stores its data on many machines and appears as one database 2Replication splits different data across many machines so each holds only a portion 3Distribution transparency hides the distribution from applications 4Fault tolerance keeps the database working when a node fails, through automatic failover 5Horizontal scaling adds capacity by adding more nodes rather than bigger ones

Line တွေရဲ့ အဓိပ္ပာယ်: (1) distributed database က ဒေတာကို စက် အများပေါ်မှာ သိမ်းပြီး database တစ်ခုတည်းလို ပေါ်တယ်၊ (2) replication က မတူတဲ့ ဒေတာကို စက် အများပေါ် ခွဲပေးလို့ စက် တစ်လုံးစီမှာ အစိတ်အပိုင်း တစ်ခုပဲ ရှိတယ်၊ (3) distribution transparency က ဒေတာ ဖြန့်ခွဲထားတာကို application တွေဆီကနေ ဖုံးကွယ်ပေးတယ်၊ (4) fault tolerance က automatic failover နဲ့ node တစ်ခု ပျက်သွားတဲ့အခါ database ကို ဆက်အလုပ်လုပ်နေအောင် ထားပေးတယ်၊ (5) horizontal scaling က ပိုကြီးတဲ့ node တွေ မဟုတ်ဘဲ node အသစ်တွေ ထပ်ထည့်ပြီး capacity တိုးတယ်။

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

Feature ကို ဖော်ထုတ်ပါ

"ပါဆယ် ပို့ဆောင်ရေး ကုမ္ပဏီ တစ်ခုမှာ ပို့ဆောင်မှုတွေကို စီစဉ်ပေးတဲ့ ဝန်ထမ်း နှစ်ယောက်က မတူတဲ့ ရုံးတွေမှာ အလုပ်လုပ်ပြီး မတူတဲ့ node တွေနဲ့ ချိတ်ထားပါတယ်။ သူတို့က တစ်ချိန်တည်းမှာ ပို့ဆောင်မှု တစ်ခုတည်းကို ပြင်ကြပါတယ်။ Transaction တစ်ခုစီက အဲဒီ ပို့ဆောင်မှုရဲ့ row ကို မဖတ်ခင်၊ မပြင်ခင် lock လုပ်လို့ ဒုတိယ transaction က ပထမ transaction commit လုပ်ပြီးတဲ့အထိ စောင့်ပြီးမှ update ဖြစ်ပြီးသား row ကို ဖတ်ကာ အဲဒီ row ပေါ်မှာ ကိုယ့် ပြောင်းလဲမှုကို လုပ်ပါတယ်။ ပြောင်းလဲမှု နှစ်ခုလုံး မပျောက်ပါဘူး။"

ဘယ် feature ကို ဖော်ပြနေတာလဲ။ (Feature နာမည်ကို English လို ရိုက်ထည့်ပါ။)

"Online ဆိုင် တစ်ဆိုင်က ကုန်ပစ္စည်း တစ်ခုစီရဲ့ လက်ကျန် အရေအတွက် copy တွေကို မြို့ သုံးမြို့က server တွေပေါ်မှာ သိမ်းထားပြီး ဘယ်မြို့က ဈေးဝယ်သူမဆို လက်ရှိ လက်ကျန်ကို မြင်ရစေချင်ပါတယ်။ ဒါကြောင့် copy သုံးခုထဲက နှစ်ခုက မှတ်တမ်းတင်ပြီးမှသာ အရောင်း တစ်ခုကို အတည်ပြုပြီး ဝဘ်ဆိုက်က copy နှစ်ခုကို ဖတ်ကာ ပိုအသစ် ဖြစ်တဲ့ အရေအတွက်ကို ပြပါတယ်။"

ဘယ် feature ကို ဖော်ပြနေတာလဲ။ (Feature နာမည်ကို English လို ရိုက်ထည့်ပါ။)

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

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

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

  1. [Core] Distributed DBs (HL) [3 marks] Distributed database ကို Define (အဓိပ္ပာယ်ကို တိတိကျကျ ဖော်ပြပါ) လုပ်ပြီး အဖွဲ့အစည်း တစ်ခုက distributed database ကို ဘာကြောင့် သုံးဖို့ ရွေးနိုင်လဲ ဆိုတဲ့ အကြောင်းရင်း တစ်ခုကို outline (အကျဉ်းချုပ် ဖော်ပြပါ) လုပ်ပါ။

  2. [Core] Distributed DBs (HL) [4 marks] ဒီစာမျက်နှာမှာ ပါတဲ့ feature ဆယ်ခုထဲက distributed database feature လေးခုကို State (ဖော်ပြပါ) လုပ်ပြီး တစ်ခုစီအတွက် စာကြောင်း တစ်ကြောင်းစီနဲ့ ဖော်ပြချက် ရေးပါ။

  3. [Core] Distributed DBs (HL) [3 marks] Distributed database မှာ partitioning နဲ့ replication ကြားက ကွာခြားချက်ကို Distinguish (အရာ နှစ်ခု ဒါမှမဟုတ် ပိုများတဲ့ အရာတွေကြားက ကွာခြားချက်ကို ရှင်းရှင်းလင်းလင်း ပြပါ) လုပ်ပါ။

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

  1. [Extension] Distributed DBs (HL) [4 marks] Car-share app (ကားကို မျှပြီး ငှားသုံးတဲ့ app) တစ်ခုက booking တိုင်းကို node ငါးခုပေါ်မှာ သိမ်းပါတယ်၊ data centre တစ်ခုမှာ နှစ်ခု၊ နောက် data centre တစ်ခုမှာ သုံးခုပါ။ Copy ငါးခုထဲက သုံးခုမှာ booking ရောက်ပြီးတာနဲ့ အတည်ပြုပါတယ်။ (a) node တစ်ခု ပျက်သွားတဲ့အခါနဲ့ (b) data centre နှစ်ခုကြားက network link ပြတ်သွားတဲ့အခါ app က ဘယ်လို ဆက်အလုပ်လုပ်လဲ၊ ယာဉ်မောင်းတွေက ဘာကို သတိထားမိလဲ ဆိုတာကို Describe (ဖော်ပြရှင်းပြပါ) လုပ်ပါ။

  2. [Extension] Distributed DBs (HL) [4 marks] Distributed database မှာ distribution transparency ဆိုတာ ဘာကို ဆိုလိုလဲ Explain (ရှင်းပြပါ) လုပ်ပါ။ မတူတဲ့ transparency အမျိုးအစား အနည်းဆုံး သုံးခုကို နာမည် ဖော်ပြပြီး တစ်ခုစီက application ဆီကနေ ဘာကို ဖုံးကွယ်ထားလဲ ဖော်ပြပါ။

  3. [Extension] Distributed DBs (HL) [5 marks] ကမ္ဘာအနှံ့ ဖြန့်ခွဲထားတဲ့ database တစ်ခုမှာ strong consistency နဲ့ high availability (availability မြင့်မားမှု) ကြားက trade-off ကို Discuss (အမြင် အမျိုးမျိုးကို ချိန်ဆပြီး ဆွေးနွေးပါ) လုပ်ပါ။ ဒီစာမျက်နှာမှာ ပါတဲ့ အခြေအနေတွေ မဟုတ်တဲ့ consistency က ပိုအရေးကြီးတဲ့ အခြေအနေ တစ်ခုနဲ့ availability က ပိုအရေးကြီးတဲ့ အခြေအနေ တစ်ခုကို ကိုးကားပါ။

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

  1. [Challenge] Distributed DBs (HL) [6 marks] Smart meter (လျှပ်စစ် သုံးစွဲမှုကို အလိုအလျောက် တိုင်းပြီး ဒေတာ ပို့ပေးတဲ့ မီတာ) ကုမ္ပဏီ တစ်ခုက နိုင်ငံငယ် တစ်နိုင်ငံထဲက အိမ် 8 သန်း တစ်အိမ်စီကနေ မိနစ် 15 တိုင်း လျှပ်စစ် ဖတ်ချက် တစ်ခုစီ မှတ်တမ်းတင်ပြီး ဖတ်ချက်တွေကို ငါးနှစ်စာ သိမ်းထားပါတယ်။ ကုမ္ပဏီရဲ့ data centre နှစ်ခုလုံးက အဲဒီ နိုင်ငံထဲမှာပဲ ရှိပါတယ်။ အများဆုံး run ရတဲ့ query က အိမ်ထောင်စု တစ်ခုစီရဲ့ app ကနေ လာပြီး အဲဒီ app က အဲဒီ အိမ်ရဲ့ ပြီးခဲ့တဲ့ တစ်လအတွင်း လျှပ်စစ် သုံးစွဲမှု graph ကို ပြပါတယ်။ တစ်ရက်ကို တစ်ကြိမ် analyst (ဒေတာ ခွဲခြမ်းစိတ်ဖြာသူ) တွေက ဒေသ တစ်ခုစီရဲ့ စုစုပေါင်း သုံးစွဲမှုကို ထုတ်ပြီး ဒီ report က မိနစ် အနည်းငယ် ကြာနိုင်ပါတယ်။ Reading table အတွက် သင့်တော်တဲ့ partitioning strategy (ခွဲသိမ်းပုံ နည်းဗျူဟာ) တစ်ခုကို Suggest (ဖြစ်နိုင်တဲ့ ဖြေရှင်းနည်း တစ်ခုကို အကြံပြုပါ) လုပ်ပြီး ကိုယ့် ရွေးချယ်မှုကို justify (ဘာကြောင့် ရွေးတာလဲ အကြောင်းပြချက်နဲ့ ပြပါ) လုပ်ပါ။ Load distribution (ဝန် ဖြန့်ခွဲမှု)၊ query pattern (query တွေ အသုံးပြုပုံ) နဲ့ latency ကို ကိုးကားပါ။

  2. [Challenge] Distributed DBs (HL) [8 marks] လူနာ သန်း 60 ပါဝင်တဲ့ နိုင်ငံအဆင့် ကျန်းမာရေး မှတ်တမ်း စနစ် တစ်ခုအတွက် distributed database သင့်တော်မှုကို Evaluate (အားသာချက်နဲ့ အားနည်းချက်တွေကို ချိန်ဆပြီး အကဲဖြတ်ပါ) လုပ်ပါ။ Feature ဆယ်ခု (concurrency control, data consistency, partitioning, security, distribution transparency, location transparency, fault tolerance, replication, scalability, global query processing) ထဲက အနည်းဆုံး ငါးခုကို ကိုးကားပြီး အကျိုးကျေးဇူးတွေကို operational complexity (node အများကြီး run ရတဲ့ အပို အလုပ်နဲ့ ကုန်ကျစရိတ်) နဲ့ ချိန်ဆပါ။

IB CS သင်တန်း တက်နေသူတွေအတွက် မှတ်ချက်: A3.4.4 က feature ဆယ်ခုကို ဖော်ပြထားပါတယ်: concurrency control, data consistency, data partitioning, data security, distribution transparency, fault tolerance, global query processing, location transparency, replication နဲ့ scalability။ Data consistency ကို ဘာကြောင့် ထိန်းထားရလဲ ဆိုတာနဲ့ node အများကြား run တဲ့ transaction တွေမှာ ACID ရဲ့ အခန်းကဏ္ဍကိုလည်း မေးပါတယ်။ Feature တစ်ခုစီကို ဥပမာ တစ်ခုနဲ့ ဖော်ပြရှင်းပြပါ။ CAP theorem က အသုံးဝင်တဲ့ နောက်ခံ အကြောင်းအရာ ဖြစ်ပေမယ့် syllabus ထဲမှာ မပါပါဘူး။

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

  • အရင် ခေါင်းစဉ်: Data Warehouses (ခွဲခြမ်းစိတ်ဖြာဖို့ ယခင် ဒေတာ သိုလှောင်ရုံများ)။ အလွန် ကြီးမားတဲ့ data warehouse တွေကိုယ်တိုင်က distributed ဖြစ်ပါတယ်။
  • ဆက်စပ် ခေါင်းစဉ်: Alternative Databases (အခြား database အမျိုးအစားများ)။ NoSQL database တွေနဲ့ cloud database တွေက များသောအားဖြင့် အစကတည်းက distributed ဖြစ်ပြီး ဒီစာမျက်နှာက feature တွေက သူတို့ အများစုမှာ သက်ဆိုင်ပါတယ်။
  • ဆက်စပ် ခေါင်းစဉ်: Transactions and Views (transaction နဲ့ view များ)။ Node အများကြားမှာ ACID ရဖို့ two-phase commit လို အပို အလုပ်တွေ လိုပါတယ်၊ distributed system တချို့က ACID အစား BASE model ကို သုံးပါတယ်။
  • Communication Layer (ဆက်သွယ်ရေး အလွှာ): Network Architecture (network ဖွဲ့စည်းပုံ)။ Network တွေက ပြတ်တောက်နိုင်၊ နှေးသွားနိုင်ပြီး အဲဒီလို ဖြစ်တဲ့အခါ distributed database တွေ ဆက်အလုပ်လုပ်နေရပါမယ်။
  • Communication Layer: Network Security (network လုံခြုံရေး)။ Distributed database ရဲ့ လုံခြုံရေး နည်းလမ်းတွေက TLS၊ encryption in transit နဲ့ access control (သုံးခွင့် ထိန်းချုပ်မှု) ပေါ်မှာ အခြေခံပါတယ်။
  • Hardware Layer (hardware အလွှာ): Cloud Computing (အင်တာနက်ကနေ ငှားသုံးတဲ့ ကွန်ပျူတာ resource)။ Distributed database အများအပြားက cloud ဝန်ဆောင်မှုတွေပေါ်မှာ run ပါတယ်။

© 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 နဲ့ တည်ဆောက်ထားပါတယ်။