Home
Blog
Come aggiornare in modo sicuro da Milvus 2.5.x a Milvus 2.6.x

Come aggiornare in modo sicuro da Milvus 2.5.x a Milvus 2.6.x

Tutorials

December 25, 2025

Yiqing Lu

Milvus 2.6 è disponibile da un po' e si sta dimostrando un solido passo avanti per il progetto. Il rilascio porta con sé un'architettura perfezionata, prestazioni più elevate in tempo reale, un minore consumo di risorse e un comportamento di scalabilità più intelligente negli ambienti di produzione. Molti di questi miglioramenti sono stati determinati direttamente dal feedback degli utenti e i primi utilizzatori della versione 2.6.x hanno già riferito di ricerche sensibilmente più veloci e di prestazioni del sistema più prevedibili in caso di carichi di lavoro pesanti o dinamici.

Per i team che utilizzano Milvus 2.5.x e che stanno valutando il passaggio a 2.6.x, questa guida è il punto di partenza. Essa analizza le differenze architettoniche, evidenzia le funzionalità chiave introdotte in Milvus 2.6 e fornisce un percorso di aggiornamento pratico e graduale, progettato per ridurre al minimo le interruzioni operative.

Se i vostri carichi di lavoro prevedono pipeline in tempo reale, ricerca multimodale o ibrida, o operazioni vettoriali su larga scala, questo blog vi aiuterà a valutare se la versione 2.6 è in linea con le vostre esigenze e, se decidete di procedere, a eseguire l'aggiornamento con fiducia, mantenendo l'integrità dei dati e la disponibilità del servizio.

Cambiamenti nell'architettura da Milvus 2.5 a Milvus 2.6

Prima di addentrarci nel flusso di aggiornamento vero e proprio, cerchiamo di capire come cambia l'architettura di Milvus 2.6.

Architettura di Milvus 2.5

Milvus 2.5 Architecture Architettura di Milvus 2.5

In Milvus 2.5, i flussi di lavoro in streaming e batch erano intrecciati tra più nodi worker:

QueryNode gestiva sia le query storiche che quelle incrementali (streaming).
IlDataNode gestiva sia l'ingest-time flushing che la compattazione in background dei dati storici.

Questa mescolanza di logica batch e real-time rendeva difficile scalare i carichi di lavoro batch in modo indipendente. Inoltre, lo stato di streaming era disperso in diversi componenti, introducendo ritardi di sincronizzazione, complicando il ripristino dei guasti e aumentando la complessità operativa.

Architettura di Milvus 2.6

Milvus 2.6 Architecture Architettura di Milvus 2.6

Milvus 2.6 introduce uno StreamingNode dedicato che gestisce tutte le responsabilità dei dati in tempo reale: consumare la coda dei messaggi, scrivere segmenti incrementali, servire query incrementali e gestire il recupero basato su WAL. Con lo streaming isolato, i restanti componenti assumono ruoli più puliti e mirati:

QueryNode gestisce ora solo le query batch sui segmenti storici.
Il DataNode gestisce solo le attività relative ai dati storici, come la compattazione e la creazione di indici.

Lo StreamingNode assorbe tutti i compiti relativi allo streaming che in Milvus 2.5 erano suddivisi tra DataNode, QueryNode e persino il Proxy, facendo chiarezza e riducendo la condivisione dello stato tra i vari ruoli.

Milvus 2.5.x vs Milvus 2.6.x: Confronto componente per componente

	Milvus 2.5.x	Milvus 2.6.x	Cosa è cambiato
