Agent Bucket: Teratason Agentin alkuperäinen tallennuslokero

AI Agenttien noustessa kuin sieniä sateella, kehittäjät rakentavat ennennäkemättömällä vauhdilla mielikuvituksellisia älykkäitä sovelluksia. Ohjelmointiavustajista, jotka auttavat sinua kirjoittamaan koodia, elokuvia yhdestä lauseesta luoviin työkaluihin ja jatkuvasti valmiina oleviin henkilökohtaisiin älykkäisiin avustajiin, Agentit muokkaavat tapaamme olla vuorovaikutuksessa digitaalisen maailman kanssa. Tämän aallon takana on yhä selkeämpi yhteisymmärrys: Serverless-arkkitehtuurin (kuten Lambda), suurten kielimallien (LLM) ja pilvitallennuksen (kuten S3, TOS) avulla yhdistettynä Vibe Codingiin, kuka tahansa voi nopeasti rakentaa oman AI Agentin 30 minuutissa.

"Käytettävissä olevasta" "hyödylliseen", Agent-kehittäjien on ylitettävä vaikeuksia siirtyessään "leluista" "tuotantotason sovelluksiin". Liiketoiminnan siirtyessä valtavalle käyttäjämäärälle kehittäjien on kohdattava erittäin monimutkainen haaste: miten rakentaa täydellinen tallennusratkaisu valtavalle määrälle loppukäyttäjiä objektitallennuksessa? Useimmille kehittäjille tämä ei ole vain tekninen kynnys, vaan myös kuilu, joka estää Agentin laajamittaisen jakelun. Agent Bucket pyrkii yksinkertaistamaan monivuokrajärjestelmien rakentamisprosessia perusteellisesti AI-natiivin tallennussuunnittelun avulla ja tarjoamaan ystävällisempiä Agent-ominaisuuksia.

Kun miljardit käyttäjät ryntäävät sisään, perinteinen objektitallennus "ei riitä"

Kuvittele, että olet kehittänyt erittäin suositun AIGC-sovelluksen. Jokainen käyttäjä luo ja tallentaa suuren määrän kuvia, videoita ja väliaikaisia tiedostoja. Kehittäjänä valitset luonnollisesti kypsät ja skaalautuvat objektitallennuspalvelut, kuten S3 ja TOS. Mutta tässä tulee ongelma: miten hallita tietoja valtavalle määrälle käyttäjiä?

S3:n blogissa vuodelta 2022 "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3" kuvataan kaksi tapaa, "jokaiselle vuokralaiselle käytetään erillistä S3-lokeroa" ja "etuliitteellä eristetty jaettu S3-lokero":

• Luo jokaiselle käyttäjälle erillinen "lokero" (Bucket): Tämä on mahdollista, kun käyttäjiä on vähän, mutta kun käyttäjämäärä kasvaa kymmeniin tuhansiin tai miljooniin, lokeroiden määrä kasvaa nopeasti räjähdysmäisesti, ja hallintakustannukset ja resurssirajoitukset ovat sietämättömiä. S3 tarjoaa yhteensä 10 000 lokeron kiintiön koko alueelle, mutta suosituille AI-ominaisuuksille 10 000 ei riitä läheskään.

• Käytä samaa lokeroa "etuliitteellä" erottaaksesi käyttäjät: Tästä on tullut valtavirran ratkaisu. Esimerkiksi käyttäjän A tiedostot alkavat kaikki user-a/, kun taas käyttäjän B tiedostot alkavat user-b/, aivan kuten tiedostojen hallinta tietokoneella kansioiden avulla. Objektitallennuksessa ei kuitenkaan ole natiiveja kansioita, tämä ratkaisu erottaa useita vuokralaisia "K-V"-tallennusjärjestelmässä "yhteisen etuliitteen" (Prefix) avulla.

Tätä "lokeroon" tai "etuliitteeseen" perustuvaa ratkaisua on käytetty laajalti viimeiset kymmenen vuotta. Mutta siinä on seuraavia ongelmia:

• Monivuokrauksen eristys: Kaikkien käyttäjien tiedot ovat sekaisin samassa lokerossa, yhden käyttäjän epänormaalin korkea taajuus voi vaikuttaa kaikkiin muihin käyttäjiin ja aiheuttaa "naapurivaikutuksen". Suorituskyvyn eristys ja vianeristys eivät ole mahdollisia.

