Home
Blog
Como atualizar com segurança do Milvus 2.5.x para o Milvus 2.6.x

Como atualizar com segurança do Milvus 2.5.x para o Milvus 2.6.x

Tutorials

December 25, 2025

Yiqing Lu

O Milvus 2.6 já está no ar há algum tempo e está a provar ser um sólido passo em frente para o projeto. O lançamento traz uma arquitetura refinada, um melhor desempenho em tempo real, um menor consumo de recursos e um comportamento de escalonamento mais inteligente em ambientes de produção. Muitas dessas melhorias foram moldadas diretamente pelo feedback dos usuários, e os primeiros usuários da versão 2.6.x já relataram uma busca visivelmente mais rápida e um desempenho mais previsível do sistema sob cargas de trabalho pesadas ou dinâmicas.

Para as equipas que utilizam o Milvus 2.5.x e estão a avaliar uma mudança para a versão 2.6.x, este guia é o seu ponto de partida. Ele detalha as diferenças de arquitetura, destaca os principais recursos introduzidos no Milvus 2.6 e fornece um caminho de atualização prático e passo a passo, projetado para minimizar a interrupção operacional.

Se as suas cargas de trabalho envolvem pipelines em tempo real, pesquisa multimodal ou híbrida, ou operações vectoriais em grande escala, este blogue irá ajudá-lo a avaliar se a versão 2.6 se alinha com as suas necessidades - e, se decidir avançar, atualizar com confiança, mantendo a integridade dos dados e a disponibilidade do serviço.

Mudanças na arquitetura do Milvus 2.5 para o Milvus 2.6

Antes de mergulhar no fluxo de trabalho de atualização em si, vamos primeiro entender como a arquitetura do Milvus muda no Milvus 2.6.

Arquitetura do Milvus 2.5

Milvus 2.5 Architecture Arquitetura do Milvus 2.5

No Milvus 2.5, os fluxos de trabalho de streaming e batch estavam interligados em vários nós de trabalho:

O QueryNode tratava tanto as consultas históricas como as incrementais (streaming).
O DataNode tratava tanto da descarga em tempo de ingestão como da compactação em segundo plano dos dados históricos.

Essa mistura de lógica em lote e em tempo real dificultava o dimensionamento independente das cargas de trabalho em lote. Também significava que o estado do streaming estava disperso em vários componentes, introduzindo atrasos de sincronização, complicando a recuperação de falhas e aumentando a complexidade operacional.

Arquitetura do Milvus 2.6

Milvus 2.6 Architecture Arquitetura do Milvus 2.6

O Milvus 2.6 introduz um StreamingNode dedicado que lida com todas as responsabilidades de dados em tempo real: consumir a fila de mensagens, escrever segmentos incrementais, servir consultas incrementais e gerenciar a recuperação baseada em WAL. Com o streaming isolado, os demais componentes assumem papéis mais limpos e mais focados:

O QueryNode agora lida apenas com consultas em lote em segmentos históricos.
O DataNode agora lida apenas com tarefas de dados históricos, como compactação e criação de índices.

O StreamingNode absorve todas as tarefas relacionadas com o streaming que estavam divididas entre o DataNode, o QueryNode e até mesmo o Proxy no Milvus 2.5, trazendo clareza e reduzindo a partilha de estado entre funções.

Milvus 2.5.x vs Milvus 2.6.x: Comparação componente a componente

	Milvus 2.5.x	Milvus 2.6.x	O que mudou
Serviços do coordenador	RootCoord / QueryCoord / DataCoord (ou MixCoord)	MixCoord	A gestão de metadados e o agendamento de tarefas são consolidados num único MixCoord, simplificando a lógica de coordenação e reduzindo a complexidade distribuída.
Camada de acesso	Proxy	Proxy	Os pedidos de escrita são encaminhados apenas através do nó de streaming para ingestão de dados.
Nós de trabalho	-	Nó de fluxo contínuo	Nó de processamento de streaming dedicado responsável por toda a lógica incremental (segmentos crescentes), incluindo:- Ingestão de dados incrementais- Consulta de dados incrementais- Persistência de dados incrementais no armazenamento de objectos- Escritas baseadas em stream- Recuperação de falhas baseada em WAL
	Nó de consulta	Nó de consulta	Nó de processamento em lote que trata apenas de consultas sobre dados históricos.
	Nó de dados	Nó de dados	Nó de processamento em lote responsável apenas por dados históricos, incluindo compactação e construção de índices.
	Nó de índice	-	O nó de índice é fundido com o nó de dados, simplificando as definições de funções e a topologia de implementação.

