Agent Bucket: Agent အခြေခံ သိုလှောင်ကန် ထရီလီယံနှင့်ချီ

AI Agent များ မိုးရွာပြီးနောက် ပေါက်ဖွားလာသည့် မှိုများကဲ့သို့ ပေါ်ထွက်လာသည့် ယနေ့ခေတ်တွင်၊ တီထွင်သူများသည် စိတ်ကူးစိတ်သန်းများ ပြည့်နှက်နေသော အသိဉာဏ်ရှိသည့် အပလီကေးရှင်းများကို မကြုံစဖူး အရှိန်အဟုန်ဖြင့် တည်ဆောက်နေကြသည်။ သင့်အတွက် ကုဒ်ရေးနိုင်သော ပရိုဂရမ်ရေးဆွဲသူ လက်ထောက်မှသည် စကားတစ်ခွန်းတည်းဖြင့် ရုပ်ရှင်တစ်ကားကို ဖန်တီးပေးနိုင်သော ဖန်တီးမှုကိရိယာအထိ၊ ထို့အပြင် အမြဲတမ်း အသင့်ရှိသော ကိုယ်ပိုင် အသိဉာဏ်လက်ထောက်အထိ Agent သည် ကျွန်ုပ်တို့၏ ဒစ်ဂျစ်တယ်ကမ္ဘာနှင့် အပြန်အလှန် ဆက်သွယ်ပုံကို ပြန်လည်ပုံဖော်နေသည်။ ဤရေစီးကြောင်းနောက်ကွယ်တွင်၊ သဘောတူညီချက်တစ်ခုသည် တဖြည်းဖြည်း ပိုမိုရှင်းလင်းလာသည်- Serverless ဗိသုကာ (Lambda ကဲ့သို့)၊ ဘာသာစကားပုံစံကြီး (LLM) နှင့် cloud သိုလှောင်မှု (S3, TOS ကဲ့သို့) တို့၏အကူအညီဖြင့် Vibe Coding နှင့်ပေါင်းစပ်ပြီး မည်သူမဆို မိနစ် 30 အတွင်း ကိုယ်ပိုင် AI Agent တစ်ခုကို လျင်မြန်စွာ တည်ဆောက်နိုင်သည်။

"အသုံးဝင်နိုင်ခြင်း" မှ "အသုံးဝင်ကောင်းခြင်း" သို့ Agent တီထွင်သူများသည် "ကစားစရာ" မှ "ထုတ်လုပ်မှုအဆင့် အပလီကေးရှင်း" သို့ ပြောင်းလဲရန် အခက်အခဲများကို ကျော်လွှားရန် လိုအပ်နေသေးသည်။ လုပ်ငန်းသည် ဧရာမအသုံးပြုသူများဆီသို့ ရွေ့လျားလာသည်နှင့်အမျှ၊ တီထွင်သူများသည် အလွန်ရှုပ်ထွေးသော စိန်ခေါ်မှုတစ်ခုကို ရင်ဆိုင်ရသည်- ဧရာမ terminal အသုံးပြုသူများအတွက် အရာဝတ္ထုသိုလှောင်မှုတွင် ပြီးပြည့်စုံသော သိုလှောင်မှုအစီအစဉ်ကို မည်သို့တည်ဆောက်ရမည်နည်း။ တီထွင်သူအများစုအတွက်၊ ၎င်းသည် နည်းပညာဆိုင်ရာ အတားအဆီးတစ်ခုသာမက Agent ၏ စကေးအလိုက် ဖြန့်ဖြူးမှုကို ဟန့်တားသည့် အတားအဆီးတစ်ခုလည်းဖြစ်သည်။ Agent Bucket သည် AI အခြေခံ သိုလှောင်မှုဒီဇိုင်းဖြင့် multi-tenant စနစ်များ၏ တည်ဆောက်မှုလုပ်ငန်းစဉ်ကို လုံးဝရိုးရှင်းစေရန်နှင့် ပိုမိုကောင်းမွန်သော Agent စွမ်းရည်များကို ပေးဆောင်ရန် ရည်ရွယ်သည်။

သန်းပေါင်းများစွာသော အသုံးပြုသူများ ဝင်ရောက်လာသောအခါ၊ ရိုးရာအရာဝတ္ထု သိုလှောင်မှုသည် "မလုံလောက်တော့ပါ"

သင်သည် လူကြိုက်များသော AIGC အပလီကေးရှင်းတစ်ခုကို တီထွင်ခဲ့သည်ဟု မြင်ယောင်ကြည့်ပါ။ အသုံးပြုသူတိုင်းသည် ပုံများ၊ ဗီဒီယိုများနှင့် ယာယီဖိုင်များစွာကို ထုတ်လုပ်ပြီး သိမ်းဆည်းမည်ဖြစ်သည်။ တီထွင်သူတစ်ဦးအနေဖြင့် သင်သည် S3 နှင့် TOS ကဲ့သို့သော ရင့်ကျက်ပြီး စကေးချဲ့နိုင်သော အရာဝတ္ထု သိုလှောင်မှုဝန်ဆောင်မှုများကို သဘာဝကျကျ ရွေးချယ်မည်ဖြစ်သည်။ သို့သော် ပြဿနာမှာ- ဧရာမအသုံးပြုသူများအတွက် ဒေတာကို မည်သို့စီမံခန့်ခွဲမည်နည်း။

2022 ခုနှစ် S3 ဘလော့ဂ် «Amazon S3 ဖြင့် Multi-Tenant SaaS ဒေတာကို ခွဲခြမ်းခြင်းနှင့် သီးခြားခွဲထုတ်ခြင်း» တွင် နည်းလမ်းနှစ်မျိုးကို ဖော်ပြထားသည်၊ "အိမ်ငှားတိုင်းအတွက် သီးခြား S3 bucket ကို အသုံးပြုခြင်း" နှင့် "ရှေ့ဆက်စာလုံးဖြင့် သီးခြားခွဲထားသော မျှဝေထားသော S3 bucket" ဖြစ်သည်:

• အသုံးပြုသူတိုင်းအတွက် သီးခြား "bucket" တစ်ခုကို ဖန်တီးပါ- ၎င်းသည် အသုံးပြုသူအရေအတွက် နည်းပါးသောအခါတွင် ဖြစ်နိုင်သော်လည်း အသုံးပြုသူအရေအတွက်သည် ထောင်ပေါင်းများစွာ၊ သန်းပေါင်းများစွာအထိ တိုးလာသောအခါတွင် bucket အရေအတွက်သည် လျင်မြန်စွာ ပေါက်ကွဲလာမည်ဖြစ်ပြီး စီမံခန့်ခွဲမှုကုန်ကျစရိတ်နှင့် အရင်းအမြစ်ကန့်သတ်ချက်များသည် ခံနိုင်ရည်မရှိတော့ပါ။ S3 သည် ဒေသတစ်ခုလုံးအတွက် စုစုပေါင်း bucket ခွဲတမ်း 10000 ကို ပေးဆောင်သော်လည်း လူကြိုက်များသော AI စွမ်းရည်များအတွက် 10000 သည် လုံလောက်မှုမရှိသေးပါ။

