Agent Bucket: Több billió objektumot tároló, natív Agent tároló

Az AI Agentek gombamód szaporodnak manapság, a fejlesztők pedig soha nem látott sebességgel építenek fantáziadús, intelligens alkalmazásokat. A kódolásban segítő programozási asszisztensektől kezdve a egyetlen mondattal egész filmet generáló alkotói eszközökön át a folyamatosan rendelkezésre álló személyi intelligens asszisztensekig az Agentek átalakítják a digitális világgal való interakciónkat. E hullám mögött egyre világosabbá válik egy konszenzus: a Serverless architektúrák (mint a Lambda), a nagy nyelvi modellek (LLM) és a felhőalapú tárolás (mint az S3, TOS) segítségével, a Vibe Codinggal kombinálva bárki 30 perc alatt gyorsan felépítheti saját AI Agentjét.

Az „használhatótól” a „jól használhatóig” az Agent fejlesztőknek még mindig le kell küzdeniük a nehézségeket a „játékszerektől” a „termelési szintű alkalmazásokig” való eljutás során. Ahogy a vállalkozás hatalmas felhasználói bázis felé halad, a fejlesztőknek egy rendkívül összetett kihívással kell szembenézniük: hogyan építsenek ki teljes körű tárolási megoldásokat hatalmas számú végfelhasználó számára az objektumtárolón? A legtöbb fejlesztő számára ez nem csak technikai akadály, hanem a az Agentek nagyméretű terjesztésének akadálya is. Az Agent Bucket célja, hogy az AI natív tárolási tervezés révén teljesen leegyszerűsítse a több bérlős rendszerek felépítésének folyamatát, és barátságosabb Agent képességeket biztosítson.

Amikor milliárdnyi felhasználó özönlik be, a hagyományos objektumtároló „nem elég”

Képzeld el, hogy kifejlesztettél egy vírusként terjedő AIGC alkalmazást. Minden felhasználó rengeteg képet, videót és ideiglenes fájlt generál és tárol. Fejlesztőként természetesen olyan kiforrott, skálázható objektumtárolási szolgáltatásokat választasz, mint az S3 és a TOS. De itt jön a kérdés: hogyan kezeljük az adatokat hatalmas számú felhasználó számára?

A S3 2022-es blogbejegyzése, a 《Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3》 két módszert mutat be: „minden bérlő külön S3 tárolót használ” és „előtag alapú elkülönítéssel megosztott S3 tárolót”:

• Hozzon létre egy külön „tárolót” (Bucket) minden felhasználó számára: Ez akkor működik, ha kevés a felhasználó, de amikor a felhasználók száma több tízezerre, több millióra nő, a tárolók száma gyorsan felrobban, a kezelési költségek és az erőforráskorlátok pedig elviselhetetlenek. Az S3 összesen 10 000 tárolót biztosít régiónként, de a népszerű AI képességekhez ez a 10 000 még messze nem elég.

• Ugyanazon a tárolón belül „előtaggal” különböztessük meg a felhasználókat: Ez lett a fő megoldás. Például az A felhasználó fájljai mind user-a/ előtaggal kezdődnek, a B felhasználó fájljai pedig user-b/ előtaggal, mintha a számítógépen mappákkal kezelnénk a fájlokat. Az objektumtárolóban azonban nincsenek natív mappák, ez a megoldás a „K-V” tárolórendszerben a „közös előtag” (Prefix) segítségével különbözteti meg a több bérlőt.

Ez a „tároló” vagy „előtag” alapú megoldás az elmúlt tíz évben széles körben elterjedt. De a következő problémák merülnek fel:

• Több bérlős elkülönítés: Az összes felhasználó adata ugyanabban a tárolóban keveredik, egy felhasználó rendellenesen magas frekvenciájú hozzáférése befolyásolhatja az összes többi felhasználót, ami „szomszédhatást” okoz. A teljesítményelkülönítésről, a hibaelkülönítésről szó sem lehet.

