Note di rilascio

Scopri le novità di Milvus! Questa pagina riassume le nuove funzionalità, i miglioramenti, i problemi noti e le correzioni di bug presenti in ogni versione. Ti consigliamo di visitare regolarmente questa pagina per rimanere aggiornato sulle novità.

v3.0.1

Data di rilascio: 9 settembre 2026

Versione di Milvus	Versione SDK Python	Versione SDK Node.js	Versione SDK Java	Versione SDK Go
3.0.1	3.0.1	3.0.5	3.0.9	3.0.1

Siamo lieti di annunciare il rilascio di Milvus v3.0.1! Questa versione introduce la gestione degli snapshot REST v2, funzionalità di riclassificazione ampliate e il supporto per i campi TEXT nel client Go e nell'API RESTful, oltre a miglioramenti delle prestazioni e correzioni relative a Storage V3, alla coerenza dei dati e alla sicurezza.

Miglioramenti alle funzionalità

• Aggiunte API REST v2 per la gestione nativa degli snapshot a livello di collezione e il ripristino asincrono (#52118, #52172)
• Aggiunta una soglia configurabile per il numero di risultati per controllare la selezione del percorso di output Take per le operazioni di ricerca e query (#52437)
• Aggiunto il supporto per i campi TEXT nel client Go e nell’API RESTful (#52450)
• Aggiunte velocità IOPS di lettura iniziali e massime configurabili per le tabelle esterne (#52503)
• Aggiunta un’impostazione opzionale per i processi di aggiornamento delle collezioni esterne, che consente di attendere l’indicizzazione di tutti i segmenti prima di segnalare il completamento, senza ritardare la pubblicazione dei dati (#52712)
• Aggiunto il supporto al re-ranking L1 alle catene di funzioni di ricerca (#52745)
• Aggiunta la riorganizzazione ponderata RRF con pesi opzionali per ogni richiesta ANN in FunctionScore, REST, ricerca ibrida legacy e nel client Go (#52891, #52926)

Miglioramenti alla stabilità

• Migliorata la sicurezza della memoria negli indici RTree geometrici e nelle cache, nonché la gestione delle query WKB non analizzabili e delle geometrie vuote (#51312)
• Gestione della memoria migliorata grazie al ripristino della gestione della memoria transitoria a livello di processo e alla correzione delle stime di memoria per il caricamento simultaneo dei campi Storage V2/V3 e il caricamento degli indici scalari V3 (#51405)
• Riduzione dei colli di bottiglia nel download e dell’utilizzo della memoria durante la creazione di indici di collezioni esterne tramite la parallelizzazione delle letture e lo streaming dei dati vettoriali grezzi su disco (#51651)
• Miglioramento della produttività di Woodpecker per carichi di lavoro a piccoli batch e ad alta concorrenza, grazie al raggruppamento in batch delle aggiunte dei client e alla disponibilità delle impostazioni di sincronizzazione (#51810)
• Migliorata la proprietà del lettore di record e la coerenza del ciclo di vita, la gestione dei blob vuoti e la segnalazione degli errori di lettura in tutti i percorsi di archiviazione e compattazione (#51891)
• Migliorata l’efficienza della ricerca hash di raggruppamento con una pipeline interlacciata a quattro vie e misure di protezione per collisioni e limiti di rehash (#51977)
• Riduzione del sovraccarico di elaborazione degli inserimenti saltando l’analisi del corpo dell’inserimento WAL per le collezioni prive di campi di output BM25 o MinHash (#51986)
• Migliorata la segnalazione dei guasti di archiviazione e la gestione dei tentativi di riprova, preservando le classificazioni degli errori transitori e permanenti tra i livelli di esecuzione (#51990)
• Migliorate le prestazioni delle query spaziali abilitando di default la suddivisione GIS in approssimativo/raffinato e la fusione dei predicati nella stessa colonna (#52008)
• Migliorata la pianificazione delle attività di indicizzazione del testo e di frammentazione JSON grazie al controllo di ammissione basato su backlog condiviso e alla priorità di invio alternata (#52010)
• Aggiunto il supporto mmap per le mappature di offset dei segmenti sigillati, con opzioni di caricamento dedicate e contabilità delle risorse su disco (#52035)
• Ottimizzato il caricamento dei dati di Storage V2 eseguendo su richiesta la stima della memoria dei blocchi per colonna (#52037)
• Aggiunto supporto AutoIndex lato server per gli indici associati ai campi di output delle nuove funzioni, consentendo alle richieste add_function_field di omettere i parametri dell’indice o di specificare AUTOINDEX (#52109)
• Ridotti i payload dei report di distribuzione QueryNode tramite report incrementali con fallback al report completo e ridotte le allocazioni di memoria durante la raccolta delle metriche (#52111, #52119)
• Migliorata la sicurezza dell’hash delle password aumentando il costo bcrypt da 4 a 10; per aggiornare gli hash esistenti è richiesta la rotazione delle credenziali (#52145)
• Ridotta la decodifica ridondante durante le importazioni Parquet leggendo solo le colonne foglia richieste per i sottocampi degli array di strutture (#52224)
• Miglioramento del raggruppamento con fusione forzata tramite una pianificazione a più round basata sulle dimensioni e deprecazione dell’impostazione della soglia di pianificazione legacy (#52242)
• Aggiornato cgosymbolizer per impedire che i processi Milvus in esecuzione come PID 1 si blocchino a seguito di errori nativi (#52299)
• Migliorata la convalida del conteggio delle righe per gli input di evidenziazione semantica (#52409)
• Migliorato il controllo dei tentativi di importazione con backoff configurabile per i tentativi di scrittura (#52414, #52415, #52427)
• Migliorata la gestione del ciclo di vita delle attività di analisi recuperando le versioni obsolete delle statistiche e persistendo gli stati terminali (#52416, #52417)
• Miglioramento del coordinamento del ciclo di vita dei segmenti tramite l'attesa del rilascio del segmento dopo i timeout di blocco (#52422)
• Miglioramento dell’ordinamento dello storage per la compattazione dei dati con un merge k-way (#52429)
• Riduzione dell’espansione del buffer di validità dei campi nullabili, preservando le maschere compresse durante l’accesso ai blocchi, la valutazione delle espressioni e le statistiche JSON (#52451)
• Migliorata la protezione di credenziali sensibili, chiavi API, hash delle password RBAC e dettagli delle fonti di raccolta esterne, impedendone l’esposizione nei log o nei messaggi di errore (#52487, #52664, #52710)
• Miglioramento del controllo della concorrenza degli aggiornamenti parziali con convalida CAS ottimistica e tentativi di ripetizione sicuri per i conflitti ammissibili (#52495)
• Migliorata la stabilità degli snapshot di lettura dei segmenti in crescita e la gestione della durata degli snapshot dello schema (#52572)
• Riduzione delle scansioni ridondanti dei metadati di autorizzazione durante i backup (#52612)
• Migliorata la mappatura degli ID vettoriali nullabili spostandola nel livello dell’indice, unificando la gestione degli ID logici e supportando mappature basate su mmap per gli indici sigillati (#52657)
• Migliorata la sincronizzazione tra la compilazione JIT di Sonic e il caricamento dei plugin Go nelle build CPU e GPU (#52738)
• Migliorata la risoluzione dei canali del percorso di scrittura del proxy tramite la cache dei metadati, eliminando le RPC ridondanti del coordinatore e migliorando la classificazione degli errori (#52739)
• Ridotto il tempo di calcolo del recall da circa 3,08 secondi a 18,5 millisecondi con topk=100000 nel benchmark riportato (#52763)
• Ottimizzazione del filtraggio dei campi nullabili riutilizzando le bitmap di validità, riducendo l’archiviazione ridondante degli offset nulli e accelerando le copie dei set di bit (#52801, #52823, #52825)
• Miglioramento degli indici scalari ibridi sui sottocampi delle strutture annidate utilizzando STL_SORT quando il numero di elementi distinti raggiunge il limite di cardinalità della bitmap (#52849)
• Migliorata l’efficienza del filtraggio degli ID di segmento nella cache dei metadati (#52855)
• Ridotte le allocazioni di memoria nelle funzioni di supporto per l’hash (#52857)
• Ottimizzazione dell’ordinamento dei risultati di riorganizzazione unificati eliminando le ricerche nella mappa per ogni confronto (#52885)
• Migliorata la sicurezza della memoria nella gestione dei valori predefiniti JSON e delle viste stringa non terminate con NUL (#52906)
• Migliorati i tempi di compilazione in C++ grazie alla compilazione unitaria con ambito, alla cache del compilatore ottimizzata e alla riduzione del lavoro di compilazione ridondante (#52995)
• Migliorata la copertura e l’aggiornamento delle metriche del filesystem raccogliendo le metriche dai filesystem memorizzati nella cache al momento dello scrape, preservando i nomi e le etichette delle metriche esistenti (#53026)
• Aggiunta l’impostazione aggiornabile growingBuildThreadRate per configurare il numero di thread per la creazione dell’indice provvisorio dei segmenti in crescita, pur mantenendo l’impostazione predefinita a thread singolo (#53033)
• Aggiunto il supporto per il writeback dei dati dei campi mmap alla versione 3.0 tramite un backport, con l’opzione queryNode.mmap.writeback disabilitata per impostazione predefinita (#53079)

Correzioni di bug

• Risolti risultati errati e convalida incoerente dei predicati nelle query JSON, ARRAY e TIMESTAMPTZ, inclusi predicati di tipo misto, confronti di numeri grandi e filtraggio su più batch (#51775)
• Risolto il problema dell’incoerenza dei dati aggiornati durante gli aggiornamenti paralleli delle raccolte esterne quando i file di origine di un segmento si estendevano su più attività (#51893)
• Corrette le espressioni MATCH che accettavano predicati che non operavano a livello di elemento (#51940)
• Risolto il problema per cui le ricerche senza corrispondenze fallivano con un errore di tipo ID non supportato (#51999)
• Risolto il blocco di Milvus standalone durante lo spegnimento aggiungendo un timeout di migrazione configurabile con un valore predefinito di 10 secondi (#52027)
• Risolto il problema delle richieste di embedding di tabelle esterne che utilizzavano un’identità di cluster errata quando i worker DataNode erano condivisi tra cluster di servizio (#52042)
• Risolto un problema che impediva l’aggiornamento di integration_id e model_deployment_id per le funzioni TextEmbedding (#52081)
• Risolto il problema per cui le risposte HTTP JSON omettevano lo stato esplicito ok=false per i segmenti di backfill non riusciti (#52082)
• Risolto il problema per cui i caricamenti di oggetti MinIO fallivano con errore HTTP 400 XAmzContentChecksumMismatch in caso di riprova dopo timeout di trasporto o di bassa velocità (#52128, #52194)
• Risolto il blocco del bilanciamento dei segmenti tra i QueryNode quando il servizio di streaming era abilitato (#52147, #52169)
• Risolta la perdita silenziosa di dati durante la compattazione mista quando non era possibile ricostruire i record conservati (#52200)
• Risolto il problema per cui i ripristini degli snapshot perdevano le impostazioni delle raccolte e passavano in modo imprevisto alla "Strong consistency" (#52206)
• Risolto il problema per cui le eliminazioni in streaming tralasciavano i segmenti sigillati appena caricati, consentendo ai dati eliminati di rimanere interrogabili (#52218)
• Risolto il problema per cui gli indici annidati non venivano creati correttamente per i dati vuoti (#52247)
• Risolti i deadlock durante il passaggio al servizio di streaming che lasciavano le operazioni in attesa a tempo indeterminato (#52292)
• Risolto il problema dei valori predefiniti errati della geometria durante la compattazione e la ricostruzione dei record, nonché delle marcature "null" errate per i valori della geometria precompilati nelle importazioni Parquet (#52350)
• Risolto il problema per cui segmenti V3 validi venivano rifiutati durante la compattazione e il ripristino dopo un riavvio di DataCoord (#52383, #52389, #52390, #52391, #52392, #52393)
• Risolti gli errori di caricamento dei segmenti con un errore di metadati di versione mancanti durante l’utilizzo di indici scalari ibridi su sottocampi di array VARCHAR nelle strutture (#52385)
• Risolto il problema per cui le colonne esterne non venivano aggiornate quando veniva riaperto un manifesto aggiornato (#52397)
• Risolta la gestione errata del fuso orario nelle ricerche con condizioni dipendenti dal tempo (#52407)
• Risolta la gestione errata degli input ArrayOfVector nelle richieste di ricerca (#52408)
• Risolto il problema per cui gli inserimenti non rifiutavano le righe che superavano il limite di dimensione supportato (#52426)
• Risolto il problema per cui gli indici provvisori ignoravano la versione dell’indice di destinazione configurata (#52449)
• Risolto il problema per cui le query che utilizzavano order_by non restituivano campi di output vettoriali densi (#52504, #52606)
• Risolto il problema per cui i privilegi revocati rimanevano attivi dopo essere stati rimossi da un gruppo di privilegi (#52554)
• Risolto il conteggio errato dei file binlog e delle etichette del formato di archiviazione per i segmenti Storage V3 dopo il riavvio di DataCoord (#52571, #52578)
• Risolto il blocco dei ripristini di snapshot esterni dovuto a controlli inaffidabili della versione dei worker o a ripetuti tentativi con worker non supportati fino al timeout (#52639)
• Risolti gli errori di caricamento dei segmenti per gli indici HYBRID sui sottocampi di array di strutture con file STLSORT legacy della versione 3.0.0, senza necessità di reindicizzazione (#52643)
• Risolti i crash durante l’elaborazione di buffer di dati Arrow C di lunghezza zero (#52652)
• Risolto il trattamento errato degli errori durante il caricamento o la riapertura di segmenti Storage V3 a seguito di errori nel manifesto, preservando lo stato esistente del segmento per riprovare in sicurezza (#52678)
• Risolti gli errori di query quando i filtri degli elementi ARRAY incontravano batch completi di array NULL o vuoti prima degli elementi successivi (#52720)
• Risolti i lavori di backfill che confermavano incorporamenti obsoleti dopo la modifica dello schema della raccolta (#52789)
• Risolti i campi mancanti nei record Storage V3 che venivano restituiti come NULL anziché con i valori predefiniti dichiarati (#52790, #52807, #52888)
• Risolti gli errori di copia lato server che impedivano il ripristino degli snapshot di Storage V3 su GCS con credenziali IAM/OAuth, incluse le copie di oggetti di dimensioni superiori a 5 GiB (#52792)
• Risolto l'accesso non autenticato tramite chiamate gRPC in streaming sulla porta del proxy esterno (#52854)
• Risolta la perdita dei timestamp di commit originali dei dati dopo la compattazione del cluster (#52859)
• Risolti i crash dei nodi di streaming causati da ripetuti errori di flush dopo l’aggiunta di un campo TEXT a collezioni con segmenti Storage V2 esistenti (#52897)
• Risolto il problema per cui le righe scadute nei segmenti di Storage V3 non innescavano la compattazione basata sul campo TTL e rimanevano memorizzate fino al verificarsi di un'altra condizione di compattazione (#52931)
• Risolto il problema delle chiavi primarie generate automaticamente incoerenti tra le collezioni di origine e di destinazione durante le importazioni replicate tramite CDC (#52941)
• Risolto il problema della perdita di scritture simultanee durante la migrazione del backend WAL (#52947, #52951, #52955)
• Risolto il problema per cui gli indici HYBRID annidati, ricostruiti o compattati con dati ad alta cardinalità, diventavano illeggibili dopo il rollback a una versione precedente (#52959)
• Risolta la gestione degli elementi nulli nelle righe vettoriali dense esterne, accettando righe nullabili interamente nulle e aggiungendo una gestione configurabile delle righe parzialmente nulle (#52968)
• Risolto il conteggio errato delle righe dei segmenti V3 e i ripetuti errori di compattazione con ordinamento a seguito del failover del nodo di streaming (#52970)
• Risolto il problema delle query che combinavano condizioni di intervallo con OR, omettendo i record al limite inferiore inclusivo (#52998)
• Risolto il problema per cui le ricerche per chiave primaria non mantenevano l'ordine degli ID richiesto (#52999)
• Risolto un problema per cui l’aggiunta di un campo TEXT dopo l’abilitazione di Storage V3 impediva il caricamento dei segmenti in crescita esistenti di Storage V2, interrompendo le operazioni di flush, ordinamento e indicizzazione (#53002)
• Risolti i problemi relativi agli snapshot che includevano segmenti Storage V3 non confermati, causando la segnalazione di successo dei ripristini mentre i segmenti ripristinati non potevano essere caricati (#53022, #53039)
• Risolto il problema per cui gli indici di testo di Storage V3 non venivano caricati quando i relativi file erano memorizzati in directory di attività o di versione nidificate (#53062)

v3.0.0

Data di rilascio: 29 luglio 2026

Versione Milvus	Versione SDK Python	Versione SDK Node.js	Versione SDK Java	Versione SDK Go
3.0.0	3.0.1	3.0.3	3.0.5	3.0.0

Milvus 3.0.0 è stato ufficialmente rilasciato! Basandosi sull'architettura nativa di Lake introdotta nella versione 3.0-beta, questa versione completa ciò che la beta aveva iniziato: External Collection copre un numero maggiore di flussi di lavoro Lakehouse; lo schema supporta l'aggiunta, il riempimento e l'eliminazione online; l'indice sparso è stato ricostruito attorno a SINDI; StructArray e la ricerca per faccette completano il motore di recupero; il passthrough FAISS e TEXT ampliano le opzioni relative a indici e modalità; inoltre, Woodpecker funziona come servizio autonomo.

Guarda il video qui sotto per saperne di più su Milvus 3.0 e partecipa alla sessione AMA con i manutentori del core:

Se non conosci ancora la linea 3.0, la sezione "Riepilogo delle funzionalità principali di 3.0" qui sotto riassume le funzionalità introdotte nella versione 3.0-beta; le note di rilascio della versione 3.0-beta contengono le descrizioni complete.

Novità della versione 3.0.0 (rispetto alla 3.0-beta)

Raccolta esterna: flussi di lavoro lakehouse più completi

La versione 3.0-beta ha introdotto la "Raccolta esterna": è possibile fare riferimento ai file del lakehouse in loco, creare indici ed effettuare ricerche senza copiare i dati in Milvus. Questa versione estende tale funzionalità verso flussi di lavoro completi di recupero dati in ambiente "lakehouse". I campi esterni possono ora alimentare i campi di output delle funzioni, come i vettori sparsi BM25, le firme MinHash e gli embedding di testo, in modo che i campi di recupero derivati dal testo e dai modelli vengano creati all’interno di Milvus senza copiare la tabella di origine. Refresh supporta inoltre l’evoluzione additiva dello schema: quando la tabella esterna acquisisce nuove colonne, Milvus applica le modifiche ai segmenti interessati invece di ricostruire la collezione.

Questa versione aggiunge inoltre un formato esterno denominato " milvus-table " che tratta i metadati degli snapshot di Milvus e i manifesti di Storage V3 come una fonte esterna, in modo che uno snapshot della collezione possa essere utilizzato a sua volta come tabella esterna: i sistemi di elaborazione in batch e di servizio ottengono una vista condivisa e supportata dal manifesto degli stessi dati.

Per ulteriori informazioni, consultare Crea una raccolta esterna e snapshot.

Schema flessibile: aggiungere, integrare e rimuovere colonne online

Gli schemi non rimangono statici in produzione — i modelli incorporati vengono sostituiti, le feature si evolvono, i campi vengono deprecati — e in passato ciò comportava la ricostruzione dell’intera collezione con tempi di inattività o doppie scritture. La versione 3.0.0 chiude il cerchio: le colonne possono essere aggiunte, popolate e rimosse mentre il servizio continua.

Il backfill funziona in entrambe le direzioni. Il backfill esterno gestisce i valori calcolati al di fuori di Milvus: si aggiunge una colonna, si esegue uno snapshot della collezione come punto di partenza coerente, si esegue il processo offline, si riscrivono i valori e Milvus indicizza la nuova colonna in modo incrementale — un aggiornamento del modello di embedding su centinaia di milioni di righe diventa un’operazione a caldo senza tempi di inattività. Il backfill interno copre i valori derivati dal kernel: basta associare una funzione BM25 o MinHash a una collezione esistente e il campo di output viene calcolato automaticamente sui dati esistenti.

Per ulteriori informazioni, consultare la sezione “Aggiunta di campi a una collezione esistente”.

Riorganizzazione degli indici sparsi: SINDI, Block-Max WAND e Block-Max MaxScore

Milvus 3.0 aggiorna l’indice vettoriale sparso su tutta la linea. Introduce nuovi algoritmi di ricerca — SINDI, Block-Max WAND e Block-Max MaxScore — insieme alla compressione con lista invertita, alla quantizzazione configurabile e alla selezione dell’algoritmo di ricerca in base al carico di lavoro. Anche il caricamento tramite mmap, la serializzazione e il punteggio BM25 sono stati ottimizzati, riducendo lo spazio di archiviazione dell’indice e il sovraccarico di caricamento per la ricerca su vettori sparsi e full-text su larga scala. Nei benchmark interni, l’indice BM25 compresso è circa 3 volte più piccolo dell’indice sparso 2.6 a un recall comparabile, mentre SINDI raggiunge fino a circa 10 volte il QPS di MaxScore su embedding sparsi appresi. Una volta abilitata la nuova versione dell’indice (vedere le note su compatibilità e comportamento), SINDI diventa l’impostazione predefinita per la ricerca IP sparsa, mentre MaxScore è l’impostazione predefinita per BM25.

Copertura di StructArray

StructArray ora supporta i valori nulli, gli indici bitmap, l’aggiunta dinamica di campi su collezioni attive e l’aggiornamento parziale dei campi delle strutture tramite upsert, con copertura REST e importazione in blocco corrispondenti.

La ricerca a livello di elemento aggiunge la ricerca ibrida tra i sotto-campi vettoriali con raggruppamento configurabile per entità (varianti max / sum / avg / top-k), oltre alla ricerca per intervallo e al raggruppamento al suo interno. Il filtraggio annidato copre i predicati element_filter, i quantificatori MATCH_ANY / MATCH_ALL / MATCH_LEAST / MATCH_MOST / MATCH_EXACT, l’accesso posizionale ai sotto-campi come tags[0][name] e array_length() sulla colonna struct.

Per ulteriori informazioni, consultare StructArray e Operatori StructArray.

Aggregazione della ricerca e ricerca per faccette

L’aggregazione delle query della versione beta calcola statistiche esatte sui dati filtrati; la versione 3.0.0 aggiunge la sfaccettatura nel percorso di ricerca. Specificare un campo di sfaccettatura al momento della ricerca e Milvus restituisce i valori di sfaccettatura principali, ciascuno rappresentato dal membro con la migliore corrispondenza nella classifica ANN e annotato con aggregati quali COUNT e AVG — la barra laterale della ricerca per faccette (marchio, fascia di prezzo, attributi) in un’unica richiesta, invece di eseguire un recupero eccessivo e un conteggio sul lato client.

Riorganizzazione della classifica tramite Function Chain

Il riclassamento è ora componibile tramite l’API Function Chain, che esegue una pipeline ordinata e tipizzata come parte di un’unica richiesta di ricerca. Una catena può combinare il riscoramento L0 iniziale su QueryNode con il riclassamento L2 post-riduzione su Proxy, supportando la trasformazione e la combinazione dei punteggi, il riclassamento basato su modelli, l’ordinamento e il trimming dei candidati senza orchestrazione lato client. Questa versione aggiunge inoltre il punteggio XGBoost nativo per il riclassamento L0 utilizzando modelli UBJ registrati come FileResources, insieme ai provider di inferenza Hugging Face per l’embedding testuale gestito dal server e il riclassamento basato sulla similarità delle frasi.

Campi TEXT per testi lunghi

I campi TEXT rendono i testi lunghi di prima classe, con la rimozione dei limiti di lunghezza a livello di archiviazione: supportano text_match, phrase_match e BM25. I valori inferiori a 64 KB rimangono in linea; quelli più grandi vengono trasferiti in file LOB a livello di partizione in formato Vortex, con la colonna che memorizza solo i riferimenti (file_id, offset). I file LOB sono condivisi tra i segmenti, quindi la compattazione sposta i riferimenti invece di riscrivere il testo. Per RAG ciò significa recuperare vettori e testo sorgente dallo stesso archivio in un'unica operazione di I/O — senza bisogno di gestire un archivio blob esterno.

Pass-through dell’indice FAISS

Un nuovo tipo di indice « FAISS » accetta stringhe arbitrarie di «index-factory» di Faiss tramite il parametro « faiss_index_name » — IVF64,Flat, HNSW16,Flat, OPQ16,IVF64,PQ16x4 — con i parametri di ricerca passati direttamente, in modo che le ricette di Faiss vengano riprodotte direttamente su Milvus.

Supporto dei formati Vortex e Lance

Il livello di archiviazione acquisisce due formati colonnari aperti: Vortex come formato interno di nuova generazione — codifiche adattive (dizionario, RLE, bit-packing, compressione specifica per i valori in virgola mobile), decompressione zero-copy, ottimizzato per carichi di lavoro misti vettoriali e scalari — e Lance, insieme a Parquet, per l’interoperabilità con l’ecosistema aperto. Vortex è destinato a diventare il formato interno predefinito, con il pushdown dei filtri e una variante locale in fase di sviluppo.

Distribuzione autonoma di Woodpecker

Woodpecker, il WAL al centro del percorso di scrittura in streaming, può ora essere implementato come servizio indipendente anziché integrato in altri nodi — scalabilità indipendente, isolamento dei guasti e osservabilità, come qualsiasi altro microservizio. Ciò è particolarmente importante per i cluster di grandi dimensioni e i carichi di lavoro con un elevato numero di scritture.

Riepilogo delle funzionalità principali della versione 3.0

Le funzionalità riportate di seguito sono state introdotte nella versione 3.0-beta e fanno parte della versione 3.0.0; consultare le note sulla versione beta per le descrizioni complete.

• Raccolta esterna — interrogazione dei dati del lakehouse (Parquet, Lance, Iceberg, Vortex) in loco: zero-copy, di sola lettura, sincronizzati tramite aggiornamento incrementale.
• Snapshot — viste di raccolta in sola lettura a un punto nel tempo tramite riferimento al segmento, con spazio di archiviazione marginale quasi nullo.
• Storage V3 (Loon) — archiviazione colonnare basata su manifest su object storage; la base per Snapshot e Raccolta esterna.
• Query / Ricerca ORDER BY — ordinamento multi-campo lato server con ASC / DESC per campo.
• Aggregazione delle query — COUNT / SUM / AVG / MIN / MAX con raggruppamento, valutate lato server.
• EmbList + DiskANN — indicizzazione multivettoriale su disco per elenchi di incorporamento StructArray, con percorsi di accelerazione quali Muvera e Lemur.
• Funzione MinHash (doc-in, doc-out) — firme MinHash lato server più " MINHASH_LSH " per il rilevamento di quasi-duplicati.
• Vettori nullabili — NULL su tutti e sei i tipi di vettore; la ricerca salta le righe NULL e AddField si estende ai campi vettoriali.
• TTL delle entità — scadenza per riga determinata da un campo TIMESTAMPTZ.
• FileResource — dizionari, elenchi di sinonimi ed elenchi di parole da escludere gestiti a livello di cluster per analizzatori, BM25 e Text Match.
• Force Merge — compattazione dei segmenti attivata dall’operatore, in modalità sincrona o asincrona.

Note sulla compatibilità e sul comportamento

• Storage V3 (Loon) è disabilitato per impostazione predefinita. Le funzionalità che dipendono da esso — come Snapshot e i campi TEXT — richiedono l’abilitazione manuale tramite common.storage.useLoonFFI. Storage V3 sarà abilitato per impostazione predefinita in una versione successiva.
• La compatibilità e il rollback dalla versione 2.6 alla 3.0 sono garantiti: un'implementazione della versione 3.0 può essere riportata alla versione 2.6. Tuttavia, una volta abilitate o utilizzate funzionalità che modificano il formato dei dati serializzati (ad esempio Storage V3), il rollback non è più possibile.
• Le nuove versioni dell’indice sono per ora opzionali. Gli algoritmi di indicizzazione di nuova introduzione richiedono l’aumento manuale della versione dell’indice di destinazione (dadataCoord.targetVecIndexVersion a 10, da dataCoord.targetScalarIndexVersion a 4) prima che entrino in vigore; una versione successiva li abiliterà per impostazione predefinita.
• Le immagini GPU passano a CUDA 12.9 e non mantengono più la compatibilità GPU con Ubuntu 20.04.

v3.0-beta

Data di rilascio: 9 maggio 2026

Versione di Milvus	Versione SDK Python	Versione SDK Node.js
3.0-beta	3.0.0	3.0.0

Milvus 3.0-beta amplia il database vettoriale Milvus con una nuova integrazione nell'ecosistema Open Lake: External Collection consente a Milvus di interrogare le tabelle Lake esterne senza copia (zero-copy), mentre Spark può leggere le collezioni Milvus direttamente tramite Snapshot. Questa versione offre inoltre funzionalità di recupero più avanzate, schemi più espressivi, una personalizzazione più approfondita della ricerca testuale, controlli più precisi sul ciclo di vita dei dati e dei modelli, nonché maggiori controlli a livello di operatore. Milvus 3.0 costituisce il nucleo centrale di Zilliz Lakebase, ne potenzia le funzionalità unificate di serving, discovery e batch.

Caratteristiche principali

External Collection

Nelle tipiche pipeline di dati per l’IA, terabyte di embedding e metadati risiedono già su sistemi di archiviazione a oggetti sotto forma di tabelle Parquet, Lance o Iceberg. Copiare tali dati in Milvus raddoppia i costi di archiviazione, aggiunge una pipeline ETL che deve essere mantenuta sincronizzata e sottrae al cliente il controllo sulla governance dei dati.

La raccolta esterna elimina la necessità di copia. Una raccolta Milvus può fare riferimento ai file nella loro posizione originale, mentre Milvus gestisce esclusivamente lo schema, gli indici e l’esecuzione delle query. Un aggiornamento incrementale mantiene la raccolta allineata ai file sottostanti. I clienti i cui dati non possono lasciare il data lake, come i team finanziari e sanitari, possono eseguire il recupero vettoriale su quei dati direttamente dove si trovano. Un singolo set di dati residente nel data lake può anche essere servito da più istanze di Milvus contemporaneamente.

Per ulteriori informazioni, consultare la sezione Creare una raccolta esterna.

Istantanea

La distribuzione e la scoperta in batch spesso richiedono la stessa Collection contemporaneamente. La valutazione di modelli A/B, la deduplicazione su larga scala, la convalida del backfill e il rollback delle versioni richiedono tutte una visione stabile della Collection mentre le operazioni di scrittura sono ancora in corso.

Lo snapshot crea una vista "point-in-time" e di sola lettura di una raccolta facendo riferimento a segmenti esistenti invece di copiare i dati, quindi il costo marginale di archiviazione è prossimo allo zero. I processi batch possono leggere dallo snapshot con isolamento di tipo MVCC mentre la raccolta attiva continua ad accettare operazioni di scrittura.

Per ulteriori informazioni, consultare le sezioni " Snapshot", "Gestione degli snapshot" e "Casi d’uso degli snapshot".

Query / Ricerca con ordinamento

La ricerca e le query ora supportano l’ordinamento su più campi, con l’operazione di ordinamento delegata al kernel di Milvus e la possibilità di impostare i parametri « ASC » e « DESC » per ciascun campo. Ciò colma una lacuna comune in produzione: il Top-K basato esclusivamente sulla distanza spesso non soddisfa le esigenze aziendali quando l’elemento più simile non è il più economico, il più recente o il più popolare.

Le applicazioni non devono più recuperare un numero eccessivo di risultati e riordinarli sul client per esprimere una classifica composita.

Per ulteriori informazioni, consultare Ordinare i risultati della ricerca in base a campi scalari e Ordinare i risultati delle query.

Aggregazione delle query

In passato, per generare statistiche sulla distribuzione dei tenant, conteggi sulla completezza dei campi o lo stato di avanzamento del rollout delle versioni da una Milvus Collection, era necessario recuperare le entità corrispondenti sul client e aggregarle lì. Milvus 3.0 integra l’aggregazione scalare in stile SQL nel kernel. Una chiamata di query accetta espressioni di aggregazione e di tipo “ group_by_fields ” in output_fields, tra cui count(*), count(<field>), sum(<field>), avg(<field>), min(<field>) e max(<field>). L’aggregazione viene valutata sul lato server dopo il filtraggio.

Per ulteriori informazioni, consultare la sezione Risultati delle query aggregate.

Vettore nullo

Gli embedding vengono spesso generati in modo asincrono, pertanto un’entità può arrivare prima del proprio vettore. Anche i dati multimodali presentano lacune naturali, come un video senza sottotitoli o un prodotto senza immagine. Le versioni precedenti non offrivano una soluzione adeguata: le applicazioni ritardavano la scrittura fino a quando il vettore non era pronto oppure inserivano un vettore segnaposto, e entrambe le scelte compromettevano la qualità del recupero.

Milvus 3.0 supporta il valore NULL nei campi vettoriali per tutti e sei i tipi di vettore. La ricerca ignora automaticamente i vettori NULL, la qualità del recupero non ne risente e i vettori NULL non occupano effettivamente spazio di archiviazione. L’estensione " AddField " si applica anche ai campi vettoriali nell’ambito di questa modifica: con l’opzione ` nullable=True`, una collezione esistente può aggiungere nuovi campi vettoriali online senza necessità di ricostruzione.

Per ulteriori informazioni, consultare Campi nullabili.

Dizionario personalizzato e dizionario dei sinonimi

I tokenizzatori predefiniti non sempre soddisfano i requisiti di qualità della ricerca in produzione. Il cinese, i settori verticali quali medicina, diritto e chimica, nonché i corpora multilingue possono trarre notevoli vantaggi dai dizionari personalizzati e dalle tabelle di sinonimi. Finora, queste risorse erano per lo più implementate come riscritture delle query a livello di applicazione.

Milvus 3.0 introduce un meccanismo FileResource per la registrazione di dizionari personalizzati per i tokenizzatori, elenchi di sinonimi, elenchi di stop-word e regole di scomposizione delle parole composte. Una volta registrata, una risorsa può essere richiamata da qualsiasi tokenizer o filtro e ha effetto su BM25, sugli analizzatori e su Text Match. I dizionari e i sinonimi possono ora essere gestiti centralmente con controllo delle versioni, anziché essere sparsi nel codice dell’applicazione.

Per ulteriori informazioni, consultare Gestione delle risorse file.

TTL delle entità

Il TTL a livello di collezione e a livello di partizione è troppo generico per molti scenari relativi al ciclo di vita e alla conformità. Tenant diversi all’interno della stessa collezione hanno spesso regole di conservazione diverse e le singole entità potrebbero dover scadere secondo una tempistica che non corrisponde al resto della collezione.

Milvus 3.0 supporta il TTL per singola entità. È sufficiente dichiarare un campo " TIMESTAMPTZ " nello schema, contrassegnarlo come campo TTL tramite una proprietà della raccolta e Milvus provvederà automaticamente a liberare le entità scadute. Ciò copre le richieste relative al "diritto all’oblio", i dati di sessione in scadenza e la cronologia delle conversazioni limitata, senza necessità di pulizia da parte dell’applicazione.

Per ulteriori informazioni, consultare Impostazione del TTL a livello di entità.

MinHash DIDO (Doc-in, Doc-out)

Milvus 2.6 ha introdotto l’indice MINHASH_LSH per il rilevamento di quasi-duplicati basato su insiemi, ma le applicazioni dovevano comunque calcolare le firme MinHash prima di scrivere i dati in Milvus.

Milvus 3.0 aggiunge una funzione MinHash lato server. È sufficiente dichiarare nello schema un campo di input " VARCHAR " e un campo di output " BINARY_VECTOR ", associare una funzione " FunctionType.MINHASH " e Milvus calcolerà le firme durante l’inserimento, l’inserimento in blocco e la ricerca. Insieme a " MINHASH_LSH", questa funzionalità supporta flussi di lavoro di deduplicazione per grandi set di dati, fingerprinting e rilevamento di plagio all’interno di Milvus.

Per ulteriori informazioni, consultare Funzione MinHash.

EmbList + DISKANN

L’assunto “un’entità = un vettore” non è più adeguato al recupero moderno. I documenti lunghi vengono suddivisi in molti blocchi, i modelli a interazione tardiva come ColBERT generano un vettore per ogni token e le entità multimodali possono presentare diverse rappresentazioni.

EmbList memorizza un elenco di vettori a lunghezza variabile per ogni entità, utilizzando DISKANN come indice su disco. Il percorso su disco mantiene sotto controllo l’utilizzo della RAM quando il corpus supera i limiti di memoria disponibili. EmbList + DISKANN è la prima variante della più ampia famiglia StructList in questa versione RC. Il resto della famiglia, compreso il filtraggio StructList e l’accelerazione multivettore Muvera / Lemur, è previsto per il rilascio ufficiale della versione 3.0.

Per ulteriori informazioni, consultare Ricerca con liste di embedding.

Force Merge

I carichi di lavoro di produzione accumulano frammentazione dei segmenti nel tempo, il che causa fluttuazioni nella latenza delle query e un aumento dello spazio di archiviazione.

Milvus 3.0 aggiunge la possibilità di attivare esplicitamente la compattazione dei segmenti durante le finestre di traffico ridotto, sia in modalità sincrona che asincrona.

Per ulteriori informazioni, consultare " Compattazione con fusione forzata".

Storage V3

Milvus 3.0 introduce Storage V3, un motore di archiviazione colonnare basato su manifest in cui dati e metadati risiedono su uno storage a oggetti compatibile con S3. Ogni versione del set di dati viene acquisita come istantanea immutabile del manifest, un file codificato in Avro che registra quali gruppi di colonne, log delta e statistiche compongono il set di dati.

I manifesti sono file Avro compatti, mentre i log delta registrano le eliminazioni a livello di entità senza riscrivere i file di dati. Ciò mantiene basso il sovraccarico dei metadati man mano che i set di dati crescono. Il manifesto inoltre disaccoppia il tracciamento dei metadati dal percorso di query, consentendo a una Collection di gestire un maggior numero di segmenti senza compromettere le prestazioni delle query.

Poiché gli stati sono memorizzati su uno storage a oggetti, il set di dati è autodescrittivo: qualsiasi lettore con accesso al percorso di archiviazione può individuarlo e interpretarlo senza bisogno di un catalogo centrale. Questa proprietà è alla base delle integrazioni con External Collection, Snapshot e dei futuri data lake.