• တူညီသော bucket အတွင်းရှိ "ရှေ့ဆက်စာလုံး" ဖြင့် အသုံးပြုသူများကို ခွဲခြားပါ- ၎င်းသည် အဓိကအစီအစဉ်ဖြစ်လာသည်။ ဥပမာအားဖြင့်၊ အသုံးပြုသူ A ၏ဖိုင်များသည် user-a/ ဖြင့်စတင်ပြီး အသုံးပြုသူ B ၏ဖိုင်များသည် user-b/ ဖြင့်စတင်သည်၊ ကွန်ပျူတာပေါ်တွင် ဖိုင်များကို ဖိုင်တွဲများဖြင့် စီမံခန့်ခွဲခြင်းနှင့်တူသည်။ သို့သော် အရာဝတ္ထုသိုလှောင်မှုတွင် မူရင်းဖိုင်တွဲများမရှိပါ၊ ဤအစီအစဉ်သည် "K-V" သိုလှောင်မှုစနစ်တွင် "အများသုံးရှေ့ဆက်စာလုံး" (Prefix) ဖြင့် multi-tenant ကို ခွဲခြားခြင်းဖြစ်သည်။

ဤ "bucket" သို့မဟုတ် "ရှေ့ဆက်စာလုံး" အခြေခံအစီအစဉ်ကို လွန်ခဲ့သော ဆယ်စုနှစ်အတွင်းတွင် ကျယ်ကျယ်ပြန့်ပြန့် အသုံးပြုခဲ့သည်။ သို့သော် အောက်ပါပြဿနာများရှိသည်:

• Multi-tenant သီးခြားခွဲထားခြင်း- အသုံးပြုသူအားလုံး၏ဒေတာသည် တူညီသော bucket တွင် ရောထွေးနေပြီး အသုံးပြုသူတစ်ဦး၏ ပုံမှန်မဟုတ်သော ကြိမ်နှုန်းမြင့်ဝင်ရောက်မှုသည် အခြားအသုံးပြုသူအားလုံးကို ထိခိုက်စေနိုင်ပြီး "အိမ်နီးချင်းအကျိုးသက်ရောက်မှု" ကို ဖြစ်ပေါ်စေနိုင်သည်။ စွမ်းဆောင်ရည်သီးခြားခွဲထားခြင်းနှင့် ချို့ယွင်းချက်သီးခြားခွဲထားခြင်းသည် မဖြစ်နိုင်ပါ။

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

• ကုန်ကျစရိတ်ရှင်းလင်းခြင်း- အသုံးပြုသူတစ်ဦးစီသည် သိုလှောင်မှုနေရာမည်မျှသုံးစွဲခဲ့သည်၊ ယာဉ်ကြောကုန်ကျစရိတ်မည်မျှဖြစ်ပေါ်ခဲ့သည်ကို သင်အတိအကျသိရန်ခက်ခဲသည်။ အသုံးပြုမှုအပေါ်အခြေခံ၍ ငွေပေးချေသောအသုံးပြုသူများကို ကောက်ခံလိုသောအခါ၊ ငွေတောင်းခံခြင်းနှင့် တိုင်းတာခြင်းသည် ရှုပ်ထွေးသောကိစ္စတစ်ခုဖြစ်လာသည်။Object Storage (S3/TOS) ၏ အနှစ်သာရမှာ "ပြားချပ်ခြင်း" ဖြစ်ပြီး၊ ဒီဇိုင်း၏ မူလရည်ရွယ်ချက်မှာ ကြီးမားသောဒေတာများကို ရိုးရှင်းစွာ သိမ်းဆည်းရန်ဖြစ်ပြီး၊ ၎င်းသည် ကြီးမားသောဂိုဒေါင်တစ်ခုနှင့်တူသည်။ ပမာဏသည် အကန့်အသတ်မရှိသလောက်ဖြစ်သော်လည်း ယုတ္တိဖွဲ့စည်းပုံအရ အလွန်ရိုးရှင်းပါသည်။ ၎င်းတွင် မူလအဆင့်မြင့် Directory စီမံခန့်ခွဲမှု၊ အသေးစိတ် Metadata ထိန်းချုပ်မှုနှင့် စစ်မှန်သော Tenant အသိအမှတ်ပြုမှုတို့ မရှိပါ။ Developer များသည် "ပြားချပ်သော" S3 တွင် Hard-coded Prefix ကို အသုံးပြု၍ "သုံးဖက်မြင်" Multi-tenant File System ကို အတုယူရန် ကြိုးစားသောအခါ၊ ကျွန်ုပ်တို့သည် အမှန်တကယ်အားဖြင့် "Static KV Storage" ကို အသုံးပြု၍ "Directory Semantic, Strong Isolation" Agent Application ၏ File Access နည်းလမ်းကို သယ်ဆောင်နေခြင်းဖြစ်သည်။ ဆိုလိုသည်မှာ Agent သည် ဖိုင်များကို စီမံခန့်ခွဲရန်နှင့် Multi-tenant ခွင့်ပြုချက်များနှင့် ခွဲထုတ်ခြင်းကို ထိန်းချုပ်ရန်အတွက် Token များကို အပိုသုံးစွဲရန် လိုအပ်ပါသည်။ ဤအပို Token များသည် S3 မှ သတ်မှတ်ထားသော ရိုးရှင်းသော Storage ဝန်ဆောင်မှုသည် Agent အတွက် မလုံလောက်ကြောင်း ဖော်ပြနေပါသည်။

2025 ခုနှစ် S3 ဘလော့ဂ် "Amazon S3 တွင် Multi-tenant Access Control အတွက် ဒီဇိုင်းပုံစံများ" တွင် S3 Access Point ကို ထပ်မံရှင်းပြထားသည်။ ဆိုလိုသည်မှာ သင်သည် Virtual Network Access Point များစွာကို ဖန်တီးနိုင်ပြီး Access Point တစ်ခုစီအတွက် စိတ်ကြိုက် Access Point မူဝါဒကို စီစဉ်သတ်မှတ်နိုင်ပြီး Network Scheduling အဆင့်တွင် Multi-tenant အခြေအနေများအတွက် အချို့သောဖြေရှင်းနည်းများရှိသည်။

Agent Wonderland

စံပြ Agent Developer သည် AI Agent ကို တီထွင်သောအခါ၊ "Agent SDK + Storage + MaaS ဝန်ဆောင်မှု" ကို အခြေခံ၍ လုံးဝ Serverless Agent တစ်ခုကို တည်ဆောက်နိုင်သည်-

• Agent သည် လုံးဝ Serverless ဖြင့် လုပ်ဆောင်နိုင်သည်

• Vibe Coding နည်းလမ်းဖြင့် လက်ရှိထုတ်ကုန်စွမ်းဆောင်ရည်များကို ပေါင်းစပ်၍ Agent ကို တည်ဆောက်နိုင်သည်

• "ADK" ၏ Python Script ကိုသာ ထိန်းသိမ်းရန် လိုအပ်သည်

• Storage သည် Object Storage ကို အသုံးပြုသည်

• AI စွမ်းရည်သည် 豆包 (Dòubāo) ကို အသုံးပြုသည်

• သီအိုရီအရ ECS သို့မဟုတ် အခြား Instance-type ထုတ်ကုန်များ မရှိပါ

တစ်ချိန်တည်းမှာပင်၊ Storage သည် အောက်ပါစွမ်းရည်များကို ပေးစွမ်းရန် လိုအပ်သည်-

