Almacenamiento V3Compatible with Milvus 3.0.x

Descripción general

Los conjuntos de datos de IA suelen evolucionar una vez creada la colección. A medida que cambian los modelos y los flujos de trabajo, es posible que los equipos necesiten añadir texto, generar nuevos campos vectoriales para entidades existentes o utilizar datos almacenados fuera de Milvus. Para dar soporte a estos flujos de trabajo se requiere un modelo de almacenamiento capaz de evolucionar junto con el conjunto de datos.

El almacenamiento V3 proporciona este modelo en Milvus 3.0. Utiliza una estructura de almacenamiento con versiones para incorporar los datos añadidos o reescritos a lo largo del tiempo, mientras que las aplicaciones siguen accediendo a las colecciones a través de las mismas API de Milvus.

El almacenamiento V3 está desactivado por defecto. Una vez que la opción « common.storage.useLoonFFI » (Habilitar almacenamiento V3) surta efecto, las nuevas escrituras y los resultados de la compactación utilizarán el almacenamiento V3. Los datos existentes permanecen en su estructura actual hasta que los datos elegibles sean reescritos mediante la compactación en segundo plano. Milvus puede leer ambas estructuras durante esta transición. Habilita el almacenamiento V3 para utilizar las funciones que dependen de él, más que como una optimización general del rendimiento.

Formatos de datos en Storage V3

Storage V3 utiliza manifiestos para describir los datos de las colecciones independientemente del formato de datos subyacente. Esto permite que la misma capa de almacenamiento funcione tanto con los datos gestionados por Milvus como con los datos que permanecen en un sistema externo.

Formatos de archivo de las colecciones gestionadas

En el caso de las colecciones gestionadas, la opción « dataNode.storage.format » selecciona el formato de archivo para los nuevos datos de Storage V3. La configuración admite los siguientes valores:

Formato	Descripción
`parquet`	El formato de archivo columnar predeterminado y ampliamente adoptado, con una amplia compatibilidad con el ecosistema y herramientas consolidadas. Parquet organiza los datos en grupos de filas y admite la codificación y compresión por columna, lo que permite a Milvus leer solo las columnas necesarias y procesar de forma eficiente grandes escaneos secuenciales.
`vortex`	Un formato de archivo columnar opcional de última generación, basado en codificaciones extensibles y combinables, y en estadísticas avanzadas. En Milvus, Vortex admite la proyección de columnas, las lecturas por rango y las lecturas de acceso aleatorio. Estas capacidades pueden reducir las lecturas de datos innecesarias en cargas de trabajo adecuadas.

Cambiar dataNode.storage.format afecta a las nuevas escrituras en Storage V3. Los archivos existentes conservan su formato actual hasta que la compactación reescriba los segmentos correspondientes. La mayoría de las implementaciones deberían mantener el formato predeterminado parquet, a menos que pruebas de rendimiento representativas demuestren que vortex se adapta mejor a sus datos y patrones de acceso.

Colecciones externas y formatos de origen compatibles

Las colecciones externas permiten a Milvus utilizar datos almacenados en archivos o tablas externos. Storage V3 admite los siguientes formatos de origen externos:

Formato	Categoría	Fuente prevista	Compatibilidad con Storage V3
`parquet`	Formato de archivo	Un directorio o prefijo de almacenamiento de objetos que contenga archivos Parquet.	Detecta los archivos, lee sus metadatos y grupos de filas, y los registra en un manifiesto de Storage V3.
`vortex`	Formato de archivo	Un directorio o prefijo de almacenamiento de objetos que contenga archivos Vortex.	Detecta los archivos y utiliza el diseño y las estadísticas de Vortex para la proyección, las lecturas por rango y las lecturas de acceso aleatorio.
`lance-table`	Formato de tabla	Un directorio de conjuntos de datos de Lance.	Lee los metadatos del conjunto de datos y asigna sus fragmentos a un manifiesto de Storage V3.
`iceberg-table`	Formato de tabla	Un archivo JSON de metadatos de Iceberg y un ID de instantánea.	Resuelve la instantánea especificada, planifica sus archivos de datos y conserva los metadatos de eliminación por posición. Las eliminaciones por igualdad no son compatibles y deben convertirse en eliminaciones por posición antes de que se actualice la colección externa.

Las fuentes externas son de solo lectura. Storage V3 crea y actualiza su propio manifiesto sin modificar ni copiar los datos de origen. A continuación, Milvus puede crear índices y realizar búsquedas y consultas sobre los datos a través de una colección externa.

Almacenamiento en la nube y autenticación entre cuentas

La siguiente tabla describe únicamente cómo una colección externa accede a los datos de origen almacenados en otra cuenta en la nube. No describe el almacenamiento de objetos utilizado para los datos gestionados por Milvus.