Servizi di coordinamento	RootCoord / QueryCoord / DataCoord (o MixCoord)	MixCoord	La gestione dei metadati e la programmazione delle attività sono consolidate in un unico MixCoord, semplificando la logica di coordinamento e riducendo la complessità della distribuzione.
Livello di accesso	Proxy	Proxy	Le richieste di scrittura vengono instradate solo attraverso il nodo di streaming per l'ingestione dei dati.
Nodi di lavoro	-	Nodo di streaming	Nodo dedicato all'elaborazione dello streaming, responsabile di tutta la logica incrementale (segmenti crescenti), tra cui:- Ingestione dei dati incrementali- Interrogazione dei dati incrementali- Persistenza dei dati incrementali nello storage degli oggetti- Scritture basate sul flusso- Recupero dei guasti basato su WAL
	Nodo di interrogazione	Nodo di interrogazione	Nodo di elaborazione batch che gestisce le interrogazioni solo sui dati storici.
	Nodo dati	Nodo dati	Nodo di elaborazione batch responsabile solo dei dati storici, compresa la compattazione e la creazione di indici.
	Nodo indice	-	L'Index Node viene unito al Data Node, semplificando la definizione dei ruoli e la topologia di distribuzione.

In breve, Milvus 2.6 traccia una chiara linea di demarcazione tra i carichi di lavoro in streaming e quelli in batch, eliminando il groviglio di componenti presenti nella versione 2.5 e creando un'architettura più scalabile e manutenibile.

Caratteristiche principali di Milvus 2.6

Prima di addentrarci nel flusso di aggiornamento, ecco una rapida occhiata a ciò che Milvus 2.6 porta in tavola. Questa versione si concentra sulla riduzione dei costi dell'infrastruttura, sul miglioramento delle prestazioni di ricerca e sulla facilità di scalare grandi carichi di lavoro dinamici di intelligenza artificiale.

Miglioramenti dei costi e dell'efficienza

QuantizzazioneRaBitQ per gli indici primari - Un nuovo metodo di quantizzazione a 1 bit che comprime gli indici vettoriali a 1/32 della loro dimensione originale. In combinazione con il reranking SQ8, riduce l'utilizzo della memoria a ~28%, aumenta il QPS di 4× e mantiene un richiamo di ~95%, riducendo significativamente i costi dell'hardware.
BM25-Optimized Full-Text Search - Punteggio nativo BM25 alimentato da vettori di pesi radi per termini. La ricerca per parole chiave viene eseguita 3-4 volte più velocemente (fino a 7 volte su alcuni set di dati) rispetto a Elasticsearch, mantenendo le dimensioni dell'indice a circa un terzo dei dati di testo originali.
Indicizzazione dei percorsi JSON con JSON Shredding - Il filtraggio strutturato su JSON annidati è ora molto più veloce e prevedibile. I percorsi JSON pre-indicizzati riducono la latenza del filtro da 140 ms a 1,5 ms (P99: 480 ms → 10 ms), rendendo la ricerca ibrida vettoriale e il filtraggio dei metadati molto più reattivi.
Supporto ampliato per i tipi di dati - Aggiunge i tipi di vettore Int8, i campi geometrici (POINT / LINESTRING / POLYGON) e gli array di strutture. Queste estensioni supportano i carichi di lavoro geospaziali, la modellazione di metadati più ricchi e schemi più puliti.
Upsert per aggiornamenti parziali - È ora possibile inserire o aggiornare entità utilizzando un'unica chiamata a chiave primaria. Gli aggiornamenti parziali modificano solo i campi forniti, riducendo l'amplificazione della scrittura e semplificando le pipeline che aggiornano frequentemente i metadati o gli embeddings.

Miglioramenti nella ricerca e nel recupero