• Agent သည် Object Semantic Storage (ဖိုင်များကို သိမ်းဆည်းခြင်း) အမျိုးအစားတစ်ခု ရှိနိုင်ပြီး Multi-tenant Access စွမ်းရည်ကို ပေးစွမ်းနိုင်ပြီး သန်းပေါင်းများစွာမှ စတင်ကာ သန်းဘီလီယံအထိ တိုးချဲ့နိုင်သည်

• Agent သည် သုံးစွဲသူတစ်ဦးစီအတွက် သီးခြားနေရာ (လုပ်ငန်းများစွာကြားတွင်၊ လုပ်ငန်း သို့မဟုတ် UID သည် အမည်တူနိုင်သည်) ကို ပေးစွမ်းနိုင်သည်

• Agent သည် သုံးစွဲသူတစ်ဦးစီ၏ Bandwidth ကို တိုက်ရိုက်စီစဉ်သတ်မှတ်နိုင်ပြီး သုံးစွဲသူ Object ၏ စုစုပေါင်း Size ကန့်သတ်ချက်ကို စီစဉ်သတ်မှတ်နိုင်သည်

• Agent သည် သုံးစွဲသူအလိုက် ငွေတောင်းခံခြင်း၊ စောင့်ကြည့်ခြင်းနှင့် လေ့လာခြင်းတို့ကို ပြုလုပ်နိုင်သည်

• Agent သည် သုံးစွဲသူတစ်ဦးစီ၏ ဖိုင်များအတွက် Access မူဝါဒကို စီစဉ်သတ်မှတ်နိုင်သည်

Agent Bucket: AI Agent သို့ "Multi-tenant Native" မျိုးဗီဇကို ထည့်သွင်းခြင်း

ဤပြဿနာကို အခြေခံမှ ဖြေရှင်းရန်အတွက် ကျွန်ုပ်တို့သည် လုံးဝ Object Storage Paradigm အသစ်တစ်ခုကို အဆိုပြုသည်- Agent Bucket။ ၎င်း၏ အဓိကတီထွင်မှုမှာ ရိုးရာ "Bucket" နှင့် "Object" အကြားတွင် မူလအရင်းအမြစ်အဆင့်အသစ်တစ်ခုကို မိတ်ဆက်ပေးခြင်းဖြစ်သည်။ Object Collection။

ဤဒီဇိုင်း၏ အဓိကအယူအဆမှာ အလွန်ရိုးရှင်းသည်- သင်၏ End User တစ်ဦးစီအတွက် သီးသန့် ObjectSet တစ်ခုကို တွဲဖက်ပေးပါ။ ObjectSet ကို သုံးစွဲသူတစ်ဦးစီအတွက် သီးသန့်ဖန်တီးထားသော "Data Safe" သို့မဟုတ် "Cloud Personal Space" အဖြစ် သင်မြင်နိုင်သည်။ ၎င်းသည် ယုတ္တိနည်းအရ သင် (Developer) ၏ Bucket ပိုင်ဖြစ်သော်လည်း ရုပ်ပိုင်းဆိုင်ရာနှင့် စီမံခန့်ခွဲမှုအရ ၎င်းတွင် သီးခြား "ကိုယ်ပိုင်လက္ခဏာ" နှင့် "သက်တမ်း" ရှိသည်။Agent Bucket တစ်ခုချင်းစီသည် ObjectSet သန်း ၁၀၀ အထိ ထောက်ပံ့ပေးသောကြောင့် သုံးစွဲသူ သန်းပေါင်းများစွာအတွက် သီးခြားစီ သိုလှောင်နေရာများရှိသကဲ့သို့ အဆင်ပြေစွာ ဝန်ဆောင်မှုပေးနိုင်ပြီး သုံးစွဲသူအများအပြားအတွက် သိုလှောင်မှုစီမံခန့်ခွဲမှုနှင့်ပတ်သက်၍ စိတ်ပူစရာမလိုတော့ပါ။

ObjectSet ဒီဇိုင်း - Agent နှင့် အဆင်ပြေသော စွမ်းဆောင်ရည်

Agent Bucket တွင် ObjectSet သည် အလွှာတစ်ခုထပ်တိုးရုံသာမက သုံးစွဲသူအများအပြားအတွက် အခက်ခဲဆုံးလိုအပ်ချက်များကိုပါ အသုံးပြုရလွယ်ကူသော မူရင်းစွမ်းဆောင်ရည်များအဖြစ် ပြောင်းလဲပေးပါသည်။ ObjectSet အလွှာတွင် ဒေတာပိုင်ဆိုင်မှုကို ရှင်းရှင်းလင်းလင်းဖော်ပြပြီးနောက် ယခင်က အကောင်အထည်ဖော်ရန်ခက်ခဲသော စွမ်းဆောင်ရည်များစွာသည် အလိုအလျောက်ဖြစ်ပေါ်လာပါသည်။

• မူရင်းသီးခြားခွဲထားခြင်း- ObjectSet အလွှာတွင် သုံးစွဲသူတစ်ဦးစီအတွက် သီးခြား QPS၊ Bandwidth ကန့်သတ်ချက်များနှင့် Capacity ခွဲတမ်းများကို သတ်မှတ်နိုင်သည်။ ငွေပေးချေထားသော သုံးစွဲသူများ၏ အတွေ့အကြုံကို အာမခံနိုင်ပြီး အခမဲ့သုံးစွဲသူများ၏ ပုံမှန်မဟုတ်သော အပြုအမူများသည် အခြားသူများကို ထိခိုက်မည်မဟုတ်ပါ။ ၎င်းသည် အမှန်တကယ် ချို့ယွင်းချက်နယ်ပယ် သီးခြားခွဲထားခြင်းဖြစ်ပြီး "အိမ်နီးချင်းများ" အချင်းချင်း အနှောင့်အယှက်မဖြစ်စေတော့ပါ။

• မူရင်းခွင့်ပြုချက်- ObjectSet တစ်ခုစီတွင် သီးခြား Domain တစ်ခုရှိနိုင်သည်။ ဆိုလိုသည်မှာ သင်သည် သုံးစွဲသူ A အား သီးသန့်ဝင်ရောက်ခွင့်လိပ်စာ user-a.yourapp.com ကို ပေးနိုင်ပြီး သိုလှောင် Bucket ၏ Domain တစ်ခုလုံးကို ထုတ်ဖော်ရန် မလိုအပ်တော့ပါ။ ပို၍ပင် လိမ္မာပါးနပ်သော "သော့နှစ်ချောင်း" ဒီဇိုင်းရှိသည်- ပထမသော့မှာ Cloud ဝန်ဆောင်မှုပေးသူမှ ထုတ်ပေးသော ယာယီဝင်ရောက်ခွင့်လက်မှတ် (STS) ဖြစ်ပြီး Application အလွှာတွင် ဝင်ရောက်ခွင့်ကို ထိန်းချုပ်သည်; ဒုတိယသော့မှာ ObjectSet ၏ သီးခြား Domain ဖြစ်ပြီး Network အလွှာမှ ဝင်ရောက်ခွင့်တောင်းဆိုချက်များကို သုံးစွဲသူ၏ ဒေတာနေရာအတွင်း၌ သော့ခတ်ထားသည်။ ၎င်းသည် ဒေတာလုံခြုံရေးကို များစွာတိုးတက်စေသည်။

