Collezione Esterna di Milvus: Indicizzare e Recuperare Dati Residenti nel Data Lake Senza Spostarli

In molte pipeline di IA, embedding e metadati vengono già prodotti e archiviati in un data lake. Una pipeline di prodotto potrebbe scrivere attributi di prodotto ed embedding multimodali in file Parquet su S3. Un corpus di retrieval o di training potrebbe risiedere in una tabella Iceberg o Lance. Il lake è già il luogo in cui questi dataset vengono generati, aggiornati, versionati e utilizzati dal resto dello stack dati.

I database vettoriali, tuttavia, sono stati tradizionalmente costruiti attorno a una copia di servizio di proprietà del database. Se i team volevano una ricerca vettoriale a bassa latenza su dati già presenti in un lake, avevano generalmente due opzioni:

• Copiare i dati in un database vettoriale. Questa opzione fornisce indici ANN e un percorso di servizio di produzione, ma crea una seconda copia del dataset e una pipeline ETL che deve rimanere sincronizzata con la sorgente.
• Interrogare direttamente il lake. Questa opzione evita la duplicazione, ma senza un livello di indicizzazione e servizio ANN, la ricerca vettoriale si riduce a scansioni non progettate per la latenza di produzione.

Milvus 3.0 External Collection introduce una terza via. I dati sorgente rimangono in Parquet, Iceberg, Lance, Vortex o in un altro formato esterno supportato, mentre Milvus costruisce e serve indici su di essi. Si mappano i campi esterni in uno schema Milvus, si definiscono gli indici necessari, si aggiorna la collezione e si utilizzano le normali API di ricerca e query di Milvus, senza dover prima copiare le righe sorgente in una collezione gestita da Milvus.

Il cambiamento architetturale è semplice: i dati possono rimanere nel lake, mentre Milvus aggiunge il livello di indicizzazione e retrieval.

Ciò rende External Collection anche un passo importante verso Vector Lakebase, un'architettura dati unificata e lake-native per l'IA che combina la capacità di servizio di livello database vettoriale con lo storage open lake, indici a livello di lake riutilizzabili e un livello semantico condiviso. Il retrieval online non deve più partire da una copia di servizio separata mentre Spark, le pipeline di training, i job di valutazione e gli strumenti di governance operano su un'altra versione dei dati. Possono lavorare dalla stessa base dati residente nel lake.

Cos'è una External Collection e cosa cambia

Una External Collection è un tipo di collezione Milvus i cui dati sorgente risiedono al di fuori dello storage gestito da Milvus.

Senza una External Collection, mettere quel catalogo dietro una ricerca vettoriale di produzione significa normalmente creare un'altra copia in Milvus:

Ogni volta che il catalogo cambia, che il modello di embedding cambia o che un campo viene riempito retroattivamente, un'altra pipeline deve spostare i dati aggiornati attraverso quel confine.

Con External Collection, l'architettura diventa:

Milvus non trasforma i file esterni in una propria copia dei dati sorgente. La External Collection contiene invece le informazioni di cui Milvus ha bisogno per interpretarli e cercarli:

1. Un external_source che identifica i file o la tabella esterni.
2. Una external_spec che descrive il formato sorgente e l'accesso allo storage.
3. I mapping external_field che collegano i campi dello schema Milvus alle colonne del dataset esterno.
4. Gli indici, i manifest e lo stato di servizio che Milvus crea per il retrieval.

Dati sorgente zero-copy non significa zero stato all'interno di Milvus. Milvus costruisce comunque gli indici. Utilizza comunque risorse di calcolo. Mantiene comunque dati in cache. Il cambiamento è che le righe authoritative non devono più essere copiate in Milvus semplicemente perché serve che Milvus le cerchi.

Collezione Milvus normale vs. External Collection

