Agent Bucket: Një kovë ruajtjeje origjinale për agjentë në shkallë trilioni

Në ditët e sotme kur Agjentët e AI po shfaqen si kërpudha pas shiut, zhvilluesit po ndërtojnë aplikacione inteligjente plot imagjinatë me një shpejtësi të paprecedentë. Nga asistentët e programimit që mund t'ju ndihmojnë të shkruani kod, tek mjetet krijuese që gjenerojnë një film nga një fjali, e deri tek asistentët inteligjentë personalë që janë gjithmonë në gatishmëri, Agjentët po riformësojnë mënyrën se si ne ndërveprojmë me botën dixhitale. Pas këtij vale, një konsensus po bëhet gjithnjë e më i qartë: me ndihmën e arkitekturës Serverless (si Lambda), modeleve të mëdha gjuhësore (LLM) dhe ruajtjes në cloud (si S3, TOS), të kombinuara me Vibe Coding, kushdo mund të ndërtojë shpejt një Agjent AI të vetin brenda 30 minutash.

Nga të qenit "i përdorshëm" në të qenit "i dobishëm", zhvilluesit e Agjentëve ende duhet të kapërcejnë vështirësitë në kalimin nga "lodër" në "aplikacion të nivelit të prodhimit". Ndërsa biznesi shkon drejt një numri të madh përdoruesish, zhvilluesit duhet të përballen me një sfidë jashtëzakonisht komplekse: si të ndërtojnë një zgjidhje të plotë ruajtjeje për një numër të madh përdoruesish fundorë në ruajtjen e objekteve? Për shumicën e zhvilluesve, kjo nuk është vetëm një pengesë teknike, por edhe një hendek që pengon shpërndarjen në shkallë të gjerë të Agjentëve. Agent Bucket synon të thjeshtojë plotësisht procesin e ndërtimit të sistemeve me shumë qira përmes një dizajni ruajtjeje origjinal të AI, duke ofruar aftësi më miqësore për Agjentët.

Kur miliona përdorues vërshojnë, ruajtja tradicionale e objekteve "nuk mjafton më"

Imagjinoni që keni zhvilluar një aplikacion AIGC jashtëzakonisht të njohur. Çdo përdorues do të gjenerojë dhe ruajë një numër të madh imazhesh, videosh dhe skedarësh të përkohshëm. Si zhvillues, natyrisht që do të zgjidhni shërbime ruajtjeje objektesh të pjekura dhe të shkallëzueshme si S3 dhe TOS. Por këtu lind pyetja: si të menaxhohen të dhënat për një numër të madh përdoruesish?

Blogu i S3 i vitit 2022, "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3", shpjegon dy mënyra, "përdorimi i një kove S3 të pavarur për çdo qiramarrës" dhe "një kovë S3 e përbashkët e izoluar në bazë të parashtesës":

• Krijimi i një "kove" (Bucket) të pavarur për çdo përdorues: Kjo është e realizueshme kur ka pak përdorues, por kur numri i përdoruesve rritet në dhjetëra mijëra, miliona, numri i kovave do të shpërthejë shpejt dhe kostot e menaxhimit dhe kufizimet e burimeve do të jenë të padurueshme. S3 ofron një kuotë totale prej 10000 kovash për të gjithë rajonin, por për aftësitë e nxehta të AI, 10000 nuk mjaftojnë aspak.

• Përdorimi i "parashtesave" për të dalluar përdoruesit brenda të njëjtës kovë: Kjo është bërë zgjidhja kryesore. Për shembull, skedarët e përdoruesit A fillojnë me user-a/, ndërsa ato të përdoruesit B fillojnë me user-b/, si menaxhimi i skedarëve me dosje në një kompjuter. Megjithatë, ruajtja e objekteve nuk ka dosje origjinale. Kjo zgjidhje dallon qiramarrësit e shumtë përmes "parashtesës së përbashkët" (Prefix) në sistemin e ruajtjes "K-V".

Kjo zgjidhje e bazuar në "kovë" ose "parashtesë" është adoptuar gjerësisht gjatë dekadës së fundit. Por ka problemet e mëposhtme:

• Izolimi i shumë qirave: Të dhënat e të gjithë përdoruesve janë të përziera në të njëjtën kovë. Një akses anormalisht i shpeshtë nga një përdorues mund të ndikojë në të gjithë përdoruesit e tjerë, duke prodhuar një "efekt fqinjësie". Izolimi i performancës dhe izolimi i defekteve nuk mund të realizohen.