Elaborazione del testo e supporto multilingue migliorati: I nuovi tokenizer Lindera e ICU migliorano la gestione del testo giapponese, coreano e multilingue. Jieba supporta ora i dizionari personalizzati. run_analyzer aiuta a eseguire il debug del comportamento della tokenizzazione e gli analizzatori multilingue assicurano una ricerca multilingue coerente.
Corrispondenza del testo ad alta precisione: Phrase Match impone query di frasi ordinate con slop configurabile. Il nuovo indice NGRAM accelera le query di sottostringa e LIKE su campi VARCHAR e percorsi JSON, consentendo una rapida corrispondenza di testo parziale e fuzzy.
Reranking time-aware e metadata-aware: I Decay Ranker (esponenziale, lineare, gaussiano) regolano i punteggi in base ai timestamp; i Boost Ranker applicano regole basate sui metadati per promuovere o declassare i risultati. Entrambi aiutano a perfezionare il comportamento di recupero senza modificare i dati sottostanti.
Integrazione semplificata dei modelli e vettorizzazione automatica: Le integrazioni integrate con OpenAI, Hugging Face e altri fornitori di incorporazioni consentono a Milvus di vettorializzare automaticamente il testo durante le operazioni di inserimento e interrogazione. Niente più pipeline di incorporamento manuale per i casi d'uso più comuni.
Aggiornamenti online dello schema per i campi scalari: Aggiungete nuovi campi scalari alle collezioni esistenti senza tempi di inattività o ricariche, semplificando l'evoluzione dello schema all'aumentare dei requisiti dei metadati.
Rilevamento di quasi duplicati con MinHash: MinHash + LSH consente un efficiente rilevamento di quasi-duplicazioni in grandi insiemi di dati senza costosi confronti esatti.

Aggiornamenti dell'architettura e della scalabilità

Archiviazione a livelli per la gestione dei dati caldi e freddi: Separa i dati caldi da quelli freddi su SSD e object storage; supporta il caricamento pigro e parziale; elimina la necessità di caricare completamente le raccolte in locale; riduce l'utilizzo delle risorse fino al 50% e accelera i tempi di caricamento per i dataset di grandi dimensioni.
Servizio di streaming in tempo reale: Aggiunge nodi di streaming dedicati integrati con Kafka/Pulsar per l'ingestione continua; consente l'indicizzazione immediata e la disponibilità di query; migliora il throughput di scrittura e accelera il recupero dei guasti per carichi di lavoro in tempo reale e in rapida evoluzione.
Scalabilità e stabilità migliorate: Milvus supporta ora oltre 100.000 collezioni per grandi ambienti multi-tenant. Gli aggiornamenti dell'infrastruttura - Woodpecker (WAL a disco zero), Storage v2 (IOPS/memoria ridotti) e Coordinator Merge - migliorano la stabilità del cluster e consentono una scalabilità prevedibile in presenza di carichi di lavoro elevati.

Per un elenco completo delle caratteristiche di Milvus 2.6, consultare le note di rilascio di Milvus.

Come aggiornare da Milvus 2.5.x a Milvus 2.6.x

Per mantenere la massima disponibilità del sistema durante l'aggiornamento, i cluster Milvus 2.5 devono essere aggiornati a Milvus 2.6 nel seguente ordine.

1. Avviare prima il nodo di streaming

Avviare il nodo di streaming in anticipo. Il nuovo Delegator (il componente del Query Node responsabile della gestione dei dati in streaming) deve essere spostato nel Milvus 2.6 Streaming Node.

2. Aggiornamento di MixCoord

Aggiornare i componenti del coordinatore a MixCoord. Durante questa fase, MixCoord deve rilevare le versioni dei Worker Nodes per gestire la compatibilità tra le versioni all'interno del sistema distribuito.

3. Aggiornamento del nodo di interrogazione

Gli aggiornamenti del Query Node richiedono in genere più tempo. Durante questa fase, i Data Node e gli Index Node di Milvus 2.5 possono continuare a gestire operazioni come il Flush e la creazione di indici, contribuendo a ridurre la pressione sul lato query mentre i Query Node vengono aggiornati.

4. Aggiornamento del nodo dati

Una volta che i DataNode di Milvus 2.5 sono stati messi offline, le operazioni di Flush diventano indisponibili e i dati nei Segmenti in crescita possono continuare ad accumularsi fino a quando tutti i nodi non saranno completamente aggiornati a Milvus 2.6.

5. Aggiornamento del Proxy

Dopo aver aggiornato un Proxy a Milvus 2.6, le operazioni di scrittura su tale Proxy rimarranno indisponibili fino a quando tutti i componenti del cluster non saranno aggiornati alla versione 2.6.