Em suma, o Milvus 2.6 traça uma linha clara entre as cargas de trabalho em fluxo e em lote, eliminando o emaranhado de componentes cruzados visto na versão 2.5 e criando uma arquitetura mais escalável e de fácil manutenção.

Destaques dos recursos do Milvus 2.6

Antes de entrar no fluxo de trabalho de atualização, aqui está uma rápida olhada no que o Milvus 2.6 traz para a mesa. Esta versão concentra-se em reduzir o custo da infraestrutura, melhorar o desempenho da pesquisa e facilitar o dimensionamento de cargas de trabalho de IA grandes e dinâmicas.

Melhorias de custo e eficiência

QuantizaçãoRaBitQ para índices primários - Um novo método de quantização de 1 bit que comprime índices vetoriais para 1/32 de seu tamanho original. Combinado com o reranking SQ8, ele reduz o uso de memória para ~28%, aumenta o QPS em 4× e mantém ~95% de recuperação, reduzindo significativamente os custos de hardware.
Pesquisa de texto completootimizada pelo BM25 - Pontuação nativa do BM25 alimentada por vetores de peso de termos esparsos. A pesquisa de palavras-chave é executada de 3 a 4 vezes mais rápida (até 7 vezes em alguns conjuntos de dados) em comparação com o Elasticsearch, mantendo o tamanho do índice em cerca de um terço dos dados de texto originais.
Indexação de caminhos JSON com fragmentação de JSON - A filtragem estruturada em JSON aninhado agora é dramaticamente mais rápida e muito mais previsível. Caminhos JSON pré-indexados reduzem a latência de filtragem de 140 ms → 1,5 ms (P99: 480 ms → 10 ms), tornando a pesquisa vetorial híbrida + filtragem de metadados significativamente mais ágil.
Suporte de tipo de dados expandido - Adiciona tipos de vetor Int8, campos de geometria (POINT / LINESTRING / POLYGON) e matriz de estruturas. Estas extensões suportam cargas de trabalho geoespaciais, modelação de metadados mais rica e esquemas mais limpos.
Upsert para actualizações parciais - Agora é possível inserir ou atualizar entidades utilizando uma única chamada de chave primária. As actualizações parciais modificam apenas os campos fornecidos, reduzindo a amplificação da escrita e simplificando os pipelines que actualizam frequentemente os metadados ou os embeddings.

Melhorias na pesquisa e recuperação

Processamento de texto e suporte multilíngue aprimorados: Os novos tokenizadores Lindera e ICU melhoram o tratamento de texto em japonês, coreano e em vários idiomas. O Jieba agora suporta dicionários personalizados. O site run_analyzer ajuda a depurar o comportamento da tokenização e os analisadores multilíngües garantem uma pesquisa consistente em vários idiomas.
Correspondência de texto de alta precisão: A correspondência de frases impõe consultas de frases ordenadas com inclinação configurável. O novo índice NGRAM acelera as consultas de substring e LIKE em campos VARCHAR e caminhos JSON, permitindo a correspondência rápida de texto parcial e difusa.
Reranking com reconhecimento de tempo e de metadados: Os classificadores de decaimento (exponencial, linear, gaussiano) ajustam as pontuações usando carimbos de data/hora; os classificadores de impulso aplicam regras orientadas por metadados para promover ou rebaixar resultados. Ambos ajudam a ajustar o comportamento de recuperação sem alterar os dados subjacentes.
Integração simplificada de modelos e vetorização automática: As integrações incorporadas com OpenAI, Hugging Face e outros fornecedores de incorporação permitem que o Milvus vetorize automaticamente o texto durante as operações de inserção e consulta. Não há mais pipelines de incorporação manual para casos de uso comuns.
Atualizações de esquema online para campos escalares: Adicione novos campos escalares a coleções existentes sem tempo de inatividade ou recargas, simplificando a evolução do esquema à medida que os requisitos de metadados aumentam.
Deteção de quase duplicatas com MinHash: O MinHash + LSH permite a deteção eficiente de quase duplicados em grandes conjuntos de dados sem comparações exactas dispendiosas.