• Käyttöoikeuksien hallinta: Monimutkaisia käyttöoikeuskäytäntöjä (IAM Policy) on vaikea ylläpitää, ja on helppo tehdä konfiguraatiovirheitä, jotka johtavat käyttäjätietojen tahattomaan käyttöön, erityisesti kun on tarpeen olla vuorovaikutuksessa muiden pilvipalveluiden kanssa, riskialttius on suurempi.

• Kustannusten selkeys: On vaikea tietää tarkalleen, kuinka paljon tallennustilaa kukin käyttäjä on kuluttanut ja kuinka paljon liikennettä on syntynyt. Kun haluat veloittaa maksullisilta käyttäjiltä käytön perusteella, laskutus ja mittaus muuttuvat sekavaksi sotkuksi.Miksi nämä näennäisesti perusvaatimukset, Agent-kehittäjät toteuttavat objektitallennuksessa niin "raskaasti"? Syy on syvällä siinä, että nykyisessä pilvinatiiviarkkitehtuurissa on valtava tyhjiö S3:n kaltaisen "objektitallennuksen" ja perinteisen "tiedostojärjestelmän" välillä. Objektitallennuksen (S3/TOS) ydin on "litistäminen", ja sen alkuperäinen tarkoitus on yksinkertainen massadatan tallennus, kuin valtava varasto. Vaikka kapasiteetti on lähes rajaton, looginen rakenne on erittäin yksinkertainen. Siitä puuttuu natiivi korkean tason hakemistohallinta, hienojakoinen metadatan hallinta ja todellinen vuokralaisen tunnistus. Kun kehittäjät yrittävät simuloida "litistetyssä" S3:ssa "kolmiulotteista" monivuokralaistiedostojärjestelmää kovakoodaamalla etuliitteitä, käytämme itse asiassa "staattista KV-tallennusta" tukemaan "hakemistosemantiikkaa ja vahvaa eristystä" vaativaa Agent-sovelluksen tiedostojen käyttöä. Toisin sanoen Agentin on käytettävä ylimääräisiä tokeneita tiedostojen hallintaan ja hallittava monivuokralaisten oikeuksia ja eristystä. Nämä ylimääräiset tokenit osoittavat, että S3:n määrittelemä yksinkertainen tallennuspalvelu ei ole riittävän yksinkertainen Agentille.

Vuoden 2025 S3-blogi "Design patterns for multi-tenant access control on Amazon S3" selittää tarkemmin S3 Access Pointin. Tämä tarkoittaa, että voidaan luoda useita virtuaalisia verkkoyhteyspisteitä ja jokaiselle yhteyspisteelle voidaan määrittää mukautettu yhteyspistekäytäntö, jolloin monivuokalaistilanteisiin on joitain ratkaisuja verkon ajoitustasolla.

Agent Wonderland

Ihanteellinen Agent-kehittäjä voi AI Agentia kehittäessään rakentaa täysin palvelimettoman Agentin "Agent SDK + tallennus + MaaS-palvelu" -pohjalta:

• Agent voi toimia täysin palvelimettomasti

• Agent voidaan rakentaa yhdistämällä olemassa olevia tuoteominaisuuksia Vibe Coding -menetelmällä

• Tarvitsee ylläpitää vain "ADK:n" python-skriptejä

• Tallennus käyttää objektitallennusta

• AI-ominaisuudet käyttävät Douboa

• Teoriassa ei ole ECS:ää tai muita instanssityyppisiä tuotteita

Samalla tallennuksen on tarjottava seuraavat ominaisuudet:

• Agentilla voi olla objektisemantiikan tallennus (tiedostojen tallentamiseen), joka tarjoaa monivuokralaisliitettävyyden, alkaen miljoonista ja laajennettavissa satoihin miljooniin

• Agent voi tarjota jokaiselle käyttäjälle erillisen tilan (useiden liiketoimintojen välillä, liiketoimintojen tai uid:ien nimet voivat olla samoja)

• Agent voi suoraan määrittää jokaisen käyttäjän kaistanleveyden ja käyttäjän objektien kokonaiskokorajan