• မူရင်းစောင့်ကြည့်ခြင်း- စောင့်ကြည့်ရေး Dashboard တွင် Bucket တစ်ခုလုံး၏ အကျဉ်းချုပ်ဒေတာကိုသာ သင်မမြင်နိုင်တော့ပါ။ သင်သည် ObjectSet အလိုက် စောင့်ကြည့်ရေးဇယားများကို ခွဲခြမ်းစိတ်ဖြာနိုင်ပြီး မည်သည့်သုံးစွဲသူသည် ဝင်ရောက်ကြည့်ရှုမှုများစွာပြုလုပ်နေသည်ကို ရှင်းရှင်းလင်းလင်းသိရှိနိုင်ပြီး တိကျသောလုပ်ငန်းလည်ပတ်မှုနှင့် အကောင်းဆုံးဖြစ်အောင် ဆုံးဖြတ်ချက်များချနိုင်ပါသည်။

• မူရင်းစွမ်းဆောင်ရည် လျှော့ချခြင်း- ယခင်က Bucket အဆင့်တွင်သာ သတ်မှတ်နိုင်သော မူဝါဒများကို ယခုအခါ သုံးစွဲသူတစ်ဦးစီသို့ လျှော့ချနိုင်သည်။ အဆင့်အမျိုးမျိုးရှိ သုံးစွဲသူများအတွက် မတူညီသော ဒေတာသက်တမ်းကို သတ်မှတ်နိုင်သည် သို့မဟုတ် ObjectSet တစ်ခုစီအတွက် မတူညီသော Encryption သော့များကို အသုံးပြုနိုင်ပြီး ပိုမိုကောင်းမွန်ပြီး လုံခြုံသော ဒေတာစီမံခန့်ခွဲမှုကို ရရှိနိုင်သည်။

• မူရင်းတိုင်းတာခြင်း- သုံးစွဲသူတစ်ဦးစီသည် သိုလှောင်နေရာမည်မျှ အသုံးပြုထားသည်ကို သိလိုပါသလား။ သိုလှောင်မှုကုန်ကျစရိတ်ကို သုံးစွဲသူတစ်ဦးစီသို့ တိကျစွာ ခွဲဝေပေးလိုပါသလား။ ယခုအခါ အလွန်လွယ်ကူလာပါပြီ။ Agent Bucket သည် ObjectSet တစ်ခုစီ၏ Capacity နှင့် အသုံးပြုမှုကို အလိုအလျောက် စာရင်းပြုစုပေးသောကြောင့် သင်၏ ငွေတောင်းခံလွှာနှင့် ခွဲဝေမှုသည် ရှင်းလင်းပြတ်သားပါသည်။

• မူရင်းငွေတောင်းခံခြင်း- Developer များသည် ကုန်ကျစရိတ်ခွဲဝေမှုကို အလွယ်တကူ အကောင်အထည်ဖော်နိုင်ပြီး သိုလှောင်မှုမှ ဖြစ်ပေါ်လာသော ကုန်ကျစရိတ်များကို သုံးစွဲသူတစ်ဦးစီသို့ တိကျစွာ တွန်းပို့နိုင်သည်။ ဥပမာအားဖြင့် A, B, C စသည့် မတူညီသော သုံးစွဲသူများမှ အမှန်တကယ်ဖြစ်ပေါ်လာသော ကုန်ကျစရိတ်အချိုးအစားအပေါ်မူတည်၍ ကွဲပြားသော နှုန်းထားများ ကောက်ခံခြင်းဖြင့် Agent ၏ စီးပွားဖြစ်လုပ်ငန်းကို ဒေတာအထောက်အပံ့ပေးပါသည်။

• မူရင်း Capacity အကန့်အသတ်- Agent ၏ လုပ်ငန်းလည်ပတ်မှုကုန်ကျစရိတ်ကို ထိန်းချုပ်ရန်အတွက် ObjectSet တစ်ခုစီအတွက် Quota (Capacity အကန့်အသတ်) ကို သတ်မှတ်နိုင်သည်။ ကြိုတင်သတ်မှတ်ထားသော တန်ဖိုးသို့ရောက်ရှိပါက စနစ်သည် သုံးစွဲသူအသစ်များ ဖိုင်များထပ်မံထုတ်လုပ်ခြင်းကို ကန့်သတ်မည်ဖြစ်ပြီး သုံးစွဲသူအများအပြားအတွက် အရင်းအမြစ်အလွဲသုံးစားပြုမှုကို အရင်းအမြစ်မှ ရှောင်ရှားနိုင်မည်ဖြစ်သည်။

• မူရင်းဉာဏ်ရည်တု- Agent Bucket သည် Agent အား ရိုးရှင်းသော ဖိုင် "သိမ်းဆည်းခြင်းနှင့် ထုတ်ယူခြင်း" ကန့်သတ်ချက်မှ လွတ်မြောက်စေပြီး Object အား မူရင်းဉာဏ်ရည်တုကို ပေးကာ Agent ၏ တစ်နေရာတည်းတွင် တီထွင်ဖန်တီးမှုကို ပိုမိုထိရောက်စွာ ထောက်ပံ့ပေးပါသည်။ ObjectSet သည် Smart Indexing ကို တစ်ချက်နှိပ်ရုံဖြင့် ဖွင့်နိုင်ပြီး Agent အား မူရင်းနှင့် အဆင်ပြေသော Multimodal မေးခွန်းဖြေဆိုနိုင်စွမ်းကို ပေးကာ ရိုးရာ Object CRUD ၏ စက်ပိုင်းဆိုင်ရာ လုပ်ဆောင်ချက်များကို အစားထိုးနိုင်သည်; Agentself မုဒ်ကို တစ်ချက်နှိပ်ရုံဖြင့် ဖွင့်နိုင်ပြီး Vector၊ Knowledge၊ Model နှင့် Prompt တို့ကို ချိတ်ဆက်ကာ အထက်အလွှာ Agent Developer များအား အဓိကလုပ်ငန်း Workflow ဖန်တီးမှုအပေါ် အာရုံစိုက်နိုင်စေကာ ဉာဏ်ရည်တုမှ ငွေရှာနိုင်စွမ်းကို အပြည့်အဝထုတ်လွှတ်ပေးနိုင်သည်။

Application အရွယ်အစား အဆမတန်ကြီးထွားလာခြင်းကြောင့် ဖြစ်ပေါ်လာသော နည်းပညာဆိုင်ရာ စိန်ခေါ်မှုများ

Agent Bucket သည် ObjectSet ဟူသော မူရင်းအယူအဆကို မိတ်ဆက်ခြင်းဖြင့် Application Developer များအား သုံးစွဲသူ သန်းပေါင်းများစွာ၏ ဒေတာကို စီမံခန့်ခွဲရန်အတွက် လှပပြီး ထိရောက်သောနည်းလမ်းကို ပေးပါသည်။ သုံးစွဲသူတစ်ဦးစီ၏ ဒစ်ဂျစ်တယ်ပိုင်ဆိုင်မှုများကို ၎င်းတို့၏ သီးသန့် ObjectSet တွင် လုံခြုံစွာ သိမ်းဆည်းထားပြီး သီးခြားခွဲထားခြင်း၊ ငွေတောင်းခံခြင်းနှင့် ခွဲတမ်းစီမံခန့်ခွဲခြင်းတို့ကို သဘာဝအားဖြင့် အကောင်အထည်ဖော်ပါသည်။

