Home
Blog
Comment passer en toute sécurité de Milvus 2.5.x à Milvus 2.6.x ?

Comment passer en toute sécurité de Milvus 2.5.x à Milvus 2.6.x ?

Tutorials

December 25, 2025

Yiqing Lu

Milvus 2.6 est en ligne depuis un certain temps et s'avère être une avancée solide pour le projet. Cette version apporte une architecture affinée, des performances en temps réel plus élevées, une consommation de ressources plus faible et un comportement de mise à l'échelle plus intelligent dans les environnements de production. Bon nombre de ces améliorations ont été façonnées directement par les commentaires des utilisateurs, et les premiers utilisateurs de la version 2.6.x ont déjà fait état d'une recherche nettement plus rapide et de performances système plus prévisibles dans le cadre de charges de travail lourdes ou dynamiques.

Pour les équipes qui utilisent Milvus 2.5.x et qui envisagent de passer à 2.6.x, ce guide est le point de départ. Il décompose les différences architecturales, met en évidence les capacités clés introduites dans Milvus 2.6 et fournit un chemin de mise à niveau pratique, étape par étape, conçu pour minimiser les perturbations opérationnelles.

Si vos charges de travail impliquent des pipelines en temps réel, des recherches multimodales ou hybrides, ou des opérations vectorielles à grande échelle, ce blog vous aidera à évaluer si 2.6 correspond à vos besoins et, si vous décidez de poursuivre, à effectuer la mise à niveau en toute confiance tout en maintenant l'intégrité des données et la disponibilité des services.

Modifications de l'architecture de Milvus 2.5 à Milvus 2.6

Avant de plonger dans le workflow de mise à niveau proprement dit, commençons par comprendre comment l'architecture Milvus change dans Milvus 2.6.

Architecture de Milvus 2.5

Milvus 2.5 Architecture Architecture de Milvus 2.5

Dans Milvus 2.5, les flux de travail en continu et par lots étaient imbriqués sur plusieurs nœuds de travail :

QueryNode gé rait à la fois les requêtes historiques et les requêtes incrémentielles (en continu).
Lenœud de données (DataNode) gérait à la fois la vidange au moment de l'ingestion et le compactage en arrière-plan des données historiques.

Ce mélange de logique de traitement par lots et de logique en temps réel a rendu difficile la mise à l'échelle indépendante des charges de travail par lots. Cela signifiait également que l'état de streaming était dispersé entre plusieurs composants, ce qui introduisait des retards de synchronisation, compliquait la reprise sur panne et augmentait la complexité opérationnelle.

Architecture de Milvus 2.6

Milvus 2.6 Architecture Architecture de Milvus 2.6

Milvus 2.6 introduit un StreamingNode dédié qui prend en charge toutes les responsabilités liées aux données en temps réel : consommation de la file d'attente de messages, écriture de segments incrémentiels, service de requêtes incrémentielles et gestion de la reprise basée sur WAL. Le streaming étant isolé, les autres composants ont des rôles plus clairs et plus ciblés :

QueryNode ne traite plus que les requêtes par lots sur les segments historiques.
LeDataNode ne gère plus que les tâches liées aux données historiques, telles que le compactage et la création d'index.

Le StreamingNode absorbe toutes les tâches liées à la diffusion en continu qui étaient réparties entre le DataNode, le QueryNode et même le Proxy dans Milvus 2.5, ce qui apporte de la clarté et réduit le partage d'états entre les rôles.

Milvus 2.5.x vs Milvus 2.6.x : Comparaison composant par composant

	Milvus 2.5.x	Milvus 2.6.x	Ce qui a changé
Services de coordination	RootCoord / QueryCoord / DataCoord (ou MixCoord)	MixCoord	La gestion des métadonnées et la planification des tâches sont regroupées dans un seul MixCoord, ce qui simplifie la logique de coordination et réduit la complexité distribuée.
Couche d'accès	Proxy	Proxy	Les demandes d'écriture sont acheminées uniquement par le nœud de streaming pour l'ingestion des données.
Nœuds de travail	-	Nœud de streaming	Nœud de traitement en continu dédié, responsable de toute la logique incrémentale (segments croissants), y compris:- l'ingestion de données incrémentales- l'interrogation de données incrémentales- la persistance de données incrémentales dans le stockage d'objets- les écritures basées sur le flux- la reprise sur défaillance basée sur WAL.
	Nœud de requête	Nœud de requête	Nœud de traitement par lots qui traite les requêtes portant uniquement sur des données historiques.
	Nœud de données	Nœud de données	Nœud de traitement par lots responsable des données historiques uniquement, y compris le compactage et la construction de l'index.
	Nœud d'index	-	Le nœud d'index est fusionné avec le nœud de données, ce qui simplifie la définition des rôles et la topologie du déploiement.