• Kontrolli i lejeve: Politikat komplekse të lejeve (IAM Policy) janë të vështira për t'u mirëmbajtur dhe është e lehtë të bëhen gabime konfigurimi, duke çuar në akses të paautorizuar në të dhënat e përdoruesve, veçanërisht kur duhet të ndërveprohet me shërbime të tjera cloud, rreziku është më i madh.

• Kosto e qartë: Është e vështirë të dihet saktësisht se sa hapësirë ruajtjeje ka konsumuar çdo përdorues dhe sa tarifa trafiku janë gjeneruar. Kur dëshironi të tarifoni përdoruesit me pagesë bazuar në përdorimin, faturimi dhe matja bëhen një rrëmujë.Pse zhvilluesit e Agentëve po e zbatojnë disi "rëndë" në ruajtjen e objekteve këto kërkesa që duken themelore? Një hetim i thellë i arsyeve zbulon se në arkitekturën aktuale cloud-native, ekziston një vakum i madh midis "ruajtjes së objekteve" si S3 dhe "sistemit tradicional të skedarëve". Esenca e ruajtjes së objekteve (S3/TOS) është "rrafshimi", qëllimi fillestar i të cilit është ruajtja e thjeshtë e sasive të mëdha të të dhënave, si një magazinë e madhe. Megjithëse kapaciteti është pothuajse i pafund, struktura logjike është jashtëzakonisht e thjeshtë. I mungon menaxhimi i avancuar i drejtorive, kontrolli i detajuar i metadatave dhe ndjeshmëria e vërtetë ndaj qiramarrësve. Kur zhvilluesit përpiqen të simulojnë një sistem skedarësh "tre-dimensional" me shumë qiramarrës në S3 "të rrafshët" duke koduar prefikse, ne në fakt po përdorim një "ruajtje statike KV" për të mbajtur një mënyrë të aksesit të skedarëve të aplikacionit Agent me "semantikë drejtorie dhe izolim të fortë". Kjo do të thotë që Agjenti duhet të harxhojë token shtesë për të menaxhuar skedarët dhe për të kontrolluar zgjidhjen e lejeve dhe izolimit të shumë qiramarrësve. Këto token shtesë të harxhuara tregojnë se shërbimi i thjeshtë i ruajtjes i përcaktuar nga S3 nuk është mjaft i thjeshtë për Agjentin.

Në blogun e S3 të vitit 2025, "Modelet e dizajnit për kontrollin e aksesit me shumë qiramarrës në Amazon S3" shpjegohet më tej S3 Access Point. Kjo do të thotë që mund të krijohen pika të shumta virtuale të aksesit në rrjet dhe për secilën pikë aksesi mund të konfigurohet një politikë e personalizuar e pikës së aksesit, duke pasur disa zgjidhje për skenarët me shumë qiramarrës në nivelin e planifikimit të rrjetit.

Agent Wonderland

Një zhvillues ideal i Agentit mund të ndërtojë një Agent plotësisht pa server duke u bazuar në "Agent SDK + ruajtje + shërbim MaaS" kur zhvillon një AI Agent:

• Agjenti mund të funksionojë plotësisht pa server

• Mund të ndërtojë një Agent duke kombinuar aftësitë ekzistuese të produktit nëpërmjet Vibe Coding

• Duhet të mirëmbajë vetëm skriptin python të "ADK"

• Ruajtja përdor ruajtjen e objekteve

• Aftësitë AI përdorin Doubao

• Teorisht pa ECS ose produkte të tjera të tipit instancë

Në të njëjtën kohë, ruajtja duhet të ofrojë aftësitë e mëposhtme:

• Agjenti mund të ketë një ruajtje me semantikë objekti (ruajtje skedarësh), duke ofruar aftësinë e aksesit me shumë qiramarrës, duke filluar nga niveli i milionave dhe duke u zgjeruar në nivelin e qindra miliona

• Agjenti mund të ofrojë hapësirë të pavarur për çdo përdorues (midis bizneseve të shumta, bizneset ose uid mund të kenë të njëjtin emër)

• Agjenti mund të konfigurojë drejtpërdrejt gjerësinë e brezit të çdo përdoruesi dhe të konfigurojë kufirin e sipërm të madhësisë totale të objektit të përdoruesit