• Jogosultságkezelés: A bonyolult jogosultságkezelési szabályzatokat (IAM Policy) nehéz karbantartani, és könnyen előfordulhat konfigurációs hiba, ami a felhasználói adatok véletlen eléréséhez vezet, különösen akkor, ha más felhőszolgáltatásokkal kell interakcióba lépni, a kockázat még nagyobb.

• Költségátláthatóság: Nehéz pontosan megmondani, hogy egy-egy felhasználó mennyi tárhelyet használt fel, és mennyi forgalmi költséget generált. Amikor a felhasználás alapján szeretnél díjat felszámítani a fizető felhasználóknak, a számlázás és a mérés zavarossá válik. Miért tűnik néhány alapvető igény megvalósítása az objektumtárolóban az Agent fejlesztők számára "nehézkesnek"? Ennek mélyebb oka, hogy a jelenlegi felhőnatív architektúrában hatalmas űr tátong az S3-hoz hasonló "objektumtárolók" és a hagyományos "fájlrendszerek" között. Az objektumtárolás (S3/TOS) lényege a "laposság", a tervezés eredeti célja a hatalmas mennyiségű adat egyszerű tárolása, olyan, mint egy hatalmas raktár, amelynek kapacitása szinte korlátlan, de logikai szerkezete rendkívül egyszerű. Hiányzik belőle a natív, fejlett könyvtárkezelés, a finom szemcsézettségű metaadat-vezérlés és a valódi bérlőérzékelés. Amikor a fejlesztők megpróbálnak egy "lapos" S3-on, keménykódolt előtagok segítségével egy "háromdimenziós" több-bérlős fájlrendszert szimulálni, akkor valójában egy "statikus KV-tárolót" használunk egy "könyvtárszemantikával és erős elkülönítéssel rendelkező" Agent alkalmazás fájlhozzáférési módjának kiszolgálására. Ez azt jelenti, hogy az Agentnek extra tokeneket kell felhasználnia a fájlok kezeléséhez, valamint a több-bérlős jogosultságok és elkülönítés megoldásához. Ezek az extra tokenfelhasználások mind azt mutatják, hogy az S3 által definiált egyszerű tárolási szolgáltatás nem elég egyszerű az Agent számára.

A 2025-ös S3 blog 《Design patterns for multi-tenant access control on Amazon S3》 tovább részletezi az S3 Access Point-ot. Ez azt jelenti, hogy több virtuális hálózati hozzáférési pont hozható létre, és minden hozzáférési ponthoz egyedi hozzáférési pont szabályzat konfigurálható, ami a hálózati ütemezés szintjén kínál megoldásokat a több-bérlős forgatókönyvekhez.

Agent Wonderland

Egy ideális Agent fejlesztő, amikor AI Agentet fejleszt, egy teljesen szerver nélküli Agentet építhet a következőkre alapozva: "Agent SDK + tárolás + MaaS szolgáltatás":

• Az Agent teljesen szerver nélkül futhat

• A Vibe Coding módszerrel kombinálhatja a meglévő termékképességeket egy Agent létrehozásához

• Csak az "ADK" python szkriptet kell karbantartania

• A tároláshoz objektumtárolót használ

• Az AI képességekhez a 豆包-t használja

• Elméletileg nincs ECS vagy más példány típusú termék

Ezzel egyidejűleg a tárolónak a következő képességeket kell biztosítania:

• Az Agentnek rendelkeznie kell egy objektum szemantikájú tárolóval (fájlok mentéséhez), amely több-bérlős hozzáférést biztosít, milliókkal kezdve, és milliárdokra bővíthető

• Az Agent minden felhasználó számára független területet biztosíthat (több üzletág között, az üzletágak vagy az uid-k nevei ismétlődhetnek)

• Az Agent közvetlenül konfigurálhatja az egyes felhasználók sávszélességét, és konfigurálhatja a felhasználói objektumok teljes méretének felső határát

• Az Agent felhasználónként számlázhat, figyelhet és megfigyelhet