Ambito	Collezione gestita da Milvus	External Collection
Record sorgente	Archiviati e gestiti da Milvus	Rimangono nei file o nella tabella esterni
Come i dati entrano in Milvus	Insert, upsert, import o scrittura in streaming	Mapping della sorgente esterna + Refresh
Mutazioni online	Supportate	Sola lettura da Milvus
Aggiornamento dei dati	Segue il percorso di scrittura e il modello di consistenza di Milvus	Segue l'ultimo Refresh pubblicato con successo
Stato gestito da Milvus	Dati sorgente, metadati, indici, cache	Mapping, manifest, indici, cache
Percorso di query	API di ricerca e query di Milvus	API di ricerca e query di Milvus
Utilizzo ottimale	Dati online in continua evoluzione	Dati lake di grandi dimensioni, prodotti in batch e con letture intensive

External Collection quindi completa le normali collezioni Milvus invece di sostituirle.

Un sistema può mantenere lo stato online in rapida evoluzione nelle normali collezioni Milvus, utilizzando le External Collection per grandi corpus, cataloghi, dataset storici, feature di modelli o altri dati già prodotti e governati nel lake.

Perché eliminare la seconda copia è importante

È forte la tentazione di descrivere le External Collection come un'ottimizzazione dello storage: non copiare diversi terabyte di dati in un altro database e si risparmia spazio. Questo è utile, ma non è il problema architetturale principale.

Il costo più alto deriva dal mantenere allineati due sistemi dati.

Si consideri di nuovo il catalogo prodotti. La piattaforma dati produce il dataset Parquet authoritative. La ricerca lo importa in un database vettoriale. Un team di raccomandazione potrebbe leggere gli stessi dati del lake tramite Spark per analisi offline. Un nuovo modello di embedding genera quindi una colonna vettoriale sostitutiva. Inventario e metadati continuano a cambiare contemporaneamente.

Una volta che la copia di servizio online diventa indipendente dal lake, ogni modifica deve attraversare quel confine:

• i dati devono essere copiati;
• il trasferimento deve essere pianificato e monitorato;
• i job falliti necessitano di nuovi tentativi;
• schemi e permessi potrebbero dover essere rappresentati in più sistemi;
• l'aggiornamento dei dati dipende dalla velocità con cui la pipeline di sincronizzazione recupera il ritardo;
• i team devono sapere quale copia rappresenta la versione che vogliono realmente.

Lo storage è solo una voce di costo.

Costo	Lake + copia di servizio separate	External Collection
Copie dei dati sorgente	Copia nel lake più una copia di servizio separata	Le righe sorgente rimangono nel lake
Movimentazione dei dati	Pipeline ETL/import persistente	Refresh sulla sorgente esterna
Aggiornamento dei dati	Dipende dalla cadenza di export/import	Controllato dalla pubblicazione di un nuovo Refresh
Governance	Le copie sorgente e di servizio devono rimanere allineate	Proprietà della sorgente, lineage e versionamento rimangono alla piattaforma lake
Riutilizzo offline	Altri consumer potrebbero preparare le proprie copie	Gli strumenti lake esistenti possono continuare a leggere la stessa sorgente
Risorse di servizio	Dimensionate in base alla copia nel database e al carico di query	Indicizzazione, calcolo delle query e cache possono essere gestiti separatamente dalla proprietà delle righe sorgente

La differenza diventa particolarmente importante man mano che i dati IA cambiano più spesso.

I team deduplicano i corpus. Raggruppano i dati per analisi. Generano nuovi embedding quando un modello cambia. Aggiungono etichette, riassunti, entità estratte, punteggi di qualità o segnali di feedback. Eseguono job di valutazione e pipeline di pulizia dei dati sullo stesso corpus da cui le applicazioni di produzione effettuano il retrieval.

Se ogni sistema possiede la propria copia, ogni miglioramento diventa un altro job di sincronizzazione.

External Collection cambia questo confine: i sistemi offline possono continuare a lavorare sul dataset del lake, mentre Milvus serve il retrieval sulla stessa base.

Quali sorgenti dati supporta External Collection

External Collection è progettata attorno a dati aperti e gestiti esternamente, piuttosto che a una struttura sorgente specifica di Milvus. Supporta più formati di sorgente esterna tramite Storage V3:

Formato esterno	Valore del formato	Cosa legge Milvus
Apache Parquet	parquet	Una directory o un prefisso di object storage contenente file Parquet e row group
Vortex	vortex	File Vortex e relativi metadati di layout
Lance	lance-table	Un dataset Lance e i relativi metadati dei frammenti
Apache Iceberg	iceberg-table	Metadati Iceberg più uno snapshot selezionato
Snapshot Milvus	milvus-table	Uno snapshot Milvus supportato esposto come sorgente esterna

Il mapping tra sorgente e Milvus è esplicito.

Una colonna sorgente chiamata product_id può diventare il campo Milvus id; image_vec può diventare embedding; e una tabella sorgente ampia non deve esporre necessariamente ogni colonna alla collezione. Ciò significa che la piattaforma dati non deve rinominare o riscrivere la propria sorgente solo per soddisfare il database di servizio.

I formati versionati aggiungono un'altra proprietà utile. Con una sorgente come Iceberg, la collezione può puntare a uno snapshot specifico anziché a qualunque cosa sia corrente al momento dell'esecuzione della query. Una versione sorgente fissa è utile per valutazioni ripetibili, test di regressione, analisi storiche e workload di audit.

I file sottostanti rimangono inoltre utilizzabili dal resto dello stack dati. Spark, framework di training, sistemi di governance e altri strumenti compatibili con il lake possono continuare a leggere gli stessi dati aperti.

External Collection aggiunge un altro consumer di quei dati; non trasforma Milvus nel suo unico proprietario.

Accesso sicuro allo storage esterno

Milvus deve inoltre disporre dell'autorizzazione per leggere lo storage esterno.

A seconda del provider di storage, le implementazioni possono utilizzare meccanismi come workload o instance identity, assunzione di ruolo AWS STS, impersonificazione di service account, accesso basato su SAS o sistemi di ruolo specifici del provider, invece di incorporare credenziali di lunga durata nella configurazione dell'applicazione.

Questa identità di storage controlla il modo in cui Milvus raggiunge la sorgente. L'autorizzazione all'interno di Milvus rimane un confine di sicurezza separato.

Come creare, indicizzare, aggiornare e interrogare una External Collection

Il ciclo di vita di una External Collection prevede quattro passaggi principali:

1. Definire la sorgente esterna e mappare le sue colonne in uno schema Milvus.
2. Definire gli indici di cui il workload ha bisogno.
3. Eseguire il Refresh affinché Milvus scopra i dati sorgente e prepari una versione interrogabile.
4. Caricare la collezione e utilizzare le normali API di ricerca e query di Milvus.

Ecco lo stesso catalogo prodotti rappresentato come External Collection:

import json
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(
uri=“http://localhost:19530”,
token=“root:Milvus”,
)
schema = client.create_schema(
external_source=“s3://my-lake/datasets/products/”,
external_spec=json.dumps(
{
“format”: “parquet”,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“use_iam”: “true”,
“iam_endpoint”: “https://sts.us-east-1.amazonaws.com”,
},
}
),
)
schema.add_field(
field_name=“id”,
datatype=DataType.INT64,
external_field=“product_id”,
)
schema.add_field(
field_name=“embedding”,
datatype=DataType.FLOAT_VECTOR,
dim=768,
external_field=“image_vec”,
)
schema.add_field(
field_name=“title”,
datatype=DataType.VARCHAR,
max_length=256,
external_field=“product_name”,
)
schema.add_field(
field_name=“stock”,
datatype=DataType.INT64,
external_field=“stock”,
)
schema.add_field(
field_name=“rating”,
datatype=DataType.FLOAT,
external_field=“rating”,
)
client.create_collection(
collection_name=“products_ext”,
schema=schema,
)

Gli indici utilizzano la normale interfaccia di Milvus:

index_params = client.prepare_index_params()
index_params.add_index(
    field_name="embedding",
    index_type="HNSW",
    metric_type="COSINE",
)
index_params.add_index(field_name="stock", index_type="AUTOINDEX")
index_params.add_index(field_name="rating", index_type="AUTOINDEX")
client.create_index(
collection_name=“products_ext”,
index_params=index_params,
)

Quindi si aggiorna la sorgente esterna:

job_id = client.refresh_external_collection(
    collection_name="products_ext",
)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(2)

Una volta pronta la versione aggiornata, la si carica e la si interroga come una normale collezione Milvus:

client.load_collection("products_ext")
results = client.search(
collection_name=“products_ext”,
data=[query_vec],
anns_field=“embedding”,
filter=“stock > 0 and rating >= 4.0”,
limit=10,
output_fields=[“id”, “title”, “stock”, “rating”],
)

La differenza importante non è la chiamata di ricerca. È il punto in cui inizia il ciclo di vita. Una collezione gestita da Milvus inizia con dati scritti o importati in Milvus. Una External Collection inizia con un riferimento a dati che esistono già altrove.

Come il Refresh rileva le modifiche nei dati esterni

La External Collection è in sola lettura dal lato Milvus, ma il dataset sottostante del lake non deve rimanere congelato per sempre.

Si supponga che la pipeline dei prodotti aggiunga un altro batch, aggiorni i metadati o scriva embedding da un nuovo modello. Milvus non segue in modo continuo ogni oggetto che appare nel percorso sorgente. Queste modifiche diventano visibili tramite il Refresh.

Il Refresh legge i metadati esterni, risolve i frammenti della sorgente, aggiorna i manifest che li collegano alla collezione Milvus e prepara lo stato dell'indice corrispondente.

Il punto chiave è che questo lavoro può essere incrementale.

Milvus identifica i frammenti della sorgente che non sono cambiati e può riutilizzare il lavoro di segmento e indice esistente. I frammenti nuovi o modificati sono le parti che richiedono nuova elaborazione.

Una piccola modifica a un dataset di molti terabyte, quindi, non deve innescare un'altra importazione completa e una ricostruzione completa dell'indice.

Il Refresh offre inoltre al sistema di servizio un chiaro confine di versione. Mentre viene preparata una nuova versione, le query continuano a utilizzare lo stato pubblicato in precedenza. Una volta completato il Refresh, il nuovo stato diventa disponibile come versione completa, anziché esporre una miscela di dati vecchi e parzialmente preparati.

Questo modello si adatta naturalmente a build di cataloghi orarie, aggiornamenti notturni della knowledge base, refresh periodici degli embedding, pipeline di feature generate da modelli e workload batch simili.

Non sostituisce invece un percorso di scrittura in streaming. Se ogni insert o delete deve diventare ricercabile tramite Milvus immediatamente, una collezione gestita rimane il modello migliore.

Come il Lazy Loading riduce l'uso della memoria per dataset ampi

Mantenere le righe sorgente nell'object storage è utile solo se il livello di servizio non deve caricare localmente ogni byte prima di poter rispondere alle query. Con Milvus Tiered Storage abilitato, non è così.

Al momento del caricamento della collezione, i QueryNode possono inizialmente mantenere solo metadati leggeri come informazioni sullo schema, definizioni degli indici, mappe dei chunk e riferimenti agli oggetti remoti. I dati dei campi vengono recuperati a livello di chunk quando una query ne ha bisogno; gli indici possono rimanere remoti fino al primo utilizzo, per poi essere memorizzati in cache localmente. I dati utilizzati di frequente rimangono caldi, mentre i dati acceduti meno di frequente possono essere espulsi.

Questo è particolarmente utile per dataset IA ampi.

Una riga di prodotto potrebbe contenere diversi embedding, una lunga descrizione, JSON grezzo, metadati delle immagini, riassunti generati, inventario, prezzi, valutazioni e molti altri attributi. Una ricerca di similarità tipica potrebbe toccare solo un vettore più inventario, prezzo e valutazione. Non c'è motivo per cui ogni altro campo debba occupare permanentemente la memoria di servizio solo perché appartiene allo stesso record.

External Collection può ridurre l'impronta di servizio su due livelli:

• Primo, proiezione a livello di schema. Tramite external_field, la External Collection può esporre solo le colonne sorgente di cui l'applicazione ha bisogno. Le altre colonne rimangono nel dataset del lake e non sono incluse in questo schema di servizio.
• Secondo, proiezione a runtime. Con il modello di servizio a livelli, i QueryNode recuperano e mettono in cache i campi e gli indici realmente necessari al workload, invece di caricare l'intero dataset mappato in anticipo.