• Agjenti mund të faturë, monitorojë dhe vëzhgojë sipas përdoruesit

• Agjenti mund të konfigurojë politikat e aksesit për skedarët e çdo përdoruesi

Agent Bucket: injekton gjene "native me shumë qiramarrës" në AI Agent

Për të zgjidhur rrënjësisht këtë problem, ne kemi propozuar një paradigmë krejtësisht të re të ruajtjes së objekteve - Agent Bucket. Inovacioni i tij thelbësor është futja e një niveli të ri burimi native midis "kovës" tradicionale dhe "objektit": koleksioni i objekteve.

Ideja thelbësore e këtij dizajni është jashtëzakonisht e thjeshtë: përputhni çdo përdorues fundor me ObjectSet-in e tij ekskluziv. Ju mund ta imagjinoni ObjectSet si një "kasafortë të dhënash" ose "hapësirë personale cloud" të krijuar posaçërisht për çdo përdorues. Ai i përket logjikisht kovës suaj (zhvilluesit), por fizikisht dhe menaxherikisht, ai ka "personalitetin" dhe "ciklin e jetës" e vet të pavarur.Agent Bucket mbështet 100 milionë ObjectSet për çdo bucket, që do të thotë se mund të ofroni shërbime për qindra miliona përdorues fundorë sikur secili prej tyre të "jetojë" në hapësirën e tij të pavarur të ruajtjes, pa u shqetësuar më për menaxhimin e ruajtjes multi-tenant.

Dizajni i ObjectSet – Aftësi miqësore për Agentët

Në Agent Bucket, ObjectSet nuk është thjesht një shtresë e shtuar, por i kthen nevojat më të vështira në skenarët multi-tenant në aftësi të gatshme për përdorim. Kur pronësia e të dhënave përcaktohet qartë në nivelin ObjectSet, një sërë aftësish që ishin të vështira për t'u realizuar në të kaluarën bëhen të natyrshme.

• Izolim nativ: Në nivelin ObjectSet, mund të vendosni kufizime të pavarura QPS, gjerësie bande dhe kuota kapaciteti për çdo përdorues. Përvoja e përdoruesve me pagesë mund të garantohet, dhe sjellja anormale e përdoruesve falas nuk do të ndikojë tek të tjerët. Ky është izolim i vërtetë i domenit të dështimit, duke mos lejuar "fqinjët" të ndërhyjnë me njëri-tjetrin.

• Leje native: Çdo ObjectSet mund të ketë një emër domain të pavarur. Kjo do të thotë se mund t'i jepni përdoruesit A një adresë ekskluzive vizite user-a.yourapp.com, në vend që të ekspozoni emrin e domain-it të të gjithë bucket-it. Më e zgjuar është dizajni i "dy bravave": brava e parë është një kredencial vizite e përkohshme (STS) e lëshuar nga ofruesi i shërbimeve cloud, duke kontrolluar lejet e vizitës në nivelin e aplikacionit; brava e dytë është emri i domain-it të pavarur të ObjectSet, duke e mbyllur kërkesën e vizitës në hapësirën e të dhënave të përdoruesit nga niveli i rrjetit. Kjo rrit ndjeshëm sigurinë e të dhënave.

• Monitorim nativ: Në panelin e monitorimit, nuk mund të shihni më vetëm të dhënat e përgjithshme të të gjithë bucket-it. Mund të dekompozoni grafikët e monitorimit sipas ObjectSet, duke vëzhguar qartë se cili përdorues fundor po kryen një numër të madh vizitash, në mënyrë që të merrni vendime të sakta operacionale dhe optimizuese.

• Zbritje e aftësive native: Politikat që mund të vendoseshin vetëm në nivelin e bucket-it në të kaluarën, tani mund të zbresin në çdo përdorues. Mund të vendosni cikle jetësore të ndryshme të të dhënave për përdorues të niveleve të ndryshme, ose të përdorni çelësa të ndryshëm enkriptimi për çdo ObjectSet, duke realizuar menaxhim më të detajuar dhe më të sigurt të të dhënave.

• Matje native: Dëshironi të dini se sa hapësirë ruajtëse zë çdo përdorues? Dëshironi të shpërndani me saktësi koston e ruajtjes për çdo përdorues? Tani bëhet e lehtë. Agent Bucket do të statistikojë automatikisht kapacitetin dhe përdorimin e çdo ObjectSet, duke i bërë faturat dhe ndarjet tuaja të qarta.