6. Rimuovere il nodo indice

Una volta che tutti gli altri componenti sono stati aggiornati, il nodo indice standalone può essere rimosso in modo sicuro.

Note:

Dal completamento dell'aggiornamento del DataNode fino al completamento dell'aggiornamento del Proxy, le operazioni di Flush non sono disponibili.
Dal momento dell'aggiornamento del primo Proxy fino all'aggiornamento di tutti i nodi Proxy, alcune operazioni di scrittura non sono disponibili.
Quando si esegue l'aggiornamento diretto da Milvus 2.5.x a 2.6.6, le operazioni DDL (Data Definition Language) non sono disponibili durante il processo di aggiornamento a causa delle modifiche apportate al framework DDL.

Come aggiornare Milvus 2.6 con Milvus Operator

Milvus Operator è un operatore Kubernetes open-source che fornisce un modo scalabile e altamente disponibile per distribuire, gestire e aggiornare l'intero stack di servizi Milvus su un cluster Kubernetes di destinazione. Lo stack di servizi Milvus gestito dall'operatore comprende:

Componenti principali di Milvus
Dipendenze necessarie come etcd, Pulsar e MinIO.

Milvus Operator segue lo schema standard di Kubernetes Operator. Introduce una risorsa personalizzata (CR) Milvus che descrive lo stato desiderato di un cluster Milvus, come la versione, la topologia e la configurazione.

Un controllore monitora continuamente il cluster e riconcilia lo stato attuale con lo stato desiderato definito nella CR. Quando vengono apportate delle modifiche, come l'aggiornamento della versione di Milvus, l'operatore le applica automaticamente in modo controllato e ripetibile, consentendo aggiornamenti automatici e una gestione continua del ciclo di vita.

Esempio di risorsa personalizzata (CR) Milvus

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-milvus-mansion    
  namespace: dev       
spec:
  mode: cluster                  # cluster or standalone
  # Milvus Components
  components:
    image: milvusdb/milvus:v2.6.5
    imageUpdateMode: rollingUpgrade 
    proxy:                   
      replicas: 1          
    mixCoord:              
      replicas: 1           
    dataNode:               
      replicas: 1          
    queryNode:              
      replicas: 2           
      resources:
        requests:
          cpu: "2"
          memory: "8Gi"  
  # Dependencies, including etcd, storage and message stream
  dependencies:
    etcd:                   
      inCluster:
        values:
          replicaCount: 3    
    storage:                 
      type: MinIO
      inCluster:
        values:
          mode: distributed     
    msgStreamType: pulsar    
    pulsar:
      inCluster:
        values:
          bookkeeper:
            replicas: 3   
  # Milvus configs
  config:
    dataCoord:
      enableActiveStandby: true

Aggiornamento continuo da Milvus 2.5 a 2.6 con Milvus Operator

Milvus Operator offre un supporto integrato per l'aggiornamento continuo da Milvus 2.5 a 2.6 in modalità cluster, adattando il proprio comportamento alle modifiche architettoniche introdotte in 2.6.

1. Rilevamento dello scenario di aggiornamento

Durante un aggiornamento, Milvus Operator determina la versione Milvus di destinazione dalle specifiche del cluster. Questo avviene tramite:

ispezionando il tag dell'immagine definito in spec.components.image, oppure
Leggendo la versione esplicita specificata in spec.components.version

L'operatore confronta quindi la versione desiderata con quella attualmente in esecuzione, registrata in status.currentImage o status.currentVersion. Se la versione attuale è 2.5 e quella desiderata è 2.6, l'operatore identifica l'aggiornamento come uno scenario di aggiornamento 2.5 → 2.6.

2. Ordine di esecuzione dell'aggiornamento continuo

