Objektspeicher für KI-Workloads
Objektspeicher für KI-Workloads
Objektspeicher speichert Daten als eigenständige Objekte statt als Dateien in Ordnern oder als Blöcke auf einer Festplatte. Er ist für unstrukturierte Daten konzipiert: Fotos, Video, Audio, E-Mail, Webseiten, Sensormesswerte und die Vektor-Embeddings, die KI-Anwendungen erzeugen.
Ein Cloud-Objektspeicher verteilt diese Daten auf viele Maschinen, lässt dich aber über eine HTTP-API auf alles als einen einzigen Pool zugreifen. Jedes Objekt enthält drei Dinge: die Daten selbst, alle Metadaten, die du hinzufügst, und eine eindeutige ID. Du rufst jedes Objekt anhand dieser ID ab oder analysierst es, unabhängig vom Dateityp.
Amazon S3, der erste Cloud-Objektspeicher, enthält heute mehr als 500 Billionen Objekte. Er ist zur Standardspeicherschicht der Cloud geworden.
Wie Objektspeicher funktioniert
Drei Speichermodelle behandeln Daten unterschiedlich. Ein Dateisystem legt Daten in verschachtelten Ordnern ab. Blockspeicher teilt Daten in Blöcke fester Größe auf einer Festplatte auf. Objektspeicher hält jedes Element vollständig in einem flachen Container, der Bucket genannt wird, ohne Ordner.
Um eine Datei zu speichern, nimmt das System die Daten, fügt alle Metadaten hinzu, die du angibst, und hängt eine ID an. Anwendungen lesen, schreiben und löschen Objekte dann anhand dieser ID über eine HTTP-API. Es gibt keinen Dateipfad und keinen Mount Point.
PUT /my-bucket/embedding-batch-042.parquet # store an object
GET /my-bucket/embedding-batch-042.parquet # retrieve it by ID
DELETE /my-bucket/embedding-batch-042.parquet # remove it
Die flache Struktur ermöglicht es Objektspeicher zu skalieren. Du fügst Kapazität hinzu, indem du Maschinen zum Pool hinzufügst, nicht indem du eine Ordnerstruktur umarbeitest, sodass ein einzelner Bucket nahezu unbegrenzt wachsen kann. Amazon S3, 2006 gestartet, setzte die API, die der Rest der Branche kopierte, und Ceph, MinIO und OpenStack Swift sind alle S3-kompatibel, ebenso wie die anderen großen Clouds.
| Dienst | Anbieter | API-Standard |
|---|---|---|
| Amazon S3 | AWS | S3 (der De-facto-Standard) |
| Cloud Storage | Google Cloud | S3-interoperabel + nativ |
| Blob Storage | Microsoft Azure | Nativ + S3-kompatible Gateways |
| MinIO / Ceph | Self-hosted (Open Source) | S3-kompatibel |
Wichtige Funktionen und Einschränkungen
Das Design von Objektspeicher gibt ihm eine klare Reihe von Stärken und eine klare Reihe von Grenzen.
Wichtige Funktionen
- Skaliert nahezu unbegrenzt. Ein einzelner Bucket enthält so viele Objekte, wie du benötigst. Du fügst Kapazität hinzu, indem du mehr Daten schreibst, und zahlst nur für das, was du speicherst, ohne im Voraus einen Cluster dimensionieren zu müssen.
- Langlebig und ausfallsicher. Objektspeicher halten Kopien jedes Objekts auf mehreren Maschinen, oft über Rechenzentren oder Regionen hinweg. Amazon S3 ist auf elf Neunen (99,999999999 %) Haltbarkeit ausgelegt, wobei jedes Objekt über mindestens drei Availability Zones gespeichert wird.
- Günstig, mit Tiers. Preise pro Gigabyte liegen deutlich unter denen von Block- oder Dateispeicher, und kalte Daten werden automatisch in günstigere Tiers verschoben.
- Enthält beliebige Daten, mit umfangreichen Metadaten. Ein Bucket kann jede Art unstrukturierter Daten enthalten, und jedes Objekt trägt Metadaten, die du definierst. Du kannst Objekte anhand dieser Metadaten finden und filtern, unabhängig vom Dateityp.
- Offen und leicht erreichbar. Objekte werden über eine einfache HTTP-API gelesen. Die S3-API ist ein De-facto-Standard, sodass viele Tools dieselben Buckets ohne spezielle Konnektoren lesen.
Einschränkungen
- Langsamer als Blockspeicher. Jede Anfrage läuft über HTTP, daher eignet sich Objektspeicher schlecht für latenzarme Random-Access-Arbeiten oder transaktionale Datenbanken.
- Keine Bearbeitung an Ort und Stelle. Du ersetzt ein ganzes Objekt, statt einen Teil davon zu ändern, was Objektspeicher ungeeignet für Daten macht, die sich häufig ändern.
- Kleine Lesevorgänge werden teuer. Ein Workload, der viele winzige Lesevorgänge ausführt, kann hohe API-Kosten verursachen, selbst wenn die Daten selbst klein sind.
- Keine integrierte Suche oder Compute. Objektspeicher speichert und liefert Bytes. Er hat keinen Index, keine Suche, keine Analytics. Alles über „dieses Objekt per ID abrufen“ hinaus benötigt eine Query Engine darüber. Diese letzte Lücke ist der Grund, warum Objektspeicher die Grundlage für KI-Daten ist, aber allein keine KI-Suche bereitstellen kann.
Anwendungsfälle und die Brücke zur KI
Der Umfang, die Haltbarkeit und die niedrigen Kosten von Object Storage machen ihn zum Standard-Zuhause für viele Workloads:
- Data Lakes (die Standard-Speichergrundlage)
- Backup und Disaster Recovery
- Langzeitarchive
- Medienspeicherung und -bereitstellung
- Logs und Analysedaten
- ML-Trainingsdatensätze (die großen Datensätze, aus denen Modelle lernen)
AI Search verlangt Object Storage jetzt mehr ab, als nur Daten zu speichern. Embeddings sind die numerischen Vektoren hinter semantischer Suche und Retrieval-Augmented Generation (RAG). Es gibt riesige Mengen davon, jedes einzelne ist groß, und ihre Speicherung in einer spezialisierten Datenbank wird teuer.
Deshalb haben Teams begonnen, Embeddings direkt in Object Storage zu speichern. Amazon S3 Vectors, seit Dezember 2025 allgemein verfügbar, erweitert S3 um native Vektorspeicherung und -suche. AWS gibt an, dass es die Kosten für das Speichern und Abfragen von Vektoren im Vergleich zu spezialisierten Vektordatenbanken um bis zu 90% senkt, bis zu zwei Milliarden Vektoren pro Index hält und häufige Abfragen in etwa 100 Millisekunden sowie seltene in unter einer Sekunde beantwortet.
Der Haken ist die Geschwindigkeit. Object Storage kann Vektoren jetzt kostengünstig speichern und durchsuchen, aber eine Suche schnell zu beantworten, während die Daten in Object Storage bleiben und niemals in einen separaten schnellen Speicher kopiert werden, ist der schwierige Teil.
Object Storage in der AI-Infrastruktur
Object Storage hat für AI eine echte Lücke: Er hat keine Möglichkeit, sich selbst zu durchsuchen. Embeddings liegen kostengünstig darin, aber eine Ähnlichkeitssuche lässt Ihnen zwei schlechte Optionen. Kopieren Sie die Daten in eine dedizierte Vektordatenbank, und Sie halten nun zwei Kopien vor, bezahlen zwei Rechnungen und müssen sie synchron halten. Durchsuchen Sie die Rohdateien ohne Index, ist das für die Produktion viel zu langsam.
Die Lösung besteht darin, Object Storage genau das zu geben, was ihm fehlt: eine Möglichkeit, die Daten dort zu durchsuchen, wo sie liegen. Dafür braucht es drei Komponenten, von denen keine von Haus aus enthalten ist:
- Indizes neben den Daten. Vektorindizes liegen auf Object Storage, neben den Daten, statt in einem separaten System.
- Lesevorgänge, die nur abrufen, was sie benötigen. Die Query Engine zieht nur die Indexseiten und Datenfragmente, die eine Abfrage berührt, nicht ganze Dateien.
- Ein Cache davor. Arbeitsspeicher oder lokale SSD sitzt vor Object Storage, sodass Hot Data ohne Round Trip bereitgestellt wird.
Zusammen ermöglichen diese Komponenten, Object Storage direkt zu durchsuchen, statt ihn als passiven Speicher zu behandeln.
Zilliz Vector Lakebase ist ein System, das so aufgebaut ist. Es hält Daten und Indizes auf Object Storage, getrennt von der Compute-Ebene, die sie abfragt. Mehrere Compute-Cluster können gleichzeitig dieselbe Kopie der Daten lesen, für Serving, Discovery oder Analytics, ohne sie zu duplizieren. Seine External Collections-Funktion verweist auf Lake Tables, die Sie bereits haben, ob in Lance, Iceberg, Parquet oder dem eigenen Vortex-Format, und führt Vektorsuche dagegen direkt vor Ort aus.
Im Benchmark von Zilliz auf einer Iceberg-Tabelle mit einer Milliarde Vektoren hängt die Geschwindigkeit davon ab, wie die Daten gecacht werden:
- Kein Index (Brute-Force-Spark-Scan): Stunden
- Cold (Index gerade erstellt, in etwa 20 Minuten): ~30 Sekunden
- Warm (aus lokalem SSD-Cache): Dutzende Millisekunden
- Hot (aus dem Speicher): einstellige Millisekunden
Da jede Abfrage nur die Seiten lädt, die sie benötigt, berichtet Zilliz, dass es Read Amplification (verschwendete Datenübertragung) um mehr als 90% reduziert, und sein Vortex-Format überträgt pro Lesevorgang 135x weniger Daten aus S3 als Parquet.
Dieses Muster ist größer als jedes einzelne Produkt. Object Storage entwickelt sich zu einem Ort, an dem AI-Daten direkt durchsucht werden, zusätzlich dazu, dass sie dort gespeichert werden.
Häufig gestellte Fragen
Ist Object Storage gut für AI-Workloads?
Ja, zum Speichern von Trainingsdaten, Embeddings und Modellartefakten in großem Maßstab, wo sich seine Haltbarkeit, nahezu unbegrenzte Kapazität und niedrigen Kosten auszahlen. Die Grenze ist die Geschwindigkeit: Um diese Daten schnell zu durchsuchen, benötigen Sie einen Index und Compute oberhalb des Rohspeichers.
Was ist der Unterschied zwischen Object Storage und einer Vektordatenbank?
Objektspeicher ist ein allgemeiner Speicher für beliebige unstrukturierte Daten, die per ID abgerufen werden. Eine Vektordatenbank ist für die Ähnlichkeitssuche über Embeddings konzipiert, mit Indizes, die für schnelle Nearest-Neighbor-Abfragen optimiert sind. Die beiden Bereiche nähern sich an: Teams speichern die Vektoren zunehmend im Objektspeicher und fügen darüber eine Suchschicht hinzu.
Kann man Vektorsuche direkt auf Objektspeicher ausführen?
Zunehmend ja. AWS S3 Vectors ergänzt native Vektorsuche, und Plattformen, die direkt auf Lake-Tabellen verweisen, ermöglichen es, Daten im Objektspeicher zu durchsuchen, ohne sie herauszukopieren. Die Abfragen laufen langsamer als bei einem In-Memory-Index, aber die Kosten sind deutlich niedriger.
Warum verwenden Data Lakes Objektspeicher?
Ein Data Lake muss riesige Mengen strukturierter und unstrukturierter Daten kostengünstig und dauerhaft in offenen Formaten speichern, sodass viele Engines gleichzeitig darauf zugreifen können. Der flache, per ID adressierbare Pool von Objektspeicher passt dazu besser als Datei- oder Blockspeicher.
Ist Objektspeicher langsamer als Blockspeicher?
Für eine einzelne Operation normalerweise ja. Blockspeicher bietet sehr niedrige Latenz für transaktionale und zufällige Zugriffsmuster. Objektspeicher tauscht das gegen Durchsatz, Dauerhaftigkeit und Kosten bei großen, überwiegend statischen Objekten ein, die über HTTP gelesen werden. Die Lücke wird bei großen sequenziellen Lesevorgängen kleiner, bleibt aber bei kleinen, latenzsensitiven Zugriffen groß.
Objektspeicher für KI: Nächste Schritte
Objektspeicher ist die Grundlage, auf der der Rest des KI-Daten-Stacks aufbaut. Um zu sehen, wie eine vektornative Plattform Retrieval, Discovery und Analytics direkt auf Daten im Objektspeicher ausführt, lesen Sie From Vector Database to Vector Lakebase oder erkunden Sie die Zilliz Cloud platform.
- Wie Objektspeicher funktioniert
- Wichtige Funktionen und Einschränkungen
- Anwendungsfälle und die Brücke zur KI
- Object Storage in der AI-Infrastruktur
- Häufig gestellte Fragen
- Objektspeicher für KI: Nächste Schritte
Inhalte
Kostenlos starten, einfach skalieren
Testen Sie die vollständig verwaltete Vektordatenbank, die für Ihre GenAI-Anwendungen entwickelt wurde.
Zilliz Cloud kostenlos ausprobieren