Agent Bucket: Trilijonų lygių Agent gimtoji saugykla

Šiandien, kai AI Agent'ai dygsta kaip grybai po lietaus, kūrėjai precedento neturinčiu greičiu kuria išmaniųjų programų, kupinų vaizduotės. Nuo programavimo asistentų, kurie gali padėti jums rašyti kodą, iki kūrybinių įrankių, kurie gali sukurti filmą iš vieno sakinio, iki asmeninių išmaniųjų asistentų, kurie visada pasiruošę, Agent'ai iš naujo formuoja mūsų sąveiką su skaitmeniniu pasauliu. Už šios bangos vis labiau aiškėja bendras sutarimas: naudojant Serverless architektūrą (pvz., Lambda), didelius kalbos modelius (LLM) ir debesų saugyklą (pvz., S3, TOS), kartu su Vibe Coding, bet kas gali greitai susikurti savo AI Agent per 30 minučių.

Nuo „veikia“ iki „gerai veikia“, Agent kūrėjams vis dar reikia įveikti sunkumus pereinant nuo „žaislų“ prie „gamybos lygio programų“. Verslui plečiantis į didžiulį skaičių vartotojų, kūrėjai turi susidurti su itin sudėtingu iššūkiu: kaip sukurti išsamų saugojimo sprendimą didžiuliam galutinių vartotojų skaičiui objektų saugykloje? Daugumai kūrėjų tai yra ne tik techninis barjeras, bet ir praraja, trukdanti Agent platinimui dideliu mastu. Agent Bucket siekia visiškai supaprastinti daugiabučių sistemų kūrimo procesą ir suteikti patogesnes Agent galimybes per AI gimtąją saugyklos dizainą.

Kai įplūsta šimtai milijonų vartotojų, tradicinės objektų saugyklos „nebepakanka“

Įsivaizduokite, kad sukūrėte populiarią AIGC programą. Kiekvienas vartotojas generuos ir saugos daugybę nuotraukų, vaizdo įrašų ir laikinų failų. Kaip kūrėjas, natūraliai pasirinksite brandžias ir išplečiamas objektų saugojimo paslaugas, tokias kaip S3 ir TOS. Bet štai problema: kaip valdyti duomenis didžiuliam vartotojų skaičiui?

2022 m. S3 tinklaraštyje „Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3“ aprašomi du būdai: „Kiekvienas nuomininkas naudoja atskirą S3 kaušą“ ir „Bendras S3 kaušas, atskirtas pagal prefiksą“:

• Sukurkite atskirą „kaušą“ (Bucket) kiekvienam vartotojui: tai įmanoma, kai vartotojų skaičius yra mažas, tačiau kai vartotojų skaičius išauga iki dešimčių tūkstančių ar milijonų, kaušų skaičius greitai sprogsta, o valdymo sąnaudos ir išteklių apribojimai tampa nepakeliami. S3 suteikia iš viso 10 000 kaušų kvotą visam regionui, tačiau populiarioms AI galimybėms 10 000 toli gražu nepakanka.

• Atskirkite vartotojus tame pačiame kauše naudodami „prefiksą“: tai tapo pagrindiniu sprendimu. Pavyzdžiui, vartotojo A failai prasideda user-a/, o vartotojo B - user-b/, tarsi valdytumėte failus kompiuteryje naudodami aplankus. Tačiau objektų saugykloje nėra gimtųjų aplankų, šis sprendimas atskiria kelis nuomininkus per „bendrą prefiksą“ (Prefix) „K-V“ saugojimo sistemoje.

Šis „kaušo“ arba „prefikso“ pagrindu sukurtas sprendimas buvo plačiai naudojamas pastarąjį dešimtmetį. Tačiau yra šių problemų:

• Daugiabučių izoliacija: visų vartotojų duomenys yra sumaišyti tame pačiame kauše, o neįprastas didelio dažnio vieno vartotojo lankymasis gali paveikti visus kitus vartotojus, sukeldamas „kaimynų efektą“. Apie našumo izoliaciją ir gedimų izoliaciją negali būti nė kalbos.

• Teisių valdymas: sudėtinga teisių politika (IAM Policy) yra sunku prižiūrėti, lengva padaryti konfigūracijos klaidų, dėl kurių vartotojo duomenys gali būti netyčia pasiekiami, ypač kai reikia sąveikauti su kitomis debesų paslaugomis, rizika yra didesnė.

