Visión general del almacenamiento por nivelesCompatible with Milvus 2.6.4+

En Milvus, el modo tradicional de carga completa requiere que cada QueryNode cargue todos los campos de datos e índices de un segmento en la inicialización, incluso los datos a los que puede que nunca se acceda. Esto garantiza la disponibilidad inmediata de los datos, pero a menudo conduce a un desperdicio de recursos, incluyendo un alto uso de memoria, una gran actividad de disco y una sobrecarga significativa de E/S, especialmente cuando se manejan conjuntos de datos a gran escala.

El almacenamiento por niveles resuelve este problema desvinculando la caché de datos de la carga de segmentos. En lugar de cargar todos los datos a la vez, el QueryNode ahora sólo carga metadatos ligeros inicialmente y extrae o desaloja dinámicamente los datos de campo bajo demanda. Esto reduce significativamente el tiempo de carga, optimiza la utilización de los recursos locales y permite a los QueryNodes procesar conjuntos de datos que superan con creces su capacidad física de memoria o disco.

Considere la posibilidad de habilitar el almacenamiento por niveles en escenarios como:

• Colecciones que superan la memoria disponible o la capacidad NVMe de un único QueryNode.

• Cargas de trabajo analíticas o por lotes en las que una carga más rápida es más importante que la latencia de la primera consulta

• Cargas de trabajo mixtas que pueden tolerar pérdidas ocasionales de caché para datos a los que se accede con menos frecuencia.

Cómo funciona

El almacenamiento por niveles cambia la forma en que QueryNode gestiona los datos de los segmentos. En lugar de almacenar en caché cada campo e índice en el momento de la carga, QueryNode carga ahora sólo los metadatos y utiliza una capa de almacenamiento en caché para obtener y desalojar los datos dinámicamente.

Modo de carga completa frente a modo de almacenamiento por niveles

Aunque los modos de carga completa y almacenamiento por niveles manejan los mismos datos, difieren en cuándo y cómo QueryNode almacena en caché estos componentes.

• Modo decarga completa: En el momento de la carga, QueryNode almacena en caché todos los datos de la colección, incluidos los metadatos, los datos de campo y los índices, desde el almacenamiento de objetos.

• Modo dealmacenamiento por niveles: En el momento de la carga, QueryNode sólo almacena en caché los metadatos. Los datos de campo se extraen bajo demanda con una granularidad de trozos. Los archivos de índice permanecen remotos hasta que la primera consulta los necesita; entonces se obtiene y almacena en caché el índice completo por segmento.

El siguiente diagrama muestra estas diferencias.

Modo de carga completa frente al modo de almacenamiento por niveles

Flujo de trabajo de carga de QueryNode

Bajo Almacenamiento por niveles, el flujo de trabajo de Almacenamiento por niveles tiene estas fases:

Flujo de trabajo de carga de Querynode

Fase 1: Carga perezosa

En la inicialización, Milvus realiza una carga lenta, almacenando en caché sólo los metadatos a nivel de segmento, como las definiciones de esquema, la información de índice y las asignaciones de trozos.

En esta fase no se almacenan en caché datos de campo reales ni archivos de índice. De este modo, las colecciones pueden consultarse casi inmediatamente después de iniciarse, con un consumo mínimo de memoria y disco.

Dado que los datos de campo y los archivos de índice permanecen en almacenamiento remoto hasta que se accede a ellos por primera vez, la primera consulta puede experimentar una latencia adicional, ya que los datos necesarios deben obtenerse bajo demanda. Para mitigar este efecto en los campos o índices críticos, puede utilizar la estrategia Warm Up (Calentamiento ) para precargarlos de forma proactiva antes de que el segmento pueda consultarse.

Configuración

Se aplica automáticamente cuando el almacenamiento por niveles está activado. No es necesaria ninguna configuración manual.

Fase 2: Calentamiento

Para reducir la latencia de primer golpe introducida por la carga lenta, Milvus proporciona un mecanismo de Calentamiento.

Antes de que un segmento sea consultable, Milvus puede recuperar y almacenar en caché de forma proactiva campos o índices específicos del almacenamiento de objetos, asegurando que la primera consulta alcance directamente los datos almacenados en caché en lugar de activar la carga bajo demanda.

Durante el calentamiento, los campos se precargarán a nivel de trozo, mientras que los índices se precargarán a nivel de segmento.

Configuración

El calentamiento puede configurarse en tres niveles:

• Nivel de cluster: Definir valores por defecto en milvus.yaml que se aplican a todas las colecciones.

• Nivel decolección: Anule los valores predeterminados del cluster para una colección específica utilizando los métodos del SDK (create_collection, alter_collection_properties).

• Nivel de campo/índice: Ajuste campos o índices individuales mediante los métodos del SDK (add_field, alter_collection_field, add_index, alter_index_properties).

Las configuraciones de nivel superior anulan las de nivel inferior (Campo/Índice > Colección > Grupo). Consulte Calentamiento para obtener configuraciones detalladas.

Fase 3: Carga parcial

Una vez que comienzan las consultas o búsquedas, el QueryNode realiza una carga parcial, obteniendo sólo los trozos de datos o archivos de índice necesarios del almacenamiento de objetos.

• Campos: Cargados bajo demanda a nivel de chunk. Sólo se obtienen los trozos de datos que coinciden con las condiciones de consulta actuales, minimizando el uso de E/S y memoria.