En bref, Milvus 2.6 trace une ligne claire entre les charges de travail en continu et par lots, éliminant l'enchevêtrement des composants vu dans la version 2.5 et créant une architecture plus évolutive et plus facile à maintenir.

Caractéristiques principales de Milvus 2.6

Avant d'aborder le processus de mise à niveau, voici un bref aperçu de ce que Milvus 2.6 apporte. Cette version se concentre sur la réduction des coûts d'infrastructure, l'amélioration des performances de recherche et la mise à l'échelle plus aisée des charges de travail d'IA dynamiques de grande taille.

Améliorations des coûts et de l'efficacité

QuantificationRaBitQ pour les index primaires - Une nouvelle méthode de quantification sur 1 bit qui compresse les index vectoriels à 1/32 de leur taille d'origine. Combinée avec le reranking SQ8, elle réduit l'utilisation de la mémoire à ~28%, augmente le QPS de 4×, et maintient un rappel de ~95%, réduisant de manière significative les coûts matériels.
Recherche plein texteoptimisée par BM25 - Notation native BM25 alimentée par des vecteurs de poids de termes épars. La recherche par mot-clé est 3-4× plus rapide (jusqu'à 7× sur certains ensembles de données) par rapport à Elasticsearch, tout en maintenant la taille de l'index à environ un tiers des données textuelles d'origine.
Indexation des chemins JSON avec déchiquetage JSON - Le filtrage structuré sur JSON imbriqué est désormais beaucoup plus rapide et prévisible. Les chemins JSON pré-indexés réduisent la latence du filtre de 140 ms → 1,5 ms (P99 : 480 ms → 10 ms), ce qui rend la recherche vectorielle hybride + le filtrage des métadonnées nettement plus réactifs.
Support étendu des types de données - Ajout des types de vecteurs Int8, des champs géométriques (POINT / LINESTRING / POLYGON), et des tableaux de structures (Array-of-Structs). Ces extensions prennent en charge les charges de travail géospatiales, une modélisation plus riche des métadonnées et des schémas plus propres.
Upsert pour les mises à jour partielles - Vous pouvez désormais insérer ou mettre à jour des entités à l'aide d'un seul appel de clé primaire. Les mises à jour partielles ne modifient que les champs fournis, ce qui réduit l'amplification de l'écriture et simplifie les pipelines qui actualisent fréquemment les métadonnées ou les embeddings.

Améliorations de la recherche et de l'extraction

Amélioration du traitement du texte et de la prise en charge multilingue : Les nouveaux tokenizers Lindera et ICU améliorent le traitement des textes japonais, coréens et multilingues. Jieba prend désormais en charge les dictionnaires personnalisés. run_analyzer permet de déboguer le comportement de la symbolisation et les analyseurs multilingues garantissent une recherche cohérente entre les langues.
Correspondance de texte de haute précision : Phrase Match applique des requêtes de phrases ordonnées avec une marge configurable. Le nouvel index NGRAM accélère les requêtes de sous-chaînes et LIKE sur les champs VARCHAR et les chemins d'accès JSON, ce qui permet une correspondance partielle et floue rapide.
Reranking tenant compte du temps et des métadonnées : Les Rankers Decay (exponentiel, linéaire, gaussien) ajustent les scores à l'aide des horodatages ; les Rankers Boost appliquent des règles basées sur les métadonnées pour promouvoir ou rétrograder les résultats. Ces deux types d'outils permettent d'affiner le comportement de recherche sans modifier les données sous-jacentes.
Intégration simplifiée des modèles et vectorisation automatique : Les intégrations intégrées avec OpenAI, Hugging Face et d'autres fournisseurs d'intégration permettent à Milvus de vectoriser automatiquement le texte pendant les opérations d'insertion et d'interrogation. Finis les pipelines d'intégration manuels pour les cas d'utilisation courants.
Mises à jour du schéma en ligne pour les champs scalaires : Ajoutez de nouveaux champs scalaires aux collections existantes sans temps d'arrêt ni rechargement, ce qui simplifie l'évolution du schéma au fur et à mesure que les besoins en métadonnées augmentent.
Détection des quasi-doublons avec MinHash : MinHash + LSH permet une détection efficace des quasi-doublons dans les grands ensembles de données sans comparaisons exactes coûteuses.

Mises à jour de l'architecture et de l'évolutivité

Stockage hiérarchisé pour la gestion des données chaudes et froides : Séparation des données chaudes et froides entre SSD et stockage d'objets ; prise en charge du chargement paresseux et partiel ; élimination du besoin de charger entièrement les collections localement ; réduction de l'utilisation des ressources jusqu'à 50 % et accélération des temps de chargement pour les grands ensembles de données.
Service de streaming en temps réel : Ajoute des nœuds de streaming dédiés intégrés à Kafka/Pulsar pour une ingestion continue ; permet une indexation immédiate et une disponibilité des requêtes ; améliore le débit d'écriture et accélère la récupération des pannes pour les charges de travail en temps réel et en évolution rapide.
Évolutivité et stabilité améliorées : Milvus prend désormais en charge plus de 100 000 collections pour les grands environnements multi-locataires. Les mises à niveau de l'infrastructure - Woodpecker (WAL sans disque), Storage v2 (IOPS/mémoire réduits) et Coordinator Merge - améliorent la stabilité des clusters et permettent une évolution prévisible en cas de charges de travail importantes.

Pour une liste complète des fonctionnalités de Milvus 2.6, consultez les notes de mise à jour de Milvus.

Comment passer de Milvus 2.5.x à Milvus 2.6.x ?

Pour que le système reste aussi disponible que possible pendant la mise à niveau, les clusters Milvus 2.5 doivent être mis à niveau vers Milvus 2.6 dans l'ordre suivant.

1. Démarrer le nœud de streaming en premier

Démarrer le nœud de streaming à l'avance. Le nouveau Delegator (le composant du nœud de requête responsable du traitement des données en continu) doit être déplacé vers le nœud de streaming Milvus 2.6.

2. Mise à niveau de MixCoord

Mettre à niveau les composants du coordinateur vers MixCoord. Au cours de cette étape, MixCoord doit détecter les versions des nœuds de travailleur afin de gérer la compatibilité entre les versions au sein du système distribué.

3. Mise à niveau du nœud de requête

Les mises à niveau du nœud de requête prennent généralement plus de temps. Pendant cette phase, les nœuds de données et les nœuds d'index de Milvus 2.5 peuvent continuer à traiter des opérations telles que le flush et la construction d'index, ce qui permet de réduire la pression côté requête pendant la mise à niveau des nœuds de requête.

4. Mise à niveau du nœud de données

Une fois que les nœuds de données Milvus 2.5 sont mis hors ligne, les opérations de rinçage deviennent indisponibles et les données dans les segments en croissance peuvent continuer à s'accumuler jusqu'à ce que tous les nœuds soient entièrement mis à niveau vers Milvus 2.6.

5. Mise à niveau du serveur mandataire

Après la mise à niveau d'un serveur mandataire vers Milvus 2.6, les opérations d'écriture sur ce serveur mandataire resteront indisponibles jusqu'à ce que tous les composants du cluster soient mis à niveau vers 2.6.

6. Suppression du nœud d'index

Une fois que tous les autres composants ont été mis à niveau, le nœud d'index autonome peut être supprimé en toute sécurité.

Notes :

Entre la fin de la mise à niveau du DataNode et la fin de la mise à niveau du Proxy, les opérations de Flush ne sont pas disponibles.
Entre le moment où le premier serveur mandataire est mis à niveau et celui où tous les nœuds mandataires sont mis à niveau, certaines opérations d'écriture sont indisponibles.
Lors de la mise à niveau directe de Milvus 2.5.x vers 2.6.6, les opérations DDL (Data Definition Language) sont indisponibles pendant le processus de mise à niveau en raison des modifications apportées au cadre DDL.

Comment passer à Milvus 2.6 avec Milvus Operator ?

Milvus Oper ator est un opérateur Kubernetes open-source qui offre un moyen évolutif et hautement disponible de déployer, gérer et mettre à niveau l'ensemble de la pile de services Milvus sur un cluster Kubernetes cible. La pile de services Milvus gérée par l'opérateur comprend :

Les composants principaux de Milvus
Les dépendances requises telles que etcd, Pulsar et MinIO.

Milvus Operator suit le modèle standard d'opérateur Kubernetes. Il introduit une ressource personnalisée Milvus (CR) qui décrit l'état souhaité d'un cluster Milvus, tel que sa version, sa topologie et sa configuration.

Un contrôleur surveille en permanence le cluster et rapproche l'état réel de l'état souhaité défini dans la CR. Lorsque des modifications sont apportées (par exemple, la mise à niveau de la version de Milvus), l'opérateur les applique automatiquement d'une manière contrôlée et reproductible, ce qui permet des mises à niveau automatisées et une gestion continue du cycle de vie.

Exemple de ressource personnalisée (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

Mises à niveau progressives de Milvus 2.5 à 2.6 avec Milvus Operator

Milvus Operator fournit une prise en charge intégrée des mises à niveau roulantes de Milvus 2.5 à 2.6 en mode cluster, en adaptant son comportement pour tenir compte des modifications architecturales introduites dans la version 2.6.

1. Détection du scénario de mise à niveau

Lors d'une mise à niveau, Milvus Operator détermine la version cible de Milvus à partir de la spécification du cluster. Pour ce faire, il peut

inspectant la balise d'image définie à l'adresse spec.components.image, ou
en lisant la version explicite spécifiée dans spec.components.version

L'opérateur compare ensuite cette version souhaitée avec la version en cours d'exécution, qui est enregistrée sur status.currentImage ou status.currentVersion. Si la version en cours est 2.5 et la version souhaitée 2.6, l'opérateur identifie la mise à niveau comme un scénario de mise à niveau 2.5 → 2.6.

2. Ordre d'exécution de la mise à niveau progressive

Lorsqu'une mise à niveau 2.5 → 2.6 est détectée et que le mode de mise à niveau est défini sur la mise à niveau continue (spec.components.imageUpdateMode: rollingUpgrade, qui est la valeur par défaut), Milvus Operator exécute automatiquement la mise à niveau dans un ordre prédéfini aligné sur l'architecture Milvus 2.6 :

Démarrer le nœud de streaming → Mettre à niveau MixCoord → Mettre à niveau le nœud de requête → Mettre à niveau le nœud de données → Mettre à niveau le proxy → Supprimer le nœud d'index.

3. Consolidation automatique des coordinateurs

Milvus 2.6 remplace plusieurs composants de coordinateur par un seul MixCoord. Milvus Operator gère automatiquement cette transition architecturale.

Lorsque spec.components.mixCoord est configuré, l'opérateur lance MixCoord et attend qu'il soit prêt. Une fois que MixCoord est pleinement opérationnel, l'opérateur arrête progressivement les anciens composants de coordination - RootCoord, QueryCoord et DataCoord - achevant ainsi la migration sans nécessiter d'intervention manuelle.

Etapes de mise à niveau de Milvus 2.5 à 2.6

1. mettre à niveau Milvus Operator vers la dernière version (dans ce guide, nous utilisons la version 1.3.3, qui était la dernière version au moment de la rédaction).

# 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. fusionner les composants du coordinateur

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

3. s'assurer que le cluster exécute Milvus 2.5.16 ou une version ultérieure

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. mettre à niveau Milvus vers la version 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

Comment passer à Milvus 2.6 avec Helm ?

Lors du déploiement de Milvus à l'aide de Helm, toutes les ressources Kubernetes Deployment sont mises à jour en parallèle, sans ordre d'exécution garanti. Par conséquent, Helm n'offre pas de contrôle strict sur les séquences de mise à niveau en continu entre les composants. Pour les environnements de production, l'utilisation de Milvus Operator est donc fortement recommandée.

Milvus peut toujours être mis à niveau de 2.5 à 2.6 à l'aide de Helm en suivant les étapes ci-dessous.

Configuration requise

Version de Helm : ≥ 3.14.0
Version de Kubernetes : ≥ 1.20.0

1.Mettre à jour la carte Milvus Helm vers la dernière version. Dans ce guide, nous utilisons la version 5.0.7, qui était la plus récente au moment de la rédaction.

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

2 Si le cluster est déployé avec plusieurs composants de coordinateur, mettez d'abord à niveau Milvus vers la version 2.5.16 ou ultérieure et activez 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. mettre à niveau Milvus vers la version 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 sur la mise à niveau et les opérations de Milvus 2.6

Q1 : Milvus Helm vs. Milvus Operator - lequel dois-je utiliser ?

Pour les environnements de production, Milvus Operator est fortement recommandé.

Se référer au guide officiel pour plus de détails : https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm

Q2 : Comment choisir une file d'attente de messages (MQ) ?

Le MQ recommandé dépend du mode de déploiement et des exigences opérationnelles :

1. Mode autonome : Pour les déploiements sensibles aux coûts, il est recommandé d'utiliser RocksMQ.

2. Mode cluster

Pulsar prend en charge le multi-tenant, permet aux grands clusters de partager l'infrastructure et offre une forte évolutivité horizontale.
Kafka dispose d'un écosystème plus mature, avec des offres SaaS gérées disponibles sur la plupart des grandes plateformes cloud.

3. Woodpecker (introduit dans Milvus 2.6) : Woodpecker supprime la nécessité d'une file d'attente de messages externe, réduisant ainsi les coûts et la complexité opérationnelle.

Actuellement, seul le mode Woodpecker intégré, léger et facile à utiliser, est pris en charge.
Pour les déploiements autonomes de Milvus 2.6, Woodpecker est recommandé.
Pour les déploiements de clusters de production, il est recommandé d'utiliser le mode cluster Woodpecker dès qu'il sera disponible.

Q3 : Peut-on changer la file d'attente des messages pendant une mise à niveau ?

Non. Le basculement de la file d'attente des messages au cours d'une mise à niveau n'est pas pris en charge actuellement. Les prochaines versions introduiront des API de gestion qui permettront de passer de Pulsar à Kafka, Woodpecker et RocksMQ.

Q4 : Les configurations de limitation de débit doivent-elles être mises à jour pour Milvus 2.6 ?

Non. Les configurations de limitation de débit existantes restent efficaces et s'appliquent également au nouveau nœud de streaming. Aucune modification n'est nécessaire.

Q5 : Après la fusion des coordinateurs, les rôles ou les configurations de surveillance changent-ils ?

Les rôles de surveillance restent inchangés (RootCoord, QueryCoord, DataCoord).
Les options de configuration existantes continuent de fonctionner comme avant.
Une nouvelle option de configuration, mixCoord.enableActiveStandby, est introduite et reviendra à rootcoord.enableActiveStandby si elle n'est pas explicitement définie.

Q6 : Quels sont les paramètres de ressources recommandés pour StreamingNode ?

Pour l'ingestion en temps réel légère ou les charges de travail occasionnelles d'écriture et de recherche, une configuration plus petite, telle que 2 cœurs de CPU et 8 Go de mémoire, est suffisante.
Pour l'ingestion en temps réel lourde ou les charges de travail d'écriture et de recherche continues, il est recommandé d'allouer des ressources comparables à celles du nœud de requête.

Q7 : Comment mettre à niveau un déploiement autonome utilisant Docker Compose ?

Pour les déploiements autonomes basés sur Docker Compose, il suffit de mettre à jour la balise d'image Milvus dans docker-compose.yaml.

Pour plus de détails, consultez le guide officiel : https://milvus.io/docs/upgrade_milvus_standalone-docker.md

Conclusion

Milvus 2.6 marque une amélioration majeure à la fois de l'architecture et des opérations. En séparant le traitement en continu et le traitement par lots avec l'introduction de StreamingNode, en consolidant les coordinateurs dans MixCoord et en simplifiant les rôles des travailleurs, Milvus 2.6 fournit une base plus stable, plus évolutive et plus facile à exploiter pour les charges de travail vectorielles à grande échelle.

Ces changements architecturaux rendent les mises à niveau, en particulier à partir de Milvus 2.5, plus sensibles à l'ordre. Une mise à niveau réussie dépend du respect des dépendances des composants et des contraintes de disponibilité temporaire. Pour les environnements de production, Milvus Operator est l'approche recommandée, car il automatise le séquençage des mises à niveau et réduit le risque opérationnel, tandis que les mises à niveau basées sur Helm sont mieux adaptées aux cas d'utilisation hors production.

Avec des fonctionnalités de recherche améliorées, des types de données plus riches, un stockage hiérarchisé et des options de file d'attente de messages améliorées, Milvus 2.6 est bien placé pour prendre en charge les applications d'IA modernes qui nécessitent une ingestion en temps réel, des performances de requête élevées et des opérations efficaces à l'échelle.

Vous avez des questions ou souhaitez approfondir l'une des fonctionnalités de la dernière version de Milvus ? Rejoignez notre canal Discord ou déposez des questions sur GitHub. Vous pouvez également réserver une session individuelle de 20 minutes pour obtenir des informations, des conseils et des réponses à vos questions dans le cadre des Milvus Office Hours.