• Aiškios sąnaudos: sunku tiksliai žinoti, kiek saugyklos vietos sunaudojo kiekvienas vartotojas ir kiek srauto mokesčių buvo sugeneruota. Kai norite apmokestinti mokančius vartotojus pagal naudojimą, atsiskaitymas ir matavimas tampa painiava.

  

2025 m. S3 tinklaraštyje „Design patterns for multi-tenant access control on Amazon S3“ toliau aiškinamas S3 Access Point. Tai reiškia, kad galima sukurti kelis virtualius tinklo prieigos taškus ir kiekvienam prieigos taškui sukonfigūruoti pritaikytą prieigos taško politiką, o tinklo planavimo lygiu yra keletas sprendimų daugiabučių scenarijams.

Agent Wonderland

Idealus Agent kūrėjas, kurdamas AI Agent, gali sukurti visiškai serverless Agent, pagrįstą „Agent SDK + saugykla + MaaS paslauga“:

• Agent gali veikti visiškai serverless

• Agent galima sukurti derinant esamas produkto galimybes Vibe Coding būdu

• Tereikia prižiūrėti „ADK“ python scenarijų

• Saugykla naudoja objektų saugyklą

• AI galimybės naudoja 豆包 (Doubao)

• Teoriškai nėra ECS ar kitų instancijos tipo produktų

Be to, saugykla turi suteikti šias galimybes:

• Agent gali turėti objektų semantikos saugyklą (failams saugoti), suteikiančią daugiabučių prieigos galimybę, pradedant nuo milijono ir išplečiant iki šimtų milijonų

• Agent gali suteikti kiekvienam vartotojui nepriklausomą erdvę (tarp kelių verslų, verslai arba uid gali turėti tą patį pavadinimą)

• Agent gali tiesiogiai konfigūruoti kiekvieno vartotojo pralaidumą, konfigūruoti bendrą vartotojo objekto dydžio limitą

• Agent gali atsiskaityti, stebėti ir stebėti pagal vartotoją

• Agent gali konfigūruoti kiekvieno vartotojo failo prieigos politiką

Agent Bucket: įliekite „daugiabučių gimtąjį“ geną į AI Agent

Siekdami iš esmės išspręsti šią problemą, siūlome visiškai naują objektų saugyklos paradigmą – Agent Bucket. Pagrindinė jo naujovė yra naujo gimtojo išteklių lygmens įvedimas tarp tradicinio „bucket“ ir „objekto“: objektų rinkinys.

Pagrindinė šio dizaino idėja yra itin paprasta: kiekvienam jūsų galutiniam vartotojui priskirkite išskirtinį ObjectSet. Galite įsivaizduoti ObjectSet kaip „duomenų seifą“ arba „debesies asmeninę erdvę“, sukurtą specialiai kiekvienam vartotojui. Logiškai jis priklauso jūsų (kūrėjo) Bucket, tačiau fiziškai ir valdymo prasme jis turi savo nepriklausomą „asmenybę“ ir „gyvavimo ciklą“.Agent Bucket kiekvienas kaušas palaiko 100 milijonų ObjectSet, o tai reiškia, kad galite patogiai aptarnauti šimtus milijonų galutinių vartotojų, tarsi kiekvienas galutinis vartotojas "gyventų" atskiroje saugyklos erdvėje, ir jums nebereikės sukti galvos dėl daugelio nuomininkų saugyklos valdymo.

ObjectSet dizainas – Agentams draugiškos galimybės

Agent Bucket ObjectSet yra ne tik papildomas lygmuo, bet ir paverčia sudėtingiausius daugelio nuomininkų scenarijų poreikius paruoštomis naudoti vietinėmis galimybėmis. Kai duomenų nuosavybės teisė yra aiškiai apibrėžta ObjectSet lygiu, daugybė anksčiau sunkiai įgyvendinamų galimybių tampa savaime suprantamais dalykais.

• Vietinė izoliacija: ObjectSet lygiu galite nustatyti atskirus QPS, pralaidumo apribojimus ir talpos kvotas kiekvienam vartotojui. Mokamų vartotojų patirtis gali būti užtikrinta, o nemokamų vartotojų neįprastas elgesys neturės įtakos kitiems. Tai yra tikra gedimų srities izoliacija, leidžianti "kaimynams" netrukdyti vieni kitiems.