• Agent voi laskuttaa, valvoa ja tarkkailla käyttäjän mukaan

• Agent voi määrittää jokaisen käyttäjän tiedostojen käyttöoikeuskäytännöt

Agent Bucket: Injektoi AI Agenttiin "natiivin monivuokralais" -geenin

Tämän ongelman ratkaisemiseksi perusteellisesti olemme ehdottaneet täysin uutta objektitallennusparadigmaa - Agent Bucket. Sen keskeinen innovaatio on uuden natiivin resurssitason käyttöönotto perinteisten "bucketien" ja "objektien" välillä: objektikokoelma.

Tämän suunnittelun ydinajatus on erittäin yksinkertainen: yhdistä jokaiselle loppukäyttäjällesi oma ObjectSet. Voit ajatella ObjectSetin olevan "datan kassakaappi" tai "pilvipohjainen henkilökohtainen tila", joka on luotu jokaiselle käyttäjälle. Se kuuluu loogisesti sinun (kehittäjän) Bucketillesi, mutta fyysisesti ja hallinnollisesti sillä on oma itsenäinen "persoonallisuus" ja "elinkaari". Agent Bucket tukee 100 miljoonaa ObjectSetiä per säiliö, mikä tarkoittaa, että voit palvella jopa satoja miljoonia loppukäyttäjiä vaivattomasti, aivan kuin jokainen loppukäyttäjä "elää" omassa erillisessä tallennustilassaan, ilman että sinun tarvitsee enää tuskailla monivuokralaisen tallennustilan hallinnan kanssa.

ObjectSet-suunnittelu – Agent-ystävälliset ominaisuudet

Agent Bucketin ObjectSet ei ole pelkästään lisätty taso, vaan se muuttaa myös monivuokralaisympäristöjen hankalimmat tarpeet heti käyttövalmiiksi natiiviominaisuuksiksi. Kun datan omistajuus on määritelty ObjectSet-tasolla, aiemmin vaikeasti toteutettavat ominaisuudet toteutuvat luonnostaan.

• Natiivi eristys: ObjectSet-tasolla voit asettaa jokaiselle käyttäjälle itsenäiset QPS-, kaistanleveysrajoitukset ja kapasiteettikiintiöt. Maksavien käyttäjien kokemus voidaan taata, eivätkä ilmaiskäyttäjien poikkeavat toiminnot vaikuta muihin. Tämä on todellista vika-alueen eristystä, joka estää "naapureita" häiritsemästä toisiaan.

• Natiivi käyttöoikeus: Jokaisella ObjectSetillä voi olla oma itsenäinen verkkotunnus. Tämä tarkoittaa, että voit antaa käyttäjälle A yksilöllisen osoitteen, kuten user-a.yourapp.com, sen sijaan, että paljastaisit koko tallennussäiliön verkkotunnuksen. Vielä nerokkaampi on "kaksi lukkoa" -suunnittelu: Ensimmäinen lukko on pilvipalveluntarjoajan myöntämä väliaikainen käyttöoikeustodistus (STS), joka hallitsee sovellustason käyttöoikeuksia; toinen lukko on ObjectSetin itsenäinen verkkotunnus, joka lukitsee verkkopyynnöt käyttäjän omaan datatilaan. Tämä parantaa huomattavasti datan turvallisuutta.

• Natiivi valvonta: Valvontanäkymässä et näe enää vain koko säiliön yleiskatsaustietoja. Voit jakaa valvontakaaviot ObjectSetin mukaan ja saada selkeän käsityksen siitä, mikä loppukäyttäjä suorittaa suuria määriä pääsyjä, jotta voit tehdä tarkkoja toiminta- ja optimointipäätöksiä.

• Natiivi kykyjen siirto alaspäin: Aiemmin vain säiliötasolla asetettavat käytännöt voidaan nyt siirtää alas jokaiselle käyttäjälle. Voit asettaa eri tasoisille käyttäjille erilaisia datan elinkaariaikoja tai käyttää eri salausavaimia jokaiselle ObjectSetille, mikä mahdollistaa tarkemman ja turvallisemman datanhallinnan.