• Az Agent konfigurálhatja az egyes felhasználók fájljainak hozzáférési szabályzatát

Agent Bucket: "Több-bérlős natív" géneket fecskendez az AI Agentbe

Ennek a problémának a gyökeres megoldása érdekében egy teljesen új objektumtárolási paradigmát javasolunk – az Agent Bucketet. Ennek a legfontosabb újítása, hogy a hagyományos "bucket" és "objektum" közé egy új, natív erőforrás szintet vezet be: az objektumgyűjteményt.

Ennek a tervnek a lényege rendkívül egyszerű: minden végfelhasználójához rendeljen egy dedikált ObjectSet-et. Az ObjectSetet úgy képzelheti el, mint egy kifejezetten minden felhasználó számára létrehozott "adat széfet" vagy "felhőalapú személyes teret". Logikailag az Ön (fejlesztő) Bucketjéhez tartozik, de fizikailag és menedzsment szempontjából saját, független "személyiséggel" és "életciklussal" rendelkezik.Az Agent Bucket minden tárolója 100 millió ObjectSet-et támogat, ami azt jelenti, hogy nyugodtan szolgálhatsz ki több százmillió végfelhasználót, mintha minden végfelhasználó a saját, független tárolóterében "élne", anélkül, hogy a többfelhasználós tárolókezelés miatt kellene aggódnod.

ObjectSet tervezés – Agent-barát képességek

Az Agent Bucketben az ObjectSet nem csupán egy újabb szintet jelent, hanem a többfelhasználós környezetek legnehezebb igényeit is azonnal használható, natív képességekké alakítja. Amint az adatok tulajdonjoga az ObjectSet szintjén tisztázódik, egy sor korábban nehezen megvalósítható képesség válik magától értetődővé.

• Natív izoláció: Az ObjectSet szintjén minden felhasználóhoz beállíthatsz független QPS-, sávszélesség-korlátozásokat és kapacitáskvótákat. A fizető felhasználók élménye garantált, a nem fizető felhasználók rendellenes viselkedése pedig nem érinti a többieket. Ez valódi hibatartomány-izoláció, amely megakadályozza, hogy a "szomszédok" zavarják egymást.

• Natív jogosultságok: Minden ObjectSet rendelkezhet saját domainnel. Ez azt jelenti, hogy a felhasználó A-nak adhatsz egy user-a.yourapp.com dedikált hozzáférési címet, ahelyett, hogy az egész tároló domainjét tennéd közzé. Még okosabb a "két zár" kialakítása: az első zár egy felhőszolgáltató által kiadott ideiglenes hozzáférési igazolás (STS), amely az alkalmazásszintű hozzáférési jogosultságokat szabályozza; a második zár pedig az ObjectSet független domainje, amely hálózati szinten zárolja a hozzáférési kérelmeket a felhasználó saját adattartományában. Ez nagymértékben növeli az adatbiztonságot.

• Natív monitorozás: A monitorozó irányítópulton többé nem csak a teljes tároló áttekintő adatait láthatod. Az ObjectSet szerint lebontva láthatod a monitorozó grafikonokat, tisztán áttekintve, hogy melyik végfelhasználó generál nagy mennyiségű forgalmat, így pontos üzemeltetési és optimalizálási döntéseket hozhatsz.

• Natív képesség-leszállítás: A korábban csak tárolószinten beállítható szabályzatok mostantól minden felhasználóhoz leszállíthatók. Különböző szintű felhasználókhoz különböző adatéletciklusokat állíthatsz be, vagy minden ObjectSet-hez különböző titkosítási kulcsokat használhatsz, ami finomabb és biztonságosabb adatkezelést tesz lehetővé.

• Natív mérés: Szeretnéd tudni, hogy mennyi tárhelyet foglal el egy felhasználó? Szeretnéd pontosan elosztani a tárolási költségeket minden felhasználó között? Mostantól ez gyerekjáték. Az Agent Bucket automatikusan statisztikát készít minden ObjectSet kapacitásáról és használatáról, így a számlázás és a költségmegosztás egyértelművé válik.