• Vietinės teisės: kiekvienas ObjectSet gali turėti atskirą domeną. Tai reiškia, kad galite suteikti vartotojui A išskirtinį prieigos adresą user-a.yourapp.com, o ne atskleisti visą saugyklos kaušo domeną. Dar sumaniau yra "dviejų spynų" dizainas: pirmoji spyna yra debesų paslaugų teikėjo išduotas laikinas prieigos kredencialas (STS), kuris kontroliuoja prieigos teises programos lygiu; antroji spyna yra atskiras ObjectSet domenas, kuris tinklo lygiu užrakina prieigos užklausas vartotojo duomenų erdvėje. Tai labai padidina duomenų saugumą.

• Vietinis stebėjimas: stebėjimo prietaisų skydelyje galite matyti ne tik visos kaušo apžvalgos duomenis. Galite suskaidyti stebėjimo diagramas pagal ObjectSet, aiškiai suprasdami, kuris galutinis vartotojas atlieka daug prieigų, kad galėtumėte priimti tikslius veiklos ir optimizavimo sprendimus.

• Vietinių galimybių perkėlimas žemyn: strategijos, kurias anksčiau buvo galima nustatyti tik kaušo lygiu, dabar gali būti perkeltos žemyn kiekvienam vartotojui. Galite nustatyti skirtingus duomenų gyvavimo ciklus skirtingų lygių vartotojams arba naudoti skirtingus šifravimo raktus kiekvienam ObjectSet, kad pasiektumėte smulkesnį ir saugesnį duomenų valdymą.

• Vietinis matavimas: norite sužinoti, kiek saugyklos vietos naudoja kiekvienas vartotojas? Norite tiksliai paskirstyti saugyklos išlaidas kiekvienam vartotojui? Dabar tai tampa lengva. Agent Bucket automatiškai statistiškai įvertins kiekvieno ObjectSet talpą ir naudojimą, kad jūsų atsiskaitymas ir paskirstymas būtų aiškūs.

• Vietinis atsiskaitymas: kūrėjai gali lengvai įgyvendinti išlaidų paskirstymą ir tiksliai perkelti saugyklos išlaidas kiekvienam galutiniam vartotojui. Pavyzdžiui, diferencijuotai apmokestinkite pagal skirtingų vartotojų A, B ir C faktines išlaidų proporcijas, kad suteiktumėte duomenų palaikymą Agento komercializavimui.

• Vietinis talpos apribojimas: norėdami kontroliuoti Agento veiklos sąnaudas, galite nustatyti kvotą (talpos apribojimą) kiekvienam ObjectSet. Pasiekus iš anksto nustatytą vertę, sistema apribos vartotojo galimybę toliau generuoti naujus failus, kad iš esmės būtų išvengta išteklių piktnaudžiavimo daugelio nuomininkų scenarijuose.

• Vietinis intelektas: Agent Bucket leidžia Agentui peržengti tradicinio paprasto failų "saugojimo ir gavimo" apribojimus, suteikiant Object vietinį intelektą ir efektyviau palaikant Agento vieno langelio kūrimą. ObjectSet gali vienu spustelėjimu įjungti intelektualų indeksavimą, kad Agentui būtų suteiktos vietinės draugiškos daugiarūšės klausimų ir atsakymų galimybės, pakeičiančios mechanines tradicinio Object CRUD operacijas; jis netgi palaiko vienu spustelėjimu įjungti Agentself režimą, sujungiant vektorius, žinias, modelius ir raginimus, kad tiesiogiai atskleistų scenarijais pagrįstas sub-Agent funkcijas, leidžiančias aukštesnio lygio Agento kūrėjams sutelkti dėmesį į pagrindinio verslo darbo eigos kūrimą ir visiškai išlaisvinti intelektualaus monetizavimo efektyvumą.

Techniniai iššūkiai, kuriuos kelia spartus programų masto augimas

Agent Bucket, įvesdamas vietinę ObjectSet koncepciją, suteikia programų kūrėjams elegantišką ir efektyvų būdą valdyti šimtų milijonų galutinių vartotojų duomenis. Kiekvieno vartotojo skaitmeninis turtas yra saugiai saugomas jam skirtame ObjectSet, natūraliai įgyvendinant izoliaciją, atsiskaitymą ir kvotų valdymą.

Sparčiai plečiantis programų mastui, kartu atsiranda didžiulis Set valdymo sudėtingumas, izoliacijos sunkumai ir fiziniai apribojimai:

• Didžiulio vartotojų kiekio suskirstymo į lygius valdymo problema: kai programa diferencijuotai valdo didelį kiekį skirtingų lygių vartotojų išteklių ir funkcijų, ji turi pati sukurti ir įgyvendinti vartotojų suskirstymo į lygius metaduomenis ir susieti objektų saugyklos funkcijų jungiklius. Pagalba kūrėjams elegantiškai valdyti vartotojų suskirstymą į lygius Set vietinės koncepcijos pagrindu yra svarbi siekiant paspartinti programos įgyvendinimą.- Vieno klasterio talpos apribojimai: Nors Agent Bucket logiškai gali būti neribotai plečiamas, jo metaduomenys pagal numatytuosius nustatymus saugomi viename fiziniame klasteryje. Kai bendras objektų skaičius kaupe pasiekia šimtus milijardų ar net trilijonus, vieno klasterio fizinė talpa tampa neįveikiama riba.

• Prieigos taško bendrinimo problema: Agentų verslo įvairovė ir didžiulis vartotojų skaičius kelia didesnę saugumo riziką ir sprogimo spindulį pačiam prieigos taškui. Kaip dinamiškai planuoti pagal didelį skaičių skirtingų verslų ir vartotojų skirtumus, kad būtų pasiektas diferencijuotas saugumas, izoliavimas ir pagreitis, tampa sunkumu.

Set Tagging: Etiketėmis pagrįstas vartotojų klasifikavimas

ObjectSet suteikia natūralų etiketėmis pagrįstą valdymo būdą, leidžiantį Agentų kūrėjams lengvai naudoti set tagging galimybes, kad užbaigtų vartotojų klasifikavimo valdymą; kūrėjai gali priskirti kiekvieną apibrėžtą vartotojo lygį atitinkamai žymai (tag), ir įjungti skirtingas kvotas ir funkcijas kiekvienai žymai, visi ObjectSet, pažymėti šia žyma, pritaikys atitinkamas kvotas ir funkcijas. Pavyzdžiui, su trimis lygiais V1, V2 ir V3:

• V1: Numatytasis lygis, nemokami vartotojai, numatytoji visų ObjectSet žyma, gali būti sukonfigūruota saugoti daugiausia 1GiB duomenų, viešojo tinklo platinimas negali viršyti 100mbps pralaidumo, vieno srauto atsisiuntimo greitis kontroliuojamas iki 1mbps;

• V2: Pradinis mokamas narys, sukonfigūruotas saugoti daugiausia 10GiB duomenų, viešojo tinklo platinimas negali viršyti 10gbps pralaidumo, vieno srauto atsisiuntimo greitis kontroliuojamas iki 10mbps;

• V3: Aukščiausios klasės mokamas narys, be didesnės saugyklos ir viešojo tinklo platinimo kvotos, taip pat palaiko papildomų viešojo tinklo silpno tinklo pagreičio ir didelio našumo terpės pagreičio galimybių konfigūravimą;

Agentų kūrėjai gali lanksčiai naudoti V1/V2/V3 tagging, kad valdytų šių vartotojų naudojamus išteklius ir pridėtinės vertės funkcijas, atsižvelgdami į skirtingus vartotojų vystymosi ciklus.

Set Slice: Natūrali didelio masto vartotojų duomenų izoliacija

Kai Set skaičius Agent Bucket pasiekia šimtus milijonų, o objektų skaičius pasiekia šimtus milijardų ar trilijonų, pats faktas, kad "visi metaduomenys viename Bucket yra centralizuoti viename KV klasteryje", kelia dvigubą talpos ir našumo riziką.

Set Slice suteikia "logiškai neskaidomas, fiziškai skaidomas" idėją:

• Logiškai žiūrint, jūs vis dar valdote tik vieną Agent Bucket.

• Fiziškai, atsižvelgiant į Set ir Set viduje esančių objektų pavadinimų diapazoną, metaduomenys yra padalijami į kelis Slice (gabalus), kiekvienas Slice gali būti saugomas skirtinguose klasteriuose, keli Set yra natūraliai izoliuoti, o vienas Set yra horizontaliai plečiamas.

Set Slice yra tolesnis ObjectSet galimybių išplėtimas ir užtikrinimas, jis iš esmės išsprendžia neriboto fizinės talpos išplėtimo problemą, tuo pačiu užtikrindamas viršutinio lygio ObjectSet valdymo modelio stabilumą ir nuoseklumą.