• Natiivi mittaus: Haluatko tietää, kuinka paljon tallennustilaa kukin käyttäjä käyttää? Haluatko jakaa tallennuskustannukset tarkasti jokaiselle käyttäjälle? Nyt se on helppoa. Agent Bucket tilastoi automaattisesti jokaisen ObjectSetin kapasiteetin ja käytön, mikä tekee laskutuksestasi ja kustannusten jaosta selkeää.

• Natiivi laskutus: Kehittäjät voivat helposti toteuttaa kustannusten jakamisen ja kohdistaa tallennuksesta aiheutuvat kustannukset tarkasti jokaiselle loppukäyttäjälle. Esimerkiksi, veloita eri tavalla A-, B- ja C-käyttäjien todellisten kustannusosuuksien perusteella, mikä tarjoaa datatukea Agentin kaupallistamiselle.

• Natiivi kapasiteettiraja: Agentin toimintakustannusten hallitsemiseksi voit asettaa jokaiselle ObjectSetille kiintiön (kapasiteettirajan). Kun ennalta asetettu arvo on saavutettu, järjestelmä rajoittaa kyseistä käyttäjää luomasta uusia tiedostoja, mikä estää resurssien väärinkäytön monivuokralaisympäristöissä.

• Natiivi älykkyys: Agent Bucket antaa Agentille mahdollisuuden ylittää perinteisen tiedostojen yksinkertaisen "tallennuksen ja noudon" rajoitukset, antaa Objectille natiivin älykkyyden ja tukee tehokkaammin Agentin yhden luukun kehitystä. ObjectSet voi yhdellä napsautuksella ottaa käyttöön älykkään indeksoinnin, joka tarjoaa Agentille natiiviystävällisen multimodaalisen kyselykyvyn, joka korvaa perinteisen Object CRUD:n mekaanisen toiminnan; se tukee jopa yhdellä napsautuksella Agentself-tilan aktivointia, yhdistää vektoreita, tietoja, malleja ja kehotteita ja paljastaa suoraan skenaariopohjaisia ali-Agent-toimintoja, jolloin ylemmän tason Agent-kehittäjät voivat keskittyä pääliiketoiminnan työnkulun luomiseen ja vapauttaa täysin älykkään rahaksi muuttamisen tehokkuuden.

Sovellusten mittakaavan räjähdysmäinen kasvu tuo mukanaan teknisiä haasteita

Agent Bucket tarjoaa ObjectSet-natiivikonseptin avulla sovelluskehittäjille tyylikkään ja tehokkaan tavan hallita satojen miljoonien loppukäyttäjien dataa. Jokaisen käyttäjän digitaalinen omaisuus on turvallisesti tallennettu heidän omaan ObjectSetiinsä, mikä mahdollistaa luonnollisen eristyksen, laskutuksen ja kiintiönhallinnan.

Sovellusten mittakaavan nopean laajenemisen myötä valtavan Set-määrän hallinnan monimutkaisuus, eristämisen vaikeus ja fyysiset pullonkaulat tulevat samanaikaisesti esiin:

• Valtavan käyttäjämäärän luokittelun hallintaongelma: Kun sovellukset hallitsevat eri tasoisten käyttäjien resursseja ja ominaisuuksia eri tavoin, niiden on suunniteltava ja toteutettava itse käyttäjien luokittelumetadata ja liitettävä ne objektitallennuksen ominaisuuskytkimiin. Setin natiivikonseptin avulla kehittäjien auttaminen hallitsemaan käyttäjäluokittelua tyylikkäästi on tärkeää sovellusten käyttöönoton nopeuttamiseksi. - Yhden klusterin kapasiteettipullonkaula: Vaikka Agent Bucket on loogisesti rajattomasti laajennettavissa, sen metatiedot tallennetaan oletusarvoisesti yhteen fyysiseen klusteriin. Kun bucketin sisällä olevien objektien kokonaismäärä saavuttaa satoja miljardeja tai jopa biljoonia, yhden klusterin fyysisestä kapasiteetista tulee ylitsepääsemätön yläraja.

• Liityntäpisteiden jakamisongelma: Agentin liiketoiminnan monimuotoisuus ja valtava käyttäjämäärä tuovat liityntäpisteille itselleen suuremman turvallisuusriskin ja räjähdysvaaran. Haasteena on, miten toteuttaa dynaaminen ajoitus suuren määrän eri liiketoimintojen ja käyttäjien erojen perusteella, jotta voidaan saavuttaa eriytynyt turvallisuus, eristys ja nopeutus.

