Agent Bucket: Billion-Scale Agent Native Storage Bucket

In today's world where AI Agents are emerging like mushrooms after rain, developers are building imaginative intelligent applications at an unprecedented speed. From programming assistants that help you write code, to creative tools that generate a movie from a single sentence, to personal intelligent assistants that are always on standby, Agents are reshaping the way we interact with the digital world. Behind this wave, a consensus is becoming increasingly clear: with the help of Serverless architectures (such as Lambda), large language models (LLM), and cloud storage (such as S3, TOS), combined with Vibe Coding, anyone can quickly build their own AI Agent in 30 minutes.

From "usable" to "easy to use", Agent developers still need to overcome difficulties in the transition from "toy" to "production-level application". As business moves towards massive users, developers have to face an extremely complex challenge: how to build a complete storage solution for massive end users on object storage? For most developers, this is not only a technical threshold, but also a gap that hinders the large-scale distribution of Agents. Agent Bucket aims to completely simplify the construction process of multi-tenant systems through AI-native storage design and provide more friendly Agent capabilities.

When hundreds of millions of users pour in, traditional object storage is "not enough"

Imagine you've developed a wildly popular AIGC application. Each user will generate and store a large number of images, videos, and temporary files. As a developer, you will naturally choose mature and scalable object storage services such as S3 and TOS. But here's the problem: how do you manage data for massive users?

The 2022 S3 blog 《Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3》 describes two ways, "Use a separate S3 bucket for each tenant" and "Shared S3 bucket isolated by prefix":

• Create a separate "bucket" for each user: This is feasible when the number of users is small, but when the number of users grows to tens of thousands or millions, the number of buckets will explode rapidly, and the management cost and resource limitations will be unbearable. S3 provides a total of 10,000 bucket quotas for the entire region, but for the hot AI capabilities, 10,000 is far from enough.

• Use "prefix" to distinguish users in the same bucket: This has become the mainstream solution. For example, user A's files all start with user-a/, and user B's files start with user-b/, just like managing files with folders on a computer. However, there are no native folders in object storage. This solution distinguishes multi-tenants through "common prefix" in the "K-V" storage system.

This "bucket" or "prefix"-based solution has been widely adopted in the past decade. But there are the following problems:

• Multi-tenant isolation: All user data is mixed in the same bucket. An abnormal high-frequency access by one user may affect all other users, resulting in a "neighbor effect". Performance isolation and fault isolation are out of the question.

• Permission control: Complex permission policies (IAM Policy) are difficult to maintain, and it is easy to make configuration errors, resulting in accidental access to user data, especially when interacting with other cloud services, the risk exposure is greater.

• Cost clarity: It is difficult for you to accurately know how much storage space each user consumes and how much traffic costs are generated. When you want to charge paying users based on usage, billing and metering become a mess.Warum diese scheinbar grundlegenden Anforderungen, die Agent-Entwickler im Objektspeicher implementieren, etwas "schwerfällig" sind? Die Ursache liegt in der aktuellen Cloud-nativen Architektur, in der eine riesige Vakuumzone zwischen dem "Objektspeicher" wie S3 und dem traditionellen "Dateisystem" besteht. Der Objektspeicher (S3/TOS) ist im Wesentlichen "abgeflacht" und wurde ursprünglich für die einfache Speicherung riesiger Datenmengen entwickelt. Er ähnelt einem riesigen Lagerhaus, das zwar eine nahezu unbegrenzte Kapazität besitzt, aber in seiner logischen Struktur extrem einfach ist. Ihm fehlen native, erweiterte Verzeichnisverwaltungsfunktionen, eine feingranulare Metadatenkontrolle und eine echte Mandantenfähigkeit. Wenn Entwickler versuchen, auf dem "flachen" S3 durch hartcodierte Präfixe ein "dreidimensionales" Multi-Tenant-Dateisystem zu simulieren, verwenden wir tatsächlich einen "statischen KV-Speicher", um eine "Verzeichnissemantik und stark isolierte" Dateizugriffsmethode einer Agent-Anwendung zu unterstützen. Das bedeutet, dass der Agent zusätzlich Token verbrauchen muss, um Dateien zu verwalten und die Berechtigungen und die Isolation von Multi-Tenants zu steuern und zu lösen. Dieser zusätzliche Token-Verbrauch zeigt, dass der von S3 definierte einfache Speicherdienst für Agenten nicht einfach genug ist.

