Agent Bucket: Terabaitu mēroga Agent vietējais krātuves spainis

Šodien, kad AI aģenti parādās kā sēnes pēc lietus, izstrādātāji ar nepieredzētu ātrumu veido iztēles bagātīgas viedās lietojumprogrammas. Sākot ar programmēšanas palīgiem, kas var palīdzēt jums rakstīt kodu, līdz radošiem rīkiem, kas var ģenerēt filmu no viena teikuma, un beidzot ar personīgiem viedajiem asistentiem, kas vienmēr ir gatavi, Agent pārveido mūsu mijiedarbību ar digitālo pasauli. Aiz šī viļņa arvien skaidrāka kļūst vienprātība: ar Serverless arhitektūras (piemēram, Lambda), lielo valodu modeļu (LLM) un mākoņkrātuves (piemēram, S3, TOS) palīdzību, apvienojumā ar Vibe Coding, ikviens var ātri izveidot savu AI Agent 30 minūtēs.

No "var izmantot" līdz "ērti lietojams", Agent izstrādātājiem joprojām ir jāpārvar grūtības, pārejot no "rotaļlietas" uz "ražošanas līmeņa lietojumprogrammu". Uzņēmumam virzoties uz milzīgu lietotāju skaitu, izstrādātājiem ir jāsaskaras ar ārkārtīgi sarežģītu izaicinājumu: kā izveidot pilnīgu krātuves risinājumu milzīgam skaitam galalietotāju objektu krātuvē? Lielākajai daļai izstrādātāju tas ir ne tikai tehnisks šķērslis, bet arī plaisa, kas kavē Agent mērogojamu izplatīšanu. Agent Bucket mērķis ir pilnībā vienkāršot vairāku nomnieku sistēmu izveides procesu, izmantojot AI vietējo krātuves dizainu, nodrošinot draudzīgākas Agent iespējas.

Kad ieplūst simtiem miljonu lietotāju, tradicionālā objektu krātuve "nav pietiekami laba"

Iedomājieties, ka esat izstrādājis populāru AIGC lietojumprogrammu. Katrs lietotājs ģenerēs un saglabās lielu skaitu attēlu, video un pagaidu failu. Kā izstrādātājs, jūs, protams, izvēlēsieties nobriedušus, mērogojamus objektu krātuves pakalpojumus, piemēram, S3 un TOS. Bet rodas jautājums: kā pārvaldīt datus milzīgam skaitam lietotāju?

2022. gada S3 emuārā "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3" ir aprakstīti divi veidi, "katrs nomnieks izmanto neatkarīgu S3 spaini" un "uz prefiksu izolācijas balstīts koplietots S3 spainis":

• Izveidojiet neatkarīgu "spaini" (Bucket) katram lietotājam: tas ir iespējams, ja ir maz lietotāju, bet, kad lietotāju skaits pieaug līdz desmitiem tūkstošu vai miljoniem, spaiņu skaits strauji eksplodēs, un pārvaldības izmaksas un resursu ierobežojumi kļūs nepanesami. S3 nodrošina kopējo spaiņu kvotu 10 000 apmērā visam reģionam, bet karstām AI iespējām 10 000 ir tālu no pietiekama.

• Izmantojiet "prefiksus", lai atšķirtu lietotājus vienā spainī: tas ir kļuvis par galveno risinājumu. Piemēram, lietotāja A faili sākas ar user-a/, bet lietotāja B faili sākas ar user-b/, tāpat kā failu pārvaldība datorā ar mapēm. Tomēr objektu krātuvē nav vietējo mapju, šis risinājums izmanto "kopējo prefiksu" (Prefix), lai atšķirtu vairākus nomniekus "K-V" krātuves sistēmā.

Šis uz "spaiņa" vai "prefiksa" balstītais risinājums ir plaši izmantots pēdējos desmit gados. Bet tam ir šādas problēmas:

• Vairāku nomnieku izolācija: visu lietotāju dati ir sajaukti vienā spainī, un viena lietotāja neparasti augsta frekvences piekļuve var ietekmēt visus pārējos lietotājus, radot "kaimiņu efektu". Par veiktspējas izolāciju un kļūdu izolāciju nevar būt ne runas.

• Piekļuves kontrole: sarežģītas piekļuves politikas (IAM Policy) ir grūti uzturēt, un ir viegli pieļaut konfigurācijas kļūdas, kas var izraisīt nejaušu piekļuvi lietotāju datiem, jo īpaši, ja ir nepieciešama mijiedarbība ar citiem mākoņpakalpojumiem, riska pakāpe ir lielāka.

• Izmaksu skaidrība: jums ir grūti precīzi zināt, cik daudz krātuves vietas patērē katrs lietotājs un cik daudz datu pārraides izmaksu ir radušās. Kad vēlaties iekasēt maksu no maksas lietotājiem, pamatojoties uz lietojumu, norēķini un mērīšana kļūst par neskaidru lietu.Objektu krātuves (S3/TOS) būtība ir "saplacināšana", un tās sākotnējais mērķis ir vienkārša liela apjoma datu glabāšana, kas atgādina milzīgu noliktavu. Lai gan tās ietilpība ir gandrīz neierobežota, loģiskā struktūra ir ārkārtīgi vienkārša. Tai trūkst vietējas augsta līmeņa direktoriju pārvaldības, smalkas metadatu kontroles un patiesas nomnieku uztveres. Kad izstrādātāji mēģina "saplacinātā" S3, izmantojot cietkodētu prefiksu, simulēt "trīsdimensiju" daudznomas failu sistēmu, mēs faktiski izmantojam "statisku KV krātuvi", lai atbalstītu "direktoriju semantiku, stingri izolētu" Agent lietojumprogrammas failu piekļuves metodi. Tas nozīmē, ka Agent ir jāpatērē papildu tokeni, lai pārvaldītu failus un kontrolētu un atrisinātu daudznomas atļaujas un izolāciju. Visi šie papildu patērētie tokeni norāda, ka S3 definētais vienkāršais krātuves pakalpojums Agent nav pietiekami vienkāršs.

2025. gada S3 emuārā "Design patterns for multi-tenant access control on Amazon S3" ir sīkāk aprakstīts S3 Access Point. Tas nozīmē, ka var izveidot vairākus virtuālos tīkla piekļuves punktus un katram piekļuves punktam konfigurēt pielāgotu piekļuves punkta politiku, kas tīkla plānošanas līmenī nodrošina dažus risinājumus daudznomas scenārijiem.

Agent Wonderland

Ideāls Agent izstrādātājs, izstrādājot AI Agent, var balstīties uz "Agent SDK + krātuve + MaaS pakalpojums", lai izveidotu pilnībā serverless Agent:

• Agent var darboties pilnībā serverless

• Izmantojot Vibe Coding metodi, var apvienot esošās produktu iespējas, lai izveidotu Agent

• Ir jāuztur tikai "ADK" python skripts

• Krātuve izmanto objektu krātuvi

• AI iespējas izmanto 豆包 (Doubao)

• Teorētiski nav ECS vai citu instanču tipa produktu

Turklāt krātuvei ir jānodrošina šādas iespējas:

• Agent var izmantot objektu semantikas krātuvi (failu saglabāšanai), nodrošinot daudznomas piekļuves iespējas, sākot no miljona un paplašinoties līdz miljardiem

• Agent var nodrošināt katram lietotājam neatkarīgu telpu (starp vairākiem pakalpojumiem pakalpojumu vai uid nosaukumi var būt vienādi)

• Agent var tieši konfigurēt katra lietotāja joslas platumu, konfigurēt lietotāja objektu kopējā lieluma ierobežojumu

• Agent var norēķināties, uzraudzīt un novērot lietotāju

• Agent var konfigurēt katra lietotāja failu piekļuves politikas

Agent Bucket: AI Agent ievieš "vietējo daudznomas" gēnu

