Glossary
Object Storage

Object storage per carichi di lavoro AI

L'object storage archivia i dati come oggetti autonomi invece che come file in cartelle o blocchi su un disco. È progettato per dati non strutturati: foto, video, audio, email, pagine web, letture di sensori e gli embedding vettoriali prodotti dalle applicazioni AI.

Un object store cloud distribuisce questi dati su molte macchine, ma ti consente di accedervi tutti come a un unico pool tramite un'API HTTP. Ogni oggetto contiene tre elementi: i dati stessi, eventuali metadati che aggiungi e un ID univoco. Puoi recuperare o analizzare qualsiasi oggetto tramite quell'ID, qualunque sia il suo tipo di file.

Amazon S3, il primo object store cloud, ora contiene più di 500 mila miliardi di oggetti. È diventato il livello di storage predefinito del cloud.

Come funziona l'object storage

Tre modelli di storage gestiscono i dati in modo diverso. Un file system mette i dati in cartelle annidate. Il block storage suddivide i dati in blocchi di dimensione fissa su un disco. L'object storage mantiene ogni elemento intero in un contenitore piatto chiamato bucket, senza cartelle.

Per archiviare un file, il sistema prende i dati, aggiunge eventuali metadati che gli fornisci e associa un ID. Le app quindi leggono, scrivono ed eliminano gli oggetti tramite quell'ID su un'API HTTP. Non esiste un percorso file né un punto di mount.

PUT /my-bucket/embedding-batch-042.parquet     # archivia un oggetto
GET /my-bucket/embedding-batch-042.parquet     # recuperalo tramite ID
DELETE /my-bucket/embedding-batch-042.parquet  # rimuovilo

La struttura piatta è ciò che permette all'object storage di scalare. Aggiungi capacità aggiungendo macchine al pool, non rielaborando un albero di cartelle, quindi un singolo bucket può crescere quasi senza limiti. Amazon S3, lanciato nel 2006, ha definito l'API che il resto del settore ha copiato, e Ceph, MinIO e OpenStack Swift sono tutti compatibili con S3, così come gli altri principali cloud.

Servizio	Provider	Standard API
Amazon S3	AWS	S3 (lo standard de facto)
Cloud Storage	Google Cloud	interoperabile con S3 + nativo
Blob Storage	Microsoft Azure	nativo + gateway compatibili con S3
MinIO / Ceph	Self-hosted (open source)	compatibile con S3

Funzionalità chiave e limitazioni

La progettazione dell'object storage gli conferisce un insieme chiaro di punti di forza e un insieme chiaro di limiti.

Funzionalità chiave

Scala quasi senza limiti. Un singolo bucket contiene tutti gli oggetti di cui hai bisogno. Aggiungi capacità scrivendo più dati e paghi solo per ciò che archivi, senza dover dimensionare un cluster in anticipo.
Durevole e resiliente. Gli object store mantengono copie di ogni oggetto su diverse macchine, spesso attraverso data center o regioni. Amazon S3 è progettato per undici nove (99,999999999%) di durabilità, con ogni oggetto archiviato in almeno tre Availability Zone.
Economico, con livelli. I prezzi per gigabyte sono ben inferiori rispetto al block storage o al file storage, e i dati freddi passano automaticamente a livelli più economici.
Contiene qualsiasi dato, con metadati ricchi. Un bucket può contenere qualsiasi tipo di dato non strutturato e ogni oggetto trasporta metadati che definisci. Puoi trovare e filtrare oggetti in base a quei metadati, qualunque sia il tipo di file.
Aperto e facile da raggiungere. Gli oggetti vengono letti tramite una semplice API HTTP. L'API S3 è uno standard de facto, quindi molti strumenti leggono gli stessi bucket senza connettori speciali.

Limitazioni

Più lento del block storage. Ogni richiesta passa su HTTP, quindi l'object storage è poco adatto a lavori a bassa latenza, ad accesso casuale o a database transazionali.
Nessuna modifica in loco. Sostituisci un intero oggetto invece di modificarne una parte, il che rende l'object storage poco adatto a dati che cambiano spesso.
Le piccole letture diventano costose. Un carico di lavoro che effettua molte letture minuscole può accumulare costi API elevati anche quando i dati stessi sono pochi.
Nessuna ricerca o calcolo integrati. L'object storage archivia e serve byte. Non ha indice, ricerca né analytics. Qualsiasi cosa oltre "recupera questo oggetto tramite ID" richiede un motore di query sopra. Quest'ultima lacuna è il motivo per cui l'object storage è la base per i dati AI ma non può, da solo, servire la ricerca AI.

Casi d'uso e il ponte verso l'AI

La scalabilità, la durabilità e il basso costo dell'object storage lo rendono la destinazione predefinita per molti carichi di lavoro:

Data lake (la base di storage standard)
Backup e disaster recovery
Archivi a lungo termine
Storage e distribuzione di media
Log e dati di analytics
Set di addestramento ML (i grandi dataset da cui i modelli apprendono)

La ricerca AI ora chiede all'object storage di fare più che conservare dati. Gli embedding sono i vettori numerici alla base della ricerca semantica e della retrieval-augmented generation (RAG). Ce ne sono in quantità enormi, ognuno è grande, e archiviarli in un database specializzato diventa costoso.