Der S3-Blog von 2025, 《Design patterns for multi-tenant access control on Amazon S3》, erläutert S3 Access Points weiter. Dies bedeutet, dass mehrere virtuelle Netzwerkzugangspunkte erstellt und für jeden Zugangspunkt eine benutzerdefinierte Zugangspunktrichtlinie konfiguriert werden kann, wodurch auf Netzwerkplanungsebene einige Lösungen für Multi-Tenant-Szenarien entstehen.

Agent Wonderland

Ein idealer Agent-Entwickler kann bei der Entwicklung eines KI-Agenten einen vollständig serverlosen Agenten auf der Grundlage von "Agent SDK + Speicher + MaaS-Dienst" erstellen:

• Agent kann vollständig serverlos ausgeführt werden

• Agent kann durch Vibe Coding die bestehenden Produktfähigkeiten kombinieren, um einen Agenten zu erstellen

• Es muss nur das Python-Skript des "ADK" verwaltet werden

• Der Speicher verwendet Objektspeicher

• Die KI-Fähigkeiten nutzen Doubao

• Theoretisch keine ECS oder andere instanzbasierte Produkte

Gleichzeitig muss der Speicher die folgenden Funktionen bereitstellen:

• Agent kann über einen Speicher mit Objektssemantik verfügen (Dateien speichern), der Multi-Tenant-Zugriff bietet, beginnend bei Millionen und erweiterbar auf Milliarden

• Agent kann jedem Benutzer einen unabhängigen Speicherplatz bereitstellen (zwischen mehreren Diensten können Dienst oder UID denselben Namen haben)

• Agent kann die Bandbreite jedes Benutzers direkt konfigurieren und die Obergrenze für die Gesamtgröße des Benutzerobjekts festlegen

• Agent kann Benutzer abrechnen, überwachen und beobachten

• Agent kann Zugriffsrichtlinien für die Dateien jedes Benutzers konfigurieren

Agent Bucket: KI-Agenten mit "nativem Multi-Tenant"-Gen ausstatten

Um dieses Problem grundlegend zu lösen, haben wir ein völlig neues Objektspeicherparadigma vorgeschlagen: Agent Bucket. Seine wichtigste Innovation ist die Einführung einer neuen nativen Ressourcenebene zwischen dem traditionellen "Bucket" und dem "Objekt": die Objektmenge.

Die Kernidee dieses Designs ist äußerst einfach: Ordnen Sie jedem Endbenutzer ein exklusives ObjectSet zu. Sie können sich ObjectSet als einen "Datensafe" oder "persönlichen Cloud-Speicher" vorstellen, der speziell für jeden Benutzer entwickelt wurde. Es gehört logisch zu Ihrem (Entwickler-)Bucket, aber physisch und verwaltungstechnisch hat es seine eigene unabhängige "Persönlichkeit" und seinen eigenen "Lebenszyklus".Agent Bucket unterstützt 100 Millionen ObjectSets pro Bucket. Das bedeutet, dass Sie problemlos Hunderten von Millionen Endbenutzern Dienste anbieten können, so als ob jeder Endbenutzer in seinem eigenen, unabhängigen Speicherbereich "lebt", ohne sich mehr um die Verwaltung von Multi-Tenant-Speichern kümmern zu müssen.

ObjectSet-Design – Agent-freundliche Fähigkeiten