Set Tagging: Käyttäjien luokittelun tagipohjainen hallinta

ObjectSet tarjoaa alkuperäisen tagipohjaisen hallintatavan, jonka avulla Agent-kehittäjät voivat helposti käyttää set tagging -ominaisuutta käyttäjien luokittelun hallintaan. Kehittäjät voivat määrittää kullekin määritellylle käyttäjätasolle tagin ja ottaa kullekin tagille käyttöön erilaisia kiintiöitä ja ominaisuuksia. Kaikki ObjectSetit, jotka on merkitty tällä tagilla, käyttävät vastaavia kiintiöitä ja ominaisuuksia. Esimerkkinä V1-, V2- ja V3-tasot:

• V1: Oletustaso, ilmaiset käyttäjät, kaikkien ObjectSetien oletustagi, voidaan määrittää tallentamaan enintään 1 GiB dataa, julkinen verkkolevitys ei saa ylittää 100 mbps kaistanleveyttä, yhden streamin latausnopeutta rajoitetaan 1 mbps:

• V2: Aloittelijatason maksullinen jäsenyys, määritetty tallentamaan enintään 10 GiB dataa, julkinen verkkolevitys ei saa ylittää 10 gbps kaistanleveyttä, yhden streamin latausnopeutta rajoitetaan 10 mbps:

• V3: Edistynyt maksullinen jäsenyys, tarjoaa suuremman tallennus- ja julkisen verkkolevityskiintiön lisäksi myös tuen ylimääräisen julkisen verkon heikon verkon kiihdytyksen ja suorituskykyisen median kiihdytyksen käyttöönotolle;

Agent-kehittäjät voivat joustavasti käyttää V1/V2/V3-taggingia hallitakseen näiden käyttäjien käytettävissä olevia resursseja ja lisäarvo-ominaisuuksia eri käyttäjien eri kehitysvaiheissa.

Set Slice: Massiivisen käyttäjädatan alkuperäinen eristys

Kun Agent Bucketin sisällä olevien Setien määrä saavuttaa satoja miljoonia ja objektien määrä satoja miljardeja tai biljoonia, itse asiassa "kaikki yhden Bucketin metatiedot on keskitetty yhteen KV-klusteriin" aiheuttaa sekä kapasiteetti- että suorituskykyriskejä.

Set Slice tarjoaa ajattelutavan "loogisesti ei jaettu, fyysisesti jaettu":

• Loogisesti katsottuna hallitset edelleen vain yhtä Agent Buckettia.

• Fyysisesti metatiedot jaetaan useisiin Sliceihin (viipaleisiin) Setin ja Setin sisällä olevien objektien nimien alueen mukaan. Jokainen Slice voidaan tallentaa eri klustereihin, useat Setit ovat luonnollisesti eristettyjä ja yksittäinen Set on vaakasuunnassa laajennettavissa.

Set Slice on ObjectSet-ominaisuuksien jatke ja suojaus. Se ratkaisee pohjimmiltaan fyysisen kapasiteetin rajattoman laajennuksen ongelman ja varmistaa samalla ylemmän tason ObjectSet-hallintamallin vakauden ja johdonmukaisuuden.

• Hallintarajat ovat vakaat: Vaikka yhden Agent Bucketin data ulottuisi useisiin fyysisiin klustereihin, ObjectSet on edelleen ainoa perusyksikkö käyttöoikeuksille, kiintiöille, laskutukselle ja valvonnalle. Kehittäjien ObjectSetille määrittämät käytännöt (kuten pääsynhallinta, kapasiteetin yläraja) tulevat automaattisesti voimaan kaikissa asiaankuuluvissa Sliceissa, eikä heidän tarvitse huolehtia pohjana olevan datan jakautumisesta.

• Yksittäinen Set on lineaarisesti laajennettavissa: Kun tietyn ObjectSetin datamäärä kasvaa nopeasti, sen data jakautuu luonnollisesti useisiin Sliceihin. Kun koko klusterin kapasiteettia laajennetaan, myös kyseisen ObjectSetin kapasiteetti kasvaa saumattomasti ja lineaarisesti. Kehittäjien ei tarvitse suorittaa kyseiselle ObjectSetille mitään jakamis- tai siirtotoimenpiteitä.