• Natív számlázás: A fejlesztők könnyen megvalósíthatják a költségmegosztást, és a tárolásból származó költségeket pontosan visszavezethetik minden végfelhasználóhoz. Például differenciált díjat számíthatsz fel az A, B és C felhasználók által ténylegesen felmerült költségek arányában, ezzel adatokat szolgáltatva az Agent üzleti hasznosításához.

• Natív kapacitáskorlát: Az Agent működési költségeinek ellenőrzése érdekében minden ObjectSet-hez beállíthatsz Quota-t (kapacitáskorlátot). Ha eléri az előre beállított értéket, a rendszer korlátozza, hogy a felhasználó új fájlokat hozzon létre, így gyökerestől elkerülhető az erőforrások túlzott használata a többfelhasználós környezetekben.

• Natív intelligencia: Az Agent Bucket lehetővé teszi, hogy az Agent kilépjen a hagyományos fájlok egyszerű "tárolása és lekérése" korlátaiból, natív intelligenciát adva az Object-nek, hatékonyabban támogatva az Agent egyablakos fejlesztését. Az ObjectSet egyetlen kattintással bekapcsolhatja az intelligens indexelést, natív, felhasználóbarát, többmódusú kérdés-válasz képességeket biztosítva az Agent számára, felváltva a hagyományos Object CRUD mechanikus műveleteit; sőt, támogatja az Agentself mód egyetlen kattintással történő bekapcsolását, összekapcsolva a vektorokat, a tudást, a modelleket és a promptokat, közvetlenül feltárva a helyzethez kötött al-Agent funkciókat, lehetővé téve a felső szintű Agent fejlesztők számára, hogy a fő üzleti munkafolyamat létrehozására összpontosítsanak, teljes mértékben felszabadítva az intelligens pénzzé tétel hatékonyságát.

Az alkalmazásméret robbanásszerű növekedése által támasztott technikai kihívások

Az Agent Bucket az ObjectSet natív koncepciójának bevezetésével elegáns és hatékony módot kínál az alkalmazásfejlesztőknek a több milliárd végfelhasználói adat kezelésére. Minden felhasználó digitális eszközei biztonságosan, a saját ObjectSet-jében vannak tárolva, természetes módon megvalósítva az izolációt, a számlázást és a kvótakezelést.

Az alkalmazásméret gyors növekedésével a hatalmas mennyiségű Set kezelésének összetettsége, az izoláció nehézsége és a fizikai szűk keresztmetszetek egyszerre jelentkeznek:

• Hatalmas felhasználói bázis hierarchikus kezelésének problémája: Amikor az alkalmazás nagyszámú, különböző szintű felhasználó erőforrásait és funkcióit differenciáltan kezeli, saját maga kell megterveznie és megvalósítania a felhasználók hierarchikus metaadatait, és hozzá kell rendelnie az objektumtárolási funkciókapcsolókat. A Set natív koncepciójának felhasználásával a felhasználói hierarchia elegáns kezelése a fejlesztők számára fontos az alkalmazás bevezetésének felgyorsításához.- Egyetlen fürt kapacitás szűk keresztmetszete: Bár az Agent Bucket logikailag korlátlanul bővíthető, a metaadatai alapértelmezés szerint egyetlen fizikai fürtben tárolódnak. Amikor a bucketben lévő objektumok száma eléri a százmilliárdos vagy akár a billió nagyságrendet, az egyetlen fürt fizikai kapacitása leküzdhetetlen felső határt jelent.

• Hozzáférési pont megosztási probléma: Az Agent üzleti sokszínűsége és a hatalmas felhasználói bázis nagyobb biztonsági kockázatot és robbanási sugarat jelent a hozzáférési pont számára. Nehéz kérdés, hogy a nagyszámú különböző üzleti és felhasználói igények alapján hogyan lehet dinamikus ütemezést végezni, és differenciált biztonsági, elkülönítési és gyorsítási képességeket megvalósítani.