In Agent Bucket ist ObjectSet nicht nur eine zusätzliche Ebene, sondern verwandelt auch die schwierigsten Anforderungen in Multi-Tenant-Szenarien in sofort einsatzbereite, native Funktionen. Sobald das Datenbesitzrecht auf der ObjectSet-Ebene festgelegt ist, werden eine Reihe von Funktionen, die in der Vergangenheit schwer zu implementieren waren, selbstverständlich.

• Native Isolation: Auf ObjectSet-Ebene können Sie für jeden Benutzer unabhängige QPS-, Bandbreitenbeschränkungen und Kapazitätskontingente festlegen. Die Erfahrung von zahlenden Benutzern kann gewährleistet werden, und das anormale Verhalten von kostenlosen Benutzern beeinträchtigt andere nicht. Dies ist eine echte Fehlerbereichsisolation, die verhindert, dass sich "Nachbarn" gegenseitig stören.

• Native Berechtigungen: Jeder ObjectSet kann eine unabhängige Domain haben. Dies bedeutet, dass Sie Benutzer A eine exklusive Zugriffsadresse user-a.yourapp.com geben können, anstatt die Domain des gesamten Speicher-Buckets preiszugeben. Noch cleverer ist das "Zwei-Schloss"-Design: Das erste Schloss ist ein temporäres Zugriffszertifikat (STS), das vom Cloud-Dienstanbieter ausgestellt wird und den Zugriff auf Anwendungsebene steuert. Das zweite Schloss ist die unabhängige Domain des ObjectSet, die Zugriffsanfragen von der Netzwerkebene aus auf den eigenen Datenbereich des Benutzers beschränkt. Dies erhöht die Datensicherheit erheblich.

• Native Überwachung: Auf dem Überwachungs-Dashboard sehen Sie nicht mehr nur die Übersichtsdaten des gesamten Buckets. Sie können Überwachungsdiagramme nach ObjectSet aufschlüsseln und klar erkennen, welcher Endbenutzer eine große Anzahl von Zugriffen durchführt, um präzise Betriebs- und Optimierungsentscheidungen zu treffen.

• Natives Capability-Sinking: Richtlinien, die in der Vergangenheit nur auf Bucket-Ebene festgelegt werden konnten, können jetzt auf jeden Benutzer heruntergebrochen werden. Sie können unterschiedliche Datenlebenszyklen für Benutzer unterschiedlicher Stufen festlegen oder unterschiedliche Verschlüsselungsschlüssel für jeden ObjectSet verwenden, um eine detailliertere und sicherere Datenverwaltung zu erreichen.

• Native Messung: Möchten Sie wissen, wie viel Speicherplatz jeder Benutzer belegt? Möchten Sie die Speicherkosten genau auf jeden Benutzer verteilen? Jetzt ist es ein Kinderspiel. Agent Bucket erfasst automatisch die Kapazität und Nutzung jedes ObjectSet, sodass Ihre Abrechnung und Aufteilung klar und deutlich sind.

• Native Abrechnung: Entwickler können die Kosten einfach verteilen und die durch die Speicherung verursachten Kosten präzise auf jeden Endbenutzer zurückführen. Beispielsweise können Sie je nach den tatsächlichen Kostenanteilen der verschiedenen Benutzer A, B und C unterschiedliche Gebühren erheben und so die Kommerzialisierung von Agenten datentechnisch unterstützen.

• Native Kapazitätsobergrenze: Um die Betriebskosten von Agenten zu kontrollieren, können Sie für jeden ObjectSet ein Quota (Kapazitätsobergrenze) festlegen. Sobald der voreingestellte Wert erreicht ist, beschränkt das System den Benutzer daran, weiterhin neue Dateien zu erstellen, wodurch Ressourcenmissbrauch in Multi-Tenant-Szenarien von vornherein vermieden wird.