Quando viene rilevato un aggiornamento 2.5 → 2.6 e la modalità di aggiornamento è impostata su rolling upgrade (spec.components.imageUpdateMode: rollingUpgrade, che è l'impostazione predefinita), Milvus Operator esegue automaticamente l'aggiornamento secondo un ordine predefinito allineato con l'architettura di Milvus 2.6:

Avviare il Nodo di Streaming → Aggiornare MixCoord → Aggiornare il Nodo di Query → Aggiornare il Nodo Dati → Aggiornare il Proxy → Rimuovere il Nodo Indice

3. Consolidamento automatico dei coordinatori

Milvus 2.6 sostituisce più componenti del coordinatore con un unico MixCoord. Milvus Operator gestisce automaticamente questa transizione architettonica.

Quando spec.components.mixCoord è configurato, l'operatore richiama MixCoord e attende che sia pronto. Una volta che MixCoord è pienamente operativo, l'operatore chiude con grazia i componenti del coordinatore precedente: RootCoord, QueryCoord e DataCoord, completando la migrazione senza richiedere alcun intervento manuale.

Fasi di aggiornamento da Milvus 2.5 a 2.6

1. Aggiornare Milvus Operator alla versione più recente (in questa guida utilizziamo la versione 1.3.3, l'ultima rilasciata al momento della stesura della guida).

# Option 1: Using Helm
helm upgrade --install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.3/milvus-operator-1.3.3.tgz
 # Option 2: Using kubectl & raw manifests
 kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.3/deploy/manifests/deployment.yaml

2. Unire i componenti del coordinatore

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "mixCoord": {
        "replicas": 1
      }
    }
  }
}'

3. Assicurarsi che nel cluster sia in esecuzione Milvus 2.5.16 o versione successiva.

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.5.22"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

4. Aggiornare Milvus alla versione 2.6.

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.6.5"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

Come aggiornare Milvus 2.6 con Helm

Quando si distribuisce Milvus utilizzando Helm, tutte le risorse di Kubernetes Deployment vengono aggiornate in parallelo, senza un ordine di esecuzione garantito. Di conseguenza, Helm non fornisce un controllo rigoroso sulle sequenze di aggiornamento tra i componenti. Per gli ambienti di produzione, si raccomanda pertanto di utilizzare Milvus Operator.

È comunque possibile aggiornare Milvus da 2.5 a 2.6 utilizzando Helm, seguendo i passaggi indicati di seguito.

Requisiti di sistema

Versione di Helm: ≥ 3.14.0
Versione di Kubernetes: ≥ 1.20.0

1.Aggiornare il grafico Milvus Helm alla versione più recente. In questa guida utilizziamo la versione 5.0.7, la più recente al momento della stesura della guida.

helm repo add zilliztech https://zilliztech.github.io/milvus-helm
helm repo update

2.Se il cluster è distribuito con più componenti coordinatori, aggiornare prima Milvus alla versione 2.5.16 o successiva e abilitare MixCoord.

mixCoordinator
。
helm upgrade -i my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.5.22" \
  --set mixCoordinator.enabled=true \
  --set rootCoordinator.enabled=false \
  --set indexCoordinator.enabled=false \
  --set queryCoordinator.enabled=false \
  --set dataCoordinator.enabled=false \
  --set streaming.enabled=false \
  --set indexNode.enabled=true \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

3.Aggiornare Milvus alla versione 2.6

helm upgrade my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.6.5" \
  --set streaming.enabled=true \
  --set indexNode.enabled=false \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

FAQ sull'aggiornamento e le operazioni di Milvus 2.6

Q1: Milvus Helm vs Milvus Operator - quale devo usare?

Per gli ambienti di produzione, Milvus Operator è fortemente consigliato.

Per maggiori dettagli, consultare la guida ufficiale: https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm.

D2: Come scegliere una coda di messaggi (MQ)?

L'MQ consigliato dipende dalla modalità di distribuzione e dai requisiti operativi:

1. Modalità standalone: Per le implementazioni sensibili ai costi, si consiglia RocksMQ.

2. Modalità cluster

Pulsar supporta la multi-tenancy, permette a grandi cluster di condividere l'infrastruttura e offre una forte scalabilità orizzontale.
Kafka ha un ecosistema più maturo, con offerte SaaS gestite disponibili sulle principali piattaforme cloud.