Application အရွယ်အစား အလျင်အမြန်ကြီးထွားလာသည်နှင့်အမျှ Set အမြောက်အမြား၏ စီမံခန့်ခွဲမှုရှုပ်ထွေးမှု၊ သီးခြားခွဲထားရန်ခက်ခဲမှုနှင့် ရုပ်ပိုင်းဆိုင်ရာ အဟန့်အတားများသည် တစ်ပြိုင်နက်ပေါ်ပေါက်လာသည်-

• သုံးစွဲသူအမြောက်အမြားကို အဆင့်ခွဲ၍ စီမံခန့်ခွဲခြင်းဆိုင်ရာ ပြဿနာ- Application သည် မတူညီသောအဆင့်ရှိ သုံးစွဲသူအမြောက်အမြား၏ အရင်းအမြစ်များနှင့် လုပ်ဆောင်ချက်များကို ကွဲပြားစွာစီမံခန့်ခွဲရာတွင် သုံးစွဲသူ၏အဆင့်ခွဲခြားထားသော Metadata ကို ကိုယ်တိုင်ဒီဇိုင်းဆွဲပြီး အကောင်အထည်ဖော်ရန်လိုအပ်ပြီး Object သိုလှောင်မှုလုပ်ဆောင်ချက်ခလုတ်များနှင့် ချိတ်ဆက်ကာ Set ၏ မူရင်းအယူအဆတွင် Developer များအား သုံးစွဲသူအဆင့်ခွဲခြားခြင်းကို လှပစွာစီမံခန့်ခွဲနိုင်ရန် ကူညီပေးခြင်းသည် Application အကောင်အထည်ဖော်မှုကို အရှိန်မြှင့်ရန် အရေးကြီးပါသည်။- Single Cluster Capacity Bottleneck: Agent Bucket သည် ယုတ္တိဗေဒအရ အကန့်အသတ်မရှိ တိုးချဲ့နိုင်သော်လည်း ၎င်း၏ metadata ကို မူလအားဖြင့် single physical cluster တွင် သိမ်းဆည်းထားသည်။ Bucket အတွင်းရှိ object အရေအတွက်သည် ဘီလီယံ သို့မဟုတ် ထရီလီယံအထိရောက်ရှိသောအခါ single cluster ၏ physical capacity သည် ကျော်လွှား၍မရသော အကန့်အသတ်တစ်ခုဖြစ်လာသည်။

• Access Point Sharing ပြဿနာ- Agent ၏ လုပ်ငန်းအမျိုးမျိုးနှင့် ကြီးမားသော user အရေအတွက်သည် access point အတွက် လုံခြုံရေးဆိုင်ရာအန္တရာယ်များနှင့် ပေါက်ကွဲနိုင်ခြေကို ပိုမိုမြင့်မားစေသည်။ မတူညီသောလုပ်ငန်းများနှင့် အသုံးပြုသူများ၏ ကွဲပြားခြားနားမှုအပေါ်အခြေခံ၍ dynamic scheduling ကို မည်သို့လုပ်ဆောင်ရမည်နည်း၊ ကွဲပြားခြားနားသော လုံခြုံရေး၊ သီးခြားခွဲထုတ်ခြင်းနှင့် အရှိန်မြှင့်တင်နိုင်စွမ်းကို မည်သို့အကောင်အထည်ဖော်ရမည်နည်းသည် ခက်ခဲသောပြဿနာတစ်ခုဖြစ်သည်။

Set Tagging: အသုံးပြုသူအဆင့်ခွဲခြားခြင်းအတွက် Tagging စီမံခန့်ခွဲမှု

ObjectSet သည် မူလ tagging စီမံခန့်ခွဲမှုနည်းလမ်းကို ပံ့ပိုးပေးသောကြောင့် Agent developer များသည် set tagging စွမ်းရည်ကို အလွယ်တကူအသုံးပြု၍ အသုံးပြုသူအဆင့်ခွဲခြားခြင်းကို ပြီးမြောက်စေနိုင်သည်။ Developer များသည် သတ်မှတ်ထားသောအသုံးပြုသူအဆင့်တစ်ခုစီအတွက် tag တစ်ခုကို သတ်မှတ်နိုင်ပြီး tag တစ်ခုစီအတွက် မတူညီသော quota များနှင့် အင်္ဂါရပ်များကို ဖွင့်နိုင်သည်။ ဤ tag ကို အသုံးပြုထားသော ObjectSet အားလုံးသည် သက်ဆိုင်ရာ quota များနှင့် အင်္ဂါရပ်များကို အသုံးပြုမည်ဖြစ်သည်။ V1, V2, V3 အဆင့်သုံးဆင့်ကို ဥပမာအဖြစ် အသုံးပြု၍ ရှင်းပြပါမည်။

• V1: မူလအဆင့်၊ အခမဲ့အသုံးပြုသူများ၊ ObjectSet အားလုံး၏ မူလ tag၊ အများဆုံး 1GiB ဒေတာကို သိမ်းဆည်းရန် configure လုပ်နိုင်သည်၊ အများပြည်သူကွန်ရက်ဖြန့်ဝေမှုသည် 100mbps bandwidth ထက် မကျော်လွန်နိုင်ပါ၊ single-stream download speed ကို 1mbps သို့ ထိန်းချုပ်ထားသည်။

• V2: Entry-level အခပေးအဖွဲ့ဝင်များ၊ အများဆုံး 10GiB ဒေတာကို သိမ်းဆည်းရန် configure လုပ်နိုင်သည်၊ အများပြည်သူကွန်ရက်ဖြန့်ဝေမှုသည် 10gbps bandwidth ထက် မကျော်လွန်နိုင်ပါ၊ single-stream download speed ကို 10mbps သို့ ထိန်းချုပ်ထားသည်။

• V3: အဆင့်မြင့် အခပေးအဖွဲ့ဝင်များ၊ ကြီးမားသော သိုလှောင်မှုနှင့် အများပြည်သူကွန်ရက်ဖြန့်ဝေမှု quota များအပြင် အပိုအများပြည်သူကွန်ရက် weak network acceleration နှင့် high-performance medium acceleration စွမ်းရည်ကို ဖွင့်ရန်လည်း ပံ့ပိုးပေးသည်။

Agent developer များသည် မတူညီသောအသုံးပြုသူများ၏ မတူညီသော ဖွံ့ဖြိုးတိုးတက်မှုကာလများအတွက် V1/V2/V3 tagging ကို အသုံးပြု၍ ဤအသုံးပြုသူများအသုံးပြုနိုင်သော အရင်းအမြစ်များနှင့် တန်ဖိုးမြှင့်အင်္ဂါရပ်များကို လိုက်လျောညီထွေစွာ စီမံခန့်ခွဲနိုင်သည်။

Set Slice: ကြီးမားသောအသုံးပြုသူဒေတာများ မူလသီးခြားခွဲထုတ်ခြင်း

