ChatGPT သုံးသူ ၁ ဘီလီယံကျော်အတွက် ဒေတာသိုလှောင်မှု ချဲ့ထွင်ခြင်း (အပိုင်း ၂)

OpenAI ထုတ်ကုန်အားလုံးသည် ဒေတာကို မြန်ဆန်၊ စိတ်ချစွာ ရယူနိုင်ရန် လိုအပ်ပြီး ကျွန်ုပ်တို့၏ သိုလှောင်ရေးပလက်ဖောင်း Habitat က ထိုလိုအပ်ချက်ကို ဖြည့်ဆည်းပေးသည်။ ၎င်းသည် ပထဝီဒေသ ၄၀ မှ သုံးစွဲသူ ၁ ဘီလီယံကျော်ကို မီလီစက္ကန့်အတွင်း တုံ့ပြန်ပေးရသည်။ ကျွန်ုပ်တို့၏ အခြေခံစနစ်သည် အလွန်လျင်မြန်သော တိုးတက်မှုနှင့် အသုံးပြုမှုပုံစံသစ်များကို ပံ့ပိုးရင်း ယုံကြည်စိတ်ချရမှု၊ စွမ်းဆောင်ရည်နှင့် ထုတ်ကုန်ရေးသားသူများ၏ အလုပ်မြန်ဆန်မှုကို ဆက်မြှင့်တင်ရသည့် ထူးခြားသော စိန်ခေါ်မှုကို ရင်ဆိုင်ခဲ့ရသည်။ ထိုစိန်ခေါ်မှုကို ဖြေရှင်းရန် အွန်လိုင်းသိုလှောင်ရေးပလက်ဖောင်း၏ ဒီဇိုင်းနှင့် လည်ပတ်ပုံကို ပြန်စဉ်းစားခဲ့ရသည်။ ကျွန်ုပ်တို့သည် အပေးအယူများကို အမြဲချိန်ဆခဲ့သည်။ ဦးစွာ မရှိမဖြစ်အရေးကြီးသော ထုတ်ကုန်တောင်းဆိုမှုများအတွက် စိတ်ချရလောက်အောင်၊ ထို့နောက် ကမ္ဘာတစ်ဝန်း သုံးစွဲသူများအတွက် မြန်လောက်အောင်၊ နောက်ဆုံးတွင် ဧရာမအတိုင်းအတာ၌ ကျွမ်းကျင်စွာ လည်ပတ်နိုင်အောင် လုပ်ဆောင်ခဲ့သည်။

ဤနှစ်ပိုင်းဆောင်းပါးတွင် Habitat ကို ရိုးရှင်းသော client library နှင့် ဒေတာဘေ့စ်မှ ဒေတာ petabyte ၅၀၀ ကျော် ပံ့ပိုးပေးသည့် ကမ္ဘာတစ်ဝန်း ဖြန့်ကျက်ထားသော သိုလှောင်ရေးပလက်ဖောင်းသို့ မည်သို့ တည်ဆောက်ခဲ့ကြောင်း ရှင်းပြထားသည်။ အပိုင်း ၁ တွင် Habitat က Python client မှ ဝန်ဆောင်မှုတစ်ခုအဖြစ် ပြောင်းလဲလာပုံကို အဓိကဖော်ပြခဲ့သည်။ Python အခြေပြု ဝန်ဆောင်မှုကို လူအများက လက်တွေ့ဖြစ်နိုင်မည်ဟု ယူဆသည့်အတိုင်းအတာထက် များစွာကျော်လွန်အောင် လုပ်နိုင်စေသည့် နည်းစနစ်များကိုလည်း ဖော်ပြခဲ့သည်။

ယခု အပိုင်း ၂ တွင် အောက်ခံသိုလှောင်ရေးအစိတ်အပိုင်း Azure Cosmos DB ကို မည်သို့ ချဲ့ထွင်ခဲ့ကြောင်း ရှင်းပြပါမည်။ Azure အဖွဲ့နှင့် နီးကပ်စွာ ပူးပေါင်းရာမှ ပူးတွဲစီမံသည့် container များကို အတူမျှဝေသုံးသော လက်တွေ့ကျသည့် နည်းလမ်းကို ရရှိခဲ့ပြီး ကမ္ဘာတစ်ဝန်း ဧရာမအတိုင်းအတာ၌ ဖတ်ယူမှုစွမ်းဆောင်ရည် အထူးကောင်းမွန်ခဲ့သည်။

ကုမ္ပဏီများ ကြီးလာသည့်အခါ အခြေခံစနစ်အဖွဲ့များသည် သီးသန့်သုံးစနစ်များမှ အတူသုံးစနစ်များသို့ ပြောင်းလဲလေ့ရှိသည်။ ထုတ်ကုန်အစိတ်အပိုင်းအဖွဲ့တိုင်းက ကိုယ်ပိုင်စနစ်ကို ထိန်းသိမ်းသည့် သီးသန့်သုံးပုံစံသည် ထိခိုက်မှုအတိုင်းအတာကို လျှော့ချပေးပြီး တာဝန်ယူမှုနယ်နိမိတ်နှင့် အလုပ်များခွဲထားမှုကို ရိုးရှင်းစေသည်။ အဖွဲ့နှင့် ထုတ်ကုန်အစိတ်အပိုင်းများ များလာသည့်အခါ ဤပုံစံသည် ကုန်ကျစရိတ် ကြီးလာသည်။ သီးသန့်သုံးပုံစံတွင် ထုတ်ကုန်အဖွဲ့တိုင်းက အရင်းအမြစ်ပမာဏ စီမံရေးကို တာဝန်ယူရပြီး လိုသည်ထက် များစွာပိုခွဲဝေထားမိလေ့ရှိသည်။

အတူသုံးပုံစံတွင်မူ အရင်းအမြစ်ခွဲဝေရေး အသိပညာနှင့် အတွေ့အကြုံ ပိုရှိသော ဗဟိုဒေတာဘေ့စ်အဖွဲ့က ထိန်းချုပ်စီမံသည်။ သို့သော် အတူသုံးပုံစံ၌လည်း သုံးသူတစ်ဦးက အရင်းအမြစ်ကို ပုံမှန်ထက် များစွာယူသုံး၍ အခြားသုံးသူများ ထိခိုက်သည့် ဝန်ပိစေသော အတူသုံးသူပြဿနာမျိုး ဖြစ်လာသည်။

Habitat တွင် စိတ်ချရပြီး အရင်းအမြစ်အကျိုးရှိစွာသုံးသော အကြီးစားသိုလှောင်ရေးစနစ် ဒီဇိုင်းဆွဲရန် ဤအပေးအယူအားလုံးကို ချိန်ဆခဲ့ရသည်။ ယနေ့ Habitat သည် OpenAI ထုတ်ကုန်များစွာအတွက် အတူသုံး ဒေတာဘေ့စ်အလွှာ ဖြစ်သည်။ သို့သော် အစပိုင်း အတူသုံး Azure Cosmos DB container တစ်ခုမှ သီးသန့်သုံး အောက်ခံ container များ ခွဲဝေခြင်းသို့ ပြောင်းပြီး နောက်ဆုံးတွင် အတူသုံး container ကို မူလပုံစံအဖြစ် ပြန်သုံးသည့် စက်ဝိုင်းခရီးကို ဖြတ်သန်းခဲ့ရသည်။ Habitat ၏ အတူသုံးစနစ်ခရီးသည် အစောပိုင်း၌သာ ရှိသေးသည်။ အသုံးပြုမှုပုံစံ များစွာကို ပံ့ပိုးသော်လည်း ဖြစ်နိုင်သမျှ Azure Cosmos DB ၏ အသင့်ပါ အခြေခံစွမ်းရည်များကို သုံးခြင်းဖြင့် ဤကဏ္ဍတွင် ထပ်မံရင်းနှီးမြှုပ်နှံရမည့်အချိန်ကို ရွှေ့ဆိုင်းနိုင်ခဲ့သည်။