3. Woodpecker (introdotto in Milvus 2.6): Woodpecker elimina la necessità di una coda di messaggi esterna, riducendo i costi e la complessità operativa.

Attualmente è supportata solo la modalità Woodpecker integrata, leggera e facile da usare.
Per le implementazioni standalone di Milvus 2.6, si raccomanda Woodpecker.
Per le implementazioni in cluster di produzione, si consiglia di utilizzare la modalità Woodpecker, di prossima uscita, non appena sarà disponibile.

D3: È possibile cambiare la coda dei messaggi durante un aggiornamento?

No. La commutazione della coda di messaggi durante un aggiornamento non è attualmente supportata. Le versioni future introdurranno API di gestione per supportare la commutazione tra Pulsar, Kafka, Woodpecker e RocksMQ.

D4: Le configurazioni di limitazione della velocità devono essere aggiornate per Milvus 2.6?

Le configurazioni di limitazione della velocità esistenti rimangono valide e si applicano anche al nuovo Streaming Node. Non sono necessarie modifiche.

D5: Dopo la fusione dei coordinatori, cambiano i ruoli di monitoraggio o le configurazioni?

I ruoli di monitoraggio rimangono invariati (RootCoord, QueryCoord, DataCoord).
Le opzioni di configurazione esistenti continuano a funzionare come prima.
È stata introdotta una nuova opzione di configurazione, mixCoord.enableActiveStandby, che tornerà a rootcoord.enableActiveStandby se non viene impostata esplicitamente.

D6: Quali sono le impostazioni delle risorse consigliate per StreamingNode?

Per un'ingestione leggera in tempo reale o per carichi di lavoro occasionali di scrittura e interrogazione, è sufficiente una configurazione più piccola, come 2 core di CPU e 8 GB di memoria.
Per l'ingestione pesante in tempo reale o per carichi di lavoro continui di scrittura e interrogazione, si consiglia di allocare risorse paragonabili a quelle del Query Node.

D7: Come si aggiorna un'implementazione standalone che utilizza Docker Compose?

Per le distribuzioni standalone basate su Docker Compose, è sufficiente aggiornare il tag dell'immagine Milvus in docker-compose.yaml.

Per i dettagli, consultare la guida ufficiale: https://milvus.io/docs/upgrade_milvus_standalone-docker.md.

Conclusione

Milvus 2.6 segna un importante miglioramento sia nell'architettura che nelle operazioni. Separando l'elaborazione in streaming da quella in batch con l'introduzione di StreamingNode, consolidando i coordinatori in MixCoord e semplificando i ruoli dei lavoratori, Milvus 2.6 fornisce una base più stabile, scalabile e facile da usare per carichi di lavoro vettoriali su larga scala.

Queste modifiche architettoniche rendono gli aggiornamenti, specialmente quelli da Milvus 2.5, più sensibili all'ordine. Il successo dell'aggiornamento dipende dal rispetto delle dipendenze dei componenti e dei vincoli di disponibilità temporanea. Per gli ambienti di produzione, Milvus Operator è l'approccio consigliato, in quanto automatizza la sequenza degli aggiornamenti e riduce il rischio operativo, mentre gli aggiornamenti basati su Helm sono più adatti ai casi d'uso non di produzione.

Con funzionalità di ricerca migliorate, tipi di dati più ricchi, archiviazione a livelli e opzioni di coda di messaggi migliorate, Milvus 2.6 è ben posizionato per supportare le moderne applicazioni di intelligenza artificiale che richiedono ingestione in tempo reale, elevate prestazioni di interrogazione e operazioni efficienti su scala.

Avete domande o volete un approfondimento su una qualsiasi caratteristica dell'ultima versione di Milvus? Unitevi al nostro canale Discord o inviate problemi su GitHub. È anche possibile prenotare una sessione individuale di 20 minuti per ottenere approfondimenti, indicazioni e risposte alle vostre domande tramite Milvus Office Hours.