Lai radikāli atrisinātu šo problēmu, mēs piedāvājam pilnīgi jaunu objektu krātuves paradigmu — Agent Bucket. Tās galvenā inovācija ir jauna vietējo resursu līmeņa ieviešana starp tradicionālajiem "spaiņiem" un "objektiem": objektu kolekcija.

Šī dizaina pamatideja ir ārkārtīgi vienkārša: katram jūsu gala lietotājam piešķiriet ekskluzīvu ObjectSet. Jūs varat iedomāties ObjectSet kā "datu seifu" vai "mākoņa personīgo telpu", kas paredzēta katram lietotājam. Loģiski tas pieder jūsu (izstrādātāja) Bucket, bet fiziski un pārvaldības ziņā tam ir sava neatkarīga "individualitāte" un "dzīves cikls".Agent Bucket Katrs spainis atbalsta 100 miljonus ObjectSet, kas nozīmē, ka varat mierīgi apkalpot simtiem miljonu gala lietotāju, it kā katrs gala lietotājs "dzīvotu" savā neatkarīgā krātuves telpā, un vairs nav jāuztraucas par daudzlīmeņu krātuves pārvaldību.

ObjectSet dizains – Agentiem draudzīgas iespējas

Agent Bucket ObjectSet nav tikai papildu līmenis, bet gan pārvērš visgrūtākās prasības daudzlīmeņu scenārijos par gatavām, vietējām iespējām. Kad datu īpašumtiesības ir skaidri noteiktas ObjectSet līmenī, virkne iespēju, kuras agrāk bija grūti īstenot, kļūst pašsaprotamas.

• Vietējā izolācija: ObjectSet līmenī varat iestatīt neatkarīgus QPS, joslas platuma ierobežojumus un jaudas kvotas katram lietotājam. Maksas lietotāju pieredze var tikt garantēta, un bezmaksas lietotāju neparasta uzvedība neietekmēs citus. Šī ir īsta kļūdu domēna izolācija, kas neļauj "kaimiņiem" traucēt viens otram.

• Vietējās atļaujas: Katram ObjectSet var būt neatkarīgs domēns. Tas nozīmē, ka varat piešķirt lietotājam A ekskluzīvu piekļuves adresi user-a.yourapp.com, nevis atklāt visu krātuves spaiņa domēnu. Vēl gudrāks ir "divu slēdzeņu" dizains: pirmā slēdzene ir mākoņpakalpojumu sniedzēja izsniegta pagaidu piekļuves akreditācijas lapa (STS), kas kontrolē piekļuves atļaujas lietojumprogrammas līmenī; otrā slēdzene ir ObjectSet neatkarīgais domēns, kas bloķē piekļuves pieprasījumus lietotāja datu telpā no tīkla līmeņa. Tas ievērojami uzlabo datu drošību.

• Vietējā uzraudzība: Uzraudzības informācijas panelī jūs vairs nevarat redzēt tikai visa spaiņa pārskata datus. Varat sadalīt uzraudzības diagrammas pēc ObjectSet, lai skaidri saprastu, kurš gala lietotājs veic lielu skaitu piekļuves, lai pieņemtu precīzus darbības un optimizācijas lēmumus.

• Vietējo iespēju samazināšana: Politikas, kuras agrāk varēja iestatīt tikai spaiņa līmenī, tagad var samazināt katram lietotājam. Varat iestatīt dažādus datu dzīves ciklus dažāda līmeņa lietotājiem vai izmantot dažādas šifrēšanas atslēgas katram ObjectSet, lai panāktu detalizētāku un drošāku datu pārvaldību.

• Vietējā mērīšana: Vai vēlaties zināt, cik daudz krātuves vietas aizņem katrs lietotājs? Vai vēlaties precīzi sadalīt krātuves izmaksas katram lietotājam? Tagad tas ir viegli. Agent Bucket automātiski statistiski apkopo katra ObjectSet jaudu un lietojumu, padarot jūsu norēķinus un sadali skaidru.