Agent Bucket တစ်ခုအတွင်းရှိ Set အရေအတွက်သည် သန်းပေါင်းများစွာအထိရောက်ရှိပြီး object အရေအတွက်သည် ဘီလီယံ သို့မဟုတ် ထရီလီယံအထိရောက်ရှိသောအခါ "single Bucket ရှိ metadata အားလုံးကို KV cluster တစ်ခုတွင် စုစည်းထားခြင်း" ဟူသောအချက်သည် capacity နှင့် performance နှစ်ခုလုံးအတွက် အန္တရာယ်ဖြစ်စေနိုင်သည်။

Set Slice သည် "ယုတ္တိဗေဒအရ ခွဲထုတ်ခြင်းမရှိ၊ ရုပ်ပိုင်းဆိုင်ရာ ခွဲထုတ်ခြင်း" ဟူသောအယူအဆကို ပေးသည်:

• ယုတ္တိဗေဒရှုထောင့်မှကြည့်လျှင် သင်သည် Agent Bucket တစ်ခုကိုသာ စီမံခန့်ခွဲနေဆဲဖြစ်သည်။

• ရုပ်ပိုင်းဆိုင်ရာအရ Set နှင့် Set အတွင်းရှိ object အမည်များ၏ အပိုင်းအခြားအရ metadata ကို Slice (အပိုင်းပိုင်း) များစွာအဖြစ် ပိုင်းခြားထားသည်။ Slice တစ်ခုစီကို မတူညီသော cluster များတွင် သိမ်းဆည်းနိုင်သည်၊ Set များစွာသည် သဘာဝအားဖြင့် သီးခြားခွဲထားပြီး single Set ကို အလျားလိုက် တိုးချဲ့နိုင်သည်။

Set Slice သည် ObjectSet စွမ်းရည်၏ နောက်ထပ်တိုးချဲ့မှုနှင့် အာမခံချက်ဖြစ်သည်။ ၎င်းသည် အောက်ခြေတွင် physical capacity ၏ အကန့်အသတ်မရှိ တိုးချဲ့နိုင်စွမ်းကို ဖြေရှင်းပေးပြီး အပေါ်ပိုင်း ObjectSet စီမံခန့်ခွဲမှုပုံစံ၏ တည်ငြိမ်မှုနှင့် ကိုက်ညီမှုကို သေချာစေသည်။

• စီမံခန့်ခွဲမှုနယ်နိမိတ် တည်ငြိမ်ခြင်း- Agent Bucket တစ်ခု၏ ဒေတာသည် physical cluster များစွာကို ဖြတ်ကျော်သွားလျှင်ပင် ObjectSet သည် ခွင့်ပြုချက်၊ quota၊ ငွေပေးချေမှုနှင့် စောင့်ကြည့်လေ့လာခြင်းအတွက် တစ်ခုတည်းသော အခြေခံယူနစ်ဖြစ်သည်။ Developer များသည် ObjectSet အတွက် configure လုပ်ထားသော မူဝါဒများ (ဥပမာ access control, capacity limit) သည် သက်ဆိုင်ရာ Slices အားလုံးတွင် အလိုအလျောက် အသက်ဝင်မည်ဖြစ်ပြီး အောက်ခြေဒေတာ၏ ဖြန့်ဖြူးမှုကို ဂရုစိုက်ရန်မလိုအပ်ပါ။

• Single Set ကို မျဉ်းဖြောင့်အတိုင်း တိုးချဲ့နိုင်ခြင်း- ObjectSet တစ်ခု၏ ဒေတာပမာဏသည် လျင်မြန်စွာ တိုးလာသောအခါ ၎င်း၏ဒေတာသည် Slices များစွာတွင် သဘာဝအတိုင်း ဖြန့်ဝေသွားမည်ဖြစ်သည်။ cluster တစ်ခုလုံး၏ တိုးချဲ့မှုနှင့်အတူ ObjectSet ၏ capacity သည် ချောမွေ့စွာနှင့် မျဉ်းဖြောင့်အတိုင်း တိုးလာမည်ဖြစ်သည်။ Developer များသည် ObjectSet ကိုယ်တိုင်ကို ခွဲထုတ်ခြင်း သို့မဟုတ် ရွှေ့ပြောင်းခြင်းကဲ့သို့သော ဖျက်ဆီးခြင်းဆိုင်ရာ လုပ်ဆောင်ချက်များကို လုပ်ဆောင်ရန်မလိုအပ်ပါ။

• Cross-Set အရင်းအမြစ် သီးခြားခွဲထုတ်ခြင်း- မတူညီသော အပိုင်းအခြားရှိ object များကို မတူညီသော physical cluster များတွင် ဖြန့်ဝေခြင်းဖြင့် SetSlice သည် ပိုမိုမြင့်မားသော အတိုင်းအတာရှိသော အရင်းအမြစ် သီးခြားခွဲထုတ်ခြင်းကို အကောင်အထည်ဖော်သည်။ ObjectSet ၏ quota စီမံခန့်ခွဲမှုနှင့် ပေါင်းစပ်ခြင်းဖြင့် "super large" ObjectSet တစ်ခု၏ ဒေတာတိုးလာမှုသည် single cluster ၏ အရင်းအမြစ်အားလုံးကို ညှစ်ထုတ်ခြင်းကို ထိရောက်စွာ တားဆီးနိုင်ပြီး အခြား ObjectSet များ၏ တည်ငြိမ်မှုကို ထိခိုက်စေကာ စုစုပေါင်း capacity အန္တရာယ်ကို ထိန်းချုပ်နိုင်စေသည်။- ယုတ္တိဗေဒဆိုင်ရာ ညီညွတ်မှုနှင့် လိုက်ဖက်ညီမှု- လုပ်ငန်းနှင့် developer များအတွက်၊ အောက်ခံတွင် Slice မည်မျှပင်ရှိစေကာမူ၊ ၎င်းတို့သည် ယုတ္တိဗေဒအရ ညီညွတ်သော Agent Bucket တစ်ခုကို အမြဲရင်ဆိုင်နေရသည်။ Bucket၊ ObjectSet နှင့် object များအတွက် လုပ်ဆောင်မှုနည်းလမ်းအားလုံးသည် မပြောင်းလဲဘဲရှိနေပြီး၊ အပေါ်ပိုင်းအပလီကေးရှင်းများအတွက် ရုပ်ပိုင်းဆိုင်ရာ တိုးချဲ့မှုကို လုံးဝပွင့်လင်းမြင်သာစေသည်။

Set AccessPoint- သုံးစွဲသူတစ်ဦးစီ၏ ဝင်ရောက်မှုအမှတ်ကို သီးခြားခွဲထားပါ

Agent Bucket သည် ObjectSet တစ်ခုစီအတွက် သီးခြားဝင်ရောက်မှုအမှတ် (သီးခြား domain name) ကိုဖွင့်ရန် ပံ့ပိုးပေးပြီး၊ ဝင်ရောက်မှုအမှတ်တွင် ကွဲပြားခြားနားသော လုံခြုံရေး၊ သီးခြားခွဲထားမှုနှင့် အရှိန်မြှင့်တင်မှုစွမ်းရည်များကို တိုးချဲ့ပေးသည်။ ဤအတွက်ကြောင့် စနစ်သည် သန်းပေါင်းများစွာသော သီးခြားဝင်ရောက်မှုအမှတ် ချိန်ညှိမှုနှင့် ကွဲပြားခြားနားသော ဖွဲ့စည်းမှုစွမ်းရည်ကို ပံ့ပိုးပေးရန်လိုအပ်သည်။