• Native Intelligenz: Agent Bucket lässt Agenten aus den Beschränkungen des einfachen "Speichern und Abrufen" traditioneller Dateien ausbrechen, verleiht Objekten native Intelligenz und unterstützt die One-Stop-Entwicklung von Agenten effizienter. ObjectSet kann mit einem Klick die intelligente Indizierung aktivieren und Agenten native, benutzerfreundliche multimodale Frage- und Antwortfunktionen bieten, die den mechanischen Betrieb von traditionellem Object CRUD ersetzen. Es unterstützt sogar die Aktivierung des Agentself-Modus mit einem Klick, verbindet Vektoren, Wissen, Modelle und Prompts und gibt direkt szenariobasierte Sub-Agent-Funktionen aus, sodass sich Agent-Entwickler der oberen Ebene auf die Erstellung von Hauptgeschäftsworkflows konzentrieren und die Effizienz der intelligenten Monetarisierung voll ausschöpfen können.

Technische Herausforderungen durch die explosionsartige Zunahme der Anwendungsgröße

Agent Bucket bietet Anwendungsentwicklern durch die Einführung des nativen Konzepts ObjectSet eine elegante und effiziente Möglichkeit, die Daten von Hunderten von Millionen Endbenutzern zu verwalten. Die digitalen Assets jedes Benutzers werden sicher in seinem eigenen ObjectSet gespeichert, wodurch auf natürliche Weise Isolation, Abrechnung und Quotenverwaltung erreicht werden.

Mit der rasanten Ausweitung der Anwendungsgröße werden gleichzeitig die Komplexität der Verwaltung riesiger Mengen von Sets, der Schwierigkeitsgrad der Isolation und die physischen Engpässe deutlich:

• Problem der hierarchischen Verwaltung von Massenbenutzern: Wenn eine Anwendung die Ressourcen und Funktionen einer großen Anzahl von Benutzern unterschiedlicher Stufen differenziert verwalten muss, muss sie ihre eigenen hierarchischen Metadaten der Benutzer entwerfen und implementieren und die Funktionseinstellungen des Objektspeichers verknüpfen. Die Unterstützung von Entwicklern bei der eleganten Verwaltung der Benutzerhierarchie auf der Grundlage des nativen Konzepts von Sets ist wichtig, um die Anwendungsimplementierung zu beschleunigen.- Einzelcluster-Kapazitätsengpass: Obwohl Agent Buckets logisch unendlich erweiterbar sind, werden ihre Metadaten standardmäßig in einem einzelnen physischen Cluster gespeichert. Wenn die Gesamtzahl der Objekte in einem Bucket Milliarden oder sogar Billionen erreicht, wird die physische Kapazität des einzelnen Clusters zu einer unüberwindbaren Obergrenze.

• Problem der gemeinsamen Nutzung von Zugangspunkten: Die Vielfalt der Agent-Geschäfte und die riesige Anzahl von Benutzern bergen größere Sicherheitsrisiken und einen größeren Explosionsradius für den Zugangspunkt selbst. Wie man dynamische Planung basierend auf den Unterschieden zwischen einer großen Anzahl verschiedener Geschäfte und Benutzer durchführt, um differenzierte Sicherheits-, Isolations- und Beschleunigungsfunktionen zu realisieren, ist eine Herausforderung.

Set Tagging: Tag-basierte Verwaltung zur Benutzerklassifizierung

ObjectSet bietet eine native Tag-basierte Verwaltungsmethode, mit der Agent-Entwickler die Set-Tagging-Funktion einfach nutzen können, um die Benutzerklassifizierung zu vervollständigen. Entwickler können jeder definierten Benutzerstufe ein Tag zuordnen und für jedes Tag unterschiedliche Quoten und Funktionen aktivieren. Alle ObjectSets, die mit diesem Tag versehen sind, übernehmen die entsprechenden Quoten und Funktionen. Ein Beispiel mit den drei Stufen V1, V2 und V3:

• V1: Standardstufe, kostenlose Benutzer, das Standard-Tag für alle ObjectSets, konfigurierbar für maximal 1 GiB Datenspeicherung, öffentliche Verteilung darf 100 Mbit/s Bandbreite nicht überschreiten, Einzelstream-Downloadgeschwindigkeit auf 1 Mbit/s begrenzt;

• V2: Kostenpflichtige Mitgliedschaft der Einstiegsklasse, konfiguriert für maximal 10 GiB Datenspeicherung, öffentliche Verteilung darf 10 Gbit/s Bandbreite nicht überschreiten, Einzelstream-Downloadgeschwindigkeit auf 10 Mbit/s begrenzt;

• V3: Kostenpflichtige Premium-Mitgliedschaft, bietet neben größeren Speicher- und öffentlichen Verteilungsquoten auch die Möglichkeit, zusätzliche öffentliche Schwachnetzwerkbeschleunigung und Hochleistungsmedienbeschleunigung zu konfigurieren;

Agent-Entwickler können die V1/V2/V3-Tagging flexibel nutzen, um die Ressourcen und Mehrwertfunktionen zu verwalten, die diesen Benutzern in verschiedenen Entwicklungsphasen zur Verfügung stehen.

Set Slice: Native Isolation von Massenbenutzerdaten

Wenn die Anzahl der Sets in einem Agent Bucket die Milliardengrenze erreicht und die Anzahl der Objekte die Milliarden oder Billionen erreicht, birgt die Tatsache, dass "alle Metadaten eines einzelnen Buckets in einem KV-Cluster zentralisiert sind", ein doppeltes Risiko in Bezug auf Kapazität und Leistung.

Set Slice bietet einen Ansatz des "logischen Nicht-Aufteilens, physischen Aufteilens":

• Logisch gesehen verwalten Sie immer noch nur einen Agent Bucket.

• Physisch werden die Metadaten basierend auf dem Set und dem Bereich der Objektnamen im Set in mehrere Slices (Scheiben) unterteilt. Jeder Slice kann auf verschiedenen Clustern gespeichert werden, wobei mehrere Sets auf natürliche Weise isoliert sind und ein einzelnes Set horizontal skaliert werden kann.

Set Slice ist eine weitere Erweiterung und Absicherung der ObjectSet-Funktionalität. Es löst das Problem der unbegrenzten Erweiterung der physischen Kapazität auf der untersten Ebene und gewährleistet gleichzeitig die Stabilität und Konsistenz des ObjectSet-Verwaltungsmodells auf der oberen Ebene.

• Stabile Verwaltungsgrenzen: Selbst wenn die Daten eines Agent Buckets mehrere physische Cluster umfassen, ist ObjectSet immer noch die einzige Grundeinheit für Berechtigungen, Quoten, Abrechnung und Überwachung. Die für ObjectSet konfigurierten Richtlinien (z. B. Zugriffskontrolle, Kapazitätsobergrenze) werden automatisch auf allen zugehörigen Slices wirksam, ohne dass die Verteilung der zugrunde liegenden Daten berücksichtigt werden muss.

• Einzelnes Set kann linear skaliert werden: Wenn die Datenmenge eines ObjectSet schnell wächst, werden seine Daten auf natürliche Weise auf mehrere Slices verteilt. Mit der Erweiterung des Gesamtclusters wächst auch die Kapazität des ObjectSet nahtlos und linear, ohne dass der Entwickler zerstörerische Operationen wie das Aufteilen oder Migrieren des ObjectSet selbst durchführen muss.