• Vietējie norēķini: Izstrādātāji var viegli īstenot izmaksu sadali un precīzi atgriezt krātuves radītās izmaksas katram gala lietotājam. Piemēram, iekasējiet dažādas maksas atkarībā no A, B un C lietotāju faktiskajām izmaksu proporcijām, lai sniegtu datu atbalstu Agent komercializācijai.

• Vietējais jaudas ierobežojums: Lai kontrolētu Agent darbības izmaksas, varat iestatīt kvotu (jaudas ierobežojumu) katram ObjectSet. Kad ir sasniegta iepriekš iestatītā vērtība, sistēma ierobežos lietotāju turpmāk ģenerēt jaunus failus, tādējādi novēršot resursu ļaunprātīgu izmantošanu daudzlīmeņu scenārijos.

• Vietējais intelekts: Agent Bucket ļauj Agent izlauzties cauri tradicionālajiem vienkāršajiem failu "uzglabāšanas un piekļuves" ierobežojumiem, piešķirot Object vietējo intelektu un efektīvāk atbalstot Agent vienas pieturas izstrādi. ObjectSet var vienu reizi atvērt viedo indeksēšanu, lai nodrošinātu Agent vietēji draudzīgas multimodālas atbildes iespējas, aizstājot tradicionālās Object CRUD mehāniskās darbības; tas pat atbalsta vienu reizi atvērt Agentself režīmu, savienojot vektorus, zināšanas, modeļus un prompt, lai tieši atklātu scenārijam specifiskas apakš Agent funkcijas, ļaujot augšējiem Agent izstrādātājiem koncentrēties uz galveno biznesa darbplūsmas izveidi un pilnībā atbrīvojot viedo monetizācijas efektivitāti.

Tehniskie izaicinājumi, ko rada lietojumprogrammu mēroga straujš pieaugums

Agent Bucket, ieviešot ObjectSet vietējo koncepciju, nodrošina lietojumprogrammu izstrādātājiem elegantu un efektīvu veidu, kā pārvaldīt simtiem miljonu gala lietotāju datus. Katra lietotāja digitālie aktīvi tiek droši glabāti viņu ekskluzīvajā ObjectSet, dabiski īstenojot izolāciju, norēķinus un kvotu pārvaldību.

Līdz ar lietojumprogrammu mēroga straujo paplašināšanos vienlaikus parādās arī milzīgs Set pārvaldības sarežģītība, izolācijas grūtības un fiziskie šķēršļi:

• Milzīgs lietotāju līmeņu pārvaldības jautājums: Lietojumprogrammai, diferencēti pārvaldot lielu skaitu dažādu līmeņu lietotāju resursus un funkcijas, ir jāizstrādā un jāīsteno lietotāju līmeņu metadati un jāsaista objektu krātuves funkciju slēdži, lai palīdzētu izstrādātājiem eleganti pārvaldīt lietotāju līmeņus, pamatojoties uz Set vietējo koncepciju, ir svarīgi paātrināt lietojumprogrammu ieviešanu.Šeit ir divas galvenās problēmas, kas jāatrisina, lai atbalstītu aģentu (Agent) horizontālu mērogošanu un izolāciju:

• Viena klastera kapacitātes ierobežojums: lai gan aģenta konteiners (Agent Bucket) loģiski var tikt paplašināts bezgalīgi, tā metadati pēc noklusējuma tiek glabāti vienā fiziskā klasterī. Kad kopējais objektu skaits konteinerā sasniedz simtiem miljardu vai pat triljonu, viena klastera fiziskā kapacitāte kļūst par nepārvaramu robežu.

• Piekļuves punktu koplietošanas problēma: aģenta biznesa daudzveidība un milzīgs lietotāju skaits rada lielākus drošības riskus un sprādziena rādiusu pašam piekļuves punktam. Kā veikt dinamisku plānošanu, pamatojoties uz lielu skaitu dažādu biznesu un lietotāju atšķirībām, lai panāktu diferencētu drošību, izolāciju un paātrinājuma iespējas, kļūst par grūtu uzdevumu.

Iestatīt tagu (Set Tagging): lietotāju līmeņu pārvaldība ar tagiem