Così i team hanno iniziato a mantenere gli embedding direttamente nell'object storage. Amazon S3 Vectors, generalmente disponibile da dicembre 2025, aggiunge storage e ricerca vettoriale nativi a S3. AWS afferma che riduce il costo di archiviazione e interrogazione dei vettori fino al 90% rispetto ai database vettoriali specializzati, contiene fino a due miliardi di vettori per indice e risponde alle query frequenti in circa 100 millisecondi e a quelle rare in meno di un secondo.

Il problema è la velocità. L'object storage ora può contenere e cercare vettori a basso costo, ma rispondere rapidamente a una ricerca, mentre i dati restano nell'object storage e non vengono mai copiati in uno store veloce separato, è la parte difficile.

Object Storage nell'infrastruttura AI

L'object storage ha un vero limite per l'AI: non ha modo di cercare al proprio interno. Gli embedding vi risiedono a basso costo, ma una ricerca di similarità lascia due cattive opzioni. Copiare i dati in un database vettoriale dedicato, e ora si mantengono due copie, si pagano due fatture e bisogna tenerle sincronizzate. Cercare nei file grezzi senza indice, ed è decisamente troppo lento per la produzione.

La soluzione è dare all'object storage l'unica cosa che gli manca: un modo per cercare i dati dove si trovano. Questo richiede tre componenti, nessuno dei quali è integrato:

Indici accanto ai dati. Gli indici vettoriali vivono sull'object storage, accanto ai dati, invece che in un sistema separato.
Letture che recuperano solo ciò che serve. Il motore di query estrae solo le pagine dell'indice e i frammenti di dati toccati da una query, non interi file.
Una cache davanti. Memoria o SSD locale si posizionano davanti all'object storage in modo che i dati hot siano serviti senza un round trip.

Messi insieme, questi elementi consentono di cercare direttamente nell'object storage invece di trattarlo come uno store passivo.

Zilliz Vector Lakebase è un sistema costruito in questo modo. Mantiene dati e indici sull'object storage, separati dal compute che li interroga. Più cluster di compute possono leggere contemporaneamente la stessa copia dei dati, per serving, discovery o analytics, senza duplicarla. La sua funzionalità External Collections punta alle lake table già esistenti, che siano in Lance, Iceberg, Parquet o nel suo formato Vortex, ed esegue la ricerca vettoriale su di esse in place.

Nel benchmark di Zilliz su una tabella Iceberg da un miliardo di vettori, la velocità dipende da come i dati sono memorizzati nella cache:

Nessun indice (scansione Spark brute-force): ore
Cold (indice appena creato, in circa 20 minuti): ~30 secondi
Warm (da cache SSD locale): decine di millisecondi
Hot (dalla memoria): millisecondi a una cifra

Poiché ogni query carica solo le pagine di cui ha bisogno, Zilliz riferisce di ridurre la read amplification (trasferimento di dati sprecato) di oltre il 90%, e il suo formato Vortex sposta 135 volte meno dati da S3 per lettura rispetto a Parquet.

Questo pattern è più ampio di qualsiasi singolo prodotto. L'object storage si sta trasformando in un luogo in cui i dati AI vengono cercati direttamente, oltre a essere il luogo in cui sono archiviati.

Domande frequenti

L'object storage è adatto ai carichi di lavoro AI?

Sì, per archiviare dati di addestramento, embedding e artefatti di modelli su larga scala, dove la sua durabilità, la capacità quasi illimitata e il basso costo ripagano. Il limite è la velocità: per cercare rapidamente quei dati, servono un indice e compute sopra lo store grezzo.

Qual è la differenza tra object storage e un database vettoriale?

L'object storage è un archivio generale per qualsiasi dato non strutturato, accessibile tramite ID. Un database vettoriale è progettato per la ricerca di similarità sugli embedding, con indici ottimizzati per query rapide dei vicini più prossimi. I due stanno convergendo: i team mantengono sempre più spesso i vettori nell'object storage e aggiungono un livello di ricerca sopra di essi.

Puoi eseguire la ricerca vettoriale direttamente sull'object storage?

Sempre più spesso, sì. AWS S3 Vectors aggiunge la ricerca vettoriale nativa, e le piattaforme che puntano direttamente alle tabelle lake ti permettono di cercare nei dati dell'object storage senza copiarli altrove. Le query vengono eseguite più lentamente rispetto a un indice in memoria, ma il costo è molto più basso.

Perché i data lake usano l'object storage?

Un data lake deve contenere enormi volumi di dati strutturati e non strutturati in modo economico e durevole, in formati aperti, accessibili da molti motori contemporaneamente. Il pool piatto dell'object storage, indirizzato tramite ID, si adatta meglio a questo rispetto allo storage a file o a blocchi.

L'object storage è più lento dello storage a blocchi?

Per una singola operazione, di solito sì. Lo storage a blocchi offre una latenza molto bassa per carichi di lavoro transazionali e ad accesso casuale. L'object storage scambia questo con throughput, durabilità e costo su oggetti grandi e per lo più statici letti tramite HTTP. Il divario si riduce per grandi letture sequenziali, ma rimane ampio per quelle piccole e sensibili alla latenza.

Object Storage for AI: Passi successivi

L'object storage è la base su cui è costruito il resto dello stack di dati per l'AI. Per vedere come una piattaforma vector-native esegue retrieval, discovery e analytics direttamente sui dati dell'object storage, leggi From Vector Database to Vector Lakebase o esplora la piattaforma Zilliz Cloud.

Contenuto

Inizia gratis, scala facilmente

Prova il database vettoriale completamente gestito progettato per le tue applicazioni GenAI.

Prova Zilliz Cloud gratuitamente