Atualizações de arquitetura e escalabilidade

Armazenamento em camadas para gerenciamento de dados quentes e frios: Separa dados quentes e frios em SSD e armazenamento de objectos; suporta carregamento parcial e preguiçoso; elimina a necessidade de carregar totalmente as colecções localmente; reduz a utilização de recursos em até 50% e acelera os tempos de carregamento de grandes conjuntos de dados.
Serviço de streaming em tempo real: Adiciona nós de streaming dedicados integrados com Kafka/Pulsar para ingestão contínua; permite indexação imediata e disponibilidade de consulta; melhora o rendimento de gravação e acelera a recuperação de falhas para cargas de trabalho em tempo real e em rápida mudança.
Escalabilidade e estabilidade aprimoradas: O Milvus suporta agora mais de 100.000 colecções para grandes ambientes multi-tenant. As actualizações da infraestrutura - Woodpecker (WAL de disco zero), Storage v2 (IOPS/memória reduzida) e o Coordinator Merge - melhoram a estabilidade do cluster e permitem um escalonamento previsível sob cargas de trabalho pesadas.

Para obter uma lista completa dos recursos do Milvus 2.6, consulte as notas de versão do Milvus.

Como atualizar do Milvus 2.5.x para o Milvus 2.6.x

Para manter o sistema o mais disponível possível durante a atualização, os clusters do Milvus 2.5 devem ser atualizados para o Milvus 2.6 na seguinte ordem.

1. Inicie o Streaming Node primeiro

Inicie o Streaming Node com antecedência. O novo Delegator (o componente no Query Node responsável pelo tratamento de dados de streaming) deve ser movido para o Milvus 2.6 Streaming Node.

2. Atualizar o MixCoord

Actualize os componentes do coordenador para o MixCoord. Durante esta etapa, o MixCoord precisa de detetar as versões dos Worker Nodes para lidar com a compatibilidade entre versões no sistema distribuído.

3. Atualizar o Query Node

As actualizações do Query Node são normalmente mais demoradas. Durante esta fase, os nós de dados e os nós de índice do Milvus 2.5 podem continuar a lidar com operações como Flush e construção de índices, ajudando a reduzir a pressão do lado da consulta enquanto os nós de consulta estão a ser actualizados.

4. Atualizar o nó de dados

Uma vez que os nós de dados do Milvus 2.5 são colocados offline, as operações de Flush tornam-se indisponíveis, e os dados em Growing Segments podem continuar a acumular-se até que todos os nós sejam totalmente actualizados para o Milvus 2.6.

5. Atualizar o Proxy

Depois de atualizar um Proxy para Milvus 2.6, as operações de escrita nesse Proxy permanecerão indisponíveis até que todos os componentes do cluster sejam atualizados para 2.6.

6. Remover o nó de índice

Depois que todos os outros componentes forem atualizados, o nó de índice autônomo poderá ser removido com segurança.

Observações:

Desde a conclusão da atualização do DataNode até à conclusão da atualização do Proxy, as operações de Flush não estão disponíveis.
A partir do momento em que o primeiro Proxy é atualizado até que todos os nós Proxy sejam actualizados, algumas operações de escrita ficam indisponíveis.
Ao atualizar diretamente do Milvus 2.5.x para o 2.6.6, as operações DDL (Data Definition Language) não estão disponíveis durante o processo de atualização devido a alterações na estrutura DDL.

Como atualizar para o Milvus 2.6 com o Milvus Operator

O Milvus Operator é um operador Kubernetes de código aberto que fornece uma maneira escalável e altamente disponível de implantar, gerenciar e atualizar toda a pilha de serviços Milvus em um cluster Kubernetes de destino. A pilha de serviços Milvus gerida pelo operador inclui:

Componentes principais do Milvus
Dependências necessárias, como etcd, Pulsar e MinIO