ကျွန်ုပ်တို့၏ Azure Cosmos DB ခရီးကို မရှင်းပြမီ အခြေခံသိထားရန် အချက်အချို့မှာ—

• Azure Cosmos DB အကောင့်တစ်ခုက container အစုနှင့် မိတ္တူပွားမူဝါဒကို သတ်မှတ်သည်

• Container တစ်ခုစီအတွက် ဆောင်ကြဉ်းပေးမှု ပမာဏကို တစ်စက္ကန့်လျှင် တောင်းဆိုမှုယူနစ် (RU/s) ဖြင့် သတ်မှတ်ခွဲဝေသည်

• Container အတွင်း ဒေတာကို သတ်မှတ်ထားသော logical partition key အလိုက် ပုံမှန် shard ခွဲနည်းဖြင့် သိမ်းဆည်းပြီး key တစ်ခုချင်းအတွက် သိုလှောင်မှုနှင့် ဆောင်ကြဉ်းပေးမှု ပမာဏ ကန့်သတ်ချက်များကို စာတမ်းတွင် ဖော်ပြထားသည်

• Azure Cosmos DB သည် logical partition key များကို အရေအတွက် ပိုနည်းသော အောက်ခံ physical partition များပေါ် ခွဲဝေသည်။ သိုလှောင်မှု သတ်မှတ်ပမာဏကျော်လျှင် သို့မဟုတ် ခွဲဝေထားသော ဆောင်ကြဉ်းပေးမှု ပမာဏ ထိန်းနိုင်ရန် container က physical partition ထပ်လိုလျှင် ၎င်းတို့ကို ထပ်ခွဲသည်

အစပိုင်းတွင် client ဝန်အားလုံးကို လက်ခံပြီး ဝန်ပြန်ထိန်းရန် logical partition key တစ်ခုလျှင် ဖော်ပြထားသည့် 10K RU/s ကန့်သတ်ချက်ကို အားကိုးခဲ့သည်။ စတင်စဉ်က အကောင့်တစ်ခုစီတွင် မူလ Azure Cosmos DB container တစ်ခုသာ သုံးခဲ့သည်။ ထိုနည်းက အတော်အသင့် အလုပ်ဖြစ်သော်လည်း အကြောင်းရင်းအချို့ကြောင့် ပြဿနာရှိလာသည်။

အစောပိုင်း API ရွေးချယ်မှုများကြောင့် client များကို logical partition key တိုက်ရိုက်ရွေးခွင့် ပေးထားခဲ့သည်။ ထို့ကြောင့် ထုတ်ကုန်အသုံးပြုမှုပုံစံအမျိုးမျိုးတွင် user_id သို့မဟုတ် workspace_id ကဲ့သို့ အသုံးများသည့် partition key များ မကြာခဏ တိုက်ဆိုင်နေသည်။ ဤအသုံးပြုမှုများက logical partition key တူရာတွင် Azure Cosmos DB ကန့်သတ်ပမာဏကို မျှဝေရသဖြင့် ဤဒီဇိုင်းသည် သုံးစွဲသူတစ်ဦး၏ စုစုပေါင်း ဆောင်ကြဉ်းပေးမှု ပမာဏကို ကန့်သတ်ခဲ့သည်။

Habitat နှင့် Azure Cosmos DB သို့ မပြောင်းမီ Postgres ကို ချဲ့ထွင်ရာတွင် မကြာခဏ ရင်ဆိုင်ခဲ့ရသည့် ပြဿနာမှာ အလွန်အလုပ်များသော အဖွဲ့အစည်း သို့မဟုတ် key မှ တောင်းဆိုမှုအများအပြားက ဒေတာဘေ့စ်တစ်ခုလုံးကို ရပ်တန့်စေနိုင်ခြင်း ဖြစ်သည်။ ဆိုလိုသည်မှာ သုံးသူတစ်ဦးက အချိုးအစားမမျှသော ဝန်ကြီးမားစွာ ဖြစ်စေခြင်းဖြစ်သည်။ ထို key များကို cache လုပ်ရန်နှင့် cache တွင် မတွေ့သည့်အခါ lease စနစ်သုံးရန် အတူတကွ များစွာအားထုတ်ခဲ့သည်။ ထို့ကြောင့် cache မတွေ့မှုမှ ဖြစ်လာသည့်ဝန်က အောက်ခံဒေတာဘေ့စ်ကို မဖိစီးတော့ပါ။

စာတမ်းတွင် ဖော်ပြထားသည့် ဒေတာအရွယ်အစားနှင့် ဆောင်ကြဉ်းပေးမှု ပမာဏ ကန့်သတ်ချက်များသည် logical partition key များအတွက် ဖြစ်သော်လည်း အမှန်တကယ် ကန့်သတ်သည့်နေရာမှာ physical partition ဖြစ်သည်။ ထို့ကြောင့် လက်တွေ့တွင် logical partition များသည် 10,000 RU/s သို့ မရောက်နိုင်ပါ။ ၎င်းတို့သည် တူညီသော physical partition ပေါ်ရှိ အခြား logical partition key အားလုံးနှင့် ထို physical partition ၏ ကန့်သတ်ပမာဏကို မျှဝေသုံးရသည်။

ထို့ကြောင့် ဝန်ပိစေသော အတူသုံးသူများက မသက်ဆိုင်သည့် logical partition key များစွာကို ထိခိုက်စေခဲ့သည်။ လူနည်းစုသုံး လုပ်ဆောင်ချက်များ၏ ဒေတာအလုပ်များက အဓိက အကောင့်ဝင်ခြင်းနှင့် စာရင်းသွင်းခြင်းတို့ကိုပင် အနှောင့်အယှက်ပေးခဲ့သည်။

Physical partition တစ်ခု၏ ဆောင်ကြဉ်းပေးမှု ပမာဏ ကန့်သတ်ချက်သည်လည်း Azure Cosmos DB container အတွက် ခွဲဝေထားသော စုစုပေါင်း ဆောင်ကြဉ်းပေးမှု ပမာဏပေါ်မူတည်၍ ပြောင်းလဲသည်။ Container အတွက် ကြိုတင်ခွဲဝေထားသော ဆောင်ကြဉ်းပေးမှု ပမာဏကို ၎င်း၏ physical partition များကြား အကြမ်းဖျင်း ညီမျှစွာ ဖြန့်ဝေသည်။

ဒေတာများလာလျှင် physical partition များ ကွဲထွက်၍ partition အရေအတွက် တိုးလာသော်လည်း စုစုပေါင်း ခွဲဝေထားသော ဆောင်ကြဉ်းပေးမှု ပမာဏက မပြောင်းလဲပါ။ ရလဒ်အနေဖြင့် ဒေတာကြီးလာသည်နှင့်အမျှ partition တစ်ခုချင်း၏ လက်တွေ့ ဆောင်ကြဉ်းပေးမှု ပမာဏ ကန့်သတ်ချက် လျော့နည်းသွားသည်။