သီးခြားဝင်ရောက်မှု domain name {$apid}။tos-objectset-ap.volces.com- အဆင့်နှစ်ဆင့် လုံခြုံရေးကာကွယ်မှု

• ပထမအဆင့် Obscurity (ဝှက်ထားနိုင်မှု)- User/ObjectSet တစ်ခုစီအတွက် သီးခြား subdomain၊ apid သည် entropy မြင့်မားသော hash ဖြစ်ပြီး၊ တိုက်ဆိုင်မှုဖြစ်နိုင်ခြေ အလွန်နည်းပါးသည်။ ဝင်ရောက်မှု domain name ရှုထောင့်မှ သတ်မှတ်ထားသော user ဝင်ပေါက်ကို ခန့်မှန်းရန်နှင့် အကုန်စုံအောင်ရှာဖွေရန် မဖြစ်နိုင်ပါ။

• ဒုတိယအဆင့် Containment (စုစည်းနိုင်မှု)- Agent developer များသည် ObjectSet အဆင့် ဝင်ရောက်ခွင့်ကို ဖြန့်ဝေရန် sts ကို အသုံးပြုသည်။ sts ပေါက်ကြားသွားလျှင်ပင်၊ ၎င်း၏ ဝင်ရောက်ခွင့်အတိုင်းအတာကို သတ်မှတ်ထားသော ObjectSet ၏ အကန့်အသတ်ရှိသော သက်တမ်းအတွင်း ထိန်းချုပ်နိုင်သည်။

Heuristic ချိန်ညှိမှုစနစ်- သန်းပေါင်းများစွာသော domain name ချိန်ညှိမှု မဟာဗျူဟာတွက်ချက်မှု

• user/ObjectSet:tag တစ်ခုစီအတွက် ကွဲပြားခြားနားသော ဝင်ရောက်မှု မဟာဗျူဟာ

• user/ObjectSet အများအပြားကို မတူညီသော အများပြည်သူကွန်ရက် ဝင်ပေါက်များတွင် အလိုအလျောက် ခွဲထုတ်ထားပြီး၊ တစ်ခုတည်းသော ဝင်ပေါက်ချို့ယွင်းမှုသည် ထိန်းချုပ်ထားသော user အရေအတွက်ကို ထိခိုက်စေသည်။

• ဒေသအားလုံးတွင် ပြောင်းလွယ်ပြင်လွယ် ချိန်ညှိနိုင်မှု၊ မည်သည့်တစ်ခုတည်းသော ဝင်ပေါက်ချို့ယွင်းမှု/ဝန်ပိုမှုသည် အသွားအလာကို အလိုအလျောက် ထုပ်ပိုးပြီး ရွှေ့ပြောင်းခြင်းကို ပြီးမြောက်စေသည်။

• အများပြည်သူကွန်ရက် အရှိန်မြှင့်ဖြန့်ဝေမှု အမျိုးအစား user များအတွက်၊ အများပြည်သူကွန်ရက် အရှိန်မြှင့်တင်မှု tag ကို ထည့်သွင်းပြီး၊ အရှိန်မြှင့်တင်မှု ဝင်ပေါက်ကို အလိုအလျောက် ချိန်ညှိပါ။

• အများပြည်သူကွန်ရက် အန္တရာယ်ရှိသော အမျိုးအစား user များအတွက်၊ အန္တရာယ် tag ကို ထည့်သွင်းပြီး၊ အများပြည်သူကွန်ရက် သီးခြားခွဲထားမှု ဝင်ပေါက်ကို အလိုအလျောက် ချိန်ညှိပြီး၊ အများပြည်သူကွန်ရက် bandwidth ခွဲတမ်းကို လျှော့ချပါ။

• အတွင်းပိုင်းကွန်ရက် ဖြတ်ကျော်ဒိုမိန်း အမျိုးအစား user များအတွက်၊ ဖြတ်ကျော်ဒိုမိန်း tag ကို ထည့်သွင်းပြီး၊ အတွင်းပိုင်းကွန်ရက် သီးသန့်လိုင်း အရှိန်မြှင့်လမ်းကြောင်းကို အလိုအလျောက် ချိန်ညှိပါ။

• ဒေသတွင်း အရှိန်မြှင့်စက် user များအတွက်၊ အရှိန်မြှင့်စက် tag ကို ထည့်သွင်းပြီး၊ ဒေသတွင်း အရှိန်မြှင့်စက်ကို အလိုအလျောက် တပ်ဆင်ပါ။

ပရိုဂရမ်ရေးသားခြင်း လက်ထောက်မှ AI Cloud Drive အထိ၊ Agent Bucket ၏ အကန့်အသတ်မဲ့ ဖြစ်နိုင်ချေများ

Agent Bucket သည် Agent အတွက် ပြီးပြည့်စုံသော ဖြေရှင်းနည်းများကို ပေးစွမ်းပြီး၊ ObjectSet ၏ ဒီဇိုင်းအသုံးချမှုမြင်ကွင်းသည် ဤမျှသာမဟုတ်ပါ။ ၎င်းသည် ကြီးမားသော terminal user များအတွက် ဝန်ဆောင်မှုပေးရန်လိုအပ်သည့် အပလီကေးရှင်းအားလုံးသို့ အလွယ်တကူ တိုးချဲ့နိုင်သည်-

• ကုဒ်သိုလှောင်ရုံ- ယခင်က၊ ကုမ္ပဏီများ သို့မဟုတ် တစ်ဦးချင်းစီသည် cloud တွင် ကုဒ်ကို လက်ခံထားသောအခါ၊ အကောင့်ခွဲခြားခြင်းနှင့် ခွင့်ပြုချက်ထိန်းချုပ်မှုကို ရရှိရန်အတွက် object သိုလှောင်မှုအပေါ်တွင် "ငှားရမ်းသူစနစ်" အလွှာတစ်ခုကို တည်ဆောက်ရန် လိုအပ်ပါသည်။ ယခုအခါ၊ developer တစ်ဦးစီအတွက် သီးသန့် ObjectSet တစ်ခုကို ခွဲဝေပေးနိုင်ပြီး၊ ကုဒ်သိုလှောင်ရုံ၊ တည်ဆောက်မှုရလဒ်များနှင့် မှီခိုမှုများကို တစ်စုတစ်စည်းတည်း စုစည်းနိုင်သည်။ Agent Skills သည် ObjectSet နှင့် သဘာဝအားဖြင့် လိုက်လျောညီထွေရှိပြီး၊ Skills တင်ခြင်းနှင့် ဒေါင်းလုဒ်ဖြန့်ဝေခြင်းကို ObjectSet မှတစ်ဆင့် ခိုင်မာသော သီးခြားခွဲထားမှုကို ပေးစွမ်းပြီး၊ Agent လုပ်ဆောင်ချိန်တွင် အနှောင့်အယှက်ဖြစ်ခြင်းကို ရှောင်ရှားနိုင်သည်။