O Milvus Operator segue o padrão padrão do Kubernetes Operator. Ele introduz um recurso personalizado (CR) do Milvus que descreve o estado desejado de um cluster do Milvus, como sua versão, topologia e configuração.

Um controlador monitoriza continuamente o cluster e reconcilia o estado atual com o estado desejado definido no CR. Quando são feitas alterações - como a atualização da versão do Milvus - o operador aplica-as automaticamente de uma forma controlada e repetível, permitindo actualizações automatizadas e uma gestão contínua do ciclo de vida.

Exemplo de recurso personalizado (CR) do 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

Atualizações contínuas do Milvus 2.5 para 2.6 com o Milvus Operator

O Milvus Operator fornece suporte integrado para atualizações contínuas do Milvus 2.5 para o 2.6 no modo de cluster, adaptando seu comportamento para levar em conta as mudanças arquitetônicas introduzidas no 2.6.

1. Deteção do Cenário de Atualização

Durante uma atualização, o Milvus Operator determina a versão alvo do Milvus a partir da especificação do cluster. Isso é feito por

Inspecionando a tag de imagem definida em spec.components.image, ou
Lendo a versão explícita especificada em spec.components.version

O operador compara então esta versão pretendida com a versão atualmente em curso, que é registada em status.currentImage ou status.currentVersion. Se a versão atual for 2.5 e a versão pretendida for 2.6, o operador identifica a atualização como um cenário de atualização 2.5 → 2.6.

2. Ordem de execução da atualização contínua

Quando uma atualização 2.5 → 2.6 é detectada e o modo de atualização está definido para atualização contínua (spec.components.imageUpdateMode: rollingUpgrade, que é o padrão), o Milvus Operator executa automaticamente a atualização numa ordem predefinida alinhada com a arquitetura do Milvus 2.6:

Iniciar o Nó de Fluxo → Atualizar o MixCoord → Atualizar o Nó de Consulta → Atualizar o Nó de Dados → Atualizar o Proxy → Remover o Nó de Índice

3. Consolidação automática de coordenadores

O Milvus 2.6 substitui vários componentes do coordenador por um único MixCoord. O Milvus Operator trata automaticamente desta transição arquitetural.

Quando spec.components.mixCoord é configurado, o operador abre o MixCoord e aguarda até que ele esteja pronto. Assim que o MixCoord estiver totalmente operacional, o operador desliga os componentes antigos do coordenador - RootCoord, QueryCoord e DataCoord - concluindo a migração sem necessidade de qualquer intervenção manual.

Etapas de atualização do Milvus 2.5 para o 2.6

1. atualizar o Milvus Operator para a versão mais recente (neste guia, usamos a versão 1.3.3, que era a versão mais recente no momento da redação).

# 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. fundir os componentes do coordenador

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

3. garantir que o cluster esteja executando o Milvus 2.5.16 ou posterior

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. atualizar o Milvus para a versão 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

Como atualizar para o Milvus 2.6 com o Helm

Ao implantar o Milvus usando o Helm, todos os recursos do Kubernetes Deployment são atualizados em paralelo, sem uma ordem de execução garantida. Como resultado, o Helm não fornece um controlo rigoroso sobre as sequências de atualização contínua entre componentes. Para ambientes de produção, o uso do Milvus Operator é, portanto, altamente recomendado.

O Milvus ainda pode ser atualizado da versão 2.5 para a 2.6 usando o Helm, seguindo as etapas abaixo.

Requisitos do sistema

Versão do Helm: ≥ 3.14.0
Versão do Kubernetes: ≥ 1.20.0

1.Atualize o gráfico do Milvus Helm para a versão mais recente. Neste guia, usamos a versão 5.0.7 do gráfico, que era a mais recente no momento da redação.

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

2.se o cluster for implantado com vários componentes de coordenação, primeiro atualize o Milvus para a versão 2.5.16 ou posterior e habilite o 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 - Atualize o Milvus para a versão 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 sobre atualização e operações do Milvus 2.6

Q1: Milvus Helm vs. Milvus Operator - qual deles devo usar?

Para ambientes de produção, recomenda-se vivamente a utilização do Milvus Operator.

Consulte o guia oficial para obter detalhes: https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm

Q2: Como devo escolher um Message Queue (MQ)?