In altre parole, il dataset può rimanere ampio nel lake senza che l'impronta di servizio debba essere altrettanto ampia.

Esiste un ovvio compromesso. Una query che incontra un campo o un indice freddo può pagare un costo di lettura remota al primo accesso. Le policy di warm-up possono precaricare campi o indici critici per la latenza, mentre le policy di cache ed espulsione impediscono che lo stato acceduto meno di frequente occupi risorse locali indefinitamente.

Il punto non è che l'object storage si comporti come la RAM. È che memoria e disco locale possono seguire il working set del workload di retrieval, piuttosto che la dimensione e l'ampiezza totali del dataset sorgente.

Anche il formato sorgente è importante qui. I formati progettati per scansioni analitiche ampie e i formati ottimizzati per letture più mirate o casuali possono produrre comportamenti I/O diversi in caso di accesso on-demand. External Collection non elimina questi compromessi a livello di storage; consente a Milvus di costruire un livello di retrieval sopra di essi.

Quali capacità di ricerca e indicizzazione supporta External Collection

External Collection non si limita a puntare Milvus a una directory di embedding e a scansionare i file. Milvus costruisce strutture di retrieval sui dati esterni ed esegue le query attraverso il suo motore di retrieval standard.

Indici Milvus costruiti sui dati esterni

A seconda dei campi e del workload, Milvus può costruire:

• indici vettoriali per la ricerca ANN;
• indici scalari per il filtraggio dei metadati;
• indici JSON per attributi semi-strutturati;
• indici BM25 e full-text per il retrieval lessicale.
• Campi generati da funzioni supportati dal modello dati di Milvus.

La ricerca ANN utilizza questi indici per restringere il set di candidati invece di leggere ogni vettore sorgente.

Questa distinzione è importante perché archiviare un embedding in un lake non equivale a gestire un database vettoriale sopra di esso. La persistenza fornisce byte. Il retrieval di produzione richiede anche indici, pianificazione delle query, filtraggio, ranking, caching e un percorso di servizio a bassa latenza.

Oltre il top-K vettoriale

Un altro errore comune è interpretare "External Collection" come "ricerca vettoriale su Parquet". Questo sottovaluta ciò di cui il retrieval di produzione ha realmente bisogno.

Un risultato di ricerca di produzione raramente dipende solo dalla similarità vettoriale. Può dipendere anche da termini esatti, policy di accesso, inventario, timestamp, categoria, prezzo, qualità della sorgente o segnali di ranking di business.

Si consideri una query come:

vestito floreale rosso per l'estate, disponibile, valutazione più alta prima

Un percorso di retrieval di produzione può richiedere diversi segnali:

• Similarità vettoriale per il significato semantico di "vestito floreale estivo".
• Ricerca lessicale o full-text per un termine esatto come "rosso".
• Filtri scalari per escludere i prodotti esauriti o al di sotto di una soglia di valutazione.
• Retrieval ibrido e ranking per combinare più segnali di retrieval.

Milvus 3.0 amplia inoltre il motore di query oltre il recupero iniziale dei vicini più prossimi con capacità come ordinamento lato server, aggregazione e faceting.

Il punto più ampio è che External Collection offre ai dati residenti nel lake un percorso di retrieval da database, non solo un modo per leggere vettori da file.

Come gli stessi dati del lake supportano il servizio online e l'elaborazione offline

La ragione architetturale più forte per mantenere la sorgente in un formato lake aperto non è semplicemente che una seconda copia costa denaro. È che lo stesso dataset può rimanere disponibile ai sistemi che lo migliorano continuamente.

Si torni al catalogo prodotti.

Durante il giorno, Milvus può servire una External Collection per la ricerca prodotti, le raccomandazioni o il retrieval per agenti.

Allo stesso tempo, altri sistemi possono lavorare direttamente sul dataset del lake:

• Spark può identificare i prodotti duplicati.
• Una pipeline di training può generare embedding da un nuovo modello.
• Un job di qualità dei dati può rilevare record malformati o anomali.
• Una pipeline di valutazione può confrontare la qualità del retrieval tra versioni del modello.
• Un processo batch può generare riassunti, etichette o metadati aggiuntivi.