သိုလှောင်မှု အများဆုံးလိုသည့် blob ဆန်သော အသုံးပြုမှုများတွင် တောင်းဆိုမှုနှုန်းနှင့် အသုံးပြုမှု တည်ငြိမ်နေသော်လည်း သိုလှောင်ဒေတာ တိုးလာရုံဖြင့် လုပ်ဆောင်နေသော အလုပ်များ၏ ဆောင်ကြဉ်းပေးမှု ပမာဏ လျော့ကျသည့် ပြဿနာ ဖြစ်ပေါ်သည်။

Container များ ခွဲထားခြင်းက partition key ကန့်သတ်ချက်နှင့် အတူသုံးသူကြောင့် ဝန်ပိမှုတို့ကို တစ်စိတ်တစ်ပိုင်း ဖြေရှင်းပေးသည်။ Container တစ်ခုစီအတွက် သီးခြား physical partition များ ခွဲဝေပေးနိုင်သဖြင့် ထို container အတွင်းရှိ အလုပ်များအချင်းချင်းသာ ဝန်ပိစေနိုင်ခြင်း သို့မဟုတ် partition key နယ်ပယ် ထပ်နိုင်ခြင်း ရှိတော့သည်။ သို့သော် container အသစ်ဖန်တီးရာ၌ အပိုအားထုတ်မှု ရှိသည်။ တစ်ခုချင်းအတွက် အရင်းအမြစ် သီးခြားစီမံရသဖြင့် သင့်လျော်သော ဝန်ဆောင်မှု သို့မဟုတ် အသုံးပြုမှုနယ်နိမိတ်အလိုက်သာ container ဖန်တီးလိုသည်။

ခိုင်မာစွာ ခွဲထားရန်လိုသည့် အရေးအကြီးဆုံး အသုံးပြုမှုအသစ်များအတွက် Azure Cosmos DB container များ သီးခြားစတင်သုံးခဲ့သည်။ အားနည်းသော partition များကို စီမံရန် container တစ်ခုစီ၏ စုစုပေါင်း ဆောင်ကြဉ်းပေးမှု ပမာဏကို physical partition အရေအတွက်နှင့် ကိုက်ညီအောင် ချိန်ညှိပေးသည့် script နှင့် ပေါင်းသုံးရာ ရင်ဆိုင်နေရသော ပြဿနာအများစုကို ရှောင်နိုင်ခဲ့သည်။

သို့သော် မူလ container တစ်ခုတည်းဖြင့် စတင်ခဲ့သဖြင့် ယခင်အရေးကြီး အသုံးပြုမှုများစွာသည် ဒေတာမရွှေ့ရသေးဘဲ ထိုနေရာမှာပင် ကျန်နေခဲ့သည်။ မျှဝေသုံး မူလ container ရှိ ဒေတာကို အားကိုးနေရဆဲ အရေးကြီးဝန်ဆောင်မှုများကို ကာကွယ်ရန် ဝန်ဆောင်မှုအသစ် သို့မဟုတ် အဓိကလုပ်ဆောင်ချက်အသစ်များအတွက် container သီးခြားဖန်တီးရန် အဖွဲ့များကို မကြာခဏ အကြံပြုခဲ့သည်။ စနစ်ချဲ့ထွင်လာသည်နှင့် မူလ container အပေါ် ဝန်တိုးလာကာ လက်တွေ့ဝန်ဆောင်မှု ပြဿနာများလည်း များလာသည်။ မူလ container ကို ဝန်ထပ်မပိစေရန် ဝန်ဆောင်မှုအသစ် သို့မဟုတ် ကြီးမားသော လုပ်ဆောင်ချက်အသစ်တိုင်းအတွက် container များ စတင်ခွဲဝေပေးခဲ့သည်။

ဤနည်းက ဆိုက်တစ်ခုလုံး ပြတ်တောက်မှုများစွာကို ကာကွယ်ပေးပြီး ထိခိုက်မှုကို လုပ်ဆောင်ချက် သို့မဟုတ် ဝန်ဆောင်မှုအဆင့် ကျဆင်းခြင်းအထိသာ ကန့်သတ်ပေးခဲ့သည်။ သို့သော် နောက်ဆုံးတွင် container အသစ်ဖန်တီးရသည့် အပိုဝန်က ပြဿနာဖြစ်လာသည်။

ယခင် မျှဝေသုံး မူလ container တွင် အသုံးပြုမှုအသစ်တစ်ခုက 0 QPS မှ QPS ၁ သန်းသို့ တက်လာလျှင်ပင် စုစုပေါင်းအသုံးပြုမှု သိသိသာသာ ပြောင်းနိုင်ခြေ နည်းသည်။ သီးခြား container တွင်မူ အသုံးပြုမှုအသစ်က 0 မှ QPS ၁ သန်းသို့ တက်လာခြင်းသည် ဝန်ထမ်းများအတွင်း စမ်းသုံးမှုသာရှိသည့် အခြေခံအဆင့်ထက် ဝန်အဆ ၁,၀၀၀ တိုးခြင်း ဖြစ်နိုင်သည်။

သီးသန့် container များသုံးသောအခါ စတင်ဖြန့်ချိချိန်၌ မျှော်မှန်းထားသည့် ဆောင်ကြဉ်းပေးမှု ပမာဏအထိ ကြိုတင်ခွဲဝေရန် အဖွဲ့များက သတိထားရတော့သည်။ ထုတ်ကုန်အဖွဲ့များက လုပ်ဆောင်ချက်များကို ဖြန့်ချိသော်လည်း ကြိုတင်ချဲ့ထွင်ရန် မေ့တတ်သည်။ ထို့ကြောင့် ဖြန့်ချိသည့်နေ့တွင် ကျွန်ုပ်တို့က အရေးပေါ်ပြဿနာဖြေရှင်းခန်းများ၌ container များကို နောက်ဆုံးမိနစ်မှ ချဲ့ထွင်ရန် ကြိုးစားနေရသည်။

ဤ container နည်းလမ်းဖြင့် ပိုကောင်းစွာ ခွဲထားနိုင်ရန်အတွက် အတူသုံးစနစ်၏ အဓိကအားသာချက်ဖြစ်သည့် အလုပ်ဝန်မျိုးစုံ ပေါင်းစပ်မျှတစေမှုကို ဆုံးရှုံးရသည်။

အချိန်ကြာလာသည်နှင့် သီးသန့် container အသုံးပြုမှုကို စောင့်ကြည့်ရာတွင် မည်သည့်အချိန်၌ အသုံးပြုမှု ပြောင်းမည်၊ တိုးမည်ကို ထုတ်ကုန်အကြောင်း နက်နက်နဲနဲ သိရန်လိုလာသည်။

တိုးတက်မှုလမ်းကြောင်းအရ container တစ်ခုစီ၏ ဆောင်ကြဉ်းပေးမှု ပမာဏ တိုးပေးရန် အခြေခံ control plane script ကို ပေးနိုင်သည်။ သို့သော် စုစုပေါင်းတိုးတက်မှု မတည်ငြိမ်သဖြင့် မှန်ကန်စွာ ချဲ့ထွင်ရန် OpenAI ရှိ ထုတ်ကုန်အဖွဲ့တိုင်းနီးပါးက အရင်းအမြစ်စီမံရေးတွင် ပါဝင်လာရသည်။

