Mejores prácticas para el almacenamiento por nivelesCompatible with Milvus 2.6.4+

Milvus proporciona almacenamiento por niveles para ayudarle a manejar eficientemente datos a gran escala mientras equilibra la latencia de las consultas, la capacidad y el uso de recursos. Esta guía resume las configuraciones recomendadas para cargas de trabajo típicas y explica el razonamiento detrás de cada estrategia de ajuste.

Antes de empezar

• Milvus v2.6.4 o posterior

• Los QueryNodes deben tener recursos locales dedicados (memoria y disco). Los entornos compartidos pueden distorsionar la estimación de la caché y llevar a una estimación errónea del desalojo.

Elija la estrategia adecuada

El almacenamiento por niveles ofrece estrategias flexibles de carga y almacenamiento en caché que pueden combinarse para adaptarse a su carga de trabajo.

Objetivo	Enfoque recomendado	Mecanismo clave
Minimizar la latencia de la primera consulta	Carga previa de campos críticos	Calentamiento
Gestión eficaz de datos a gran escala	Carga bajo demanda	Carga lenta + carga parcial
Mantener la estabilidad a largo plazo	Evitar el desbordamiento de la caché	Desalojo
Equilibrar rendimiento y capacidad	Combinar precarga y caché dinámica	Configuración híbrida

Escenario 1: recuperación en tiempo real y baja latencia

Cuándo utilizarlo

• La latencia de la consulta es crítica (por ejemplo, recomendación en tiempo real o clasificación de búsquedas)

• Se accede con frecuencia a los índices vectoriales centrales y a los filtros escalares.

• El rendimiento constante importa más que la velocidad de arranque

Configuración recomendada

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      warmup:
        # scalar field/index warm-up to eliminate first-time latency
        scalarField: sync
        scalarIndex: sync
        # warm-up of vector fields is disabled (if the original vector is not required)
        vectorField: disable
        # vector indexes warm-up to elminate first-time latenct
        vectorIndex: sync
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.75
      memoryHighWatermarkRatio: 0.8
      diskLowWatermarkRatio: 0.75
      diskHighWatermarkRatio: 0.8
      # no expiration time, which avoids frequent reloading
      cacheTtl: 0

Justificación

• El calentamiento elimina la latencia de primer golpe para los índices escalares y vectoriales de alta frecuencia.

• El desalojo en segundo plano mantiene estable la presión de la caché sin bloquear las consultas.

• La desactivación del TTL de la caché evita recargas innecesarias para los datos calientes.

Escenario 2: análisis por lotes fuera de línea

Cuándo utilizarlo

• La tolerancia a la latencia de las consultas es alta

• Las cargas de trabajo implican conjuntos de datos masivos o muchos segmentos

• La capacidad y el rendimiento tienen prioridad sobre la capacidad de respuesta

Configuración recomendada

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      enabled: true
      warmup:
        # disable scalar field/index warm-up to speed up loading
        scalarField: disable
        scalarIndex: disable
        # disable vector field/index warm-up to speed up loading
        vectorField: disable
        vectorIndex: disable
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.7
      memoryHighWatermarkRatio: 0.85
      diskLowWatermarkRatio: 0.7
      diskHighWatermarkRatio: 0.85
      # use 1 day expiration to clean unused cache
      cacheTtl: 86400

Justificación

• Desactivar el calentamiento acelera el arranque cuando se inicializan muchos segmentos.

• Las marcas de agua más altas permiten un uso más denso de la caché, lo que mejora la capacidad de carga total.

• El TTL de la caché limpia automáticamente los datos no utilizados para liberar espacio local.

Escenario 3: despliegue híbrido (mixto online + offline)

Cuándo utilizarlo

• Un único clúster sirve tanto a cargas de trabajo en línea como analíticas

• Algunas colecciones requieren baja latencia, otras priorizan la capacidad

Estrategia recomendada

• Aplicar la configuración en tiempo real a las colecciones sensibles a la latencia

• Aplicar la configuración fuera de línea a las colecciones analíticas o de archivo

• Ajustar los ratios evictableMemoryCacheRatio, cacheTtl y watermark de forma independiente para cada tipo de carga de trabajo

Justificación

La combinación de configuraciones permite un control detallado de la asignación de recursos.

Las colecciones críticas mantienen garantías de baja latencia, mientras que las colecciones secundarias pueden gestionar más segmentos y volumen de datos.

Consejos adicionales de ajuste

Aspecto	Recomendación	Explicación
Ámbito de calentamiento	Precargue sólo los campos o índices con alta frecuencia de consulta.	La precarga innecesaria aumenta el tiempo de carga y el uso de recursos.
Ajuste del desalojo	Comience con las marcas de agua predeterminadas (75-80%) y ajústelas gradualmente.	Un intervalo pequeño provoca un desalojo frecuente; un intervalo grande retrasa la liberación de recursos.
TTL de caché	Desactivar para conjuntos de datos calientes estables; activar (por ejemplo, 1-3 días) para datos dinámicos.	Evita la acumulación de datos obsoletos en la caché y equilibra la sobrecarga de limpieza.
Ratio de sobrecompromiso	Evite valores superiores a 0,7 a menos que el margen de recursos sea grande.	Un sobrecompromiso excesivo puede provocar el colapso de la caché y una latencia inestable.
Monitorización	Controle la tasa de aciertos de la caché, la utilización de los recursos y la frecuencia de desalojo.	Las cargas en frío frecuentes pueden indicar que es necesario ajustar el calentamiento o las filigranas.