External Collection non esegue questi job da sola. Spark rimane Spark; il training rimane training. Il suo ruolo è rimuovere il confine extra dei dati di servizio tra di loro.

Il lavoro offline può scrivere dati migliorati o nuovi campi nel lake. Un Refresh successivo rende la sorgente aggiornata disponibile al percorso di retrieval di Milvus.

Non esiste un ciclo separato di export-and-import il cui unico scopo sia ricostruire un'altra copia authoritative per il servizio.

Anche la governance rimane nettamente separata. Le versioni della sorgente, il lineage e la proprietà della sorgente restano alla piattaforma lake. Milvus mantiene la propria autorizzazione a livello di collezione e le credenziali necessarie per leggere la sorgente. Condividere un'unica base dati non significa fondere ogni dominio di sicurezza in un unico sistema.

Questo è il collegamento con Vector Lakebase: il lake rimane la base dati condivisa, mentre Milvus fornisce un livello di retrieval a bassa latenza sopra di esso. External Collection è una parte di quell'architettura, insieme a Storage V3, Snapshots, integrazione Spark, evoluzione dello schema e backfill.

Dove si colloca External Collection, e dove no

External Collection è la scelta giusta quando:

• I tuoi dati authoritative risiedono già in Parquet, Vortex, Lance, Iceberg o in un'altra sorgente esterna supportata.
• Il dataset è prodotto principalmente in batch anziché tramite scritture transazionali ad alta frequenza.
• Mantenere una seconda copia di servizio crea un overhead significativo di ETL, aggiornamento o governance.
• Più sistemi devono lavorare con lo stesso dataset aperto.
• Un confine di Refresh esplicito è accettabile per l'aggiornamento del servizio.
• Vuoi il retrieval di produzione di Milvus senza rendere Milvus il proprietario delle righe sorgente.

Una normale collezione Milvus è ancora la scelta migliore quando:

• l'applicazione inserisce o aggiorna record in modo continuo;
• le eliminazioni devono diventare visibili attraverso il percorso di scrittura online;
• il workload dipende da funzionalità della collezione non disponibili per gli schemi esterni;
• Il design di servizio intende mantenere intenzionalmente tutti i dati necessari in memoria, evitando cache miss remoti.

Vale la pena tenere a mente diversi confini.

• Le External Collection sono in sola lettura. Le modifiche alla sorgente avvengono al di fuori di Milvus.
• Lo zero-copy si applica alle righe sorgente. Indici, manifest, cache e risorse di calcolo hanno comunque un costo.
• Il Refresh è esplicito. Non è un meccanismo di sincronizzazione in streaming.
• La sorgente deve rimanere raggiungibile. Il comportamento di ricerca, indicizzazione e refresh dipende comunque dall'accesso allo storage e dalle credenziali.
• Storage V3 è obbligatorio. In Milvus 3.0 open-source, deve essere abilitato prima di utilizzare External Collection.
• External Collection non sostituisce l'elaborazione a monte. La generazione di embedding, il clustering, la deduplicazione e la pulizia dei dati avvengono comunque nei sistemi a monte appropriati.

La scelta è quindi complementare, non binaria. Un sistema può utilizzare le normali collezioni Milvus per lo stato online in rapida evoluzione e le External Collection per dataset ampi prodotti in batch la cui sede naturale è il lake.

Prova External Collection in Milvus 3.0

External Collection è disponibile in Milvus 3.0. Inizia con un dataset lake rappresentativo e valuta gli aspetti che contano per il tuo workload: refresh iniziale e incrementale, costo di costruzione degli indici, comportamento delle query a caldo e a freddo e l'intervallo di aggiornamento richiesto dalla tua applicazione.

Per i dettagli di implementazione, consulta:

• Create an External Collection
• Milvus 3.0 release notes
• Milvus 3.0 launch blog

Se preferisci un percorso gestito, External Collection è disponibile anche come parte di Zilliz Vector Lakebase in Zilliz Cloud. Consulta:

• External Collection in Zilliz Cloud
• From Vector Database to Vector Lakebase
• Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI

Puoi anche portare domande di implementazione o feedback al repository GitHub di Milvus o alla community Discord di Milvus.