Zilliz ha presentato Loon, un nuovo motore di storage lake-native sviluppato per gestire dati vettoriali su object storage senza doverne mantenere copie separate per ricerca in tempo reale, discovery su larga scala e analisi batch. Loon è il livello di archiviazione alla base di Zilliz Vector Lakebase e sarà incluso in Milvus 3.0, con l’obiettivo di estendere il ruolo del vector database verso una piattaforma dati unificata per workload AI differenti.
Il problema affrontato da Loon nasce dalla crescita dei sistemi basati su embedding. Un’azienda può utilizzare gli stessi vettori per alimentare una ricerca semantica in produzione, addestrare o valutare nuovi modelli, eseguire analisi offline, aggiornare metadati e creare indici specifici per diversi casi d’uso. Nelle architetture tradizionali, queste attività richiedono spesso pipeline di copia, ETL e sincronizzazione tra database vettoriali, data lake e motori analitici. Il risultato è una moltiplicazione delle versioni dello stesso dataset, con costi più elevati e maggiore rischio di disallineamento.
Loon parte da un principio diverso: una sola copia logica del dataset vettoriale deve poter servire più motori di elaborazione contemporaneamente. La stessa base dati può quindi essere interrogata da cluster dedicati alla ricerca a bassa latenza, da risorse elastiche utilizzate per analisi e discovery, oppure da motori esterni come Spark e Ray. Il dataset rimane nell’object storage, mentre le applicazioni accedono alla stessa struttura dati senza doverne creare duplicati operativi.
L’architettura utilizza formati file differenti in base al tipo di informazione archiviata. I campi scalari e i metadati usati per filtri e scansioni analitiche vengono gestiti tramite Parquet, un formato adatto alla lettura colonnare su grandi quantità di dati. I vettori densi e sparsi utilizzano invece Vortex, formato aperto progettato per consentire letture puntuali e precise a livello di record direttamente su object storage. File originali come immagini, video e PDF non vengono importati e duplicati nel database, ma restano nel bucket di origine e vengono semplicemente richiamati dai record vettoriali.
Questa separazione dei formati risponde a un’esigenza tecnica concreta. La ricerca vettoriale in tempo reale richiede accessi rapidi a record specifici, mentre l’analisi batch tende a eseguire scansioni molto più ampie. Utilizzare lo stesso formato per entrambe le operazioni può creare inefficienze. Zilliz dichiara che, nei test interni su object storage, l’organizzazione basata su Vortex ha ridotto di circa 135 volte la quantità di dati letti per singolo record rispetto a Parquet, rendendo più praticabile l’uso di storage a basso costo anche per workload con requisiti di latenza più stretti.
Loon utilizza inoltre un allineamento basato sugli identificativi di riga. Colonne archiviate con formati differenti continuano a comportarsi come una singola tabella logica. Questo permette, ad esempio, di aggiungere una nuova colonna di embedding generata da un modello più recente senza dover riscrivere didascalie, attributi, vettori già presenti o altri metadati collegati allo stesso contenuto. In un sistema AI che aggiorna periodicamente modelli e rappresentazioni semantiche, questa capacità evita riscritture molto pesanti di dataset che possono raggiungere centinaia di gigabyte o diversi terabyte.
Il coordinamento delle modifiche avviene tramite un manifest versionato, che contiene lo stato corrente del dataset, i file associati, gli indici, i log delle cancellazioni e le statistiche utili al funzionamento dei motori. Il manifest agisce come fonte di verità condivisa tra cluster di serving, risorse on demand e strumenti esterni. In questo modo, più componenti possono leggere o aggiornare lo stesso dataset mantenendo una visione coerente delle versioni disponibili.
Questa impostazione permette anche di gestire dati che cambiano continuamente. Nei sistemi AI non è raro ricalcolare gli embedding quando viene introdotto un nuovo modello, aggiornare classificazioni, correggere metadati o ricostruire un indice. Invece di spostare il dataset tra più ambienti e creare una nuova copia completa per ogni aggiornamento, Loon tratta queste operazioni come modifiche versionate sulla stessa base dati.
Vector Lakebase utilizza questa architettura per separare i workload senza separare i dati. I cluster destinati alla ricerca in produzione possono restare stabili e ottimizzati per la risposta rapida, mentre le attività di esplorazione, analisi batch e sperimentazione vengono eseguite su capacità di calcolo elastica. Le External Collections consentono inoltre di indicizzare dati mantenuti direttamente nei bucket S3 o Google Cloud Storage del cliente, evitando ulteriori trasferimenti e duplicazioni.
Loon introduce quindi un modello nel quale il vector database non è più soltanto il punto di arrivo di una pipeline di embedding, ma diventa una componente integrata con data lake, analisi e aggiornamenti continui dei modelli. Il valore dell’architettura dipenderà dalla capacità di mantenere prestazioni elevate su dati in evoluzione, riducendo al tempo stesso il costo e la complessità generati dalla proliferazione delle copie vettoriali.