• Faturim nativ: Zhvilluesit mund të realizojnë lehtësisht ndarjen e kostove dhe të shtyjnë me saktësi kostot e gjeneruara nga ruajtja tek çdo përdorues fundor. Për shembull, tarifat diferenciale mund të tarifohen sipas raportit të kostove aktuale të gjeneruara nga përdoruesit e ndryshëm A, B dhe C, duke ofruar mbështetje të dhënash për komercializimin e Agentit.

• Kufi nativ i kapacitetit: Për të kontrolluar kostot operative të Agentit, mund të vendosni një Kuotë (kufi kapaciteti) për çdo ObjectSet. Pasi të arrihet vlera e paracaktuar, sistemi do të kufizojë përdoruesin të gjenerojë skedarë të rinj, duke shmangur abuzimin me burimet në skenarët multi-tenant nga rrënja.

• Inteligjencë native: Agent Bucket e lejon Agentin të dalë nga kufizimet e thjeshta "akses" të skedarëve tradicionalë, duke i dhënë Object-it inteligjencë native dhe duke mbështetur në mënyrë më efikase zhvillimin e një ndalese të Agentit. ObjectSet mund të aktivizojë indeksimin inteligjent me një klik, duke i ofruar Agentit aftësi pyetjesh dhe përgjigjesh multi-modale miqësore, duke zëvendësuar operacionet mekanike tradicionale Object CRUD; madje mbështet aktivizimin e modalitetit Agentself me një klik, duke lidhur vektorët, njohuritë, modelet dhe prompt-et, duke zbuluar drejtpërdrejt funksionet e nën-Agentëve të skenarëve, duke i lejuar zhvilluesit e Agentëve të sipërm të përqendrohen në krijimin e rrjedhës së punës kryesore të biznesit dhe duke çliruar plotësisht efikasitetin e shndërrimit inteligjent.

Sfidat teknike të sjella nga shpërthimi i shkallës së aplikimit

Agent Bucket ofron një mënyrë elegante dhe efikase për zhvilluesit e aplikacioneve për të menaxhuar të dhënat e qindra miliona përdoruesve fundorë duke futur konceptin nativ të ObjectSet. Asetet dixhitale të çdo përdoruesi ruhen në mënyrë të sigurt në ObjectSet-in e tij ekskluziv, duke realizuar natyrshëm izolimin, faturimin dhe menaxhimin e kuotave.

Me zgjerimin e shpejtë të shkallës së aplikimit, kompleksiteti i menaxhimit të grupeve masive, vështirësia e izolimit dhe pengesat fizike shfaqen në të njëjtën kohë:

• Problemi i menaxhimit të hierarkizuar të përdoruesve masivë: Kur aplikacionet menaxhojnë në mënyrë diferenciale një numër të madh burimesh dhe karakteristikash të përdoruesve të niveleve të ndryshme, ato duhet të projektojnë dhe zbatojnë vetë metadata hierarkike të përdoruesve dhe të lidhin çelësat e veçorive të ruajtjes së objekteve. Ndihma e zhvilluesve për të menaxhuar në mënyrë elegante hierarkinë e përdoruesve në konceptin nativ të Set-it është e rëndësishme për të përshpejtuar zbatimin e aplikacionit.## Sfidat e Shkallëzimit dhe Izolimit të të Dhënave

Në skenarët e aplikacioneve me shumë qira, shpesh hasim sfidat e mëposhtme:

• Kufizimet e kapacitetit të një grupi të vetëm: Edhe pse Agent Bucket mund të zgjerohet pafundësisht logjikisht, metadatat e tij ruhen në mënyrë të parazgjedhur në një grup të vetëm fizik. Kur numri i përgjithshëm i objekteve brenda një bucket arrin qindra miliarda ose edhe trilionë, kapaciteti fizik i një grupi të vetëm bëhet një kufi i pakalueshëm.

• Problemet e ndarjes së pikave të aksesit: Diversiteti i biznesit të Agentit dhe numri i madh i përdoruesve sjellin rreziqe më të mëdha sigurie dhe rreze shpërthimi në vetë pikat e aksesit. Si të bëhet planifikimi dinamik bazuar në diferencat e një numri të madh biznesesh dhe përdoruesish të ndryshëm, dhe të realizohen aftësi të diferencuara sigurie, izolimi dhe përshpejtimi bëhet një sfidë.