ဝန်ဆောင်မှုတာဝန်ခံအဖွဲ့တစ်ခုစီက Azure Cosmos DB အရင်းအမြစ်ခွဲဝေမှုကို ဂရုစိုက်ပုံ များစွာကွာခြားသဖြင့် အဖွဲ့အစည်း ကြီးလာသည့်အခါ ဤနည်းကို ဆက်မသုံးနိုင်ခဲ့ပါ။

အဖွဲ့အစည်း ကြီးလာသည်နှင့် ထိုလည်ပတ်ရေးပြဿနာများကို အတိုင်းအတာလိုက် ကိုင်တွယ်ရန် ခက်ခဲလာသည်။ စီမံရေးကို ဗဟိုအဖွဲ့တစ်ခုတည်းက မလုပ်သဖြင့် အဖွဲ့များစွာ၏ စီမံမှု အားနည်းခဲ့သည်။ ထို့ကြောင့် အတူသုံးဖြေရှင်းနည်းဘက်သို့ ပြန်ပြောင်းခဲ့ပြီး မျှဝေသုံးဒီဇိုင်းဖြင့် မူလအတူသုံးစနစ်၏ ပြဿနာများကို ဖြေရှင်းရန် Azure အဖွဲ့နှင့် နီးကပ်စွာ ပူးပေါင်းတည်ဆောက်ခဲ့သည်။

အသုံးအများဆုံး key များကို ဦးစွာကန့်သတ်ခြင်းက ဝန်ပိစေသော အတူသုံးသူများအား physical partition တစ်ခု၏ ဆောင်ကြဉ်းပေးမှု ပမာဏအားလုံးကို ယူမသုံးနိုင်အောင် တားဆီးသည်။ ထို့ကြောင့် key တစ်ခု အလွန်အသုံးများရုံဖြင့် ဆိုက်တစ်ခုလုံး ထိခိုက်နိုင်သည့် အကျိုးဆက်ကို လျှော့ချသည်။

တောင်းဆိုမှုများကို အဆင့်ခွဲသည့် QoS ကလည်း ဒေတာအစုလိုက်ထည့်ခြင်း၊ ထုတ်ယူခြင်းကဲ့သို့ offline အလုပ်များအား physical partition တစ်ခု၏ ဆောင်ကြဉ်းပေးမှု ပမာဏအားလုံးကို ယူမသုံးနိုင်အောင် တားဆီးသည်။ ထိုအလုပ်များ၏ တောင်းဆိုမှုကို ဦးစားပေးအဆင့်နိမ့် သတ်မှတ်သဖြင့် ၎င်းတို့ကို ဦးစွာကန့်သတ်သည်။ ထို့ကြောင့် သုံးစွဲသူကို တိုက်ရိုက်တုံ့ပြန်ပေးသည့် ဦးစားပေးအဆင့်မြင့် တောင်းဆိုမှုများ ကန့်သတ်ခံရခြင်းမှ ကာကွယ်ပေးသည်။

Azure Cosmos DB တွင် ကြိုတင်ခွဲဝေမုဒ်၏ အားနည်းသော partition ပြဿနာကို ဖြေရှင်းနိုင်မည့် serverless မုဒ် ရှိပြီးသားဖြစ်သည်။ သို့သော် အဓိကအားနည်းချက်မှာ သိုလှောင်မှုအသုံးပြုပမာဏအရသာ ချဲ့ထွင်ပြီး physical partition တစ်ခုလျှင် RU သုံးစွဲမှုကို 5K RU/s အထိသာ ခွင့်ပြုခြင်းဖြစ်သည်။ ဤနည်းက အားနည်းသော partition ပြဿနာကို ဖြေရှင်းပေးသော်လည်း RU များစွာလိုသည့် အသုံးပြုမှုများကို ချဲ့ထွင်မရစေပါ။

Azure Cosmos DB အဖွဲ့က ကျွန်ုပ်တို့အတွက် တည်ဆောက်ပေးသည့် serverless မုဒ်အသစ်တွင် physical partition တိုင်းကို 10K RU/s အထိ ချဲ့နိုင်သည်။ သိုလှောင်မှုအသုံးပြုပမာဏအပြင် RU သုံးစွဲမှုအရပါ partition ခွဲပေးသဖြင့် container များကို ကိုယ်တိုင်စောင့်ကြည့်၊ ချဲ့ထွင်ရန် မလိုတော့ပါ။

ဤပြောင်းလဲမှုများကြောင့် မျှဝေသုံး container တစ်ခုသို့ ပြန်ပြောင်းနိုင်ခဲ့သည်။ အလုပ်များအကြား ခွဲခြားထားနိုင်စွမ်းကို ထိန်းထားရင်း ထုတ်ကုန်အဖွဲ့များ၏ ကြိုတင်နှင့် ဆက်လက်အရင်းအမြစ်စီမံရေး လိုအပ်ချက်ကို များစွာ ရိုးရှင်းစေခဲ့သည်။ ထိုအချိန်မှစ၍ လအတန်ကြာအတွင်း ထုတ်ကုန်တည်ဆောက်မှု အရှိန်မြင့်လာသော်လည်း အရင်းအမြစ်ခွဲဝေမှု သို့မဟုတ် အတူသုံးသူကြောင့် ဝန်ပိသည့် ပြဿနာ မရှိခဲ့ပါ။

ကုမ္ပဏီများ OpenAI အရွယ်အစားအထိ ကြီးလာသောအခါ စီမံပေးထားသည့် ဝန်ဆောင်မှုများကို ယခင်လောက် “စီမံပေးထားခြင်း” မရှိတော့ပါ။ အလုပ်ဝန်များစွာသည် cloud ဝန်ဆောင်မှုပေးသူ၏ စနစ်အတွင်း ပုံမှန်နှင့်မတူသော အခြေအနေများ ဖြစ်လာသည်။ OpenAI က Azure Cosmos DB ၏ အကြီးဆုံးသုံးစွဲသူများထဲ ပါလာချိန်တွင် အောင်မြင်စွာ လည်ပတ်ရန် မတူသောပုံစံ လိုအပ်လာသည်။ ပူးတွဲစမ်းသပ်မှု၊ မျှဝေသုံး dashboard၊ အင်ဂျင်နီယာများ တိုက်ရိုက်ဆက်သွယ်ရေးနှင့် ကျွန်ုပ်တို့အရွယ်အစား၌သာ ပေါ်လာသည့် ချို့ယွင်းမှုများကို ပူးတွဲတာဝန်ယူခြင်းတို့ ဖြစ်သည်။ ယနေ့ ကျွန်ုပ်တို့၏ အကြီးဆုံး Azure Cosmos DB အကောင့်တွင် ဒေတာ petabyte ဆယ်ဂဏန်း သိမ်းထားပြီး 20M QPS ကျော်ကို တုံ့ပြန်ပေးသည်။ ကျွန်ုပ်တို့ သိသလောက် ဤအတိုင်းအတာဖြင့် Azure Cosmos DB ကို သုံးထားသည့် ကုမ္ပဏီမှာ ကျွန်ုပ်တို့တစ်ခုတည်း ဖြစ်သည်။