• Resurssien eristys Setien välillä: Jakamalla eri alueiden objektit eri fyysisiin klustereihin SetSlice toteuttaa korkeamman ulottuvuuden resurssien eristyksen. Yhdessä ObjectSetin kiintiöhallinnan kanssa voidaan tehokkaasti estää tietyn "superkäyttäjän" ObjectSetin datan kasvua viemästä yhden klusterin kaikkia resursseja, mikä vaikuttaa muiden ObjectSetien vakauteen ja tekee kokonaiskapasiteettiriskistä hallittavan. - Looginen yhtenäisyys ja yhteensopivuus: Liiketoiminnan ja kehittäjien kannalta, riippumatta siitä, kuinka monta Slicea pohjalla on, he kohtaavat aina loogisesti yhtenäisen Agent Bucketin. Kaikki toiminnot, jotka kohdistuvat bucketiin, ObjectSetiin ja objekteihin, pysyvät ennallaan, mikä mahdollistaa fyysisen laajennuksen täydellisen läpinäkyvyyden ylemmille sovelluksille.

Set AccessPoint: Eristä jokaisen käyttäjän pääsypiste

Agent Bucket tukee itsenäisten pääsypisteiden (itsenäisten verkkotunnusten) avaamista jokaiselle ObjectSetille ja laajentaa niihin eriytettyjä suojaus-, eristys- ja nopeutusominaisuuksia. Järjestelmän on tuettava miljardiluokan itsenäisten pääsypisteiden ajoitusta ja eriytettyjä konfiguraatioita.

Itsenäinen pääsyverkkotunnus {$apid}.tos-objectset-ap.volces.com: Kaksitasoinen suojaus

• Ensimmäinen taso Obscurity (peittävyys): Käyttäjä-/ObjectSet-kohtainen itsenäinen aliverkkotunnus, apid korkea entropia hajautus, erittäin pieni törmäystodennäköisyys, tietyn käyttäjän sisäänpääsyä ei voida arvata tai tyhjentää pääsyverkkotunnuksen näkökulmasta;

• Toinen taso Containment (rajoittavuus): Agent-kehittäjät käyttävät sts:ää ObjectSet-tason käyttöoikeuksien jakamiseen. Vaikka sts vuotaisi, sen käyttöaluetta voidaan hallita rajoitetusti tietyn ObjectSetin voimassaolon aikana;

Heuristinen ajoitusjärjestelmä: Miljardiluokan verkkotunnusten ajoitusstrategian laskenta

• Käyttäjä-/ObjectSet:tag-kohtainen eriytetty pääsystrategia

• Useat käyttäjät/ObjectSetit hajautetaan automaattisesti eri julkisiin verkkoportteihin, ja yksittäisen portin vikaantumisen vaikutus käyttäjämäärään on hallinnassa

• Täydellinen alueellinen joustava ajoitus, minkä tahansa yksittäisen portin vikaantuminen/ylikuormitus suorittaa automaattisesti liikenteen pakkaamisen ja siirtämisen

• Julkisen verkon nopeutusjakeluluokan käyttäjät, joilla on julkisen verkon siirtonopeutustagi, ajoitetaan automaattisesti nopeutusporttiin

• Julkisen verkon riskiluokan käyttäjät, joilla on riskitagi, ajoitetaan automaattisesti julkisen verkon eristysporttiin ja julkisen verkon kaistanleveyskiintiötä pienennetään

• Sisäisen verkon verkkotunnusten välisen luokan käyttäjät, joilla on verkkotunnusten välinen tagi, ajoitetaan automaattisesti sisäisen verkon erikoislinjan nopeutusreittiin

• Paikallisen alueen kiihdyttimen käyttäjät, joilla on kiihdytintagi, liitetään automaattisesti paikallisen alueen kiihdyttimeen

Ohjelmointiavustajasta AI-pilvitallennukseen, Agent Bucketin rajattomat mahdollisuudet