• Ressourcenisolation über Sets hinweg: Durch die Verteilung von Objekten unterschiedlicher Bereiche auf verschiedene physische Cluster realisiert SetSlice eine höherdimensionale Ressourcenisolation. In Kombination mit der Quotenverwaltung von ObjectSet kann effektiv verhindert werden, dass das Datenwachstum eines "Super-Großkunden"-ObjectSet alle Ressourcen eines einzelnen Clusters beansprucht und so die Stabilität anderer ObjectSets beeinträchtigt, wodurch das Gesamtkapazitätsrisiko beherrschbar wird.- Logische Einheitlichkeit und Kompatibilität: Für Unternehmen und Entwickler ist der Agent Bucket immer ein logisch einheitlicher Bucket, unabhängig davon, wie viele Slices im Hintergrund vorhanden sind. Alle Operationen an Buckets, ObjectSets und Objekten bleiben unverändert, wodurch die physische Erweiterung für die darüber liegenden Anwendungen vollständig transparent wird.

Set AccessPoint: Isolierung des Zugangs für jeden Benutzer

Agent Bucket unterstützt die Aktivierung unabhängiger Zugangspunkte (unabhängige Domains) für jedes ObjectSet und erweitert die differenzierten Sicherheits-, Isolations- und Beschleunigungsfunktionen an den Zugangspunkten. Das System muss daher die Planung von Milliarden unabhängiger Zugangspunkte und differenzierte Konfigurationsfunktionen unterstützen.

Unabhängige Zugangsdomain {$apid}.tos-objectset-ap.volces.com: Zweistufiger Sicherheitsschutz

• Erste Stufe Obscurity (Verdeckung): Unabhängige Subdomain By User/ObjectSet, apid hoch-entropische Hash-Funktion, extrem geringe Kollisionswahrscheinlichkeit, es ist unmöglich, den spezifischen Benutzereingang über die Zugangsdomain zu erraten und aufzuzählen;

• Zweite Stufe Containment (Eindämmung): Agent-Entwickler verwenden sts, um ObjectSet-Zugriffsberechtigungen zu verteilen. Selbst wenn sts durchsickert, kann der Zugriffsbereich auf eine begrenzte Gültigkeitsdauer eines bestimmten ObjectSet beschränkt werden;

Heuristisches Planungssystem: Berechnung von Planungsstrategien für Milliarden von Domains

• Differenzierte Zugangsstrategie By user/ObjectSet:tag

• Automatische Verteilung mehrerer Benutzer/ObjectSets auf verschiedene öffentliche Netzwerkeingänge, die Anzahl der Benutzer, die von einem einzelnen Eingangsausfall betroffen sind, ist kontrolliert

• Elastische Planung in allen Regionen, automatische Verkehrsverpackung und -verschiebung bei Ausfall/Überlastung eines einzelnen Eingangs

• Benutzer der öffentlichen Netzwerkbeschleunigungsverteilung, die mit einem öffentlichen Netzwerkübertragungsbeschleunigungs-Tag versehen sind, planen automatisch den Beschleunigungseingang

• Benutzer der öffentlichen Netzwerkrisikoklasse, die mit einem Risikotag versehen sind, planen automatisch den öffentlichen Netzwerkisolierungseingang und reduzieren die Bandbreitenquote des öffentlichen Netzwerks

• Benutzer der internen Netzwerk-Cross-Domain-Klasse, die mit einem Cross-Domain-Tag versehen sind, planen automatisch den internen Netzwerk-Dedicated-Line-Beschleunigungspfad

• Benutzer des lokalen Beschleunigers, die mit einem Beschleuniger-Tag versehen sind, mounten automatisch den lokalen Beschleuniger

Vom Programmierassistenten zur KI-Cloud-Festplatte: Die unendlichen Möglichkeiten von Agent Bucket

Agent Bucket bietet eine umfassende Lösung für Agenten, und das Design der ObjectSets ist nicht auf diese Anwendungsszenarien beschränkt. Es kann problemlos auf alle Anwendungen erweitert werden, die eine Bereitstellung von Diensten für eine große Anzahl von Endbenutzern erfordern:

• Code-Repository: In der Vergangenheit mussten Unternehmen oder Einzelpersonen, die Code in der Cloud hosteten, oft ein "Tenant-System" auf dem Objektspeicher aufbauen, um Kontoisolierung und Zugriffskontrolle zu erreichen. Jetzt kann jedem Entwickler ein exklusives ObjectSet zugewiesen werden, um Code-Repositorys, Build-Artefakte und Abhängigkeiten einheitlich zu speichern. Agent Skills sind auch nativ an ObjectSets angepasst. Das Hochladen, Herunterladen und Verteilen von Skills erfolgt über ObjectSets mit starker Isolierung, um zu vermeiden, dass Agenten zur Laufzeit Nachbarn stören.

• Enterprise-Fotoalbum-Cloud-Festplatte: Traditionelle Fotoalbum- oder Cloud-Festplattendienste mischen oft die Fotos aller Benutzer in demselben Bucket und unterscheiden Benutzer anhand von Präfixen. Dies ist nicht nur komplex zu verwalten, sondern führt auch leicht zu "Nachbareffekten". Basierend auf ObjectSets werden die Fotos und Videos jedes Benutzers in ihren jeweiligen Sets gespeichert, und die Zugriffsspitzen beeinträchtigen sich nicht gegenseitig. Sie können auch Kapazitätslimits, Sicherungsrichtlinien und Verschlüsselungsmethoden pro Benutzer festlegen, um wirklich "jeder hat ein sicheres, kontrollierbares Cloud-Fotoalbum" zu erreichen.

• Hadoop Data Warehouse: In Enterprise Data Warehouses teilen sich verschiedene Geschäftsbereiche und verschiedene Datenbanken oft Ressourcen auf demselben zugrunde liegenden Speicher. Durch die Zuordnung jeder Datenbank zu einem ObjectSet können Unternehmen Isolierung und Quotensteuerung pro Datenbank auf einem einheitlichen Speicher realisieren. Insbesondere bietet ObjectSet eine zusätzliche Berechtigungsebene auf TOS, um Isolierung und Zugriffskontrolle für in TOS gespeicherte Datenbanken und Tabellen bereitzustellen, ohne das vorhandene Proton on TOS zu ändern. - Modellhosting-Plattform: In Szenarien für das Hosting großer Modelle ist jedes Modell nicht nur sehr umfangreich, sondern kann auch unterschiedliche Versionen, Gewichtungen und Inferenzkonfigurationen haben. Durch die Erstellung eines ObjectSet für jedes Modell können Modellgewichtungen, Tokenizer, Konfigurationsdateien und zugehörige Bewertungsdaten im selben Speicherplatz gebündelt und gehostet werden. Die Betriebsseite kann differenzierte Verschlüsselungsrichtlinien, Sicherungsrichtlinien und Bandbreitenkontrolle für verschiedene Modelle festlegen und gleichzeitig die tatsächlichen Nutzungskosten jedes Modells durch native Messfunktionen statistisch erfassen, um eine Grundlage für die Abrechnung und Ressourcenplanung auf Modellebene zu schaffen.

• Daten-SaaS-Dienst: Datenverteilungsplattformen, die sich an eine große Anzahl von Endbenutzern richten, müssen oft gleichzeitig mit vielen Datenanbietern verbunden sein. Dabei muss sichergestellt werden, dass die Datengrenzen der einzelnen Parteien klar sind, und gleichzeitig das Leistungsrisiko vermieden werden, dass "ein großes Fass alle mit sich zieht". Mit Agent Bucket kann jeder Datenanbieter sein eigenes ObjectSet haben, um Rohdaten und Verarbeitungsergebnisse einheitlich zu verwalten. Durch unabhängige Domains und Bandbreiten- sowie QPS-Kontingente können unterschiedliche Servicegarantien und Ratenbegrenzungen für verschiedene Anbieter realisiert werden, um eine Datenverteilungsinfrastruktur zu schaffen, die "eine Plattform, mehrere Anbieter, voneinander isoliert und kontrolliert zusammenarbeiten" ermöglicht.

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/