၂၀၂၄ နှောင်းပိုင်း ဒေသတစ်ခု ဝန်ဆောင်မှုပြတ်တောက်မှုက ဤပူးပေါင်းမှု ဘာကြောင့်လိုအပ်ကြောင်း ထင်ရှားစေခဲ့သည်။ ထိုစဉ်က ကျွန်ုပ်တို့၏ အကြီးဆုံး Azure Cosmos DB အကောင့်များထဲမှ တစ်ခု၏ အဓိက Azure ဒေသတွင် လျှပ်စစ်ပြတ်တောက်ခဲ့သည်။ ထို့နောက် အရန်ဒေသသို့ ပြောင်းရာတွင် အကြီးဆုံးအကောင့်များအတွက် နာရီအတော်ကြာ လိုမည်ကို တွေ့ခဲ့ရသည်။ ဤအတိုင်းအတာဖြင့် ကျွန်ုပ်တို့အဖွဲ့ရော Azure Cosmos DB အဖွဲ့ပါ ယခင်က မစမ်းသပ်ဖူးခဲ့ပါ။

တစ်လခန့်ကြာပြီးနောက် ထိုအကောင့်များကို မူလဒေသသို့ ပြန်ပြောင်းရာ၌ နောက်ထပ်ပြင်းထန်သော ပြတ်တောက်မှု ဖြစ်စေခဲ့သည်။ မူလဒေသသို့ ချိတ်ဆက်မှုများ တစ်ပြိုင်နက် အလုံးအရင်းဝင်လာ၍ ထိုဒေသ၏ Azure Cosmos DB gateway ဝန်ပိသွားသည်။ Gateway မုဒ်သုံး Azure Cosmos DB client ၏ failover ကိုင်တွယ်ပုံ ထူးခြားချက်တစ်ခုကြောင့် physical partition အချို့သာ မူလဒေသသို့ ပြန်ရောက်သေးသော်လည်း client အားလုံးက ချက်ချင်း ထိုဒေသသို့ ချိတ်ဆက်၍ တောင်းဆိုမှုများ ပို့ခဲ့သည်။

ပြတ်တောက်မှုတိုင်းတွင် OpenAI နှင့် Azure နှစ်ဖွဲ့စလုံးက သက်ဆိုင်ရာ ဖြစ်ရပ်စီမံရေးလုပ်ငန်းစဉ်များကို ဆောင်ရွက်ပြီး အရင်းခံအကြောင်းရင်းများကို ဖော်ထုတ်ကာ ပြင်ဆင်မှုများ ထည့်သွင်းခဲ့သည်။ သို့သော် ဤပြတ်တောက်မှုများသည် ကျွန်ုပ်တို့အဖွဲ့နှင့် Azure Cosmos DB အဖွဲ့၏ လည်ပတ်၊ စမ်းသပ်ပုံတို့အကြား ပိုကြီးသော စနစ်ပိုင်းဆိုင်ရာ ပြဿနာ၏ လက္ခဏာများ ဖြစ်သည်။ အစပိုင်းတွင် စီမံပေးထားသည့် ဝန်ဆောင်မှုများကို သုံးခြင်းက လျင်မြန်စွာ လုပ်ဆောင်၍ လုပ်ငန်းရည်မှန်းချက်များကို အာရုံစိုက်နိုင်စေခဲ့သည်။ အတိုင်းအတာကြီးလာလျှင် ထိုဝန်ဆောင်မှုများက စီမံပေးနိုင်မှု လျော့လာပြီး ဒီဇိုင်းမှ လည်ပတ်ရေးအထိ အဆင့်တိုင်းတွင် ဝန်ဆောင်မှုပေးသူနှင့် နက်ရှိုင်းစွာ ပေါင်းစည်းရန် လိုအပ်သည်။

ယနေ့ Habitat နှင့် Azure အင်ဂျင်နီယာအဖွဲ့များသည် ကျွန်ုပ်တို့၏ ဝန်ဆောင်မှုအလွှာများမှ Azure Cosmos DB ၏ ရုပ်ပိုင်းသိုလှောင်ရေးအလွှာများအထိ Habitat အလွှာတိုင်းကို ပူးတွဲစောင့်ကြည့်သည်။ လက်တွေ့ဝန်ဆောင်မှုနှင့် အရွယ်အစားတူသော်လည်း လက်တွေ့ဝန်ဆောင်မှုအတွက် မသုံးသော Azure Cosmos DB အကောင့်တစ်ခုတွင် ပြောင်းလဲမှုများကို လည်ပတ်စမ်းသပ်သည်။ SDK များကို အတူစမ်းသပ်ပြင်ဆင်ပြီး Azure Cosmos DB အကောင့်များ၏ အရွယ်အစား သတ်မှတ်ပုံ၊ ချဲ့ထွင်ပုံအတွက် အကောင်းဆုံးနည်းလမ်းများ သတ်မှတ်သည်။ Teams မှတစ်ဆင့် အင်ဂျင်နီယာအချင်းချင်း တိုက်ရိုက်ဆက်သွယ်နိုင်သည့်အပြင် အကူအညီပေးရေးအဆင့်များကို ဖြတ်စရာမလိုဘဲ အရေးပေါ် တိုက်ရိုက်လှမ်းခေါ်နိုင်သည့် နည်းလမ်းများပါ ထားရှိထားသည်။

ပြီးခဲ့သည့်နှစ်အတွင်း Azure Cosmos DB ၏ control plane နှင့် gateway ကို ပိုမိုချဲ့ထွင်နိုင်ရန် အတူတကွ များစွာလုပ်ဆောင်ခဲ့သည်။ Azure Cosmos DB metadata partition ကို ကာကွယ်ရန် gateway တွင် ဝန်ပိမှုကာကွယ်ရေးနှင့် metadata အမျိုးမျိုး၏ cache ကို ထည့်သွင်းခဲ့သည်။ Connection pooling နှင့် ချိတ်ဆက်မှုများ ပိုမိုပြန်သုံးခြင်းဖြင့် ကျွန်ုပ်တို့၏ Python habitat-service process များမှ ဝန်ကို လျှော့ချခဲ့သည်။ ဖြစ်နိုင်သမျှ အလုပ်များကို နေရာတူထားပြီး အရေးကြီးအလုပ်များနှင့် offline အလုပ်များကို မတူညီသော VPC များဖြင့် ခွဲထားခဲ့သည်။

ဤမျှနီးကပ်စွာ ပူးပေါင်းတည်ဆောက်ခဲ့ခြင်းက ပြီးခဲ့သည့်နှစ်အတွင်း ကျွန်ုပ်တို့၏ Azure Cosmos DB တည်ငြိမ်ရေးအတွက် အလွန်အရေးပါခဲ့သည်။ လုံလောက်စွာ ကြီးမားသည့် သို့မဟုတ် အရေးပါသည့် မည်သည့်စနစ်မဆို တာဝန်ယူမှုနယ်နိမိတ်များကို ကျော်လွန်ကာ အဖွဲ့အစည်းများအကြား ဤကဲ့သို့ ပူးပေါင်းလုပ်ဆောင်ရန် လိုအပ်သည်။

