Notes de mise à jour

Découvrez les nouveautés de Milvus ! Cette page présente un résumé des nouvelles fonctionnalités, des améliorations, des problèmes connus et des corrections de bogues de chaque version. Nous vous recommandons de consulter régulièrement cette page pour vous tenir informé des mises à jour.

v3.0.2

Date de sortie : 20 septembre 2026

Version de Milvus	Version du SDK Python	Version du SDK Node.js	Version du SDK Java	Version du SDK Go
3.0.2	3.0.2	3.0.6	3.0.10	3.0.2

Nous sommes ravis d’annoncer la sortie de Milvus v3.0.2 ! Cette version met l’accent sur les performances de recherche et de requête — en supprimant les conflits de chemins fréquents dans la recherche filtrée, le regroupement et la création d’index — ainsi que sur une prise en charge renforcée des collections externes et de Storage V2, et un large ensemble de corrections de stabilité concernant le streaming, la compaction et la gestion des index.

Améliorations

• Optimisation du filtrage ARRAY grâce à la fusion des prédicats « contains » enchaînés en une seule expression « ContainsAny » / «ContainsAll » dans le planificateur de requêtes (#52365)
• Ajout de la prise en charge des points de terminaison personnalisés compatibles S3 dans les collections externes via l’option ` extfs.endpoint_url `, avec validation des paramètres de point de terminaison non sécurisés ou conflictuels (#52814)
• Unification des filtres d’appartenance Bloom et Roaring derrière une seule expression membership_match, avec prise en charge correspondante du client Go pour la création et l’interrogation des deux types de filtres (#53019)
• Réduction de l’amplification d’écriture lors de la création d’index basée sur Tantivy, ce qui diminue les E/S disque pour les index de correspondance de texte, NGRAM et de statistiques de clés JSON (#53057)
• Ajout d’un contrôle d’admission sur les points de terminaison DQL RESTful v2 qui renvoie un code HTTP 429 avec « Retry-After » avant le décodage de la requête lorsque la file d’attente des requêtes du proxy est pleine (#53111)
• Réduction d’un goulot d’étranglement lié au comptage atomique des références dans le chemin d’évaluation des filtres scalaires, qui représentait environ 48 % du temps CPU des nœuds feuilles lors des recherches, ce qui améliore le débit des recherches filtrées (#53167)
• Amélioration de l’évolutivité du pool de threads de stockage en remplaçant l’implémentation personnalisée par l’ folly::CPUThreadPoolExecutor et en rétablissant la mise à l’échelle élastique des workers (#53184)
• Amélioration de la correspondance des journaux d’accès REST afin que les formateurs soient mis en correspondance avec le chemin d’URL analysé, et que les méthodes configurées s’appliquent désormais aux requêtes comportant des paramètres de requête (#53147)
• Ajout de la prise en charge de la diffusion idempotente afin que les requêtes réessayées ne créent plus de tâches en double, avec BulkImport comme premier utilisateur (#53228)
• Ajout de caractères de délimitation de phrase configurables pour le tokeniseur Lindera, permettant aux entrées du dictionnaire utilisateur contenant des signes de ponctuation d’être traitées comme un seul token (#53287)
• Ajout d’un contrôle de version du cluster qui n’active automatiquement la matérialisation des fonctions en écriture préalable qu’une fois la mise à niveau terminée sur tous les nœuds, évitant ainsi les incohérences liées au mélange de versions lors des mises à niveau progressives (#53261)
• Mise à niveau de Woodpecker vers la version v0.1.42, corrigeant les échecs de récupération WAL sur les segments vides finalisés et améliorant la stabilité et les métriques du chemin d’ajout (#53295)
• Réduction de la surcharge liée aux opérations atomiques et au comptage de références par bloc dans le chemin critique de recherche et de requête, grâce à l’ancrage d’un instantané de segment scellé une fois par requête (#53301)
• Amélioration de la latence des mises à jour partielles en remplaçant les attentes TimeTick par un verrouillage optimiste basé sur des instantanés, et affinement de la gestion des AutoID afin que les clés primaires existantes soient conservées et que les ID renvoyés respectent l’ordre d’entrée (#53337)
• Réduction de la construction redondante de vues de lignes lors du regroupement des résultats de recherche par champs VARCHAR ou JSON sur des segments scellés, ce qui réduit la surcharge liée aux recherches avec regroupement (#53500)
• Ajout d’une API de conformité qui rend compte de la convergence de la configuration de charge à l’échelle globale et par groupe de ressources, couvrant l’opérabilité des répliques, la visibilité des requêtes, les ressources résiduelles et le placement du WAL (#53517)

Corrections de bogues

• Correction d’un problème où les requêtes pouvaient renvoyer des résultats incorrects après la suppression puis la réintégration d’un champ de type « struct array » (#52921)
• Correction des échecs d’authentification SASL/SCRAM-SHA-256 lors de la connexion à des brokers Apache Kafka 4.x grâce à la mise à niveau de librdkafka vers la version 2.6.1 (#53086)
• Correction d’un problème où tous les canaux d’une réplique étaient attribués à un seul nœud de requête, ce qui provoquait des arrêts répétés pour cause de mémoire insuffisante et rendait la réplique inutilisable (#53094)
• Correction d’un problème de « fencing » WAL répété qui bloquait les écritures sur un PChannel pendant 45 à 60 secondes toutes les quelques minutes en cas d’ingestion soutenue (#53118)
• Correction d’un problème de compaction de Storage V2 qui supprimait des chemins de groupe physiques valides, ce qui pouvait entraîner un désalignement des index de colonnes compressées dans les segments compactés (#53202)
• Correction de l’affichage dans les journaux de compactage des clés de chiffrement de collection et des identifiants de stockage d’objets (#53226)
• Correction d’alias de décalage de tableaux de structures obsolètes pouvant afficher des données incorrectes après la réouverture d’un segment scellé (#53154)
• Correction d’un problème où la synchronisation des ressources de fichiers s’exécutait avant l’ajout de toute ressource, ce qui pouvait effacer les fichiers locaux du nœud au démarrage ou lors de l’enregistrement du nœud (#53170)
• Correction d’un problème où un bloc de journal de binaire incomplet pouvait être traité en silence comme entièrement lu, risquant ainsi de provoquer des pertes de données dans les résultats des requêtes et de la compaction (#53263)
• Correction d’un problème où l’espace de stockage des segments supprimés n’était jamais récupéré pour les collections ne comportant aucun index actif (#53252)
• Correction d’une estimation inexacte des ressources lors du chargement d’index vectoriels clairsemés, ce qui pouvait entraîner une gestion incorrecte des données brutes et des avertissements répétés sur QueryNode (#53249)
• Correction d’un problème où un nœud de streaming gelé en dehors du groupe de ressources principal pouvait être dégelé de manière inattendue lors du rééquilibrage (#53229)
• Correction d’un échec de connexion à Google Cloud Storage lorsque les identifiants GCP (IAM et HMAC) n’étaient pas enregistrés avant la vérification préalable du gestionnaire de blocs (#53288)
• Correction d’un problème où les journaux C++ étaient inopinément écrits dans le répertoire ` /tmp ` au lieu d’être transférés vers la sortie de journaux unifiée (#53293)
• Correction d’un échec des commits de backfill avec une erreur HTTP 500 lorsqu’un résultat Spark s’étendait sur plusieurs partitions (#53346)
• Correction d’une fuite de mémoire dans DataNode : une tâche de création d’index ou d’analyse annulée ne libérait jamais la mémoire native de l’objet qu’elle avait déjà créé (#53348)
• Correction d’un problème où l’importation du journal binaire échouait lorsqu’un champ vectoriel pouvant être nul ne disposait d’aucun fichier de journal binaire (#53363)
• Correction des champs de sortie incomplets ou incorrects lorsque les requêtes de recherche et d’interrogation lisaient les données des tables externes (#53372, #53385)
• Correction de la duplication des lignes de vecteurs clairsemés et des identifiants de partition dans les requêtes REST, ainsi que des problèmes de propriété et de nettoyage de la mémoire pouvant entraîner des plantages ou des fuites lorsque les requêtes se terminaient prématurément (#53402)
• Correction d’un problème où une compaction signalant sa fin sans charge utile de résultat pouvait provoquer le plantage de DataCoord ou bloquer la tâche de compaction au lieu de la relancer correctement (#53443)
• Correction d’un problème où les propriétés des fichiers de données externes étaient supprimées lors de la création des manifestes de segments, ce qui entraînait la perte des métadonnées des fichiers sources pour les collections externes (#53444)
• Correction d’un plantage de QueryNode pouvant survenir lors du traitement des requêtes « count(*) » au niveau du journal de débogage, notamment lors de mises à niveau progressives (#53474)
• Correction d’un problème où les tâches de création d’index et de statistiques continuaient à consommer des ressources des workers après la suppression de leur segment, index ou collection, et amélioration du nettoyage des fichiers d’index orphelins (#53515)
• Correction de la gestion des chemins de stockage local afin que les données écrites par différents composants soient toujours placées là où les lecteurs et le ramasse-miettes s’y attendent, avec une mise à niveau automatique pour les déploiements locaux existants (#53530)
• Correction des tâches de création d’index qui réessayaient indéfiniment lorsqu’un segment contenait des documents JSON mal formés ; ces créations échouent désormais rapidement au lieu de consommer indéfiniment les ressources des workers (#53531)
• Correction des restaurations simultanées d’instantanés ciblant la même collection : les restaurations sont désormais sérialisées et une restauration vers une cible existante est rejetée avec un message d’erreur clair « existe déjà dans la base de données » au lieu de provoquer des conflits d’accès ou des fuites de ressources (#53586)
• Correction de la corruption des clés de chiffrement binaires sur les interfaces de stockage et du désalignement des curseurs dans les lecteurs compressés Storage V2 projetés, grâce à la mise à jour de milvus-storage (#53569)

v3.0.1

Date de sortie : 9 septembre 2026

Version de Milvus	Version du SDK Python	Version du SDK Node.js	Version du SDK Java	Version du SDK Go
3.0.1	3.0.1	3.0.5	3.0.9	3.0.1

Nous sommes ravis d’annoncer la sortie de Milvus v3.0.1 ! Cette version ajoute la gestion des instantanés REST v2, des capacités de reclassement étendues et la prise en charge des champs TEXT dans le client Go et l’API RESTful, ainsi que des améliorations de performances et des corrections concernant Storage V3, la cohérence des données et la sécurité.

Améliorations des fonctionnalités

• Ajout d’API REST v2 pour la gestion native des instantanés au niveau des collections et la restauration asynchrone (#52118, #52172)
• Ajout d’un seuil configurable pour le nombre de résultats afin de contrôler la sélection du chemin de sortie « Take » pour les opérations de recherche et de requête (#52437)
• Ajout de la prise en charge des champs TEXT dans le client Go et l’API RESTful (#52450)
• Ajout de taux d’IOPS de lecture initiaux et maximaux configurables pour les tables externes (#52503)
• Ajout d’un paramètre optionnel permettant aux tâches de rafraîchissement des collections externes d’attendre que tous les segments soient indexés avant de signaler l’achèvement, sans retarder la publication des données (#52712)
• Ajout de la prise en charge du reclassement L1 aux chaînes de fonctions de recherche (#52745)
• Ajout du reclassement RRF pondéré avec des pondérations optionnelles par requête ANN dans FunctionScore, REST, la recherche hybride héritée et le client Go (#52891, #52926)

Améliorations de la stabilité

• Amélioration de la sécurité mémoire dans les index et caches RTree de géométrie, ainsi que de la gestion des requêtes WKB non analysables et des requêtes de géométrie vide (#51312)
• Amélioration de la gestion de la mémoire grâce à la restauration de la gestion budgétaire de la mémoire transitoire à l’échelle du processus et à la correction des estimations de mémoire pour le chargement simultané de champs Storage V2/V3 et le chargement d’index scalaires V3 (#51405)
• Réduction des goulots d’étranglement au niveau des téléchargements et de l’utilisation de la mémoire lors de la création d’index de collections externes grâce à la parallélisation des lectures et à la transmission en continu des données vectorielles brutes vers le disque (#51651)
• Amélioration du débit de Woodpecker pour les charges de travail à petits lots et à forte concurrence grâce au traitement par lots des ajouts des clients et à l’exposition des paramètres de synchronisation (#51810)
• Amélioration de la propriété et de la cohérence tout au long du cycle de vie des lecteurs d’enregistrements, de la gestion des blobs vides et du signalement des erreurs de lecture sur les chemins de stockage et de compactage (#51891)
• Amélioration de l’efficacité de la recherche de hachage par regroupement grâce à un pipeline entrelacé à quatre voies et à des mesures de protection contre les collisions et les limites de rehachage (#51977)
• Réduction de la surcharge de traitement des insertions en ignorant l’analyse du corps d’insertion WAL pour les collections ne comportant pas de champs de sortie BM25 ou MinHash (#51986)
• Amélioration du signalement des défaillances de stockage et de la gestion des nouvelles tentatives grâce à la conservation des classifications d’erreurs transitoires et permanentes à travers les couches d’exécution (#51990)
• Amélioration des performances des requêtes spatiales grâce à l’activation par défaut du fractionnement grossier/affiné des requêtes SIG et de la fusion des prédicats sur une même colonne (#52008)
• Amélioration de la planification des tâches d’indexation de texte et de fragmentation JSON grâce à un contrôle d’admission basé sur une file d’attente partagée et à une priorité de soumission alternée (#52010)
• Ajout de la prise en charge de mmap pour les mappages de décalage de segments scellés, avec des options de chargement dédiées et la comptabilisation des ressources disque (#52035)
• Optimisation du chargement des données Storage V2 grâce à l’estimation à la demande de la mémoire requise par bloc et par colonne (#52037)
• Ajout de la prise en charge côté serveur d’AutoIndex pour les index liés aux nouveaux champs de sortie de fonction, permettant aux requêtes add_function_field d’omettre les paramètres d’index ou de spécifier AUTOINDEX (#52109)
• Réduction de la taille des rapports de distribution QueryNode grâce à des rapports incrémentiels avec repli sur un rapport complet, et réduction des allocations de mémoire lors de la collecte des métriques (#52111, #52119)
• Amélioration de la robustesse du hachage des mots de passe en augmentant le coût bcrypt de 4 à 10, la rotation des identifiants étant requise pour mettre à niveau les hachages existants (#52145)
• Réduction du décodage redondant lors des importations Parquet en ne lisant que les colonnes feuilles requises pour les sous-champs des tableaux de structures (#52224)
• Amélioration du regroupement par fusion forcée grâce à une planification en plusieurs étapes basée sur la taille, et obsolescence du paramètre de seuil de planification hérité (#52242)
• Mise à jour de cgosymbolizer pour empêcher les processus Milvus s’exécutant sous le PID 1 de se bloquer après des erreurs natives (#52299)
• Amélioration de la validation du nombre de lignes pour les entrées de mise en évidence sémantique (#52409)
• Amélioration du contrôle des tentatives d’importation avec un délai de réessai configurable pour les tentatives d’écriture (#52414, #52415, #52427)
• Amélioration de la gestion du cycle de vie des tâches d’analyse grâce à la récupération des versions obsolètes des statistiques et à la persistance des états finaux (#52416, #52417)
• Amélioration de la coordination du cycle de vie des segments grâce à l’attente de la libération des segments après les délais d’expiration des verrous (#52422)
• Amélioration du tri en mémoire pour la compaction des données avec une fusion à k voies (#52429)
• Réduction de l’expansion du tampon de validité des champs pouvant être nuls grâce à la conservation des masques compressés lors de l’accès aux blocs, de l’évaluation des expressions et des statistiques JSON (#52451)
• Amélioration de la protection des identifiants sensibles, des clés API, des hachages de mots de passe RBAC et des détails des sources de collecte externes en empêchant leur divulgation dans les journaux ou les messages d’erreur (#52487, #52664, #52710)
• Amélioration du contrôle de la concurrence des mises à jour partielles grâce à une validation CAS optimiste et à des tentatives de reprise sécurisées pour les conflits éligibles (#52495)
• Amélioration de la stabilité des instantanés de lecture des segments en croissance et de la gestion de la durée de vie des instantanés de schéma (#52572)
• Réduction des analyses redondantes des métadonnées d’autorisation lors des sauvegardes (#52612)
• Amélioration du mappage des identifiants de vecteur pouvant être nuls grâce à son déplacement vers la couche d’index, à l’unification de la gestion des identifiants logiques et à la prise en charge des mappages basés sur mmap pour les index scellés (#52657)
• Amélioration de la synchronisation entre la compilation JIT de Sonic et le chargement des plugins Go dans les versions CPU et GPU (#52738)
• Amélioration de la résolution des canaux du chemin d’écriture du proxy via le cache de métadonnées, éliminant les appels RPC redondants vers le coordinateur et améliorant la classification des erreurs (#52739)
• Réduction du temps de calcul du rappel d’environ 3,08 secondes à 18,5 millisecondes pour topk=100 000 dans le benchmark rapporté (#52763)
• Optimisation du filtrage des champs pouvant être nuls grâce à la réutilisation des bitmaps de validité, ce qui réduit le stockage redondant des décalages nuls et accélère les copies de jeux de bits (#52801, #52823, #52825)
• Amélioration des index scalaires hybrides sur les sous-champs de structures imbriquées grâce à l’utilisation de STL_SORT lorsque le nombre d’éléments distincts atteint la limite de cardinalité de la carte de bits (#52849)
• Amélioration de l’efficacité du filtrage des identifiants de segment dans le cache de métadonnées (#52855)
• Réduction des allocations de mémoire dans les fonctions d’aide au hachage (#52857)
• Optimisation du tri des résultats de reclassement fusionnés en éliminant les recherches dans la table de correspondance à chaque comparaison (#52885)
• Amélioration de la sécurité mémoire lors du traitement des valeurs par défaut JSON et des vues de chaînes non terminées par un caractère NUL (#52906)
• Amélioration des temps de compilation C++ grâce à la compilation unitaire par portée, à l’amélioration de la mise en cache du compilateur et à la réduction des tâches de compilation redondantes (#52995)
• Amélioration de la couverture et de l’actualité des métriques du système de fichiers grâce à la collecte de métriques à partir des systèmes de fichiers mis en cache au moment de la collecte, tout en conservant les noms et les étiquettes de métriques existants (#53026)
• Ajout d’un paramètre « growingBuildThreadRate » actualisable pour configurer le nombre de threads par segment croissant lors de la construction de l’index intermédiaire, tout en conservant le comportement par défaut à thread unique (#53033)
• Ajout de la prise en charge de la réécriture des données de champ via mmap dans la version 3.0 grâce à un backport, avec l’option queryNode.mmap.writeback désactivée par défaut (#53079)

Corrections de bogues

• Correction de résultats incorrects et d’une validation incohérente des prédicats dans les requêtes JSON, ARRAY et TIMESTAMPTZ, notamment pour les prédicats de types mixtes, les comparaisons de grands nombres et le filtrage sur plusieurs lots (#51775)
• Correction d’une incohérence dans l’actualisation des données lors des actualisations parallèles de collections externes lorsque les fichiers source d’un segment s’étendaient sur plusieurs tâches (#51893)
• Correction des expressions MATCH acceptant des prédicats qui ne fonctionnaient pas au niveau des éléments (#51940)
• Correction d’un problème où les recherches sans résultat échouaient avec une erreur de type d’ID non pris en charge (#51999)
• Correction d’un blocage de Milvus autonome lors de l’arrêt grâce à l’ajout d’un délai de migration configurable, avec une valeur par défaut de 10 secondes (#52027)
• Correction d’un problème où les requêtes d’intégration de tables externes utilisaient une identité de cluster erronée lorsque les nœuds de travail DataNode étaient partagés entre plusieurs clusters de service (#52042)
• Correction d’un problème empêchant la mise à jour des identifiants `integration_id` et `model_deployment_id` pour les fonctions TextEmbedding (#52081)
• Correction des réponses HTTP JSON omettant le statut explicite « ok=false » pour les segments de backfill ayant échoué (#52082)
• Correction des échecs de téléchargement d’objets MinIO avec le code HTTP 400 XAmzContentChecksumMismatch lors d’une nouvelle tentative après des délais d’attente liés au transport ou à une faible vitesse (#52128, #52194)
• Correction du blocage de l’équilibrage des segments entre les QueryNodes lorsque le service de streaming était activé (#52147, #52169)
• Correction d’une perte de données silencieuse lors de la compaction mixte lorsque les enregistrements conservés ne pouvaient pas être reconstruits (#52200)
• Correction d’un problème où les restaurations d’instantanés perdaient les paramètres de collection et passaient de manière inattendue à la cohérence forte (#52206)
• Correction d’un problème de suppression en streaming où les segments scellés nouvellement chargés étaient ignorés, ce qui permettait de continuer à interroger les données supprimées (#52218)
• Correction de la création incorrecte d’index imbriqués pour les données vides (#52247)
• Correction des blocages lors du passage au service de streaming, qui laissaient les opérations en attente indéfiniment (#52292)
• Correction des valeurs par défaut incorrectes de la géométrie lors de la compaction et de la reconstruction des enregistrements, ainsi que des marquages « null » incorrects pour les valeurs de géométrie renseignées par défaut lors des importations Parquet (#52350)
• Correction du rejet de segments V3 valides lors de la compaction et de la récupération après un redémarrage de DataCoord (#52383, #52389, #52390, #52391, #52392, #52393)
• Correction des échecs de chargement de segments dus à une erreur de métadonnées de version manquante lors de l’utilisation d’index scalaires hybrides sur des sous-champs de type tableau VARCHAR dans des structures (#52385)
• Correction d'un problème empêchant l'actualisation des colonnes externes lors de la réouverture d'un manifeste mis à jour (#52397)
• Correction d’un traitement incorrect du fuseau horaire dans les recherches comportant des conditions dépendantes du temps (#52407)
• Correction d’une gestion incorrecte des entrées ArrayOfVector dans les requêtes de recherche (#52408)
• Correction des échecs d’insertion dus au non-rejet des lignes dépassant la limite de taille prise en charge (#52426)
• Correction d'un problème où les index provisoires ignoraient la version d'index cible configurée (#52449)
• Correction d'un problème empêchant les requêtes utilisant `order_by` de renvoyer des champs de sortie vectoriels denses (#52504, #52606)
• Correction d'un problème où des privilèges révoqués restaient actifs après avoir été supprimés d'un groupe de privilèges (#52554)
• Correction des comptes de fichiers binlog et des libellés de format de stockage incorrects pour les segments Storage V3 après les redémarrages de DataCoord (#52571, #52578)
• Correction d’un blocage des restaurations de snapshots externes dû à des vérifications de version des workers peu fiables ou à des tentatives répétées d’utilisation de workers non pris en charge jusqu’à l’expiration du délai d’attente (#52639)
• Correction des échecs de chargement de segments pour les index HYBRID sur les sous-champs de type « struct-array » avec des fichiers STLSORT hérités de la version 3.0.0, sans nécessiter de réindexation (#52643)
• Correction des plantages lors du traitement de tampons de données Arrow C de longueur nulle (#52652)
• Correction d’une gestion incorrecte des échecs lors du chargement ou de la réouverture de segments Storage V3 après des erreurs de manifeste, en préservant l’état existant des segments pour des nouvelles tentatives en toute sécurité (#52678)
• Correction des échecs de requête lorsque les filtres d’éléments ARRAY rencontraient des lots entiers de NULL ou de tableaux vides avant les éléments suivants (#52720)
• Correction d’un problème où les tâches de réactualisation validaient des intégrations obsolètes après une modification du schéma de la collection (#52789)
• Correction d’un problème où les champs manquants dans les enregistrements Storage V3 étaient renvoyés sous forme de NULL au lieu de leurs valeurs par défaut déclarées (#52790, #52807, #52888)
• Correction des échecs de copie côté serveur qui empêchaient la restauration d’instantanés Storage V3 sur GCS avec des identifiants IAM/OAuth, y compris pour les copies d’objets de plus de 5 GiB (#52792)
• Correction d’un accès non authentifié via des appels gRPC en streaming sur le port du proxy externe (#52854)
• Correction de la perte des horodatages de validation d’origine des données après un compactage en cluster (#52859)
• Correction des plantages des nœuds de streaming causés par des échecs répétés de vidage après l’ajout d’un champ TEXT à des collections comportant des segments Storage V2 existants (#52897)
• Correction d’un problème où les lignes expirées dans les segments Storage V3 ne déclenchaient pas la compaction basée sur le champ TTL et restaient stockées jusqu’à ce qu’une autre condition de compaction soit remplie (#52931)
• Correction d’une incohérence entre les clés primaires générées automatiquement dans les collections source et cible lors d’importations répliquées via CDC (#52941)
• Correction de la perte d’écritures simultanées lors de la migration du backend WAL (#52947, #52951, #52955)
• Correction d’un problème où les index HYBRID imbriqués, reconstruits ou compactés et contenant des données à cardinalité élevée, devenaient illisibles après une restauration vers une version antérieure (#52959)
• Correction de la gestion des éléments nuls dans les lignes de vecteurs denses externes en acceptant les lignes nullables entièrement nulles et en ajoutant une gestion configurable des lignes partiellement nulles (#52968)
• Correction des comptages incorrects de lignes de segments V3 et des échecs répétés de compactage par tri suite d’un basculement de nœud de streaming (#52970)
• Correction des requêtes combinant des conditions de plage avec l’opérateur OR qui omettaient des enregistrements à la limite inférieure incluse (#52998)
• Correction des recherches par clé primaire qui ne préservaient pas l'ordre des ID demandé (#52999)
• Correction d’un problème où l’ajout d’un champ TEXT après l’activation de Storage V3 empêchait le chargement des segments Storage V2 existants en cours d’extension, perturbant ainsi les opérations de vidage, de tri et d’indexation (#53002)
• Correction d’un problème lié aux instantanés incluant des segments Storage V3 non validés, ce qui entraînait un message de réussite lors de la restauration alors que les segments restaurés ne pouvaient pas être chargés (#53022, #53039)
• Correction d'un problème empêchant le chargement des index de texte de Storage V3 lorsque leurs fichiers étaient stockés dans des répertoires de tâches ou de versions imbriqués (#53062)

v3.0.0

Date de sortie : 29 juillet 2026

Version de Milvus	Version du SDK Python	Version du SDK Node.js	Version du SDK Java	Version du SDK Go
3.0.0	3.0.1	3.0.3	3.0.5	3.0.0

Milvus 3.0.0 est officiellement disponible ! S'appuyant sur l'architecture « lake-native » introduite dans la version 3.0-beta, cette version achève ce que la version bêta avait commencé : External Collection couvre davantage de workflows « lakehouse » ; le schéma prend en charge l'ajout, le remplissage et la suppression en ligne ; l'index clairsemé est reconstruit autour de SINDI ; StructArray et la recherche à facettes viennent compléter le moteur de recherche ; le passthrough FAISS et TEXT élargissent les choix d’index et de modalités ; et Woodpecker fonctionne désormais comme un service autonome.

Regardez la vidéo ci-dessous pour en savoir plus sur Milvus 3.0 et participez à la session de questions-réponses avec les responsables du noyau :

Si vous découvrez la version 3.0, la section « Rappel des fonctionnalités de Core 3.0 » ci-dessous résume les capacités introduites dans la version 3.0-beta ; les notes de mise à jour de la version 3.0-beta contiennent les descriptions complètes.

Nouveautés de la version 3.0.0 (depuis la version 3.0-beta)

Collection externe : des workflows « lakehouse » plus complets

La version 3.0-beta a introduit la fonctionnalité « External Collection » : référencez des fichiers de lac de données sur place, créez des index et effectuez des recherches sans copier les données dans Milvus. Cette version étend cette fonctionnalité pour offrir des workflows complets de recherche « lakehouse ». Les champs externes peuvent désormais alimenter des champs de sortie de fonctions tels que les vecteurs clairsemés BM25, les signatures MinHash et les représentations textuelles, ce qui permet de créer des champs de recherche textuels et dérivés de modèles au sein de Milvus sans copier la table source. La fonctionnalité « Refresh » prend également en charge l’évolution additive du schéma : lorsque la table externe se dote de nouvelles colonnes, Milvus met à jour les segments concernés au lieu de reconstruire la collection.

Cette version ajoute également un format externe « milvus-table » qui traite les métadonnées Milvus Snapshot et les manifestes Storage V3 comme une source externe, de sorte qu’un instantané de collection peut lui-même être servi en tant que table externe — les systèmes de traitement par lots et de service bénéficient ainsi d’une vue partagée, adossée au manifeste, des mêmes données.

Pour plus d’informations, consultez les sections Créer une collection externe et les instantanés.

Schéma flexible : ajouter, compléter et supprimer des colonnes en ligne

Les schémas ne restent pas statiques en production — les modèles intégrés sont remplacés, les fonctionnalités évoluent, les champs sont obsolètes — et cela impliquait auparavant de reconstruire l’intégralité de la collection, avec des temps d’arrêt ou des écritures en double. La version 3.0.0 boucle la boucle : les colonnes peuvent être ajoutées, remplies et supprimées sans interrompre la mise à disposition des données.

Le remplissage fonctionne dans les deux sens. Le remplissage externe gère les valeurs calculées en dehors de Milvus : ajoutez une colonne, effectuez un instantané de la collection comme point de départ cohérent, exécutez la tâche hors ligne, réécrivez les valeurs, et Milvus indexe la nouvelle colonne de manière incrémentielle — une mise à niveau du modèle d’embedding sur des centaines de millions de lignes devient ainsi une opération à chaud sans temps d’arrêt. Le « backfill » interne couvre les valeurs dérivées du noyau : associez une fonction BM25 ou MinHash à une collection existante et son champ de sortie est automatiquement calculé à partir des données existantes.

Pour plus d’informations, consultez la section « Ajouter des champs à une collection existante ».

Refonte de l’index clairsemé : SINDI, Block-Max WAND et Block-Max MaxScore

Milvus 3.0 améliore l’index des vecteurs clairsemés à tous les niveaux. Il introduit de nouveaux algorithmes de recherche — SINDI, Block-Max WAND et Block-Max MaxScore — ainsi que la compression par liste inversée, la quantification configurable et la sélection d’algorithmes de recherche par charge de travail. Le chargement via mmap, la sérialisation et le calcul du score BM25 sont également optimisés, ce qui réduit l’espace de stockage des index et la surcharge liée au chargement pour la recherche de vecteurs clairsemés et en texte intégral à grande échelle. Lors de tests de performance internes, l’index BM25 compressé est environ trois fois plus petit que l’index clairsemé 2.6 pour un rappel comparable, et SINDI atteint jusqu’à environ dix fois le QPS de MaxScore sur des plongements clairsemés appris. Une fois la nouvelle version de l’index activée (voir les remarques sur la compatibilité et le comportement), SINDI devient la valeur par défaut pour la recherche IP clairsemée, et MaxScore la valeur par défaut pour BM25.

Prise en charge de StructArray

StructArray prend désormais en charge les valeurs nulles, les index bitmap, l’ajout dynamique de champs sur des collections actives et la mise à jour partielle des champs de structure via upsert, avec une prise en charge correspondante de REST et de l’importation en masse.

La recherche au niveau des éléments ajoute une recherche hybride sur les sous-champs vectoriels avec un regroupement configurable par entité (variantes max / sum / avg / top-k), ainsi que la recherche par plage et le regroupement au sein de celle-ci. Le filtrage imbriqué couvre les prédicats « element_filter », les quantificateurs « MATCH_ANY » / « MATCH_ALL » / « MATCH_LEAST » / « MATCH_MOST » / « MATCH_EXACT », l’accès positionnel aux sous-champs tel que « tags[0][name] », et « array_length() » sur la colonne struct.

Pour plus d’informations, reportez-vous aux sections « StructArray » et « Opérateurs StructArray ».

Agrégation de recherche et recherche à facettes

L’agrégation de requêtes de la version bêta calcule des statistiques exactes sur les données filtrées ; la version 3.0.0 ajoute la facettisation au chemin de recherche. Spécifiez un champ de facettisation au moment de la recherche et Milvus renvoie les valeurs de facettisation les plus pertinentes, chacune représentée par son élément le mieux correspondant dans le classement ANN et annotée avec des agrégats tels que COUNT et AVG — la barre latérale de recherche à facettes (marque, fourchette de prix, attributs) en une seule requête, au lieu d’effectuer une récupération excessive et un comptage côté client.

Re-classement via la chaîne de fonctions

Le reclassement est désormais composable via l’API « Function Chain », qui exécute un pipeline ordonné et typé dans le cadre d’une seule requête de recherche. Une chaîne peut combiner un réévaluation L0 précoce sur QueryNode avec un reclassement L2 post-réduction sur Proxy, prenant en charge la transformation et la combinaison des scores, le reclassement basé sur des modèles, le tri et la réduction des candidats sans orchestration côté client. Cette version ajoute également un calcul de score XGBoost natif pour le reclassement L0 à l’aide de modèles UBJ enregistrés en tant que FileResources, ainsi que les fournisseurs d’inférence Hugging Face pour l’intégration de texte gérée par le serveur et le reclassement par similarité de phrases.

Champs de texte long TEXT

Les champs TEXT accordent une place de choix aux textes longs, en supprimant les limites de longueur côté stockage : ils prennent en charge text_match, phrase_match et BM25. Les valeurs inférieures à 64 Ko restent en ligne ; les valeurs plus volumineuses sont transférées vers des fichiers LOB au niveau des partitions au format Vortex, la colonne ne stockant que des références (file_id, offset). Les fichiers LOB sont partagés entre les segments ; ainsi, la compaction déplace les références au lieu de réécrire le texte. Pour RAG, cela signifie récupérer les vecteurs et le texte source à partir du même magasin en une seule opération d’E/S — aucun magasin de blobs externe n’est nécessaire.

Pass-through de l’index FAISS

Un nouveau type d’index « FAISS » accepte des chaînes arbitraires de la fabrique d’index Faiss via le paramètre « faiss_index_name » — IVF64,Flat, HNSW16,Flat, OPQ16,IVF64,PQ16x4 — avec transmission des paramètres de recherche, ce qui permet aux recettes Faiss de s’exécuter directement sur Milvus.

Prise en charge des formats Vortex et Lance

La couche de stockage s’enrichit de deux formats colonnaires ouverts : Vortex, en tant que format interne de nouvelle génération — encodages adaptatifs (dictionnaire, RLE, bit-packing, compression spécifique aux nombres à virgule flottante), décompression sans copie, optimisé pour les charges de travail mixtes vecteur + scalaire — et Lance, aux côtés de Parquet, pour l’interopérabilité au sein d’un écosystème ouvert. Vortex est appelé à devenir le format interne par défaut, avec la descente de filtre et une variante locale prévues dans la feuille de route.

Déploiement autonome de Woodpecker

Woodpecker, le WAL au cœur du chemin d’écriture en continu, peut désormais être déployé en tant que service indépendant au lieu d’être intégré à d’autres nœuds — avec une évolutivité, une isolation des pannes et une observabilité indépendantes, comme n’importe quel autre microservice. Cela revêt une importance particulière pour les grands clusters et les charges de travail à forte intensité d’écriture.

Récapitulatif des fonctionnalités principales de la version 3.0

Les fonctionnalités ci-dessous ont été introduites dans la version 3.0-beta et font partie de la version 3.0.0 ; consultez les notes de la version bêta pour les descriptions complètes.

• Collection externe — interrogez les données du lakehouse (Parquet, Lance, Iceberg, Vortex) sur place : sans copie, en lecture seule, synchronisées via un rafraîchissement incrémental.
• Snapshot — vues de collection en lecture seule à un instant donné par référence de segment, avec un coût de stockage marginal quasi nul.
• Stockage V3 (Loon) — stockage en colonnes basé sur un manifeste sur un système de stockage d’objets ; base technique des fonctionnalités « Snapshot » et « Collection externe ».
• Requête / Recherche ORDER BY — tri multi-champs côté serveur avec ASC / DESC par champ.
• Agrégation de requêtes — COUNT / SUM / AVG / MIN / MAX avec regroupement, évaluées côté serveur.
• EmbList + DiskANN — indexation multivectorielle sur disque pour les listes d’intégration StructArray, avec des voies d’accélération telles que Muvera et Lemur.
• Fonction MinHash (doc-in, doc-out) — signatures MinHash côté serveur et « MINHASH_LSH » pour la détection de quasi-duplicatas.
• Vecteurs pouvant contenir des valeurs NULL — NULL sur les six types de vecteurs ; la recherche ignore les lignes NULL, et AddField s’étend aux champs vectoriels.
• TTL d’entité — expiration par ligne pilotée par un champ TIMESTAMPTZ.
• FileResource — dictionnaires, listes de synonymes et listes de mots vides gérés au niveau du cluster pour les analyseurs, BM25 et Text Match.
• Force Merge — compactage de segments déclenché par un opérateur, en mode synchrone ou asynchrone.

Remarques sur la compatibilité et le comportement

• Storage V3 (Loon) est désactivé par défaut. Les fonctionnalités qui en dépendent — telles que les champs Snapshot et TEXT — nécessitent une activation manuelle via common.storage.useLoonFFI. Storage V3 sera activé par défaut dans une version ultérieure.
• La compatibilité et la restauration entre les versions 2.6 et 3.0 sont garanties: un déploiement en version 3.0 peut être restauré en version 2.6. Cependant, une fois que vous activez ou utilisez des fonctionnalités qui modifient le format de sérialisation des données (par exemple, Storage V3), la restauration n’est plus possible.
• Les nouvelles versions d’index sont pour l’instant optionnelles. Les algorithmes d’indexation récemment introduits nécessitent de faire passer manuellement la version d’index cible (dataCoord.targetVecIndexVersion à 10, dataCoord.targetScalarIndexVersion à 4) avant qu’ils ne prennent effet ; une version ultérieure les activera par défaut.
• Les images GPU passent à CUDA 12.9 et ne conservent plus la compatibilité GPU avec Ubuntu 20.04.

v3.0-beta

Date de sortie : 9 mai 2026

Version de Milvus	Version du SDK Python	Version du SDK Node.js
3.0-beta	3.0.0	3.0.0

Milvus 3.0-beta étend la base de données vectorielle Milvus grâce à une nouvelle intégration dans l’écosystème Open Lake : la fonctionnalité « External Collection » permet à Milvus d’interroger des tables externes d’Open Lake sans copie, et Spark peut lire directement les collections Milvus via Snapshot. Cette version apporte également des fonctionnalités de recherche plus riches, un schéma plus expressif, une personnalisation plus poussée de la recherche textuelle, des contrôles plus précis sur le cycle de vie des données et des modèles, ainsi que davantage de contrôles côté opérateur. Milvus 3.0 constitue le noyau central de Zilliz Lakebase, assurant ses fonctionnalités unifiées de service, de découverte et de traitement par lots.

Principales fonctionnalités

External Collection

Dans les pipelines de données d’IA classiques, des téraoctets d’embeddings et de métadonnées se trouvent déjà sur un stockage objet sous forme de tables Parquet, Lance ou Iceberg. Copier ces données dans Milvus double le coût de stockage, ajoute un pipeline ETL qui doit être synchronisé en permanence et soustrait la gouvernance des données au contrôle du client.

La collecte externe élimine cette copie. Une collection Milvus peut référencer les fichiers là où ils se trouvent déjà, et Milvus ne gère que le schéma, les index et l’exécution des requêtes. Une actualisation incrémentielle assure l’alignement de la collection avec les fichiers sous-jacents. Les clients dont les données ne peuvent pas quitter le lac de données, tels que les équipes des secteurs de la finance et de la santé, peuvent effectuer des recherches vectorielles sur ces données là où elles se trouvent. Un même ensemble de données résidant dans le lac de données peut également être mis à disposition simultanément à partir de plusieurs instances Milvus.

Pour plus d’informations, consultez la section Créer une collection externe.

Instantané

La mise à disposition et la découverte par lots nécessitent souvent d’accéder à la même collection simultanément. L’évaluation de modèles A/B, la déduplication à grande échelle, la validation des données rétrospectives et la restauration de versions antérieures requièrent toutes une vue stable de la collection alors que les écritures se poursuivent.

Le « Snapshot » crée une vue à un instant donné et en lecture seule d’une collection en référençant des segments existants au lieu de copier les données, ce qui rend le coût marginal de stockage proche de zéro. Les tâches par lots peuvent lire à partir du « Snapshot » sous isolation de type MVCC tandis que la collection active continue d’accepter les écritures.

Pour plus d’informations, consultez les sections « Snapshots », « Gestion des snapshots » et « Cas d’utilisation des snapshots ».

Requête / Recherche « Order By »

La recherche et les requêtes acceptent désormais le tri sur plusieurs champs, le tri étant déporté vers le noyau Milvus et les paramètres « ASC » et « DESC » pouvant être définis par champ. Cela comble une lacune courante en production : le classement Top-K basé uniquement sur la distance ne répond souvent pas aux besoins métier lorsque l’élément le plus similaire n’est pas le moins cher, le plus récent ou le plus populaire.

Les applications n’ont plus besoin de récupérer un nombre excessif de résultats et de les trier à nouveau côté client pour établir un classement composite.

Pour plus d’informations, consultez les sections « Trier les résultats de recherche par champs scalaires » et « Trier les résultats de requête ».

Agrégation des requêtes

Auparavant, pour générer des statistiques de répartition des locataires, des comptages d’exhaustivité des champs ou la progression du déploiement d’une version à partir d’une collection Milvus, il fallait récupérer les entités correspondantes sur le client et les agréger à cet endroit. Milvus 3.0 intègre l’agrégation scalaire de type SQL au cœur du système. Un appel de requête accepte des expressions d’ group_by_fields s et d’agrégation sous la forme output_fields, notamment count(*), count(<field>), sum(<field>), avg(<field>), min(<field>) et max(<field>). L’agrégation est évaluée côté serveur après le filtrage.

Pour plus d’informations, consultez la section « Agrégation des résultats de requête ».

Vecteur nul

Les représentations sont souvent générées de manière asynchrone ; une entité peut donc arriver avant son vecteur. Les données multimodales présentent également des lacunes naturelles, comme une vidéo sans sous-titres ou un produit sans image. Les versions antérieures n’apportaient pas de solution satisfaisante : les applications retardaient soit l’écriture jusqu’à ce que le vecteur soit prêt, soit inséraient un vecteur de remplacement, et ces deux choix nuisaient à la qualité de la recherche.

Milvus 3.0 prend en charge la valeur NULL sur les champs vectoriels pour les six types de vecteurs. La recherche ignore automatiquement les vecteurs NULL, la qualité de la recherche n’en est pas affectée et les vecteurs NULL ne prennent pratiquement pas de place en stockage. L’ AddField s s’étend également aux champs vectoriels dans le cadre de cette modification : grâce à l’ nullable=True, une collection existante peut ajouter de nouveaux champs vectoriels en ligne sans avoir à être reconstruite.

Pour plus d’informations, consultez la section « Champs pouvant prendre la valeur NULL ».

Dictionnaire personnalisé et dictionnaire de synonymes

Les tokenizers prêts à l’emploi ne répondent pas toujours aux exigences de qualité de recherche en production. Le chinois, les domaines verticaux tels que la médecine, le droit et la chimie, ainsi que les corpus multilingues peuvent tirer un avantage considérable des dictionnaires personnalisés et des tables de synonymes. Jusqu’à présent, ces ressources se présentaient principalement sous la forme de réécritures de requêtes côté application.

Milvus 3.0 ajoute un mécanisme FileResource permettant d’enregistrer des dictionnaires de tokeniseurs personnalisés, des listes de synonymes, des listes de mots vides et des règles de décomposition des mots composés. Une fois enregistrée, une ressource peut être référencée depuis n’importe quel tokenizer ou filtre et s’applique à BM25, aux analyseurs et à Text Match. Les dictionnaires et les synonymes peuvent désormais faire l’objet d’un contrôle de version et être gérés de manière centralisée, au lieu d’être dispersés dans le code de l’application.

Pour plus d’informations, consultez la section « Gérer les ressources de fichiers ».

Durée de vie (TTL) des entités

Les durées de vie (TTL) au niveau de la collection et au niveau de la partition sont trop grossières pour de nombreux scénarios de cycle de vie et de conformité. Différents locataires au sein d’une même collection ont souvent des règles de conservation différentes, et certaines entités peuvent devoir expirer selon un calendrier qui ne correspond pas à celui du reste de la collection.

Milvus 3.0 prend en charge le TTL par entité. Déclarez un champ « TIMESTAMPTZ » dans le schéma, marquez-le comme champ TTL via une propriété de collection, et Milvus récupère automatiquement les entités expirées. Cela couvre les demandes relatives au « droit à l’oubli », l’expiration des données de session et l’historique des conversations limité, sans nécessiter de nettoyage côté application.

Pour plus d’informations, consultez la section « Définir la durée de vie (TTL) au niveau de l’entité ».

MinHash DIDO (Doc-in, Doc-out)

Milvus 2.6 a ajouté l’index « MINHASH_LSH » pour la détection des quasi-duplicatas basée sur des ensembles, mais les applications devaient toujours calculer les signatures MinHash avant d’écrire les données dans Milvus.

Milvus 3.0 ajoute une fonction MinHash côté serveur. Déclarez un champ d’entrée « VARCHAR » et un champ de sortie « BINARY_VECTOR » dans le schéma, associez-y une fonction « FunctionType.MINHASH », et Milvus calcule les signatures lors de l’insertion, de l’insertion en masse et de la recherche. Associée à la fonction « MINHASH_LSH », cette fonctionnalité prend en charge les workflows de déduplication pour les grands ensembles de données, la création d’empreintes numériques et la détection de plagiat au sein de Milvus.

Pour plus d’informations, consultez la section Fonction MinHash.

EmbList + DISKANN

L’hypothèse « une entité = un vecteur » ne correspond plus aux techniques modernes de recherche. Les longs documents sont fractionnés en plusieurs segments, les modèles à interaction tardive tels que ColBERT génèrent un vecteur par token, et les entités multimodales peuvent comporter plusieurs vues.

EmbList stocke une liste de vecteurs de longueur variable par entité, avec « DISKANN » comme index sur disque. Le chemin d’accès au disque permet de maîtriser l’utilisation de la RAM lorsque le corpus dépasse les limites de mémoire. EmbList + « DISKANN » est la première variante de la famille plus large StructList dans cette version RC. Le reste de la famille, notamment le filtrage StructList et l’accélération multivectorielle Muvera / Lemur, est prévu pour la version officielle 3.0.

Pour plus d’informations, consultez la section « Recherche avec des listes d’embeddings ».

Fusion forcée

Les charges de travail en production accumulent au fil du temps une fragmentation des segments, ce qui entraîne une instabilité de la latence des requêtes et une augmentation de l’espace de stockage.

Milvus 3.0 ajoute la possibilité de déclencher explicitement la compaction des segments pendant les périodes creuses, aussi bien en mode synchrone qu’asynchrone.

Pour plus d’informations, consultez la section « Compactage par fusion forcée ».

Stockage V3

Milvus 3.0 introduit Storage V3, un moteur de stockage en colonnes basé sur des manifestes, dans lequel les données et les métadonnées résident sur un stockage objet compatible S3. Chaque version d’un ensemble de données est capturée sous la forme d’un instantané de manifeste immuable, un fichier encodé en Avro qui enregistre les groupes de colonnes, les journaux delta et les statistiques composant l’ensemble de données.

Les manifestes sont des fichiers Avro compacts, et les journaux delta enregistrent les suppressions au niveau des entités sans réécrire les fichiers de données. Cela permet de maintenir une faible surcharge de métadonnées à mesure que les ensembles de données s’étoffent. Le manifeste dissocie également le suivi des métadonnées du chemin de requête, ce qui permet à une collection de gérer davantage de segments sans dégrader les performances des requêtes.

Les états étant stockés sur un stockage objet, le jeu de données est autodescriptif : tout lecteur ayant accès au chemin de stockage peut le découvrir et l’interpréter sans avoir besoin d’un catalogue central. Cette propriété est à la base des intégrations avec les collections externes, les instantanés et les futurs lacs de données.