ObjectSet nodrošina sākotnēju pārvaldības metodi ar tagiem, kas ļauj aģentu izstrādātājiem vienkārši izmantot iestatīšanas tagu iespējas, lai pabeigtu lietotāju līmeņu pārvaldību. Izstrādātāji var katram definētajam lietotāju līmenim atbilstīgi izveidot tagu un katram tagam iespējot dažādas kvotas un funkcijas. Visiem ObjectSet, kas ir atzīmēti ar šo tagu, tiks piemērotas atbilstošās kvotas un funkcijas. Apskatīsim piemēru ar trim līmeņiem: V1, V2 un V3:

• V1: noklusējuma līmenis, bezmaksas lietotāji, visu ObjectSet noklusējuma tags, var konfigurēt maksimāli 1GiB datu glabāšanu, publiskā tīkla izplatīšana nedrīkst pārsniegt 100mbps joslas platumu, un vienas plūsmas lejupielādes ātrums tiek kontrolēts līdz 1mbps.

• V2: sākuma līmeņa maksas dalībnieki, konfigurēti maksimāli 10GiB datu glabāšanai, publiskā tīkla izplatīšana nedrīkst pārsniegt 10gbps joslas platumu, un vienas plūsmas lejupielādes ātrums tiek kontrolēts līdz 10mbps.

• V3: augstākā līmeņa maksas dalībnieki, papildus lielākai krājumu un publiskā tīkla izplatīšanas kvotai, atbalsta arī papildu publiskā tīkla vāja tīkla paātrinājuma un augstas veiktspējas datu nesēju paātrinājuma iespēju konfigurēšanu.

Aģentu izstrādātāji var elastīgi izmantot V1/V2/V3 tagus, lai pārvaldītu resursus un pievienotās vērtības funkcijas, ko šie lietotāji var izmantot dažādos lietotāju attīstības ciklos.

Iestatīt šķēli (Set Slice): sākotnēja datu izolācija milzīgam lietotāju skaitam

Kad iestatījumu skaits aģenta konteinerā (Agent Bucket) sasniedz simtiem miljonu, un objektu skaits sasniedz simtiem miljardu vai triljonu, fakts, ka "visi viena konteinera metadati ir koncentrēti vienā KV klasterī", pats par sevi rada dubultus kapacitātes un veiktspējas riskus.

Iestatīt šķēle (Set Slice) nodrošina "loģiskās nedalīšanas, fiziskās dalīšanas" pieeju:

• No loģiskā viedokļa jūs joprojām pārvaldāt tikai vienu aģenta konteineru (Agent Bucket).

• Fiziski, atkarībā no iestatījuma un iestatījumā esošo objektu nosaukumu diapazona, metadati tiek sadalīti vairākās šķēlēs (Slice), un katru šķēli var glabāt dažādos klasteros. Vairāki iestatījumi ir dabiski izolēti, un vienu iestatījumu var horizontāli paplašināt.

Iestatīt šķēle (Set Slice) ir ObjectSet iespēju turpmāks paplašinājums un nodrošinājums. Tas pamatā atrisina fiziskās kapacitātes bezgalīgas paplašināšanas problēmu, vienlaikus nodrošinot ObjectSet pārvaldības modeļa stabilitāti un konsekvenci.

• Stabila pārvaldības robeža: pat ja viena aģenta konteinera (Agent Bucket) dati aptver vairākus fiziskus klasterus, ObjectSet joprojām ir vienīgā pamata vienība atļaujām, kvotām, norēķiniem un uzraudzībai. Stratēģijas, ko izstrādātāji konfigurē ObjectSet (piemēram, piekļuves kontrole, kapacitātes ierobežojums), automātiski stāsies spēkā visās saistītajās šķēlēs (Slices), un nav jāuztraucas par datu sadalījumu pamatā.

