Notas de la versión

¡Descubre las novedades de Milvus! En esta página se resumen las nuevas funciones, las mejoras, los problemas conocidos y las correcciones de errores de cada versión. Te recomendamos que visites esta página con regularidad para estar al tanto de las actualizaciones.

v3.0.2

Fecha de lanzamiento: 20 de septiembre de 2026

Versión de Milvus	Versión del SDK de Python	Versión del SDK de Node.js	Versión del SDK de Java	Versión del SDK de Go
3.0.2	3.0.2	3.0.6	3.0.10	3.0.2

¡Nos complace anunciar el lanzamiento de Milvus v3.0.2! Esta versión se centra en el rendimiento de las búsquedas y consultas —eliminando la contienda en las rutas más transitadas en las búsquedas filtradas, las agrupaciones y la creación de índices—, junto con una mayor compatibilidad con colecciones externas y Storage V2, y un amplio conjunto de correcciones de estabilidad en las áreas de transmisión, compactación y gestión de índices.

Mejoras

• Se ha optimizado el filtrado ARRAY fusionando los predicados «contains» encadenados en una única expresión « ContainsAny » / «ContainsAll » en el planificador de consultas (#52365)
• Se ha añadido compatibilidad con puntos finales personalizados compatibles con S3 en colecciones externas mediante la opción « extfs.endpoint_url », con validación de configuraciones de puntos finales inseguras o conflictivas (#52814)
• Se han unificado los filtros de pertenencia Bloom y Roaring en una única expresión membership_match, con la correspondiente compatibilidad del cliente Go para crear y consultar ambos tipos de filtro (#53019)
• Se ha reducido la amplificación de escritura durante la creación de índices basados en Tantivy, lo que disminuye la E/S de disco para los índices de coincidencia de texto, NGRAM y estadísticas de claves JSON (#53057)
• Se ha añadido un control de admisión en los puntos finales DQL RESTful v2 que devuelve un código de estado HTTP 429 con « Retry-After » antes de la decodificación de la solicitud cuando la cola de consultas del proxy está llena (#53111)
• Se ha reducido un punto crítico de recuento de referencias atómico en la ruta de evaluación de filtros escalares que representaba aproximadamente el 48 % del tiempo de CPU de las hojas en las búsquedas, lo que ha mejorado el rendimiento de las búsquedas filtradas (#53167)
• Se ha mejorado la escalabilidad del grupo de subprocesos de almacenamiento sustituyendo la implementación personalizada por « folly::CPUThreadPoolExecutor » y restableciendo el escalado elástico de los trabajadores (#53184)
• Se ha mejorado la coincidencia de los registros de acceso REST, de modo que los formateadores se comparan con la ruta de la URL analizada, y los métodos configurados ahora se aplican a las solicitudes que llevan parámetros de consulta (#53147)
• Se ha añadido compatibilidad con la difusión idempotente, de modo que las solicitudes reintentadas ya no crean tareas duplicadas, siendo BulkImport el primero en adoptarla (#53228)
• Se han añadido caracteres configurables de separación de frases para el tokenizador Lindera, lo que permite que las entradas del diccionario de usuario que contengan signos de puntuación se coincidan como un único token (#53287)
• Se ha añadido un control de versión del clúster que habilita automáticamente la materialización de funciones «write-before» solo después de que todos los nodos hayan finalizado la actualización, evitando así la inconsistencia por versiones mixtas durante las actualizaciones progresivas (#53261)
• Se ha actualizado Woodpecker a la versión v0.1.42, corrigiendo los fallos de recuperación de WAL en segmentos vacíos finalizados y mejorando la estabilidad y las métricas de la ruta de anexión (#53295).
• Se ha reducido la sobrecarga atómica y de recuento de referencias por fragmento en la ruta principal de búsqueda y consulta, fijando una instantánea del segmento sellado una vez por solicitud (#53301)
• Se ha mejorado la latencia de las actualizaciones parciales sustituyendo las esperas de TimeTick por un bloqueo optimista basado en instantáneas, y se ha perfeccionado el manejo de AutoID para que se conserven las claves primarias existentes y los ID devueltos mantengan el orden de entrada (#53337).
• Se ha reducido la construcción redundante de vistas de filas al agrupar resultados de búsqueda por campos VARCHAR o JSON en segmentos sellados, lo que reduce la sobrecarga de las búsquedas agrupadas (#53500)
• Se ha añadido una API de cumplimiento que informa de la convergencia de la configuración de carga a nivel global y por grupo de recursos, abarcando la operatividad de las réplicas, la visibilidad de las consultas, los recursos residuales y la ubicación del WAL (n.º 53517)

Correcciones de errores

• Se ha corregido un problema por el que las consultas podían devolver resultados incorrectos después de eliminar y volver a añadir un campo de matriz de estructuras (#52921)
• Se han corregido los errores de autenticación SASL/SCRAM-SHA-256 al conectarse a brokers de Apache Kafka 4.x mediante la actualización de librdkafka a la versión 2.6.1 (#53086)
• Se ha corregido un problema por el que todos los canales de una réplica se asignaban a un único nodo de consulta, lo que provocaba repetidas interrupciones por falta de memoria y dejaba la réplica inoperativa (#53094)
• Se ha corregido el «fencing» repetido de WAL que bloqueaba las escrituras en un PChannel durante 45-60 segundos cada pocos minutos bajo una ingesta sostenida (#53118)
• Se ha corregido un error por el que la compactación de Storage V2 eliminaba rutas de grupo físicas válidas, lo que podía desalinear los índices de columnas empaquetadas en los segmentos compactados (#53202)
• Se ha corregido un error por el que los registros de compactación mostraban claves de cifrado de la colección y credenciales de almacenamiento de objetos (#53226).
• Se ha corregido un problema con alias de desplazamiento de matrices de estructuras obsoletas que podían mostrar datos incorrectos tras la reapertura de un segmento sellado (#53154)
• Se ha corregido un error por el que la sincronización de recursos de archivo se ejecutaba antes de que se añadiera ningún recurso, lo que podía borrar los archivos locales del nodo al inicio o al registrar el nodo (#53170)
• Se ha corregido un problema por el que un fragmento de binlog incompleto podía tratarse de forma silenciosa como si se hubiera leído por completo, con el riesgo de que faltaran datos en los resultados de las consultas y la compactación (#53263)
• Se ha corregido un problema por el que el almacenamiento de los segmentos eliminados nunca se recuperaba para colecciones sin ningún índice activo (#53252)
• Se ha corregido una estimación inexacta de los recursos al cargar índices vectoriales dispersos, lo que podía provocar un manejo incorrecto de los datos sin procesar y advertencias repetidas en QueryNode (#53249)
• Se ha corregido un problema por el que un nodo de streaming congelado fuera del grupo de recursos principal podía descongelarse inesperadamente durante el reequilibrio (#53229)
• Se ha corregido un error de conexión a Google Cloud Storage cuando las credenciales de GCP (IAM y HMAC) no se habían registrado antes de la comprobación previa del gestor de fragmentos (#53288)
• Se ha corregido un problema por el que los registros de C++ se escribían inesperadamente en el directorio « /tmp » en lugar de reenviarse a la salida de registros unificada (#53293)
• Se ha corregido un error por el que las confirmaciones de relleno fallaban con un error HTTP 500 cuando un resultado de Spark abarcaba varias particiones (#53346)
• Se ha corregido una fuga de memoria en DataNode en la que una tarea de creación de índices o de análisis cancelada nunca liberaba la memoria nativa del objeto que ya había creado (#53348)
• Se ha corregido un problema por el que la importación de binlog fallaba cuando un campo vectorial nulo no tenía archivos binlog (#53363)
• Se han corregido campos de salida incompletos o incorrectos cuando las solicitudes de búsqueda y consulta leían datos de tablas externas (#53372, #53385)
• Se han corregido las filas de vectores dispersos y los ID de partición duplicados en las solicitudes REST, además de problemas de propiedad y limpieza de memoria que podían provocar fallos o fugas cuando las consultas finalizaban prematuramente (#53402)
• Se ha corregido un problema por el que una compactación que informaba de su finalización sin una carga útil de resultados podía provocar un fallo de DataCoord o dejar la tarea de compactación atascada en lugar de reintentarse correctamente (#53443)
• Se ha corregido un problema por el que se perdían las propiedades de los archivos de datos externos al crear manifiestos de segmentos, lo que provocaba que las colecciones externas perdieran los metadatos de los archivos de origen (#53444)
• Se ha corregido un fallo de QueryNode que podía producirse al gestionar solicitudes de tipo « count(*) » en el nivel de registro de depuración, especialmente durante las actualizaciones progresivas (#53474)
• Se ha corregido un problema por el que las tareas de creación de índices y estadísticas seguían consumiendo recursos de los trabajadores después de que su segmento, índice o colección se hubieran eliminado, y se ha mejorado la limpieza de los archivos de índice huérfanos (#53515)
• Se ha corregido la gestión de las rutas de almacenamiento local para que los datos escritos por diferentes componentes siempre se guarden donde los lectores y la recolección de basura esperan, con una actualización automática para las implementaciones locales existentes (#53530)
• Se ha corregido el problema por el que las tareas de creación de índices reintentaban indefinidamente cuando un segmento contenía documentos JSON mal formados; ahora, dichas creaciones fallan rápidamente en lugar de consumir recursos de los trabajadores indefinidamente (#53531)
• Se ha corregido el problema de las restauraciones simultáneas de instantáneas dirigidas a la misma colección: ahora las restauraciones se serializan y una restauración a un destino ya existente se rechaza con un error claro del tipo «ya existe en la base de datos», en lugar de provocar conflictos de acceso o fugas de recursos (#53586).
• Se ha corregido la corrupción de las claves de cifrado binario en las interfaces de almacenamiento y la desalineación de los cursores en los lectores empaquetados de Storage V2 proyectados mediante la actualización de milvus-storage (#53569)

v3.0.1

Fecha de lanzamiento: 9 de septiembre de 2026

Versión de Milvus	Versión del SDK de Python	Versión del SDK de Node.js	Versión del SDK de Java	Versión del SDK de Go
3.0.1	3.0.1	3.0.5	3.0.9	3.0.1

¡Nos complace anunciar el lanzamiento de Milvus v3.0.1! Esta versión incorpora la gestión de instantáneas REST v2, capacidades ampliadas de reordenación y compatibilidad con el campo TEXT en el cliente Go y la API RESTful, además de mejoras de rendimiento y correcciones relacionadas con Storage V3, la consistencia de los datos y la seguridad.

Mejoras en las funcionalidades

• Se han añadido API REST v2 para la gestión nativa de instantáneas en el ámbito de la colección y la restauración asíncrona (#52118, #52172)
• Se ha añadido un umbral configurable para el recuento de resultados con el fin de controlar la selección de la ruta de salida de «Take» para operaciones de búsqueda y consulta (#52437)
• Se ha añadido compatibilidad con campos TEXT en el cliente Go y la API RESTful (#52450)
• Se han añadido tasas de IOPS de lectura iniciales y máximas configurables para las tablas externas (#52503)
• Se ha añadido una configuración opcional para que los trabajos de actualización de colecciones externas esperen hasta que todos los segmentos estén indexados antes de informar de la finalización, sin retrasar la publicación de datos (#52712)
• Se ha añadido compatibilidad con la reordenación L1 a las cadenas de funciones de búsqueda (#52745)
• Se ha añadido la reordenación ponderada de RRF con ponderaciones opcionales por solicitud ANN en FunctionScore, REST, la búsqueda híbrida heredada y el cliente Go (#52891, #52926)

Mejoras de estabilidad

• Se ha mejorado la seguridad de la memoria en los índices y cachés RTree de geometría, así como el tratamiento de consultas WKB no analizables y de geometría vacía (#51312)
• Se ha mejorado la gestión de la memoria restaurando la asignación de memoria transitoria en todo el proceso y corrigiendo las estimaciones de memoria para la carga simultánea de campos de Storage V2/V3 y la carga de índices escalares V3 (#51405)
• Reducción de los cuellos de botella en la descarga y del uso de memoria durante la creación de índices de colecciones externas mediante la paralelización de las lecturas y la transmisión de datos vectoriales sin procesar al disco (#51651)
• Se ha mejorado el rendimiento de Woodpecker para cargas de trabajo de lotes pequeños y alta concurrencia mediante la agrupación en lotes de las adiciones de los clientes y la exposición de los ajustes de sincronización (#51810)
• Se ha mejorado la propiedad del lector de registros y la consistencia a lo largo de su ciclo de vida, el manejo de blobs vacíos y la notificación de errores de lectura en las rutas de almacenamiento y compactación (#51891)
• Se ha mejorado la eficiencia de la sonda de hash de agrupación mediante un canal entrelazado de cuatro vías y medidas de protección contra colisiones y límites de re-hash (#51977)
• Reducción de la sobrecarga de procesamiento de inserciones al omitir el análisis del cuerpo de la inserción en el WAL para colecciones sin campos de salida BM25 o MinHash (#51986)
• Se ha mejorado la notificación de fallos de almacenamiento y la gestión de reintentos conservando las clasificaciones de errores transitorios y permanentes en todas las capas de ejecución (#51990)
• Se ha mejorado el rendimiento de las consultas espaciales al habilitar de forma predeterminada la división en niveles gruesos y refinados de GIS y la fusión de predicados en la misma columna (#52008)
• Se ha mejorado la programación de tareas de indexación de texto y fragmentación de JSON mediante un control de admisión basado en una cola de trabajo compartida y una prioridad de envío alterna (#52010)
• Se ha añadido compatibilidad con mmap para las asignaciones de desplazamiento de segmentos sellados, con opciones de carga específicas y contabilidad de recursos de disco (#52035)
• Se ha optimizado la carga de datos de Storage V2 mediante la ejecución bajo demanda de estimaciones de memoria por fragmentos por columna (#52037)
• Se ha añadido compatibilidad con AutoIndex del lado del servidor para índices vinculados a campos de salida de nuevas funciones, lo que permite que las solicitudes add_function_field omitan los parámetros de índice o especifiquen AUTOINDEX (#52109)
• Se han reducido las cargas útiles de los informes de distribución de QueryNode mediante la generación incremental de informes con un informe completo como alternativa, y se han reducido las asignaciones de memoria durante la recopilación de métricas (#52111, #52119)
• Se ha mejorado la solidez del hash de contraseñas aumentando el coste de bcrypt de 4 a 10; para actualizar los hashes existentes es necesaria la rotación de credenciales (#52145)
• Se ha reducido la decodificación redundante durante las importaciones de Parquet leyendo únicamente las columnas de hoja necesarias para los subcampos de las matrices de estructuras (#52224)
• Se ha mejorado la agrupación de fusiones forzadas mediante una planificación basada en el tamaño en varias rondas y se ha dejado de utilizar la configuración heredada del umbral de planificación (#52242).
• Se ha actualizado cgosymbolizer para evitar que los procesos de Milvus que se ejecutan como PID 1 se cuelguen tras fallos nativos (#52299)
• Se ha mejorado la validación del recuento de filas para las entradas de resaltado semántico (#52409)
• Se ha mejorado el control de reintentos de importación con un retardo configurable para los reintentos de escritura (#52414, #52415, #52427)
• Se ha mejorado la gestión del ciclo de vida de las tareas de análisis mediante la recuperación de versiones de estadísticas obsoletas y la persistencia de los estados finales (#52416, #52417)
• Se ha mejorado la coordinación del ciclo de vida de los segmentos mediante la espera de la liberación del segmento tras los tiempos de espera de bloqueo (#52422)
• Se ha mejorado la clasificación del almacenamiento para la compactación de datos mediante una fusión de k vías (#52429)
• Se ha reducido la expansión del búfer de validez de los campos nulos conservando las máscaras empaquetadas en el acceso a fragmentos, la evaluación de expresiones y las estadísticas JSON (#52451)
• Se ha mejorado la protección de credenciales confidenciales, claves de API, hash de contraseñas RBAC y detalles de fuentes de recopilación externas, evitando su exposición en registros o mensajes de error (#52487, #52664, #52710)
• Se ha mejorado el control de concurrencia de actualizaciones parciales mediante la validación CAS optimista y reintentos seguros para los conflictos admisibles (#52495)
• Se ha mejorado la estabilidad de las instantáneas de lectura de segmentos en crecimiento y la gestión de la vida útil de las instantáneas de esquemas (#52572)
• Reducción de los escaneos redundantes de metadatos de autorización durante las copias de seguridad (#52612)
• Se ha mejorado la asignación de ID de vectores nulos trasladándola a la capa de índices, unificando la gestión de los ID lógicos y admitiendo asignaciones respaldadas por mmap para índices sellados (#52657)
• Se ha mejorado la sincronización entre la compilación JIT de Sonic y la carga de complementos de Go en las compilaciones para CPU y GPU (#52738)
• Se ha mejorado la resolución de canales de la ruta de escritura del proxy a través de la caché de metadatos, lo que elimina las llamadas RPC redundantes al coordinador y mejora la clasificación de errores (#52739)
• Se ha reducido el tiempo de cálculo de la recuperación de aproximadamente 3,08 segundos a 18,5 milisegundos con topk=100 000 en la prueba de rendimiento indicada (#52763)
• Se ha optimizado el filtrado de campos nulos reutilizando mapas de bits de validez, reduciendo el almacenamiento redundante de desplazamientos nulos y acelerando las copias de conjuntos de bits (#52801, #52823, #52825)
• Se han mejorado los índices escalares híbridos en subcampos de estructuras anidadas mediante el uso de STL_SORT cuando el recuento de elementos distintos alcanza el límite de cardinalidad del mapa de bits (#52849)
• Se ha mejorado la eficiencia del filtrado de ID de segmentos en la caché de metadatos (#52855)
• Se han reducido las asignaciones de memoria en las funciones auxiliares de hash (#52857).
• Se ha optimizado la ordenación de los resultados de reordenación fusionados eliminando las consultas al mapa por cada comparación (#52885)
• Se ha mejorado la seguridad de la memoria al gestionar valores predeterminados de JSON y vistas de cadenas no terminadas en NUL (#52906)
• Se han mejorado los tiempos de compilación en C++ mediante la compilación unificada con ámbito, se ha mejorado el almacenamiento en caché del compilador y se ha reducido el trabajo de compilación redundante (#52995)
• Se ha mejorado la cobertura y la actualidad de las métricas del sistema de archivos mediante la recopilación de métricas de los sistemas de archivos almacenados en caché en el momento del rastreo, conservando al mismo tiempo los nombres y etiquetas de las métricas existentes (#53026)
• Se ha añadido el parámetro «growingBuildThreadRate», que se puede actualizar, para configurar el número de subprocesos por segmento creciente durante la compilación del índice provisional, conservando al mismo tiempo el valor predeterminado de un solo subproceso (#53033)
• Se ha añadido compatibilidad con la reescritura de datos de campo mmap a la versión 3.0 mediante un backport, con la opción queryNode.mmap.writeback desactivada por defecto (#53079)

Corrección de errores

• Se han corregido resultados incorrectos y una validación inconsistente de predicados en consultas JSON, ARRAY y TIMESTAMPTZ, incluyendo predicados de tipos mixtos, comparaciones de números grandes y filtrado a través de varios lotes (#51775)
• Se ha corregido la inconsistencia en la actualización de datos durante las actualizaciones paralelas de colecciones externas cuando los archivos de origen de un segmento abarcaban varias tareas (#51893)
• Se ha corregido el hecho de que las expresiones MATCH aceptaran predicados que no operaban a nivel de elemento (#51940)
• Se ha corregido el error por el que las búsquedas sin coincidencias fallaban con un error de tipo de ID no compatible (#51999).
• Se ha corregido el bloqueo de Milvus autónomo durante el apagado añadiendo un tiempo de espera de migración configurable con un valor predeterminado de 10 segundos (#52027)
• Se ha corregido un error por el que las solicitudes de incrustación de tablas externas utilizaban una identidad de clúster incorrecta cuando los trabajadores de DataNode se compartían entre clústeres de servicio (#52042)
• Se ha corregido un problema que impedía actualizar integration_id y model_deployment_id para las funciones TextEmbedding (#52081)
• Se ha corregido el hecho de que las respuestas HTTP JSON omitieran el estado explícito «ok=false» para los segmentos de rellenado fallidos (#52082)
• Se ha corregido el error en las cargas de objetos MinIO que fallaban con el código HTTP 400 XAmzContentChecksumMismatch al reintentarse tras tiempos de espera de transporte o de baja velocidad (#52128, #52194)
• Se ha corregido el bloqueo del equilibrio de segmentos entre QueryNodes cuando el servicio de streaming estaba habilitado (#52147, #52169)
• Se ha corregido la pérdida silenciosa de datos durante la compactación mixta cuando no se podían reconstruir los registros retenidos (#52200)
• Se ha corregido un error por el que las restauraciones de instantáneas perdían la configuración de las colecciones y, de forma inesperada, se establecían por defecto en «consistencia fuerte» (#52206)
• Se ha corregido un error por el que las eliminaciones en streaming omitían los segmentos sellados recién cargados, lo que permitía que los datos eliminados siguieran siendo consultables (#52218)
• Se ha corregido un error por el que los índices anidados no se creaban correctamente para datos vacíos (#52247)
• Se han corregido los interbloqueos al cambiar al servicio de streaming que dejaban las operaciones en espera indefinidamente (#52292)
• Se ha corregido el uso de valores predeterminados de geometría incorrectos durante la compactación y la reconstrucción de registros, así como el marcado incorrecto como nulos de los valores de geometría rellenados por defecto en las importaciones de Parquet (#52350)
• Se ha corregido el rechazo de segmentos V3 válidos durante la compactación y la recuperación tras un reinicio de DataCoord (#52383, #52389, #52390, #52391, #52392, #52393)
• Se han corregido los errores de carga de segmentos debidos a la falta de metadatos de versión al utilizar índices escalares híbridos en subcampos de matriz VARCHAR en estructuras (#52385)
• Se ha corregido el fallo en la actualización de las columnas externas al reabrir un manifiesto actualizado (#52397)
• Se ha corregido el tratamiento incorrecto de la zona horaria en búsquedas con condiciones dependientes del tiempo (#52407)
• Se ha corregido el tratamiento incorrecto de las entradas ArrayOfVector en las solicitudes de búsqueda (#52408)
• Se ha corregido el fallo en las inserciones que no rechazaban las filas que superaban el límite de tamaño admitido (#52426)
• Se ha corregido el problema por el que los índices provisionales ignoraban la versión de índice de destino configurada (#52449)
• Se ha corregido el error por el que las consultas que utilizaban «order_by» no devolvían campos de salida de vectores densos (#52504, #52606)
• Se ha corregido el problema por el que los privilegios revocados seguían vigentes tras ser eliminados de un grupo de privilegios (#52554)
• Se ha corregido el recuento incorrecto de archivos binlog y las etiquetas de formato de almacenamiento para los segmentos de Storage V3 tras el reinicio de DataCoord (#52571, #52578)
• Se ha corregido el bloqueo de las restauraciones de instantáneas externas debido a comprobaciones poco fiables de la versión de los trabajadores o a reintentos repetidos de trabajadores no compatibles hasta que se agotaba el tiempo de espera (#52639)
• Se ha corregido el error de carga de segmentos para índices HYBRID en subcampos de matrices de estructuras con archivos STLSORT heredados de la versión 3.0.0, sin necesidad de reindexar (#52643)
• Se han corregido los bloqueos al procesar búferes de datos Arrow C de longitud cero (#52652)
• Se ha corregido un error en la gestión de fallos al cargar o reabrir segmentos de Storage V3 tras errores en el manifiesto, conservando el estado actual del segmento para realizar reintentos seguros (n.º 52678)
• Se han corregido los errores de consulta cuando los filtros de elementos ARRAY encontraban lotes completos de NULL o matrices vacías antes de los elementos posteriores (#52720)
• Se han corregido los trabajos de relleno que confirmaban incrustaciones obsoletas tras un cambio en el esquema de la colección (#52789)
• Se ha corregido el problema por el que los campos ausentes en los registros de Storage V3 se devolvían como NULL en lugar de sus valores predeterminados declarados (#52790, #52807, #52888)
• Se han corregido los errores de copia del lado del servidor que impedían la restauración de instantáneas de Storage V3 en GCS con credenciales de IAM/OAuth, incluidas las copias de objetos de más de 5 GiB (#52792)
• Se ha corregido el acceso no autenticado a través de llamadas gRPC en streaming en el puerto del proxy externo (#52854)
• Se ha corregido la pérdida de las marcas de tiempo de confirmación originales de los datos tras la compactación en clúster (#52859)
• Se han corregido los bloqueos de los nodos de streaming causados por fallos repetidos en el vaciado tras añadir un campo TEXT a colecciones con segmentos existentes de Storage V2 (n.º 52897).
• Se ha corregido el problema por el que las filas caducadas en segmentos de Storage V3 no activaban la compactación basada en el campo TTL y permanecían almacenadas hasta que se cumplía otra condición de compactación (#52931)
• Se ha corregido la inconsistencia en las claves primarias generadas automáticamente entre las colecciones de origen y destino durante las importaciones replicadas mediante CDC (n.º 52941).
• Se ha corregido la pérdida de escrituras simultáneas durante la migración del backend de WAL (#52947, #52951, #52955)
• Se ha corregido el problema por el que los índices HYBRID anidados, reconstruidos o compactados con datos de alta cardinalidad, se volvían ilegibles tras revertir a una versión anterior (#52959)
• Se ha corregido el tratamiento de los elementos nulos en filas de vectores densos externos, aceptando filas nulas totalmente nulas y añadiendo un tratamiento configurable de las filas parcialmente nulas (#52968)
• Se ha corregido el recuento incorrecto de filas de segmentos V3 y los fallos repetidos de compactación por ordenación tras la conmutación por error de un nodo de streaming (#52970)
• Se ha corregido el problema por el que las consultas que combinaban condiciones de rango con «OR» omitían registros en el límite inferior inclusivo (#52998)
• Se ha corregido un error en las búsquedas por clave primaria que impedía conservar el orden de ID solicitado (#52999)
• Se ha corregido un problema por el que añadir un campo TEXT tras habilitar Storage V3 impedía la carga de segmentos de Storage V2 existentes en crecimiento, lo que interrumpía las operaciones de vaciado, ordenación e indexación (#53002)
• Se ha corregido un problema por el que las instantáneas incluían segmentos de Storage V3 no confirmados, lo que provocaba que las restauraciones se marcaran como exitosas aunque los segmentos restaurados no se pudieran cargar (#53022, #53039)
• Se ha corregido un error por el que los índices de texto de Storage V3 no se cargaban cuando sus archivos se almacenaban en directorios anidados de tareas o versiones (#53062)

v3.0.0

Fecha de lanzamiento: 29 de julio de 2026

Versión de Milvus	Versión del SDK de Python	Versión del SDK de Node.js	Versión del SDK de Java	Versión del SDK de Go
3.0.0	3.0.1	3.0.3	3.0.5	3.0.0

¡Ya está disponible oficialmente Milvus 3.0.0! Basándose en la arquitectura «lake-native» introducida en la versión 3.0-beta, esta versión completa lo que la beta inició: External Collection abarca más flujos de trabajo de «lakehouse»; el esquema admite la adición, el rellenado y la eliminación en línea; el índice disperso se ha reconstruido en torno a SINDI; StructArray y la búsqueda por facetas completan el motor de recuperación; el paso directo de FAISS y TEXT amplían las opciones de índice y modalidad; y Woodpecker se ejecuta como un servicio independiente.

Mira el vídeo a continuación para obtener más información sobre Milvus 3.0 y participa en la sesión de preguntas y respuestas (AMA) con los responsables del mantenimiento del núcleo:

Si eres nuevo en la línea 3.0, la sección «Resumen de las características principales de la versión 3.0» que aparece a continuación resume las capacidades introducidas en la versión 3.0-beta; las notas de la versión 3.0-beta contienen la información completa.

Novedades de la versión 3.0.0 (desde la 3.0-beta)

Colección externa: flujos de trabajo de «lakehouse» más completos

La versión 3.0-beta introdujo la «Colección externa»: permite hacer referencia a archivos de «lakehouse» in situ, crear índices y realizar búsquedas en ellos sin copiar los datos a Milvus. Esta versión amplía esta funcionalidad hacia flujos de trabajo completos de recuperación en «lakehouse». Los campos externos ahora pueden alimentar campos de salida de funciones, como vectores dispersos BM25, firmas MinHash e incrustaciones de texto, de modo que los campos de recuperación de texto y derivados de modelos se crean dentro de Milvus sin copiar la tabla de origen. Refresh también admite la evolución aditiva de esquemas: cuando la tabla externa incorpora nuevas columnas, Milvus actualiza los segmentos afectados en lugar de reconstruir la colección.

Esta versión también añade un formato externo « milvus-table » que trata los metadatos de Milvus Snapshot y los manifiestos de Storage V3 como una fuente externa, de modo que una instantánea de la colección puede servirla como tabla externa: los sistemas de procesamiento por lotes y de servicio obtienen una vista compartida, respaldada por el manifiesto, de los mismos datos.

Para obtener más información, consulta «Crear una colección externa y instantáneas».

Esquema flexible: añadir, rellenar y eliminar columnas en línea

Los esquemas no permanecen estáticos en producción —los modelos incrustados se sustituyen, las características se actualizan, los campos quedan obsoletos— y esto solía implicar reconstrucciones completas de la colección con tiempo de inactividad o escrituras duplicadas. La versión 3.0.0 cierra el círculo: se pueden añadir, rellenar y eliminar columnas mientras continúa el servicio.

El rellenado funciona en ambas direcciones. El rellenado externo gestiona valores calculados fuera de Milvus: añade una columna, realiza una instantánea de la colección como punto de partida coherente, ejecuta el trabajo sin conexión, vuelve a escribir los valores y Milvus indexa la nueva columna de forma incremental; así, una actualización del modelo de incrustación en cientos de millones de filas se convierte en una ruta activa sin tiempo de inactividad. El rellenado interno cubre los valores derivados del núcleo: al asociar una función BM25 o MinHash a una colección existente, su campo de salida se calcula automáticamente a partir de los datos existentes.

Para obtener más información, consulta «Añadir campos a una colección existente».

Revisión del índice disperso: SINDI, Block-Max WAND y Block-Max MaxScore

Milvus 3.0 actualiza el índice de vectores dispersos en todos los aspectos. Introduce nuevos algoritmos de búsqueda —SINDI, Block-Max WAND y Block-Max MaxScore— junto con la compresión de listas invertidas, la cuantificación configurable y la selección del algoritmo de búsqueda por carga de trabajo. También se han optimizado la carga mediante mmap, la serialización y la puntuación BM25, lo que reduce el almacenamiento del índice y la sobrecarga de carga para la búsqueda de vectores dispersos y de texto completo a gran escala. En pruebas de rendimiento internas, el índice BM25 comprimido es aproximadamente tres veces más pequeño que el índice disperso 2.6 con una recuperación comparable, y SINDI alcanza hasta unas 10 veces el QPS de MaxScore en incrustaciones dispersas aprendidas. Una vez habilitada la nueva versión del índice (véanse las notas sobre compatibilidad y comportamiento), SINDI es la opción predeterminada para la búsqueda de IP dispersa, y MaxScore es la opción predeterminada para BM25.

Cobertura de StructArray

StructArray ahora admite valores nulos, índices de mapa de bits, la adición dinámica de campos en colecciones activas y la actualización parcial de campos de estructura mediante «upsert», con la correspondiente cobertura de REST e importación masiva.

La búsqueda a nivel de elemento añade la búsqueda híbrida a través de subcampos vectoriales con colapso configurable por entidad (variantes «max», «sum», «avg» y «top-k»), además de la búsqueda por rango y la agrupación dentro de la misma. El filtrado anidado abarca los predicados « element_filter », los cuantificadores « MATCH_ANY », « MATCH_ALL », « MATCH_LEAST », « MATCH_MOST » y « MATCH_EXACT », el acceso posicional a subcampos como « tags[0][name] » y « array_length() » en la columna de estructura.

Para obtener más información, consulta StructArray y Operadores de StructArray.

Agregación de búsquedas y búsqueda por facetas

La agregación de consultas de la versión beta calcula estadísticas exactas sobre los datos filtrados; la versión 3.0.0 añade la faceta a la ruta de búsqueda. Especifica un campo de faceta en el momento de la búsqueda y Milvus devuelve los valores de faceta principales, cada uno representado por su miembro que mejor se ajusta en la clasificación ANN y anotado con agregados como COUNT y AVG — la barra lateral de búsqueda por facetas (marca, rango de precios, atributos) en una sola solicitud, en lugar de realizar una recuperación excesiva y el recuento en el lado del cliente.

Reordenación mediante la cadena de funciones

La reordenación de la clasificación ahora se puede componer a través de la API de la cadena de funciones, que ejecuta un flujo ordenado y tipado como parte de una única solicitud de búsqueda. Una cadena puede combinar la reevaluación temprana L0 en QueryNode con la reordenación L2 posterior a la reducción en Proxy, lo que permite la transformación y combinación de puntuaciones, la reordenación basada en modelos, la clasificación y la eliminación de candidatos sin necesidad de orquestación del lado del cliente. Esta versión también añade la puntuación nativa de XGBoost para la reordenación de L0 utilizando modelos UBJ registrados como FileResources, junto con los proveedores de inferencia de Hugging Face para la incrustación de texto gestionada por el servidor y la reordenación por similitud de frases.

Campos de texto largo TEXT

Los campos TEXT convierten el texto largo en contenido de primera clase, al eliminar los límites de longitud del lado del almacenamiento: admiten text_match, phrase_match y BM25. Los valores inferiores a 64 KB permanecen en línea; los valores más grandes se almacenan en archivos LOB a nivel de partición en formato Vortex, y la columna solo almacena referencias (file_id, offset). Los archivos LOB se comparten entre segmentos, por lo que la compactación mueve las referencias en lugar de reescribir el texto. Para RAG, esto significa recuperar vectores y texto fuente del mismo almacén en una sola operación de E/S, sin necesidad de utilizar un almacén de blobs externo.

Pasar el índice FAISS

Un nuevo tipo de índice « FAISS » acepta cadenas arbitrarias de la fábrica de índices Faiss a través del parámetro « faiss_index_name » — IVF64,Flat, HNSW16,Flat, OPQ16,IVF64,PQ16x4 — con los parámetros de búsqueda pasados directamente, de modo que las recetas de Faiss se reproducen directamente en Milvus.

Compatibilidad con los formatos Vortex y Lance

La capa de almacenamiento incorpora dos formatos columnares abiertos: Vortex como formato interno de próxima generación —codificaciones adaptativas (diccionario, RLE, empaquetado de bits, compresión específica para números flotantes), descompresión sin copia, optimizado para cargas de trabajo mixtas de vectores y escalares— y Lance, junto con Parquet, para el intercambio en un ecosistema abierto. Vortex está destinado a convertirse en el formato interno por defecto, con la aplicación de filtros y una variante local previstas en la hoja de ruta.

Implementación autónoma de Woodpecker

Woodpecker, el WAL que constituye el núcleo de la ruta de escritura en tiempo real, ahora puede implementarse como un servicio independiente en lugar de integrarse en otros nodos —escalabilidad independiente, aislamiento de fallos y observabilidad, como cualquier otro microservicio—. Esto es especialmente importante para clústeres de gran tamaño y cargas de trabajo con un alto volumen de escritura.

Resumen de las características principales de la versión 3.0

Las características que se indican a continuación se introdujeron en la versión 3.0-beta y forman parte de la 3.0.0; consulta las notas de la versión beta para obtener la información completa.

• Colección externa: consulta de datos de lakehouse (Parquet, Lance, Iceberg, Vortex) in situ: sin copias, de solo lectura, sincronizados mediante actualización incremental.
• Instantánea: vistas de recopilación de solo lectura en un momento determinado por referencia de segmento, con un almacenamiento marginal prácticamente nulo.
• Almacenamiento V3 (Loon): almacenamiento columnar basado en manifiestos en almacenamiento de objetos; la base para Snapshot y Colección externa.
• Consulta/Búsqueda ORDER BY: ordenación de varios campos del lado del servidor con ASC/DESC por campo.
• Agregación de consultas: COUNT / SUM / AVG / MIN / MAX con agrupación, evaluadas en el lado del servidor.
• EmbList + DiskANN: indexación multivectorial en disco para listas de incrustación StructArray, con vías de aceleración como Muvera y Lemur.
• Función MinHash (doc-in, doc-out): firmas MinHash del lado del servidor, además de « MINHASH_LSH » para la detección de casi duplicados.
• Vectores nulos — NULL en los seis tipos de vectores; la búsqueda omite las filas NULL, y AddField se extiende a los campos vectoriales.
• TTL de entidad — caducidad por fila controlada por un campo TIMESTAMPTZ.
• FileResource: diccionarios, listas de sinónimos y listas de palabras vacías gestionados por el clúster para analizadores, BM25 y Text Match.
• Fusión forzada: compactación de segmentos activada por un operador, en modo síncrono o asíncrono.

Notas sobre compatibilidad y comportamiento

• Storage V3 (Loon) está desactivado por defecto. Las funciones que dependen de él —como Snapshot y los campos TEXT— requieren activarlo manualmente a través de common.storage.useLoonFFI. Storage V3 se activará por defecto en una versión posterior.
• Se garantiza la compatibilidad y la reversión de la versión 2.6 a la 3.0: una implementación de la versión 3.0 se puede revertir a la 2.6. Sin embargo, una vez que se habiliten o utilicen funciones que modifiquen el formato de datos serializados (por ejemplo, Storage V3), ya no será posible revertir la actualización.
• Las nuevas versiones de índice son opcionales por el momento. Los algoritmos de índice recién introducidos requieren aumentar manualmente la versión de índice de destino (dataCoord.targetVecIndexVersion a 10, dataCoord.targetScalarIndexVersion a 4) antes de que surtan efecto; en una versión posterior se habilitarán de forma predeterminada.
• Las imágenes de GPU pasan a CUDA 12.9 y ya no conservan la compatibilidad con las GPU de Ubuntu 20.04.

v3.0-beta

Fecha de lanzamiento: 9 de mayo de 2026

Versión de Milvus	Versión del SDK de Python	Versión del SDK de Node.js
3.0-beta	3.0.0	3.0.0

Milvus 3.0-beta amplía la base de datos vectorial de Milvus con una nueva integración en el ecosistema de Open Lake: la función «External Collection» permite a Milvus consultar tablas externas de Open Lake sin copia, y Spark puede leer las colecciones de Milvus directamente a través de Snapshot. Esta versión también ofrece una recuperación más completa, un esquema más expresivo, una personalización más profunda de la búsqueda de texto, controles más precisos sobre el ciclo de vida de los datos y los modelos, y más controles por parte del operador. Milvus 3.0 es el núcleo central de Zilliz Lakebase, que impulsa su servicio unificado, el descubrimiento y el procesamiento por lotes.

Características principales

Colección externa

En los flujos de datos típicos de IA, ya existen terabytes de representaciones y metadatos en el almacenamiento de objetos en forma de tablas Parquet, Lance o Iceberg. Copiar esos datos a Milvus duplica el coste de almacenamiento, añade un flujo ETL que debe mantenerse sincronizado y aleja la gobernanza de los datos del cliente.

La recopilación externa elimina la necesidad de copiar. Una recopilación de Milvus puede hacer referencia a los archivos allí donde ya se encuentran, y Milvus solo gestiona el esquema, los índices y la ejecución de consultas. Una actualización incremental mantiene la colección alineada con los archivos subyacentes. Los clientes cuyos datos no pueden salir del lago de datos —como los equipos de finanzas y sanidad— pueden realizar búsquedas vectoriales en esos datos allí donde se encuentran. Un único conjunto de datos residente en el lago de datos también puede servirse desde varias instancias de Milvus a la vez.

Para obtener más información, consulta «Crear una colección externa».

Instantánea

La entrega de datos y el descubrimiento por lotes suelen necesitar la misma colección al mismo tiempo. La evaluación de modelos A/B, la deduplicación a gran escala, la validación de datos retrospectivos y la reversión de versiones requieren una vista estable de la colección mientras siguen produciéndose escrituras.

La instantánea crea una vista de una colección en un momento determinado y de solo lectura haciendo referencia a segmentos existentes en lugar de copiar datos, por lo que el coste marginal de almacenamiento es prácticamente nulo. Los trabajos por lotes pueden leer desde la instantánea bajo aislamiento de tipo MVCC mientras la colección activa sigue aceptando escrituras.

Para obtener más información, consulta «Instantáneas», «Gestión de instantáneas» y «Casos de uso de instantáneas».

Ordenación en consultas y búsquedas

La búsqueda y las consultas admiten ahora la ordenación por varios campos, con la ordenación delegada al núcleo de Milvus y la configuración de « ASC » / « DESC » por campo. Esto resuelve una deficiencia habitual en producción: la ordenación «Top-K» basada únicamente en la distancia a menudo no se ajusta a las necesidades empresariales cuando el elemento más similar no es el más barato, el más reciente ni el más popular.

Las aplicaciones ya no tienen que recuperar resultados en exceso y volver a ordenarlos en el cliente para expresar una clasificación compuesta.

Para obtener más información, consulta «Ordenar resultados de búsqueda por campos escalares » y «Ordenar resultados de consulta».

Agregación de consultas

La generación de estadísticas de distribución por inquilino, recuentos de completitud de campos o el progreso del despliegue de versiones a partir de una colección de Milvus solía requerir la recuperación de las entidades coincidentes en el cliente y su agregación allí. Milvus 3.0 integra la agregación escalar de estilo SQL en el núcleo. Una llamada de consulta admite expresiones de agregación de tipo « group_by_fields » y « output_fields », incluyendo « count(*) », « count(<field>) », « sum(<field>) », « avg(<field>) », « min(<field>) » y « max(<field>) ». La agregación se evalúa en el lado del servidor tras el filtrado.

Para obtener más información, consulte «Agregar resultados de consultas».

Vector nulo

Las representaciones suelen generarse de forma asíncrona, por lo que una entidad puede llegar antes que su vector. Los datos multimodales también presentan lagunas naturales, como un vídeo sin subtítulos o un producto sin imagen. Las versiones anteriores no ofrecían una solución adecuada: las aplicaciones retrasaban la escritura hasta que el vector estuviera listo o introducían un vector provisional, y ambas opciones perjudicaban la calidad de la recuperación.

Milvus 3.0 admite el valor NULL en los campos vectoriales de los seis tipos de vectores. La búsqueda omite automáticamente los vectores NULL, la calidad de la recuperación no se ve afectada y los vectores NULL prácticamente no ocupan espacio de almacenamiento. La función « AddField » también se extiende a los campos vectoriales con este cambio: con nullable=True, una colección existente puede ampliar sus campos vectoriales en línea sin necesidad de reconstruirla.

Para obtener más información, consulta «Campos nulos».

Diccionario personalizado y diccionario de sinónimos

Los tokenizadores predeterminados no siempre cumplen los requisitos de calidad de búsqueda en producción. El chino, los ámbitos verticales como la medicina, el derecho y la química, y los corpus multilingües pueden beneficiarse sustancialmente de los diccionarios personalizados y las tablas de sinónimos. Hasta ahora, estos recursos se gestionaban principalmente mediante reescrituras de consultas del lado de la aplicación.

Milvus 3.0 incorpora un mecanismo FileResource para registrar diccionarios personalizados de tokenizadores, listas de sinónimos, listas de palabras vacías y reglas de descomposición de compuestos. Una vez registrado, se puede hacer referencia a un recurso desde cualquier tokenizador o filtro, y surte efecto en BM25, los analizadores y Text Match. Ahora es posible versionar y gestionar de forma centralizada los diccionarios y los sinónimos, en lugar de tenerlos dispersos por el código de la aplicación.

Para obtener más información, consulta «Gestionar recursos de archivo».

TTL de entidades

El TTL a nivel de colección y de partición resulta demasiado general para muchos escenarios de ciclo de vida y cumplimiento normativo. Los distintos inquilinos dentro de una misma colección suelen tener reglas de retención diferentes, y es posible que las entidades individuales deban caducar según un calendario que no coincida con el del resto de la colección.

Milvus 3.0 admite el TTL por entidad. Basta con declarar un campo « TIMESTAMPTZ » en el esquema, marcarlo como campo de TTL mediante una propiedad de la colección, y Milvus recuperará automáticamente las entidades caducadas. Esto cubre las solicitudes del «derecho al olvido», la caducidad de los datos de sesión y el historial de conversaciones delimitado sin necesidad de limpieza por parte de la aplicación.

Para obtener más información, consulta «Establecer el TTL a nivel de entidad».

MinHash DIDO (Doc-in, Doc-out)

Milvus 2.6 añadió el índice « MINHASH_LSH » para la detección de casi duplicados basada en conjuntos, pero las aplicaciones aún tenían que calcular las firmas MinHash antes de escribir los datos en Milvus.

Milvus 3.0 incorpora una función MinHash del lado del servidor. Basta con declarar un campo de entrada « VARCHAR » y un campo de salida « BINARY_VECTOR » en el esquema, asociar una función « FunctionType.MINHASH », y Milvus calculará las firmas durante la inserción, la inserción masiva y la búsqueda. Junto con MINHASH_LSH, esto permite flujos de trabajo de deduplicación para grandes conjuntos de datos, la generación de huellas digitales y la detección de plagio dentro de Milvus.

Para obtener más información, consulta la función MinHash.

EmbList + DISKANN

La suposición de «una entidad = un vector» ya no se ajusta a la recuperación de información moderna. Los documentos largos se dividen en muchos fragmentos, los modelos de interacción tardía como ColBERT emiten un vector por token y las entidades multimodales pueden tener varias vistas.

EmbList almacena una lista de vectores de longitud variable por entidad, con DISKANN como índice en disco. La ruta de disco mantiene bajo control el uso de la RAM cuando el corpus supera los límites de memoria. EmbList + DISKANN es la primera variante de la familia más amplia de StructList en esta versión RC. El resto de la familia, incluido el filtrado de StructList y la aceleración multivectorial de Muvera / Lemur, está previsto para la versión oficial 3.0.

Para obtener más información, consulta «Búsqueda con listas de incrustación».

Fusión forzada

Las cargas de trabajo en producción acumulan fragmentación de segmentos con el tiempo, lo que provoca fluctuaciones en la latencia de las consultas y un aumento del almacenamiento.

Milvus 3.0 añade la capacidad de activar la compactación de segmentos de forma explícita durante las franjas horarias de menor actividad, tanto en modo síncrono como asíncrono.

Para obtener más información, consulta «Compactación de fusión forzada».

Almacenamiento V3

Milvus 3.0 introduce «Almacenamiento V3», un motor de almacenamiento columnar basado en manifiestos en el que los datos y los metadatos residen en un almacenamiento de objetos compatible con S3. Cada versión del conjunto de datos se captura como una instantánea de manifiesto inmutable, un archivo codificado en Avro que registra qué grupos de columnas, registros delta y estadísticas componen el conjunto de datos.

Los manifiestos son archivos Avro compactos, y los registros delta registran las eliminaciones a nivel de entidad sin reescribir los archivos de datos. Esto mantiene baja la sobrecarga de metadatos a medida que crecen los conjuntos de datos. El manifiesto también desacopla el seguimiento de metadatos de la ruta de consulta, lo que permite que una colección gestione más segmentos sin degradar el rendimiento de las consultas.

Dado que los estados se almacenan en el almacenamiento de objetos, el conjunto de datos es autodescriptivo: cualquier lector con acceso a la ruta de almacenamiento puede descubrirlo e interpretarlo sin necesidad de un catálogo central. Esta propiedad sustenta las integraciones con External Collection, Snapshot y futuros lagos de datos.