အပိုင်း ၁ တွင် ဖော်ပြခဲ့သည့်အတိုင်း ကျွန်ုပ်တို့၏ အခြေခံမူမှာ အလုပ်လုပ်အောင်လုပ်၊ မြန်အောင်လုပ်၊ ကုန်ကျစရိတ်နည်းအောင်လုပ် ဟူ၍ဖြစ်သည်။ ဦးစွာ ယုံကြည်စိတ်ချရမှု၊ ထို့နောက် စွမ်းဆောင်ရည်၊ နောက်ဆုံး အရင်းအမြစ် အကျိုးရှိစွာ အသုံးချနိုင်မှု ဖြစ်သည်။ Habitat သည် OpenAI အတွက် အရေးပါသော အခြေခံစနစ် ဖြစ်လာသဖြင့် ယုံကြည်စိတ်ချရအောင်လုပ်ရေးကို ပထမဦးစားပေးခဲ့သည်။ ၂၀၂၅ တွင် စနစ်တည်ငြိမ်လာပြီး OpenAI က ကမ္ဘာတစ်ဝန်း ချဲ့ထွင်လာသောအခါ တုံ့ပြန်ချိန်ကြာမြင့်မှုက သုံးစွဲသူများနှင့် ထုတ်ကုန်အဖွဲ့များအတွက် နောက်ထပ်အဟန့်အတား ဖြစ်လာသည်။

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

ဒေတာသိမ်းထားရာနှင့် တောင်းဆိုမှုကို တုံ့ပြန်ပေးရာ နေရာပေါ်မူတည်ပြီး တုံ့ပြန်ချိန်မှာ များစွာကွာခြားခဲ့သည်။ Habitat တောင်းဆိုမှုများ မြန်ဆန်စေရန် ထုတ်ကုန်ရေးသားသူများက client ဘက်၌ cache ထပ်ထည့်ခြင်း၊ တောင်းဆိုမှုများကို စု၍ပို့ခြင်း၊ ဒေတာဘေ့စ်ဖတ်ရေးမှု လျှော့ချခြင်းနှင့် ဖြစ်နိုင်သမျှ အလုပ်များကို မဖြစ်မနေ အစဉ်လိုက်လုပ်ရသည့် လမ်းကြောင်းမှ ဖယ်ထုတ်ခြင်းတို့ကို အားကိုးခဲ့ရသည်။ ထိုနည်းဖြင့် ဒေတာဘေ့စ်ပြဿနာများကို ပိုခံနိုင်သော စိတ်ဝင်စားဖွယ် ထုတ်ကုန်ဒီဇိုင်းများ ရလာသော်လည်း ထုတ်ကုန်များ ပိုရှုပ်ထွေးပြီး ပြင်ဆင်ထုတ်ဝေမှု နှေးကွေးလာသည်။ ဒေတာဘေ့စ်ကို နားလည်စရာမလိုဘဲ ထုတ်ကုန်များ မြန်မြန်တည်ဆောက်နိုင်စေရန် ဟူသော Habitat ၏ ရည်မှန်းချက်ကို မပြည့်မီခဲ့ပါ။

၂၀၂၆ တွင် ဤကိစ္စကို အဓိကအာရုံစိုက်ပြီး Habitat တောင်းဆိုမှုများ၏ ၉၀% ကျော်ရှိသော ဖတ်ယူမှုများ၏ စွမ်းဆောင်ရည်ကို မြှင့်တင်ရန် အလွှာလိုက် မဟာဗျူဟာ ချမှတ်ခဲ့သည်။

ဒေတာ သိမ်းဆည်းပြီး စီမံဆောင်ရွက်သည့်နေရာ သတ်မှတ်ချက်ရှိသည့် သုံးစွဲသူများအတွက် ကမ္ဘာတစ်ဝန်း Azure ဒေသအသီးသီး၌ Azure Cosmos DB အကောင့်များ ထားရှိထားသည်။ ဒေတာ သိမ်းဆည်းပြီး စီမံဆောင်ရွက်သည့်နေရာ တင်းကျပ်စွာ သတ်မှတ်မထားသည့် သုံးစွဲသူများအတွက်လည်း ဒေတာကို အနီး၌ထားခြင်းက တုံ့ပြန်ချိန်လျော့စေပြီး သုံးစွဲမှုအတွေ့အကြုံ ပိုကောင်းစေသည်။

လက်တွေ့တွင် နေရာချထားမှုကို cloud ၏ ရုပ်ပိုင်းအရင်းအမြစ်များက ကန့်သတ်နေသဖြင့် ဒေတာ သိမ်းဆည်းပြီး စီမံဆောင်ရွက်သည့်နေရာ သတ်မှတ်ချက်ရှိသည့် ကိစ္စများအပြင် အခြားနေရာများ၌ ကျယ်ကျယ်ပြန့်ပြန့် မလုပ်နိုင်သေးပါ။ ကျွန်ုပ်တို့၏ ဒေတာအစုများ ကြီးမားလွန်းသဖြင့် ဒေသများစွာသည် ၎င်းတို့ထံဝင်လာသော သုံးစွဲမှုအချိုးအစားအတွက် လိုအပ်သည့် ဧရာမသိုလှောင်မှုပမာဏကို မဖြည့်ဆည်းနိုင်ပါ။

ဒေတာစင်တာပမာဏ၊ လျှပ်စစ် သို့မဟုတ် အအေးပေးစနစ် အကန့်အသတ်ရှိသည့် ဒေသများတွင် တစ်ခုခုကို ရွေးရတတ်သည်။ သိုလှောင်မှုကို အနီး၌ထားပြီး Habitat တုံ့ပြန်ချိန် လျှော့မည်လား၊ ထိုအရင်းအမြစ်ကို တုံ့ပြန်ပေးသည့် တွက်ချက်ရေးစနစ်အတွက် ထပ်သုံးပြီး သိုလှောင်မှုတောင်းဆိုချက်များကို အဝေးသို့ ပို့မည်လား ဟူ၍ဖြစ်သည်။

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

တောင်းဆိုမှုတိုင်း လိုအပ်သည့် အထောက်အထားစစ်ဆေးရေး metadata ကဲ့သို့ တုံ့ပြန်ချိန် အရေးအကြီးဆုံးအလုပ်များအတွက် ဒုတိယဒေသများစွာသို့ မိတ္တူပွားထားသော Azure Cosmos DB အကောင့်များကို သုံးသည်။ ထို့ကြောင့် တွက်ချက်ရေးစနစ်နှင့် Habitat ကြား အသွားအပြန်ကြာချိန် (RTT) လျော့ကျသည်။ အချို့အကောင့်များက ကျွန်ုပ်တို့ ဝန်ဆောင်မှုပေးသည့် Azure ဒေသ ၄၀ စလုံးသို့ မိတ္တူပွားပြီး အခြားအကောင့်များက တိုက်ကြီးတစ်ခုလျှင် အနည်းဆုံး ဒေသတစ်ခုသို့ မိတ္တူပွားသည်။

မိတ္တူဖြန့်ဝေပုံ မတူသည့် အကောင့်များကြား ဒေတာအစုများ ရွှေ့နိုင်ရန် အသုံးပြုသူဘက်မှ သိစရာမလိုသော ဒေတာရွှေ့ပြောင်း၊ လမ်းကြောင်းညွှန် အလွှာကို Habitat တွင် မျှော်မှန်းထားသည်ထက် စောစွာ တည်ဆောက်ခဲ့ရသည်။

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