• Stabilus valdymo ribos: Net jei Agent Bucket duomenys apima kelis fizinius klasterius, ObjectSet vis dar yra vienintelis pagrindinis vienetas leidimams, kvotoms, atsiskaitymui ir stebėjimui. Kūrėjų ObjectSet konfigūruotos strategijos (pvz., prieigos kontrolė, talpos apribojimai) automatiškai įsigalios visuose susijusiuose Slices, nereikia rūpintis apatinių duomenų paskirstymu.

• Vienas Set gali būti tiesiškai plečiamas: Kai tam tikro ObjectSet duomenų kiekis sparčiai auga, jo duomenys natūraliai paskirstomi į kelis Slices. Plečiantis bendram klasteriui, šio ObjectSet talpa taip pat sklandžiai ir tiesiškai auga, kūrėjams nereikia atlikti jokių ardomųjų operacijų, tokių kaip šio ObjectSet skaidymas ar perkėlimas.

• Išteklių izoliavimas tarp Set: Paskirstant skirtingo diapazono objektus skirtinguose fiziniuose klasteriuose, SetSlice pasiekia aukštesnės dimensijos išteklių izoliavimą. Kartu su ObjectSet kvotų valdymu, galima veiksmingai užkirsti kelią tam tikro "super didelio" ObjectSet duomenų augimui, kuris išstumia visus vieno klasterio išteklius, taip paveikdamas kitų ObjectSet stabilumą, todėl bendra talpos rizika tampa valdoma.- Logikos vieningumas ir suderinamumas: verslui ir kūrėjams, nepriklausomai nuo to, kiek Slice yra po apačia, jie visada susiduria su logiškai vieningu Agent Bucket. Visi veiksmai su kaupu, ObjectSet ir objektais išlieka nepakitę, užtikrinant visišką fizinio išplėtimo skaidrumą viršutinėms programoms.

Set AccessPoint: izoliuokite kiekvieno vartotojo prieigos tašką

Agent Bucket palaiko nepriklausomų prieigos taškų (nepriklausomų domenų) įjungimą kiekvienam ObjectSet, o prieigos taškuose išplečiamos diferencijuotos saugos, izoliavimo ir pagreitinimo galimybės. Sistemai reikia palaikyti milijardų lygių nepriklausomų prieigos taškų planavimą ir diferencijuotą konfigūravimo galimybę.

Nepriklausomas prieigos domenas {$apid}.tos-objectset-ap.volces.com: dviejų lygių saugos apsauga

• Pirmas lygis Obscurity (paslėptumas): By User/ObjectSet nepriklausomas subdomenas, apid didelės entropijos maiša, labai maža susidūrimo tikimybė, neįmanoma atspėti ir išsamiai išvardyti konkretaus vartotojo įėjimo iš prieigos domeno perspektyvos;

• Antras lygis Containment (sulaikymas): Agent kūrėjai naudoja sts ObjectSet lygio prieigos leidimams platinti, net jei sts nutekės, galima kontroliuoti jo prieigos sritį, apribotą ribotu ObjectSet galiojimo laikotarpiu;

Heuristinė planavimo sistema: milijardo lygio domenų planavimo strategijos skaičiavimas

• By user/ObjectSet:tag diferencijuota prieigos strategija

• Daugelis user/ObjectSet automatiškai išsklaidomi į skirtingus viešojo tinklo įėjimus, vieno įėjimo gedimas kontroliuoja paveiktų vartotojų skaičių

• Viso regiono elastingas planavimas, bet koks vieno įėjimo gedimas/perkrova automatiškai užbaigia srauto pakavimą ir perkėlimą

• Viešojo tinklo pagreitinimo platinimo klasės vartotojai, pažymėti viešojo tinklo perdavimo pagreitinimo žyma, automatiškai planuoja pagreitinimo įėjimą

• Viešojo tinklo rizikos klasės vartotojai, pažymėti rizikos žyma, automatiškai planuoja viešojo tinklo izoliavimo įėjimą ir sumažina viešojo tinklo pralaidumo kvotą

• Vidinio tinklo tarpdomenų klasės vartotojai, pažymėti tarpdomenų žyma, automatiškai planuoja vidinio tinklo specialios linijos pagreitinimo kelią

• Vietinio regiono greitintuvo vartotojai, pažymėti greitintuvo žyma, automatiškai prijungia vietinio regiono greitintuvą