Almacenamiento en la nube	Formatos externos compatibles	Autenticación entre cuentas para colecciones externas
Amazon S3	Los cuatro formatos enumerados anteriormente.	Especifica el ARN del rol de IAM propiedad del cliente. Storage V3 utiliza el servicio de gestión de identidades y accesos de AWS (AWS STS) `AssumeRole` para obtener credenciales temporales y actualizarlas según sea necesario. También puedes proporcionar un identificador externo cuando así lo exija la política de confianza del rol.
Google Cloud Storage (GCS)	Los cuatro formatos indicados anteriormente.	Especifica la cuenta de servicio de destino. Storage V3 se hace pasar por esa cuenta de servicio, utiliza sus tokens de acceso OAuth de corta duración para acceder al bucket de origen y actualiza los tokens antes de que caduquen.
Almacenamiento de blobs de Azure	`parquet`, `vortex` y `lance-table`. No se admite `iceberg-table`.	Milvus solicita credenciales SAS de corta duración a través del servicio gRPC privado de `milvus-tools`. Storage V3 utiliza las credenciales SAS para acceder al contenedor de origen, y las credenciales se renuevan antes de que caduquen.
Azure Data Lake Storage Gen2 (ADLS Gen2)	Los cuatro formatos mencionados anteriormente.	Milvus solicita credenciales SAS de corta duración a través del servicio gRPC privado `milvus-tools`. Storage V3 utiliza las credenciales SAS para acceder al contenedor de origen, y las credenciales se renuevan antes de que caduquen.
Servicio de almacenamiento de objetos de Alibaba Cloud (OSS)	Los cuatro formatos mencionados anteriormente.	Especifica el ARN del rol RAM propiedad del cliente. Storage V3 asume el rol utilizando la identidad de carga de trabajo del entorno de ejecución o el rol RAM de ECS, y a continuación utiliza credenciales temporales para acceder al bucket de origen.

Para obtener información sobre la configuración de la recopilación externa y las instrucciones de uso, consulta Crear una recopilación externa.

Funciones que requieren Storage V3

Funcionalidad	Descripción	Configuración necesaria
Formato de archivo Vortex	Escribir nuevos datos de colecciones gestionadas en el formato de archivo Vortex.	`common.storage.useLoonFFI=true` `dataNode.storage.format=vortex`
`TEXT` campo	Almacena texto de origen extenso, como pasajes, documentos, tickets o registros, sin establecer una longitud máxima fija en el esquema de la colección.	`common.storage.useLoonFFI=true`
Campos vectoriales generados por funciones	Añade una función BM25 o MinHash a una colección existente para que Milvus genere un nuevo campo vectorial a partir de un campo « `VARCHAR` » ya existente. Milvus rellena los valores generados para las entidades existentes de forma asíncrona mediante la compactación en segundo plano.	`common.storage.useLoonFFI=true` `dataCoord.compaction.bumpSchemaVersion.enabled=true` `dataCoord.compaction.storageVersion.enabled=true`
Colecciones externas	Consulta datos almacenados fuera de Milvus sin copiarlos en una colección gestionada. Actualiza la colección externa cuando cambien los datos de origen. Para exponer campos de origen adicionales, consulta «Modificar el esquema de una colección externa».	`common.storage.useLoonFFI=true`

Antes de habilitar Storage V3

Una vez que Milvus escribe datos en Storage V3, no se admite la vuelta a una versión de Milvus que no pueda leer Storage V3. Desactivar Storage V3 posteriormente no convierte de forma inmediata todos los datos existentes de Storage V3 ni restaura la compatibilidad con la versión anterior.

Antes de habilitar Storage V3, tenga en cuenta el siguiente comportamiento de los datos:

Dado que la compactación en segundo plano ( dataCoord.compaction.storageVersion.enabled ) está habilitada de forma predeterminada, los datos existentes que cumplan los requisitos pueden pasar a Storage V3 de forma gradual mediante dicha compactación.
Desactivar Storage V3 cambia la versión de almacenamiento de destino para futuras escrituras y para los resultados de compactación que cumplan los requisitos. No convierte de forma sincrónica todos los datos existentes de Storage V3 ni garantiza que la actualización a una versión anterior sea segura.

Habilitar Storage V3

Establece « common.storage.useLoonFFI » en « true » en tu configuración de Milvus:

common:
  storage:
    useLoonFFI: true

Milvus considera que este ajuste se puede actualizar. Aplica el cambio mediante el flujo de trabajo de actualización de la configuración compatible con tu implementación. La mera edición de un archivo de configuración estático no garantiza que la implementación en ejecución haya recibido el nuevo valor.

Si tiene previsto añadir una función y su campo vectorial generado a una colección existente, active también los dos ajustes de compactación necesarios para la retroalimentación de datos existentes:

dataCoord:
  compaction:
    bumpSchemaVersion:
      enabled: true
    storageVersion:
      enabled: true

La salida de la función para las entidades existentes se genera de forma asíncrona mediante la compactación en segundo plano. Una actualización correcta del esquema no indica que el rellenado se haya completado para todas las entidades existentes.