• Vienu iestatījumu var lineāri paplašināt: kad viena ObjectSet datu apjoms strauji pieaug, tā dati dabiski tiks sadalīti vairākās šķēlēs (Slices). Līdz ar visa klastera paplašināšanu, ObjectSet kapacitāte arī nemanāmi un lineāri pieaug, un izstrādātājiem nav jāveic nekādas destruktīvas darbības, piemēram, sadalīšana vai migrācija pašam ObjectSet.

• Resursu izolācija starp iestatījumiem: sadalot dažāda diapazona objektus dažādos fiziskos klasteros, SetSlice nodrošina augstāku dimensiju resursu izolāciju. Apvienojumā ar ObjectSet kvotu pārvaldību, tas var efektīvi novērst to, ka viena "super liela" ObjectSet datu pieaugums izspiež visus viena klastera resursus, tādējādi ietekmējot citu ObjectSet stabilitāti un padarot kopējo kapacitātes risku kontrolējamu.- Loģiskā vienotība un saderība: uzņēmumiem un izstrādātājiem neatkarīgi no tā, cik daudz Slice ir apakšā, viņi vienmēr saskaras ar loģiski vienotu Agent Bucket. Visas darbības ar spaiņiem, ObjectSet un objektiem paliek nemainīgas, nodrošinot pilnīgu fiziskās paplašināšanas caurspīdīgumu augšējiem lietojumiem.

Set AccessPoint: izolē katra lietotāja piekļuves punktu

Agent Bucket atbalsta neatkarīgu piekļuves punktu (neatkarīgu domēnu) atvēršanu katram ObjectSet, un piekļuves punktā tiek paplašinātas diferencētas drošības, izolācijas un paātrinājuma iespējas, tāpēc sistēmai ir jāatbalsta miljarda līmeņa neatkarīga piekļuves punkta plānošana un diferencēta konfigurācijas iespēja.

Neatkarīgs piekļuves domēns {$apid}.tos-objectset-ap.volces.com: divu līmeņu drošības aizsardzība

• Pirmais līmenis Obscurity (slēptība): By User/ObjectSet neatkarīgs apakšdomēns, apid augstas entropijas izkliede, ļoti zema sadursmes varbūtība, no piekļuves domēna viedokļa nav iespējams uzminēt un izsmelt konkrētu lietotāja ieeju;

• Otrais līmenis Containment (ierobežojums): Agent izstrādātāji izmanto sts, lai izplatītu ObjectSet līmeņa piekļuves atļaujas, pat ja sts noplūst, var kontrolēt tā piekļuves diapazonu, kas ir ierobežots ar noteikta ObjectSet ierobežotu derīguma termiņu;

Heiristiskā plānošanas sistēma: miljarda līmeņa domēnu plānošanas stratēģijas aprēķins

• By user/ObjectSet:tag diferencēta piekļuves stratēģija

• Vairāki user/ObjectSet automātiski izkliedēti dažādās publiskā tīkla ieejās, vienas ieejas kļūme ietekmē kontrolētu lietotāju skaitu

• Pilna reģiona elastīga plānošana, jebkura vienas ieejas kļūme/pārslodze automātiski pabeidz trafika iepakošanu un pārvietošanu

• Publiskā tīkla paātrinājuma izplatīšanas klases lietotāji, atzīmēti ar publiskā tīkla pārraides paātrinājuma tagu, automātiski plāno paātrinājuma ieeju

• Publiskā tīkla riska klases lietotāji, atzīmēti ar riska tagu, automātiski plāno publiskā tīkla izolācijas ieeju un samazina publiskā tīkla joslas platuma kvotu

• Iekšējā tīkla starpdomēnu klases lietotāji, atzīmēti ar starpdomēnu tagu, automātiski plāno iekšējā tīkla speciālās līnijas paātrinājuma ceļu

• Vietējā reģiona paātrinātāja lietotāji, atzīmēti ar paātrinātāja tagu, automātiski pievieno vietējā reģiona paātrinātāju

No programmēšanas palīga līdz AI mākoņdiskam, Agent Bucket neierobežotās iespējas