Set Tagging: Menaxhimi i Nivelizuar i Përdoruesve me Etiketa

ObjectSet ofron një mënyrë të lindur të menaxhimit të etiketave, duke lejuar zhvilluesit e Agentit të përdorin thjesht aftësinë e set tagging për të përfunduar qeverisjen e nivelizuar të përdoruesve; zhvilluesit mund t'i caktojnë çdo niveli përdoruesi të përcaktuar një tag, dhe të aktivizojnë kuota dhe karakteristika të ndryshme për çdo tag. Të gjitha ObjectSet-et e etiketuara me këtë tag do të aplikojnë kuotat dhe karakteristikat përkatëse. Le të ilustrojmë me tre nivele, V1, V2 dhe V3:

• V1: Niveli i parazgjedhur, përdorues falas, tagu i parazgjedhur për të gjitha ObjectSet-et, mund të konfigurohet për të ruajtur maksimumi 1GiB të dhëna, shpërndarja publike nuk mund të kalojë gjerësinë e brezit 100mbps, dhe shpejtësia e shkarkimit të një rryme të vetme kontrollohet në 1mbps;

• V2: Anëtarësi e paguar e nivelit fillestar, e konfiguruar për të ruajtur maksimumi 10GiB të dhëna, shpërndarja publike nuk mund të kalojë gjerësinë e brezit 10gbps, dhe shpejtësia e shkarkimit të një rryme të vetme kontrollohet në 10mbps;

• V3: Anëtarësi e paguar e nivelit të lartë, përveç ofrimit të një sasie më të madhe ruajtjeje dhe kuotave të shpërndarjes publike, ajo gjithashtu mbështet konfigurimin për të aktivizuar përshpejtimin shtesë të rrjetit të dobët publik dhe aftësitë e përshpejtimit të medias me performancë të lartë;

Zhvilluesit e Agentit mund të përdorin në mënyrë fleksibël etiketimin V1/V2/V3 për të menaxhuar burimet dhe karakteristikat me vlerë të shtuar që këta përdorues mund të përdorin, duke u bazuar në cikle të ndryshme zhvillimi të përdoruesve të ndryshëm.

Set Slice: Izolimi i Lindur i të Dhënave të Përdoruesve Masivë

Kur numri i Set-eve brenda një Agent Bucket arrin qindra miliona dhe numri i objekteve arrin qindra miliarda ose trilionë, vetë fakti që "të gjitha metadatat e një Bucket të vetëm janë të përqendruara në një grup KV" do të sjellë rreziqe të dyfishta të kapacitetit dhe performancës.

Set Slice ofron një ide të "mos-ndarjes logjike, ndarjes fizike":

• Nga pikëpamja logjike, ju ende menaxhoni vetëm një Agent Bucket.

• Fizikisht, metadatat ndahen në shumë Slice (copëza) bazuar në Set dhe gamën e emrave të objekteve brenda Set-it. Çdo Slice mund të ruhet në grupe të ndryshme. Set-et e shumta janë të izoluara natyrshëm, dhe një Set i vetëm zgjerohet horizontalisht.

Set Slice është një zgjerim dhe garanci e mëtejshme e aftësisë ObjectSet. Ai zgjidh në thelb problemin e zgjerimit të pafund fizik të kapacitetit, duke siguruar gjithashtu stabilitetin dhe konsistencën e modelit të menaxhimit ObjectSet të shtresës së sipërme.

• Kufijtë e menaxhimit të qëndrueshëm: Edhe nëse të dhënat e një Agent Bucket shtrihen nëpër shumë grupe fizike, ObjectSet është ende njësia themelore e vetme e lejeve, kuotave, faturimit dhe monitorimit. Politikat e konfiguruara nga zhvilluesit për ObjectSet (si kontrolli i aksesit, kufijtë e kapacitetit) do të hyjnë automatikisht në fuqi në të gjitha Slices përkatëse, pa pasur nevojë të shqetësoheni për shpërndarjen e të dhënave themelore.

• Një Set i vetëm mund të zgjerohet në mënyrë lineare: Kur sasia e të dhënave të një ObjectSet të caktuar rritet me shpejtësi, të dhënat e tij do të shpërndahen natyrshëm në shumë Slices. Me zgjerimin e përgjithshëm të grupit, kapaciteti i këtij ObjectSet gjithashtu rritet pa probleme dhe në mënyrë lineare. Zhvilluesit nuk kanë nevojë të kryejnë ndonjë operacion shkatërrues si ndarja ose migrimi në vetë ObjectSet.