• လုပ်ငန်းဓာတ်ပုံအယ်လ်ဘမ် cloud drive- ရိုးရာဓာတ်ပုံအယ်လ်ဘမ် သို့မဟုတ် cloud drive ဝန်ဆောင်မှုများသည် သုံးစွဲသူများ၏ ဓာတ်ပုံအားလုံးကို bucket တစ်ခုတည်းတွင် ရောနှောထားလေ့ရှိပြီး၊ သုံးစွဲသူများကို ခွဲခြားရန်အတွက် prefix ကို အသုံးပြုသည်။ ၎င်းသည် စီမံခန့်ခွဲရန် ရှုပ်ထွေးရုံသာမက "အိမ်နီးချင်းအကျိုးသက်ရောက်မှု" ကိုလည်း ဖြစ်ပေါ်စေနိုင်သည်။ ObjectSet ကိုအခြေခံ၍ သုံးစွဲသူတစ်ဦးစီ၏ ဓာတ်ပုံများနှင့် ဗီဒီယိုများသည် သက်ဆိုင်ရာ Set များတွင် ကျရောက်ပြီး၊ ဝင်ရောက်မှုအထွတ်အထိပ်များသည် တစ်ခုနှင့်တစ်ခု အနှောင့်အယှက်မဖြစ်စေဘဲ၊ သုံးစွဲသူတစ်ဦးစီအတွက် စွမ်းရည်ကန့်သတ်ချက်များ၊ အရန်ကူးယူခြင်း မဟာဗျူဟာများနှင့် ကုဒ်ဝှက်ခြင်းနည်းလမ်းများကို သတ်မှတ်နိုင်ပြီး၊ "လူတိုင်းတွင် လုံခြုံပြီး ထိန်းချုပ်နိုင်သော cloud ဓာတ်ပုံအယ်လ်ဘမ်" တစ်ခုရှိကြောင်း အမှန်တကယ် သေချာစေနိုင်သည်။

• Hadoop data warehouse- လုပ်ငန်း data warehouse တွင်၊ မတူညီသော လုပ်ငန်းလိုင်းများနှင့် မတူညီသော database များသည် အရင်းအမြစ်များကို တူညီသောအောက်ခံ သိုလှောင်မှုတွင် မျှဝေလေ့ရှိသည်။ database တစ်ခုစီကို ObjectSet တစ်ခုအဖြစ် မြေပုံဆွဲခြင်းဖြင့်၊ ကုမ္ပဏီများသည် သီးခြားခွဲထားခြင်းနှင့် ခွဲတမ်းထိန်းချုပ်မှုကို တူညီသော သိုလှောင်မှုအပေါ်တွင် အကောင်အထည်ဖော်နိုင်သည်။ အထူးသဖြင့် ObjectSet သည် TOS တွင် နောက်ထပ်ခွင့်ပြုချက်အလွှာတစ်ခုကို ပေးစွမ်းပြီး၊ လက်ရှိ Proton on TOS ကို မပြောင်းလဲဘဲ၊ TOS တွင် သိမ်းဆည်းထားသော Database နှင့် Tables အတွက် သီးခြားခွဲထားခြင်းနှင့် ခွင့်ပြုချက်ထိန်းချုပ်မှုကို ပေးစွမ်းသည်။ - မော်ဒယ်လ် လက်ခံကျင်းပခြင်း ပလက်ဖောင်း- ကြီးမားသော မော်ဒယ်လ် လက်ခံကျင်းပခြင်း အခြေအနေများတွင်၊ မော်ဒယ်လ်တစ်ခုစီသည် ကြီးမားရုံသာမက မတူညီသော ဗားရှင်းများ၊ အလေးချိန်များနှင့် အကြောင်းပြချက်ဆိုင်ရာ ဖွဲ့စည်းမှုပုံစံများနှင့်လည်း သက်ဆိုင်နိုင်သည်။ မော်ဒယ်လ်တစ်ခုစီအတွက် ObjectSet တစ်ခုကို ဖန်တီးခြင်းသည် မော်ဒယ်လ်၏ အလေးချိန်များ၊ Tokenizer၊ ဖွဲ့စည်းမှုပုံစံဖိုင်များနှင့် သက်ဆိုင်ရာ အကဲဖြတ်ဒေတာများကို တူညီသောနေရာတွင် ထုပ်ပိုးပြီး လက်ခံကျင်းပနိုင်စေပါသည်။ လုပ်ငန်းလည်ပတ်မှုဘက်မှ မတူညီသော မော်ဒယ်လ်များအတွက် ကွဲပြားခြားနားသော ကုဒ်ဝှက်စနစ်မူဝါဒများ၊ အရန်ကူးယူခြင်း မူဝါဒများနှင့် bandwidth ထိန်းချုပ်မှုတို့ကို သတ်မှတ်နိုင်ပြီး မော်ဒယ်လ်တစ်ခုစီ၏ အမှန်တကယ်အသုံးပြုမှုကုန်ကျစရိတ်ကို မူရင်းတိုင်းတာမှုစွမ်းရည်များမှတစ်ဆင့် စာရင်းအင်းပြုလုပ်နိုင်ပြီး မော်ဒယ်လ်အတိုင်းအတာအလိုက် ငွေတောင်းခံခြင်းနှင့် အရင်းအမြစ်စီမံခန့်ခွဲမှုအတွက် အခြေခံအုတ်မြစ်ကို ပံ့ပိုးပေးပါသည်။

• ဒေတာ SaaS ဝန်ဆောင်မှု- ကြီးမားသော အသုံးပြုသူများအတွက် ဒေတာဖြန့်ဝေရေးပလက်ဖောင်းများသည် ဒေတာပေးသွင်းသူများစွာနှင့် တစ်ပြိုင်နက် ချိတ်ဆက်ရန်လိုအပ်ပြီး သက်ဆိုင်ရာ ဒေတာနယ်နိမိတ်များ ရှင်းလင်းကြောင်း သေချာစေရန်နှင့် "အိုးကြီးတစ်လုံးက လူတိုင်းကို နှေးကွေးစေသည်" ဟူသော စွမ်းဆောင်ရည်အန္တရာယ်ကို ရှောင်ရှားရန်လိုအပ်သည်။ Agent Bucket ၏အကူအညီဖြင့် ဒေတာပေးသွင်းသူတိုင်းသည် ၎င်းတို့၏ကိုယ်ပိုင် ObjectSet ကို ပိုင်ဆိုင်နိုင်ပြီး မူရင်းဒေတာနှင့် ပြုပြင်ထားသောရလဒ်များကို စီမံခန့်ခွဲနိုင်ကာ သီးခြားဒိုမိန်းအမည်များနှင့် bandwidth၊ QPS ခွဲတမ်းများမှတစ်ဆင့် မတူညီသော ပေးသွင်းသူများအတွက် ကွဲပြားခြားနားသော ဝန်ဆောင်မှုအာမခံချက်များနှင့် ကန့်သတ်ချက်များကို အကောင်အထည်ဖော်နိုင်ပြီး "ပလက်ဖောင်းတစ်ခု၊ ပေးသွင်းသူများစွာ၊ တစ်ဦးနှင့်တစ်ဦး သီးခြားစီရှိပြီး ထိန်းချုပ်နိုင်သော ပူးပေါင်းဆောင်ရွက်မှု" ဒေတာဖြန့်ဝေရေး အခြေခံအဆောက်အအုံကို အကောင်အထည်ဖော်နိုင်ပါသည်။

Reference:

• https://aws.amazon.com/cn/blogs/apn/partitioning-and-isolating-multi-tenant-saas-data-with-amazon-s3/

• https://aws.amazon.com/cn/blogs/storage/design-patterns-for-multi-tenant-access-control-on-amazon-s3/