Set Tagging: Címkézéssel történő felhasználói szintű menedzsment

Az ObjectSet natív címkézési menedzsmentet biztosít, amely lehetővé teszi az Agent fejlesztők számára, hogy egyszerűen használják a set tagging képességeket a felhasználók szintű irányításának befejezéséhez. A fejlesztők minden meghatározott felhasználói szinthez hozzárendelhetnek egy címkét, és minden címkéhez különböző kvótákat és funkciókat engedélyezhetnek. Az összes, ezzel a címkével ellátott ObjectSet a megfelelő kvótákat és funkciókat fogja alkalmazni. Példaként a V1, V2 és V3 szinteket használva:

• V1: Alapértelmezett szint, ingyenes felhasználók, az összes ObjectSet alapértelmezett címkéje, konfigurálható legfeljebb 1GiB adat tárolására, a nyilvános hálózati terjesztés nem haladhatja meg a 100mbps sávszélességet, az egyfolyamos letöltési sebesség 1mbps-re van korlátozva;

• V2: Belépő szintű fizetős tagság, konfigurálható legfeljebb 10GiB adat tárolására, a nyilvános hálózati terjesztés nem haladhatja meg a 10gbps sávszélességet, az egyfolyamos letöltési sebesség 10mbps-re van korlátozva;

• V3: Haladó fizetős tagság, a nagyobb tárolási és nyilvános hálózati terjesztési kvóták mellett támogatja a további nyilvános hálózati gyenge hálózati gyorsítás és a nagy teljesítményű adathordozó gyorsítás engedélyezését is;

Az Agent fejlesztők rugalmasan használhatják a V1/V2/V3 tagginget a különböző felhasználók különböző fejlődési ciklusaihoz, hogy kezeljék az ezeknek a felhasználóknak elérhető erőforrásokat és hozzáadott értékű funkciókat.

Set Slice: Hatalmas felhasználói adatok natív izolációja

Amikor egy Agent Bucketben lévő Set-ek száma eléri a százmilliót, az objektumok száma pedig a százmilliárdos, billió nagyságrendet, akkor az a tény, hogy "az összes Bucket metaadata egyetlen KV fürtben van központosítva", kapacitás- és teljesítménykockázatot is jelent.

A Set Slice egy "logikailag nem bont, fizikailag bont" megközelítést kínál:

• Logikailag nézve továbbra is csak egy Agent Bucketet kezel.

• Fizikailag a Set és a Set-en belüli objektumnevek tartománya alapján a metaadatok több Slice-ra (szeletre) vannak osztva. Minden Slice különböző fürtökön tárolható, a több Set természetesen elkülönül, az egy Set pedig vízszintesen bővíthető.

A Set Slice az ObjectSet képességeinek további kiterjesztése és biztosítása. A háttérben megoldja a fizikai kapacitás korlátlan bővítésének problémáját, miközben biztosítja a felső szintű ObjectSet menedzsment modell stabilitását és konzisztenciáját.

• Stabil menedzsment határ: Még akkor is, ha egy Agent Bucket adatai több fizikai fürtön terjednek el, az ObjectSet továbbra is az engedélyek, kvóták, számlázás és monitorozás egyetlen alapegysége. A fejlesztők által az ObjectSet-hez konfigurált szabályzatok (például hozzáférés-vezérlés, kapacitáskorlát) automatikusan érvénybe lépnek az összes kapcsolódó Slice-on, anélkül, hogy aggódniuk kellene az adatok eloszlása miatt.

• Az egy Set lineárisan bővíthető: Amikor egy ObjectSet adatmennyisége gyorsan növekszik, az adatok természetesen több Slice-ra oszlanak el. A teljes fürt bővítésével az ObjectSet kapacitása is zökkenőmentesen és lineárisan növekszik, anélkül, hogy a fejlesztőknek bármilyen bontást vagy migrációt kellene végezniük magán az ObjectSet-en.