Agent Bucket nodrošina Agent pilnīgu risinājumu, un ObjectSet dizaina lietojuma scenāriji ir daudz vairāk nekā tikai šis, to var viegli paplašināt visiem lietojumiem, kuriem jāsniedz pakalpojumi milzīgam skaitam gala lietotāju:

• Koda repozitorijs: agrāk, kad uzņēmumi vai privātpersonas mitināja kodu mākonī, viņiem bieži vien bija jāuzbūvē "īrnieku sistēma" virs objektu krātuves, lai panāktu konta izolāciju un piekļuves kontroli. Tagad katram izstrādātājam var piešķirt ekskluzīvu ObjectSet, lai vienoti apkopotu koda repozitoriju, būvējuma artefaktus un atkarības. Agent Skills arī dabiski pielāgojas ObjectSet, Skills augšupielāde un lejupielāde tiek izplatīta, izmantojot ObjectSet, lai nodrošinātu spēcīgu izolāciju, izvairoties no Agent darbības laikā traucējumiem kaimiņiem.

• Uzņēmuma fotoalbumu tīkla disks: tradicionālie fotoalbumu vai tīkla disku pakalpojumi bieži vien sajauc visu lietotāju fotoattēlus vienā spainī, atšķirot lietotājus pēc prefiksa, kas ne tikai sarežģī pārvaldību, bet arī viegli rada "kaimiņu efektu". Pamatojoties uz ObjectSet, katra lietotāja fotoattēli un videoklipi atrodas katrā Set, piekļuves maksimumi netraucē viens otram, un jūs varat arī iestatīt ietilpības ierobežojumus, dublēšanas stratēģijas un šifrēšanas metodes katram lietotājam, lai patiešām panāktu, ka "katram ir drošs, kontrolējams mākoņa fotoalbums".

• Hadoop datu noliktava: uzņēmuma datu noliktavā dažādas biznesa līnijas un dažādas datu bāzes bieži vien koplieto resursus vienā un tajā pašā apakšējā krātuvē, kartējot katru datu bāzi kā ObjectSet, uzņēmumi var realizēt izolāciju un kvotu kontroli pēc datu bāzes virs vienotas krātuves. Jo īpaši ObjectSet nodrošina papildu atļauju slāni TOS, nodrošinot izolāciju un piekļuves kontroli Database un Tables, kas tiek glabātas TOS, nemainot esošo Proton on TOS. - Modeļu mitināšanas platforma: Lielu modeļu mitināšanas scenārijos katrs modelis ir ne tikai apjomīgs, bet tam var būt arī dažādas versijas, svari un secinājumu konfigurācijas. Izveidojot ObjectSet katram modelim, modeļa svarus, Tokenizer, konfigurācijas failus un saistītos novērtēšanas datus var iepakot un mitināt vienā telpā. Operāciju puse var iestatīt atšķirīgas šifrēšanas politikas, dublēšanas politikas un joslas platuma kontroli dažādiem modeļiem, vienlaikus izmantojot vietējās mērīšanas iespējas, lai aprēķinātu katra modeļa faktiskās lietošanas izmaksas, nodrošinot pamatu norēķiniem un resursu plānošanai pēc modeļa dimensijas.

• Datu SaaS pakalpojums: Datu izplatīšanas platformai, kas paredzēta milzīgam skaitam galalietotāju, bieži vien ir vienlaikus jāsadarbojas ar daudziem datu nodrošinātājiem, nodrošinot, ka visu pušu datu robežas ir skaidras, un jāizvairās no veiktspējas riska, ka "viena liela muca velk visus uz leju". Izmantojot Agent Bucket, katram datu nodrošinātājam var būt savs ObjectSet, lai vienoti pārvaldītu sākotnējos datus un apstrādes rezultātus, un pēc tam, izmantojot neatkarīgu domēnu un joslas platumu, QPS kvotu, nodrošināt diferencētu pakalpojumu garantiju un ierobežot plūsmu dažādiem nodrošinātājiem, realizējot datu izplatīšanas infrastruktūru "viena platforma, vairāki nodrošinātāji, izolēti viens no otra un kontrolējami sadarbojas".

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/