Habitat အလုပ်အများစုမှာ ဖတ်ယူမှုများဖြစ်ပြီး အက်ပ်များက ဆက်တင်၊ အခြေအနေနှင့် အခြားဂုဏ်သတ္တိများကို အမြဲရယူနေသည်။ သုံးစွဲမှုအများစုမှာ မကြာခဏ ဖတ်ယူသည့် ဒေတာအမျိုးအစား အစုငယ်လေးမှ လာခြင်းဖြစ်သည်။ ထို့ကြောင့် ဤစနစ်သည် ဖြန့်ကျက် cache စနစ်အတွက် အထူးသင့်လျော်သည်။ Cache က ဒေသတစ်ခုတည်းရှိ စနစ်၏ စွမ်းဆောင်ရည်ကို တိုးစေသလို ဒေသများစွာတွင် သုံးပါက ဒေသဖြတ်ကျော်ကြာချိန်ကို “ဖုံးကွယ်” ပေးနိုင်သဖြင့် အကျိုးကျေးဇူး ပိုတိုးလာသည်။

Habitat တွင် ဖြန့်ကျက် lookaside cache အလွှာကို ပေါင်းထည့်ထားသည်။ ၎င်းက မကြာသေးမီက ဖတ်ယူထားသော object နှင့် edge မိတ္တူများကို သုံးစွဲသူတောင်းဆိုမှုများ လုပ်ဆောင်ရာအနီးရှိ ကျွန်ုပ်တို့စနစ်၏ Valkey ဆာဗာများတွင် သိမ်းသည်။ ဤ cache မျိုးတွင် တွေ့ရှိနှုန်းနှင့် ဒေတာဟောင်းနေမှုကို ချိန်ဆရန် ပုံမှန်အားဖြင့် သက်တမ်း (TTL) သတ်မှတ်သည်။ TTL တိုလျှင် ဒေတာဟောင်းနေမှု နည်းသော်လည်း cache ထဲမှ ဒေတာ မြန်မြန်သက်တမ်းကုန်၍ မကြာခဏ ပြန်ယူရသဖြင့် cache ၏ အကျိုးကျေးဇူး လျော့သည်။ TTL ရှည်လျှင် တွေ့ရှိနှုန်း တိုးသော်လည်း ဒေတာဟောင်းကို ကြာရှည်ပေးနေသဖြင့် သုံးစွဲမှုအတွေ့အကြုံ ညံ့ပြီး ထုတ်ကုန်လုပ်ဆောင်ပုံ မခန့်မှန်းနိုင်ဖြစ်စေသည်။

နောက်တစ်နည်းမှာ အက်ပ်က မူလဒေတာကို ရေးသားချိန်တွင် cache ကို တိုက်ရိုက် ပယ်ဖျက်သတ်မှတ်ခြင်းဖြစ်သည်။ ဤနည်းက cache ဒေတာကို များစွာ ပိုလတ်ဆတ်စေသော်လည်း မှန်ကန်စွာ လုပ်ဆောင်ရန် ခက်နိုင်သည်။ တစ်စိတ်တစ်ပိုင်း ချို့ယွင်းမှုကဲ့သို့ ခြွင်းချက်အခြေအနေများကြောင့် cache ဒေတာ ဟောင်းနေနိုင်ဆဲဖြစ်သည်။ ဒေသစုံဖြန့်ကျက်လျှင် ဒေသဖြတ်ကျော်ကွန်ရက်များ ပိုမစိတ်ချရခြင်းနှင့် cache၊ အောက်ခံသိုလှောင်မှု မိတ္တူပွားခြင်းတို့ အချိန်မကိုက်ခြင်းက ပြဿနာများကို ပိုဆိုးစေသည်။ TTL နှင့် တွဲသုံးခြင်းက ဒေတာဟောင်းနေနိုင်သည့် အများဆုံးအချိန်ကို ကန့်သတ်သော်လည်း အထက်ပါ TTL အပေးအယူကို ရင်ဆိုင်ရဆဲဖြစ်သည်။

Meta ၏ TAO ကဲ့သို့သော စနစ်များကို အတုယူ၍ ပိုအဆင့်မြင့်သော cache ပယ်ဖျက်နည်းကို သုံးထားသည်။ Habitat ၏ cache သည် Azure Cosmos DB change feed မှ ဒေတာပြောင်းလဲမှုဖမ်းယူခြင်း (CDC) ကို သုံးကာ စက္ကန့်ပိုင်းအတွင်း ကမ္ဘာတစ်ဝန်း ပယ်ဖျက်အမိန့် ဖြန့်ပေးသည်။ ထို့ကြောင့် တွေ့ရှိနှုန်း မြင့်ပြီး ဒေတာဟောင်းနေမှု နည်းသည်။ ကျွန်ုပ်တို့စနစ်ရှိ ဝန်ဆောင်မှုတစ်ခုက change feed ကို ဖတ်ပြီး မူလဒေတာ ပြောင်းလဲသည့်အခါ ဒေသတွင်း cache များကို ပယ်ဖျက်သတ်မှတ်သည်။ ထို့ကြောင့် နောက်တစ်ကြိမ် ဖတ်ချိန်တွင် cache ၌ မတွေ့တော့ဘဲ နောက်ဆုံးဒေတာဖြင့် cache ကို ပြန်ဖြည့်သည်။

မူလ Python ထက် ပိုမြန်သော Rust ဖြင့် ကုဒ်ပြန်ရေးကာ Habitat ဝန်ဆောင်မှုကိုယ်တိုင်၏ အပိုဝန်ကို ဖယ်ရှားခြင်းဖြင့် တုံ့ပြန်ချိန်ကိုလည်း များစွာ လျှော့ချခဲ့သည်။

ဤပြောင်းလဲမှုများကြောင့် ကမ္ဘာတစ်ဝန်း ဖတ်ယူမှု p50 အချိန်သည် 120 ms ခန့်မှ 10 ms ခန့်သို့ ကျဆင်းသွားသည်။ ယခုနှစ်အစပိုင်း စွမ်းဆောင်ရည်ကို အာရုံစိုက်ချိန်မှစ၍ ၁၂ ဆ တိုးတက်လာခြင်းဖြစ်သည်။

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

ဒေတာဘေ့စ်ပြောင်းလဲမှုများကို နောက်ဆက်တွဲစနစ်များသို့ ဖြန့်ပေးသည့် စိတ်ချရပြီး ချဲ့ထွင်နိုင်သော CDC သည် Habitat cache မဟာဗျူဟာအတွက်သာမက အခြားနေရာများ၌ပါ အရေးကြီးသည်။ Container ထောင်ချီနှင့် partition သန်းချီမှ တစ်စက္ကန့်လျှင် ဖမ်းယူသော ပြောင်းလဲမှုသန်းချီသည် Kafka topic ရာကျော်ကို ဖြတ်သန်းသည်။ ၎င်းတို့က နောက်ဆုံးတွင် ကိုက်ညီလာမည့် ဒုတိယအညွှန်းများ၊ ဒေတာရွှေ့ပိုက်လိုင်းများ၊ offline ခွဲခြမ်းစိတ်ဖြာမှုနှင့် အချိန်နှင့်တစ်ပြေးညီ လုပ်ဆောင်ချက်များကိုလည်း ပံ့ပိုးသည်။ အောက်ခံစနစ် ကမ္ဘာတစ်ဝန်း ကြီးထွားလာသည်နှင့် ဒေတာအတန်း ပြောင်းလဲမှုများကို စောင့်ကြည့်ရန် ပိုရှုပ်ထွေးလာသည်။ Client က မိမိဒေတာအမျိုးအစား၏ အတန်းများ ပြောင်းတိုင်း ခေါ်ရန် callback မှတ်ပုံတင်လိုပါက ဒေတာရှိသည့် Cosmos အကောင့်နှင့် container များ၊ သက်ဆိုင်ရာဒေသ၌ ထို container များကို စောင့်ကြည့်သော CDC ဝန်ဆောင်မှုတို့ကို ဦးစွာသိရမည်။ CDC worker အစု၊ Kafka နှင့် မိမိ consumer ကိုလည်း သင့်လျော်စွာ ချဲ့ထွင်ရမည်။ ကျွန်ုပ်တို့၏ CDC ပလက်ဖောင်းက ထိုရှုပ်ထွေးမှုအားလုံးကို ထုတ်ကုန်ရေးသားသူများအတွက် ဖုံးကွယ်ပေးရန် ရည်ရွယ်သည်။ Client က အတန်းပြောင်းလဲချိန် ခေါ်လိုသည့် function ကို ရိုးရှင်းစွာ မှတ်ပုံတင်ရုံသာရှိပြီး ချိတ်ဆက်ခြင်းနှင့် ချဲ့ထွင်ခြင်းအားလုံးကို ကျွန်ုပ်တို့ ကိုင်တွယ်သည်။