O MQ recomendado depende do modo de implementação e dos requisitos operacionais:

1. Modo autónomo: Para implantações sensíveis ao custo, o RocksMQ é recomendado.

2. Modo de cluster

O Pulsar oferece suporte a multilocação, permite que grandes clusters compartilhem a infraestrutura e oferece forte escalabilidade horizontal.
O Kafka tem um ecossistema mais maduro, com ofertas de SaaS gerenciadas disponíveis na maioria das principais plataformas de nuvem.

3. Woodpecker (introduzido no Milvus 2.6): O Woodpecker elimina a necessidade de uma fila de mensagens externa, reduzindo o custo e a complexidade operacional.

Atualmente, só é suportado o modo Woodpecker incorporado, que é leve e fácil de operar.
Para implantações autônomas do Milvus 2.6, o Woodpecker é recomendado.
Para implantações de cluster de produção, recomenda-se usar o próximo modo de cluster Woodpecker assim que ele estiver disponível.

P3: A fila de mensagens pode ser trocada durante uma atualização?

Não. A troca da fila de mensagens durante uma atualização não é atualmente suportada. Versões futuras introduzirão APIs de gerenciamento para oferecer suporte à alternância entre Pulsar, Kafka, Woodpecker e RocksMQ.

Q4: As configurações de limitação de taxa precisam ser atualizadas para o Milvus 2.6?

Não. As configurações de limitação de taxa existentes permanecem efetivas e também se aplicam ao novo nó de streaming. Não são necessárias alterações.

Q5: Após a fusão do coordenador, as funções ou configurações de monitoramento são alteradas?

As funções de monitoramento permanecem inalteradas (RootCoord, QueryCoord, DataCoord).
As opções de configuração existentes continuam a funcionar como antes.
Uma nova opção de configuração, mixCoord.enableActiveStandby, é introduzida e voltará para rootcoord.enableActiveStandby se não for explicitamente definida.

Q6: Quais são as configurações de recursos recomendadas para o StreamingNode?

Para ingestão leve em tempo real ou cargas de trabalho ocasionais de gravação e consulta, uma configuração menor, como 2 núcleos de CPU e 8 GB de memória, é suficiente.
Para ingestão pesada em tempo real ou cargas de trabalho contínuas de gravação e consulta, recomenda-se alocar recursos comparáveis aos do Query Node.

Q7: Como faço para atualizar uma implantação autônoma usando o Docker Compose?

Para implantações autônomas baseadas no Docker Compose, basta atualizar a tag de imagem do Milvus em docker-compose.yaml.

Consulte o guia oficial para obter detalhes: https://milvus.io/docs/upgrade_milvus_standalone-docker.md

Conclusão

O Milvus 2.6 marca uma grande melhoria tanto na arquitetura quanto nas operações. Ao separar o streaming e o processamento em lote com a introdução do StreamingNode, consolidando os coordenadores no MixCoord e simplificando as funções do trabalhador, o Milvus 2.6 fornece uma base mais estável, escalável e fácil de operar para cargas de trabalho vetoriais em grande escala.

Essas mudanças na arquitetura tornam as atualizações - especialmente do Milvus 2.5 - mais sensíveis à ordem. Uma atualização bem-sucedida depende do respeito às dependências dos componentes e às restrições de disponibilidade temporária. Para ambientes de produção, o Milvus Operator é a abordagem recomendada, uma vez que automatiza a sequência de actualizações e reduz o risco operacional, enquanto as actualizações baseadas no Helm são mais adequadas para casos de utilização não produtivos.

Com recursos de pesquisa aprimorados, tipos de dados mais ricos, armazenamento em camadas e opções aprimoradas de fila de mensagens, o Milvus 2.6 está bem posicionado para oferecer suporte a aplicativos modernos de IA que exigem ingestão em tempo real, alto desempenho de consulta e operações eficientes em escala.

Tem dúvidas ou quer um mergulho profundo em qualquer recurso do Milvus mais recente? Junte-se ao nosso canal Discord ou arquive problemas no GitHub. Também pode reservar uma sessão individual de 20 minutos para obter informações, orientação e respostas às suas perguntas através do Milvus Office Hours.