Nuo programavimo asistento iki AI debesies disko, Agent Bucket neribotos galimybės

Agent Bucket suteikia Agent visapusišką sprendimą, o ObjectSet dizaino taikymo scenarijai tuo nesibaigia, jį galima lengvai išplėsti į visas programas, kurioms reikia teikti paslaugas didžiuliam galutinių vartotojų skaičiui:

• Kodo saugykla: anksčiau, kai įmonės ar asmenys debesyje talpindavo kodą, jiems dažnai reikėdavo ant objektų saugyklos uždėti "nuomininkų sistemą", kad būtų galima atlikti paskyros izoliavimą ir prieigos kontrolę. Dabar kiekvienam kūrėjui galima priskirti išskirtinį ObjectSet, kuriame būtų vieningai saugoma kodo saugykla, kūrimo produktai ir priklausomybės. Agent Skills taip pat natūraliai pritaikytas ObjectSet, Skills įkėlimas ir atsisiuntimas platinamas per ObjectSet, užtikrinant stiprią izoliaciją, kad būtų išvengta Agent vykdymo trukdžių.

• Įmonės nuotraukų tinklo diskas: tradicinės nuotraukų albumų ar tinklo disko paslaugos dažnai sumaišo visų vartotojų nuotraukas tame pačiame kaupe, atskirdamos vartotojus pagal prefiksą, o tai ne tik sudėtinga valdyti, bet ir lengvai sukelia "kaimynų efektą". Remiantis ObjectSet, kiekvieno vartotojo nuotraukos ir vaizdo įrašai patenka į atskirus Set, o prieigos pikai netrukdo vieni kitiems. Taip pat galima nustatyti kiekvieno vartotojo talpos limitą, atsarginių kopijų kūrimo strategiją ir šifravimo metodą, kad iš tikrųjų būtų pasiekta "kiekvienas turi saugų, valdomą debesies nuotraukų albumą".

• Hadoop duomenų saugykla: įmonės duomenų saugykloje skirtingos verslo linijos ir skirtingos duomenų bazės dažnai dalijasi ištekliais toje pačioje pagrindinėje saugykloje. Susiejant kiekvieną duomenų bazę su ObjectSet, įmonės gali įgyvendinti izoliavimą ir kvotų kontrolę pagal duomenų bazę vieningoje saugykloje. Visų pirma, ObjectSet suteikia papildomą leidimų lygį TOS, o nekeičiant esamo Proton on TOS, suteikia izoliavimą ir prieigos kontrolę duomenų bazėms ir lentelėms, saugomoms TOS. - Modelio talpinimo platforma: Didelių kalbos modelių talpinimo scenarijuose kiekvienas modelis yra ne tik didelis, bet ir gali turėti skirtingas versijas, svorius ir išvadų konfigūracijas. Sukuriant ObjectSet kiekvienam modeliui, modelio svoriai, Tokenizer, konfigūracijos failai ir susiję vertinimo duomenys gali būti supakuoti ir talpinami toje pačioje erdvėje. Operacijų pusė gali nustatyti skirtingas šifravimo strategijas, atsarginių kopijų strategijas ir pralaidumo valdymą skirtingiems modeliams. Tuo pačiu metu, naudojant gimtąsias matavimo galimybes, galima apskaičiuoti tikrąją kiekvieno modelio naudojimo kainą, suteikiant pagrindą atsiskaitymui pagal modelio dimensiją ir išteklių planavimui.

• Duomenų SaaS paslauga: Duomenų platinimo platforma, skirta dideliam galutinių vartotojų skaičiui, dažnai turi vienu metu sąveikauti su daugybe duomenų tiekėjų. Būtina užtikrinti aiškias kiekvienos šalies duomenų ribas ir išvengti našumo rizikos, kai "vienas didelis kibiras trukdo visiems". Naudojant Agent Bucket, kiekvienas duomenų tiekėjas gali turėti savo ObjectSet, vieningai valdydamas pirminius duomenis ir apdorojimo rezultatus. Tada, naudojant atskirą domeną ir pralaidumą, QPS kvotas, skirtingiems tiekėjams užtikrinamas skirtingas paslaugų užtikrinimas ir srauto ribojimas, realizuojant "vieną platformą, daug tiekėjų, izoliuotą ir kontroliuojamą bendradarbiavimą" duomenų platinimo infrastruktūrą.

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/