အတွင်းပိုင်း control plane က လိုအပ်သော container အားလုံးကို ဖမ်းယူနေကြောင်း အမြဲစစ်ဆေးပြီး ဖတ်ယူမည့် Cosmos ဒေသများကို ရွေးကာ ဒေသစုံရှိ worker ထောင်ချီကြား အလုပ်ကို ထိရောက်စွာ ဖြန့်ဝေသည်။ မိတ္တူဒေသများနှင့် ဦးစားပေးအဆင့်နိမ့် feed ဖတ်ယူမှုကို သုံးခြင်းက တုံ့ပြန်ချိန်အရေးကြီးသော Habitat တောင်းဆိုမှုများကို နောက်ကွယ်ဖမ်းယူအလုပ်များ၏ ထိခိုက်မှုမှ ကာကွယ်သည်။ ဤမျှကြီးသော အစုတွင် worker ပျက်ခြင်း၊ container ပြဿနာ၊ lease-store အမှား၊ မမှန်ကန်သော ဆက်တင်နှင့် ပို့မည့်စနစ် ချို့ယွင်းမှုများ အမြဲဖြစ်နေသည်။ CDC worker သက်တမ်းစက်ဝန်းနှင့် lease ကိုင်တွယ်မှုကို ပိုခိုင်မာစေပြီး stream များကြား ချို့ယွင်းမှု မကူးစေရန် ခွဲထားသည်။ ဆက်တင်ပြောင်းလဲမှုနှင့် ဖြန့်ချိမှုများအတွက်လည်း ကာကွယ်ရေးများ တည်ဆောက်ခဲ့သည်။ အမြဲတမ်း ပို့မရသည့်အရာများကြောင့် တန်းစီမှုရှေ့ဆုံး၌ ပိတ်မနေစေရန် dead letter queue များကို သုံးသည်။ ဖတ်ယူသူများကို အခြား Cosmos ဒေသသို့ ပြောင်းပေးခြင်းဖြင့် ဒေသအလိုက် ပြတ်တောက်မှုကို ခံနိုင်စေသည်။ ကျွန်ုပ်တို့အတိုင်းအတာ၌ Azure ၏ CDC SDK ကိုပင် ပြင်ခဲ့ရသည်။ Checkpoint များကို မမ်မိုရီထဲ၌ စုထားပြီး အချိန်အပိုင်းအခြားအလိုက်သာ ရေးချစေကာ checkpoint သိမ်းမှုကို ပိုထိရောက်စေခဲ့သည်။

Habitat အတွင်း Azure Cosmos DB သုံးပုံ ရှုပ်ထွေးသော်လည်း ၎င်း၏ အဓိကတန်ဖိုးမှာ အခြေခံစနစ်အသေးစိတ်ကို ထုတ်ကုန်ရေးသားသူများ သိစရာမလိုစေဘဲ ဖန်တီးမှုမြန်စေရန် ဖြစ်သည်။ CDC ပလက်ဖောင်းလည်း ထိုနည်းတူပင်ဖြစ်သည်။

သိုလှောင်ရေး API ကို ရည်ရွယ်ချက်ရှိရှိ ကျဉ်းကျဉ်းထားခြင်း၊ Python ဝန်ဆောင်မှုကို ဆက်ချဲ့ခြင်းနှင့် အရေးအကြီးဆုံး အင်ဂျင်နီယာစိန်ခေါ်မှုများကို ဦးစားပေးခြင်းဖြင့် အဖွဲ့ငယ်တစ်ခုက လျင်မြန်စွာကြီးလာသော သိုလှောင်ရေးပလက်ဖောင်းကို ပံ့ပိုးနိုင်ခဲ့သည်။ ဦးစွာ အရေးကြီးထုတ်ကုန်တောင်းဆိုမှုများအတွက် စိတ်ချရမှု၊ ထို့နောက် ကမ္ဘာတစ်ဝန်း သုံးစွဲသူများအတွက် ဖတ်ယူမှုစွမ်းဆောင်ရည်၊ နောက်ဆုံး အကြီးစားလည်ပတ်မှု ထိရောက်ရေးကို အာရုံစိုက်ခဲ့သည်။ ဤနည်းက စိတ်ချရမှု၊ စွမ်းဆောင်ရည်နှင့် ထုတ်ကုန်တည်ဆောက်မှုအမြန်နှုန်းကို တိုးတက်စေရင်း လျင်မြန်စွာကြီးထွားမှုနှင့် အသုံးပြုမှုပုံစံသစ်များကို ပံ့ပိုးနိုင်ခဲ့သည်။

နောက်ထပ် သုံးစွဲသူ ၁ ဘီလီယံအတွက် Habitat နှင့် စကားဝိုင်းသိုလှောင်မှု ချဲ့ထွင်ရန် ကျွန်ုပ်တို့စနစ်တစ်လျှောက် ဒေတာကို ပိုကြီးမားသော အတိုင်းအတာဖြင့် မိတ္တူပွားရသည့် အခက်အခဲကို ဖြေရှင်းရမည်။ ကြိုတင်ပြင်ဆင်ရန် ဒေတာထုထည်ကြီးသော Habitat အမျိုးအစားများအတွက် အထူးပြုထားသည့် exabyte အဆင့် အွန်လိုင်းသိုလှောင်ရေးစနစ်ကို ကိုယ်တိုင်တည်ဆောက်နေသည်။ တည်ဆောက်ဆဲ ဤစနစ်တွင် Rockset မှ RocksDB Cloud အူတိုင်နှင့် Raft အခြေပြု မိတ္တူပွားခြင်းကို ပေါင်းစပ်ထားသည်။ Azure Cosmos DB နှင့် တူညီသော document ဖွဲ့စည်းပုံကို သုံးသော်လည်း ခွဲထုတ်ထားသော သိုလှောင်မှုနှင့် ရုပ်ပိုင်းမိတ္တူပွားခြင်းဖြင့် လိုအပ်သည့် flash ပမာဏကို လျှော့ချထားသည်။ အပေးအယူအဖြစ် အမြင့်ဆုံး qps ပိုနည်းမည်ဖြစ်သည်။

ဤဒေတာအခြေခံစနစ်လုပ်ငန်းမျိုးကို ရှေ့တန်းအဆင့် အတိုင်းအတာဖြင့် လုပ်ကိုင်လိုပါက ကျွန်ုပ်တို့၏ ခေါ်ယူနေသော ရာထူးများကို ကြည့်ပါ⁠။