• Izolimi i burimeve ndërmjet Set-eve: Duke shpërndarë objekte të gamave të ndryshme në grupe të ndryshme fizike, SetSlice realizon izolim burimesh me dimensione më të larta. Në kombinim me menaxhimin e kuotave të ObjectSet, mund të parandalojë në mënyrë efektive që rritja e të dhënave të një ObjectSet "super të madh" të zërë të gjitha burimet e një grupi të vetëm, duke ndikuar kështu në stabilitetin e ObjectSet-eve të tjera, duke e bërë rrezikun e përgjithshëm të kapacitetit të kontrollueshëm.- Logjikë e unifikuar dhe pajtueshmëri: Për bizneset dhe zhvilluesit, pavarësisht se sa Slice ka në shtresën e poshtme, ajo që ata përballen është gjithmonë një Agent Bucket me logjikë të unifikuar. Të gjitha metodat e funksionimit për bucket, ObjectSet dhe objekte mbeten të pandryshuara, duke realizuar zgjerimin fizik plotësisht transparent për aplikacionet e shtresës së sipërme.

Set AccessPoint: Izolimi i pikave të hyrjes për çdo përdorues

Agent Bucket mbështet hapjen e pikave të pavarura të hyrjes (emra domenesh të pavarur) për çdo ObjectSet, dhe zgjeron aftësitë e diferencuara të sigurisë, izolimit dhe shpejtimit në pikat e hyrjes. Sistemi duhet të mbështesë planifikimin e pikave të pavarura të hyrjes në shkallë miliarda dhe aftësitë e konfigurimit të diferencuar.

Emri i pavarur i domenit {$apid}.tos-objectset-ap.volces.com: Mbrojtje sigurie me dy nivele

• Niveli i parë Obscurity (Fshehtësi): Nën-domen i pavarur By User/ObjectSet, shpërndarje e entropisë së lartë apid, probabilitet jashtëzakonisht i ulët i përplasjes, pamundësia për të hamendësuar dhe shteruar hyrjen e përdoruesit specifik nga këndvështrimi i emrit të domenit;

• Niveli i dytë Containment (Përmbajtje): Zhvilluesit e Agent përdorin sts për të shpërndarë lejet e aksesit në nivel ObjectSet, edhe nëse sts rrjedh, mund të kontrollojë që fushëveprimi i aksesit të jetë i kufizuar brenda një periudhe të kufizuar vlefshmërie të një ObjectSet të caktuar;

Sistemi heuristik i planifikimit: Llogaritja e strategjisë së planifikimit të emrave të domenesh në shkallë miliarda

• Strategji e diferencuar e aksesit By user/ObjectSet:tag

• Përdorues të shumtë/ObjectSet shpërndahen automatikisht në pika të ndryshme hyrëse publike, numri i përdoruesve të prekur nga dështimi i një pike hyrëse të vetme është i kontrolluar

• Planifikim elastik në të gjitha rajonet, dështimi/mbingarkesa e çdo pike hyrëse të vetme përfundon automatikisht zhvendosjen e paketimit të trafikut

• Përdoruesit e shpërndarjes së shpejtimit publik, vendosin etiketën e shpejtimit të transmetimit publik, planifikojnë automatikisht hyrjen e shpejtimit

• Përdoruesit e rrezikshëm publik, vendosin etiketën e rrezikut, planifikojnë automatikisht hyrjen e izolimit publik dhe ulin kuotën e gjerësisë së brezit publik

• Përdoruesit e klasës së ndër-domenit të rrjetit të brendshëm, vendosin etiketën e ndër-domenit, planifikojnë automatikisht rrugën e shpejtimit të linjës së dedikuar të rrjetit të brendshëm

• Përdoruesit e përshpejtuesit lokal, vendosin etiketën e përshpejtuesit, montohen automatikisht përshpejtuesin lokal

Nga asistenti i programimit te disku cloud AI, mundësitë e pafundme të Agent Bucket

Agent Bucket ofron një zgjidhje të plotë për Agent, dhe skenarët e aplikimit të dizajnit të ObjectSet shkojnë shumë përtej kësaj. Mund të zgjerohet lehtësisht në të gjitha aplikacionet që duhet t'u ofrojnë shërbime një numri të madh përdoruesish fundorë:

• Depo e kodit: Në të kaluarën, kur ndërmarrjet ose individët strehonin kodin në cloud, ata shpesh duhej të ndërtonin një shtresë "sistemi qiramarrës" mbi ruajtjen e objekteve për të arritur izolimin e llogarisë dhe kontrollin e lejeve. Tani, një ObjectSet ekskluziv mund t'i caktohet çdo zhvilluesi për të mbledhur në mënyrë unike depon e kodit, artefaktet e ndërtimit dhe varësitë. Agent Skills gjithashtu përshtaten natyrshëm me ObjectSet. Ngarkimi, shkarkimi dhe shpërndarja e Skills ofrohet nga ObjectSet me izolim të fortë, duke shmangur ndërhyrjen e fqinjëve gjatë ekzekutimit të Agent.

• Albumi fotografik i ndërmarrjes/disku cloud: Shërbimet tradicionale të albumeve fotografike ose disqeve cloud shpesh i përziejnë fotot e të gjithë përdoruesve në të njëjtin bucket dhe i dallojnë përdoruesit përmes prefikseve. Kjo jo vetëm që është e ndërlikuar për t'u menaxhuar, por gjithashtu e prirur ndaj "efektit të fqinjit". Bazuar në ObjectSet, fotot dhe videot e çdo përdoruesi bien në Set-in e tyre përkatës, dhe kulmet e aksesit nuk ndërhyjnë me njëri-tjetrin. Mund të vendosni gjithashtu kufij të kapacitetit, strategji rezervimi dhe metoda enkriptimi për përdoruesit, duke arritur vërtet "çdo person ka një album fotografik cloud të sigurt dhe të kontrollueshëm".

• Hadoop Data Warehouse: Në data warehouse të ndërmarrjes, linja të ndryshme biznesi dhe baza të ndryshme të të dhënave shpesh ndajnë burime në të njëjtën ruajtje themelore. Duke hartuar çdo bazë të të dhënave në një ObjectSet, ndërmarrjet mund të realizojnë izolimin dhe kontrollin e kuotave sipas bazës së të dhënave mbi ruajtjen e unifikuar. Në veçanti, ObjectSet ofron një shtresë shtesë lejesh në TOS, duke ofruar izolim dhe kontroll të lejeve për bazat e të dhënave dhe tabelat e ruajtura në TOS pa ndryshuar Proton-in ekzistues në TOS. - Platforma e pritjes së modeleve: Në skenarët e pritjes së modeleve të mëdha, çdo model jo vetëm që ka vëllim të madh, por gjithashtu mund të korrespondojë me versione, pesha dhe konfigurime të ndryshme të inferencës. Krijimi i një ObjectSet për çdo model mund të paketojë dhe presë peshat e modelit, Tokenizer, skedarët e konfigurimit dhe të dhënat e vlerësimit të lidhura në të njëjtin hapësirë. Ana e operacioneve mund të vendosë strategji të ndryshme enkriptimi, strategji rezervimi dhe kontroll të gjerësisë së brezit për modele të ndryshme, dhe në të njëjtën kohë të përdorë aftësitë e matjes amtare për të statistizuar koston e vërtetë të përdorimit të çdo modeli, duke ofruar një bazë për faturimin dhe planifikimin e burimeve sipas dimensionit të modelit.

• Shërbimi SaaS i të dhënave: Platformat e shpërndarjes së të dhënave që adresojnë një numër të madh përdoruesish fundorë shpesh duhet të ndërveprojnë me shumë ofrues të të dhënave në të njëjtën kohë, duke siguruar që kufijtë e të dhënave të secilës palë të jenë të qarta dhe duke shmangur rrezikun e performancës "një kovë e madhe zvarrit të gjithë". Me Agent Bucket, çdo ofrues i të dhënave mund të ketë ObjectSet-in e vet, duke menaxhuar në mënyrë unike të dhënat origjinale dhe rezultatet e përpunuara, dhe më pas duke përdorur emra domenesh dhe gjerësi bande të pavarura, kuota QPS, për të ofruar garanci të diferencuara shërbimi dhe kufizim të trafikut për ofrues të ndryshëm, duke realizuar "një platformë, shumë ofrues, të izoluar nga njëri-tjetri dhe bashkëpunim i kontrollueshëm" infrastrukturë e shpërndarjes së të dhënave.

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/