Agent Bucket tarjoaa täydellisen ratkaisun Agenteille, ja ObjectSetin suunnittelusovellusskenaariot ovat paljon enemmän kuin tämä. Sitä voidaan helposti laajentaa kaikkiin sovelluksiin, jotka tarvitsevat palveluita valtavalle määrälle loppukäyttäjiä:

• Koodivarasto: Aiemmin, kun yritykset tai yksityishenkilöt isännöivät koodia pilvessä, heidän piti usein rakentaa "vuokralaisjärjestelmä" objektitallennuksen päälle, jotta tilien eristys ja käyttöoikeuksien hallinta olisi mahdollista. Nyt jokaiselle kehittäjälle voidaan määrittää oma ObjectSet, joka sisältää koodivaraston, rakennustuotteet ja riippuvuudet yhtenäisesti. Agent Skills on myös luonnostaan sovitettu ObjectSetiin. Skillsien lataus, lataaminen ja jakelu tarjoavat vahvan eristyksen ObjectSetin kautta, mikä välttää Agentin suoritusajan häiriöt.

• Yrityksen valokuva-albumi/verkkolevy: Perinteiset valokuva-albumi- tai verkkolevypalvelut sekoittavat usein kaikkien käyttäjien valokuvat samaan bucketiin ja erottavat käyttäjät etuliitteen avulla, mikä ei ole vain monimutkaista hallita, vaan myös altis "naapuruusvaikutukselle". ObjectSetin perusteella jokaisen käyttäjän valokuvat ja videot sijoitetaan omiin Setteihinsä, ja ruuhka-ajat eivät häiritse toisiaan. Voit myös asettaa kapasiteettirajoituksia, varmuuskopiointikäytäntöjä ja salausmenetelmiä käyttäjien mukaan, jotta "jokaisella on turvallinen ja hallittavissa oleva pilvialbumi".

• Hadoop-datavarasto: Yrityksen datavarastossa eri liiketoimintalinjat ja eri tietokannat jakavat usein resursseja samassa pohjatallennuksessa. Määrittelemällä jokainen tietokanta ObjectSetiksi yritykset voivat toteuttaa eristyksen ja kiintiöiden hallinnan tietokantakohtaisesti yhtenäisen tallennuksen päällä. Erityisesti ObjectSet tarjoaa TOS:ssa ylimääräisen käyttöoikeustason, joka tarjoaa eristyksen ja käyttöoikeuksien hallinnan TOS:ssa tallennetuille tietokannoille ja tauluille muuttamatta nykyistä Proton on TOS -tilannetta. - Mallien hallintaympäristö: Suurten kielimallien hallinnassa jokainen malli ei ole vain kooltaan valtava, vaan sillä voi olla myös eri versioita, painotuksia ja päättelykokoonpanoja. Luomalla jokaiselle mallille ObjectSetin, mallin painotukset, Tokenizer, konfiguraatiotiedostot ja niihin liittyvät arviointitiedot voidaan paketoida ja hallita samassa tilassa. Ylläpidon puolella voidaan asettaa erilaisia salauskäytäntöjä, varmuuskopiointikäytäntöjä ja kaistanleveyden hallintaa eri malleille. Samalla alkuperäisen mittauskyvyn avulla voidaan tilastoida kunkin mallin todelliset käyttökustannukset, mikä luo perustan mallikohtaiselle laskutukselle ja resurssienhallinnalle.

• Data SaaS -palvelu: Massiivisten loppukäyttäjien datan jakelualustat joutuvat usein olemaan yhteydessä moniin datan tarjoajiin. On varmistettava, että kaikkien osapuolten datan rajat ovat selkeät, ja vältettävä "yksi suuri tynnyri vetää kaikki alas" -suorituskykyriski. Agent Bucketin avulla jokaisella datan tarjoajalla voi olla oma ObjectSet, joka hallitsee yhtenäisesti raakadataa ja prosessoituja tuloksia. Lisäksi erillisten verkkotunnusten ja kaistanleveyden sekä QPS-kiintiöiden avulla voidaan tarjota erilaisia palvelutakuita ja rajoituksia eri tarjoajille, mikä mahdollistaa "yhden alustan, useita tarjoajia, eristettyä mutta hallittua yhteistyötä" datan jakeluinfrastruktuurin.

Viitteet:

• 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/