• Kereszt Set erőforrás izoláció: A különböző tartományú objektumok különböző fizikai fürtökön való elosztásával a SetSlice magasabb dimenziójú erőforrás izolációt valósít meg. Az ObjectSet kvótamenedzsmentjével kombinálva hatékonyan megakadályozható, hogy egy "szuper nagy" ObjectSet adatnövekedése kiszorítsa az egyetlen fürt összes erőforrását, ezáltal befolyásolva a többi ObjectSet stabilitását, és ezáltal a teljes kapacitáskockázatot kezelhetővé téve.- Logikai egységesség és kompatibilitás: Az üzleti felhasználók és a fejlesztők számára, függetlenül attól, hogy hány Slice van a háttérben, mindig egy logikailag egységes Agent Bucket-tel találkoznak. A bucketekkel, ObjectSetekkel és objektumokkal kapcsolatos összes művelet változatlan marad, ami a fizikai bővítés teljes átláthatóságát valósítja meg a felső rétegbeli alkalmazások számára.

Set AccessPoint: Minden felhasználó hozzáférési pontjának elkülönítése

Az Agent Bucket támogatja az önálló hozzáférési pontok (önálló domainek) engedélyezését minden ObjectSethez, és ezen a hozzáférési ponton kiterjeszti a differenciált biztonsági, elkülönítési és gyorsítási képességeket. A rendszernek ehhez több százmillió önálló hozzáférési pont ütemezését és differenciált konfigurációs képességét kell támogatnia.

Önálló hozzáférési domain {$apid}.tos-objectset-ap.volces.com: Kétszintű biztonsági védelem

• Első szint Obscurity (rejtőzködés): Felhasználó/ObjectSet szerinti önálló aldomain, apid nagy entrópiájú hashelés, rendkívül alacsony ütközési valószínűség, a hozzáférési domain szempontjából nem lehet kitalálni és kimeríteni egy adott felhasználói belépési pontot;

• Második szint Containment (visszafogottság): Az Agent fejlesztők sts-t használnak az ObjectSet szintű hozzáférési jogosultságok terjesztésére, még ha az sts kiszivárog is, a hozzáférési tartomány korlátozható egy adott ObjectSet korlátozott érvényességi idejére;

Heurisztikus ütemező rendszer: Több százmilliós domain ütemezési stratégia számítás

• Felhasználó/ObjectSet:tag szerinti differenciált hozzáférési stratégia

• Több felhasználó/ObjectSet automatikusan eloszlik a különböző nyilvános hálózati belépési pontokon, az egyetlen belépési pont meghibásodása által érintett felhasználók száma ellenőrzött

• Teljes körű rugalmas ütemezés, bármely egyetlen belépési pont meghibásodása/túlterhelése automatikusan befejezi a forgalom dobozolását és áthelyezését

• Nyilvános hálózati gyorsítási terjesztési típusú felhasználók, nyilvános hálózati átviteli gyorsítási tag hozzáadása, automatikus gyorsítási belépési pont ütemezése

• Nyilvános hálózati kockázati típusú felhasználók, kockázati tag hozzáadása, automatikus nyilvános hálózati elkülönítési belépési pont ütemezése és a nyilvános hálózati sávszélesség kvóta csökkentése

• Belső hálózati tartományok közötti típusú felhasználók, tartományok közötti tag hozzáadása, automatikus belső hálózati dedikált vonali gyorsítási útvonal ütemezése

• Helyi gyorsító felhasználók, gyorsító tag hozzáadása, automatikus helyi gyorsító csatlakoztatása

A programozási asszisztenstől az AI felhőlemezig, az Agent Bucket végtelen lehetőségei

Az Agent Bucket teljes körű megoldást kínál az Agent számára, és az ObjectSet tervezési alkalmazási forgatókönyvei messze túlmutatnak ezen, könnyen kiterjeszthető minden olyan alkalmazásra, amelynek nagyszámú végfelhasználót kell kiszolgálnia:

• Kódtár: A múltban, amikor a vállalatok vagy magánszemélyek kódot tároltak a felhőben, gyakran egy "bérlői rendszert" kellett építeniük az objektumtároló fölé, hogy megvalósítsák a fiókok elkülönítését és a jogosultságok vezérlését. Mostantól minden fejlesztőhöz hozzárendelhető egy exkluzív ObjectSet, amely egységesen tartalmazza a kódtárat, a build termékeket és a függőségeket. Az Agent Skills természetesen alkalmazkodik az ObjectSethez, a Skills feltöltése, letöltése és terjesztése erős elkülönítést biztosít az ObjectSeten keresztül, elkerülve az Agent futásidejű szomszédsértést.

• Vállalati fotóalbum hálózati lemez: A hagyományos fotóalbum vagy hálózati lemez szolgáltatások gyakran összekeverik az összes felhasználó fényképét ugyanabban a bucketben, és előtagokkal különböztetik meg a felhasználókat, ami nemcsak bonyolult kezelést eredményez, hanem "szomszédhatást" is okozhat. Az ObjectSeten alapulva minden felhasználó fényképei és videói a saját Setjükbe kerülnek, a hozzáférési csúcsok nem zavarják egymást, és a felhasználók beállíthatnak kapacitáskorlátokat, biztonsági mentési stratégiákat és titkosítási módszereket is, valóban megvalósítva, hogy "mindenkinek legyen egy biztonságos, ellenőrizhető felhőalbuma".

• Hadoop adattárház: A vállalati adattárházban a különböző üzletágak és adatbázisok gyakran ugyanazon az alsó rétegbeli tárolón osztoznak az erőforrásokon. Ha minden adatbázist egy ObjectSetre képezünk le, a vállalatok megvalósíthatják az adatbázis szerinti elkülönítést és kvóta vezérlést egy egységes tárolón. Különösen az ObjectSet biztosít egy további jogosultsági réteget a TOS-on, amely a meglévő Proton on TOS megváltoztatása nélkül elkülönítést és jogosultságok vezérlését biztosítja a TOS-on tárolt Database és Tables számára.- Modellhoszting platform: A nagyméretű modellek hosztingja során minden modell nemcsak hatalmas méretű, hanem különböző verziókkal, súlyokkal és következtetési konfigurációkkal is rendelkezhet. Minden modellhez létrehozva egy ObjectSet-et, a modell súlyai, a Tokenizer, a konfigurációs fájlok és a kapcsolódó értékelési adatok ugyanabban a térben csomagolhatók és hosztolhatók. Az üzemeltetési oldalon különböző titkosítási, biztonsági mentési és sávszélesség-szabályozási stratégiák állíthatók be a különböző modellekhez. Ugyanakkor a natív mérési képességekkel statisztikailag nyomon követhető az egyes modellek valós használati költsége, ami alapot nyújt a modell-dimenziós számlázáshoz és erőforrás-ütemezéshez.

• Adat SaaS szolgáltatás: A nagyszámú végfelhasználót kiszolgáló adatforgalmazási platformoknak gyakran egyszerre kell számos adatszolgáltatóval kapcsolatot tartaniuk. Biztosítani kell az egyes felek adatainak egyértelmű határait, és el kell kerülni a "egy nagy vödör mindenkit lehúz" teljesítménykockázatot. Az Agent Bucket segítségével minden adatszolgáltató saját ObjectSet-tel rendelkezhet, amelyben egységesen kezelheti a nyers adatokat és a feldolgozási eredményeket. A független domainnévvel és sávszélességgel, valamint a QPS-kvótával differenciált szolgáltatást és sebességkorlátozást biztosíthat a különböző szolgáltatók számára, megvalósítva egy "egy platform, több szolgáltató, egymástól elkülönítve, mégis szabályozható együttműködés" adatforgalmazási infrastruktúrát.

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/