• Índices: Se cargan bajo demanda a nivel de segmento. Los archivos de índices deben obtenerse como unidades completas y no pueden dividirse en trozos.

Configuración

La carga parcial se aplica automáticamente cuando el almacenamiento por niveles está activado. No es necesaria ninguna configuración manual. Para minimizar la latencia de primer golpe para datos críticos, combínelo con Warm Up.

Fase 4: Desalojo

Para mantener un uso saludable de los recursos, Milvus libera automáticamente los datos en caché no utilizados cuando se alcanzan umbrales específicos.

El desalojo sigue una política de Uso Menos Reciente (LRU ), asegurando que los datos a los que se accede con poca frecuencia se eliminan primero mientras que los datos activos permanecen en la caché.

El desalojo se rige por los siguientes elementos configurables:

• Marcas de agua: Define umbrales de memoria o disco que activan y detienen el desalojo.

• TTL de la caché: elimina los datos obsoletos de la caché tras un periodo de inactividad definido.

Configuración

Habilite y ajuste los parámetros de desalojo en milvus.yaml. Consulte Desalojo para una configuración detallada.

Primeros pasos

Requisitos previos

• Milvus 2.6.4+

• QueryNodes con memoria y recursos de disco dedicados

• Backend de almacenamiento de objetos (S3, MinIO, etc.)

Plantilla de configuración básica

Edite el archivo de configuración de Milvus (milvus.yaml) para configurar los parámetros de almacenamiento por niveles a nivel de clúster:

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      # Warm Up Configuration
      warmup:
        scalarField: sync      # Preload scalar field data
        scalarIndex: sync      # Preload scalar indexes
        vectorField: disable   # Don't preload vector field data (large)
        vectorIndex: sync      # Preload vector indexes
      
      # Eviction Configuration
      evictionEnabled: true
      backgroundEvictionEnabled: true
      
      # Memory Watermarks
      memoryLowWatermarkRatio: 0.75   # Stop evicting at 75%
      memoryHighWatermarkRatio: 0.80  # Start evicting at 80%
      
      # Disk Watermarks  
      diskLowWatermarkRatio: 0.75
      diskHighWatermarkRatio: 0.80
      
      # Cache TTL (7 days)
      cacheTtl: 604800

Pasos siguientes

1. Configurar Warm Up - Optimizar la precarga para sus patrones de acceso. Consulte Calentamiento.

2. Ajuste el desalojo: establezca marcas de agua y TTL adecuados para sus limitaciones de recursos. Consulte Desalojo.

3. Supervisar el rendimiento: realice un seguimiento de los índices de aciertos de la caché, la frecuencia de desalojo y los patrones de latencia de las consultas.

4. Iterar la configuración: ajuste la configuración en función de las características observadas de la carga de trabajo.

PREGUNTAS FRECUENTES

¿Puedo cambiar los parámetros de almacenamiento por niveles en tiempo de ejecución?

Depende del tipo de parámetro:

• Parámetros de calentamiento: El calentamiento a nivel de colección y a nivel de campo/índice puede configurarse a través del SDK antes de cargar la colección. Una vez cargada la colección, primero debe liberarla, modificar los ajustes y, a continuación, volver a cargarla.

• Ajustes de desalojo y marca de agua: Deben configurarse en milvus.yaml antes de iniciar Milvus. Los cambios requieren un reinicio para surtir efecto.

¿Afecta el almacenamiento por niveles a la durabilidad de los datos?

No. La persistencia de los datos sigue siendo gestionada por el almacenamiento remoto de objetos. El almacenamiento por niveles sólo gestiona el almacenamiento en caché en los QueryNodes.

¿Serán siempre más rápidas las consultas con el almacenamiento por niveles?

No necesariamente. El almacenamiento por niveles reduce el tiempo de carga y el uso de recursos, pero las consultas que tocan datos no almacenados en caché (fríos) pueden experimentar una mayor latencia. Para cargas de trabajo sensibles a la latencia, se recomienda el modo de carga completa.

¿Por qué un QueryNode se queda sin recursos incluso con el almacenamiento por niveles activado?

Dos causas comunes:

• El QueryNode fue configurado con muy pocos recursos. Las marcas de agua son relativas a los recursos disponibles, por lo que un aprovisionamiento insuficiente amplifica los errores de cálculo.

• Los recursos del QueryNode se comparten con otras cargas de trabajo, por lo que el almacenamiento por niveles no puede evaluar correctamente la capacidad real disponible.

Para resolver este problema, le recomendamos que asigne recursos dedicados a los QueryNodes.

¿Por qué fallan algunas consultas cuando hay mucha concurrencia?

Si demasiadas consultas acceden a datos calientes al mismo tiempo, es posible que se superen los límites de recursos de QueryNode. Algunos hilos pueden fallar debido a tiempos de espera de reserva de recursos. Si se reintenta cuando la carga disminuye, o si se asignan más recursos, esto puede resolverse.

¿Por qué aumenta la latencia de búsqueda/consulta después de activar el almacenamiento por niveles?

Las posibles causas son:

• Consultas frecuentes a datos fríos, que deben obtenerse del almacenamiento.

• Marcas de agua colocadas demasiado cerca, lo que provoca frecuentes desalojos sincrónicos.