Home
Blog
Deje de pagar por datos fríos: Reducción de costes del 80% con la carga de datos en caliente y en frío bajo demanda en el almacenamiento por niveles de Milvus

Deje de pagar por datos fríos: Reducción de costes del 80% con la carga de datos en caliente y en frío bajo demanda en el almacenamiento por niveles de Milvus

Engineering

December 15, 2025

Buqian Zheng

¿Cuántos de ustedes siguen pagando facturas de infraestructura premium por datos que su sistema apenas toca? Seamos sinceros: la mayoría de los equipos lo hacen.

Si ejecuta búsquedas vectoriales en producción, probablemente lo haya comprobado de primera mano. Usted aprovisiona grandes cantidades de memoria y SSD para que todo esté "listo para la consulta", aunque sólo una pequeña parte de su conjunto de datos esté realmente activa. Y no es el único. También hemos visto muchos casos similares:

Plataformas SaaS multiusuario: Cientos de inquilinos incorporados, pero sólo el 10-15% activo en un día determinado. El resto permanece inactivo, pero sigue ocupando recursos.
Sistemas de recomendación de comercio electrónico: Un millón de SKU, pero el 8% de los productos genera la mayoría de las recomendaciones y el tráfico de búsqueda.
Búsqueda de inteligencia artificial: Vastos archivos de incrustaciones, aunque el 90% de las consultas de los usuarios se refieren a artículos de la semana pasada.

Es la misma historia en todos los sectores: menos del 10% de los datos se consultan con frecuencia, pero a menudo consumen el 80% del almacenamiento y la memoria. Todo el mundo sabe que existe un desequilibrio, pero hasta hace poco no había una arquitectura limpia para solucionarlo.

Eso cambia con Milvus 2.6.

Antes de esta versión, Milvus (como la mayoría de las bases de datos vectoriales) dependía de un modelo de carga completa: si los datos tenían que ser buscables, tenían que cargarse en nodos locales. No importaba si esos datos se consultaban mil veces por minuto o una vez por trimestre: todos tenían que permanecer calientes. Esa elección de diseño garantizaba un rendimiento predecible, pero también significaba sobredimensionar los clústeres y pagar por recursos que los datos fríos simplemente no merecían.

El almacenamiento por niveles es nuestra respuesta.

Milvus 2.6 introduce una nueva arquitectura de almacenamiento por niveles con verdadera carga bajo demanda, que permite al sistema diferenciar automáticamente entre datos calientes y fríos:

Los segmentos calientes permanecen en caché cerca del ordenador.
Los segmentos fríos viven a bajo coste en el almacenamiento remoto de objetos
Los datos se transfieren a los nodos locales sólo cuando una consulta los necesita realmente.

Esto cambia la estructura de costes de "cuántos datos tiene" a "cuántos datos utiliza realmente". Y en las primeras implantaciones de producción, este sencillo cambio supone una reducción de hasta el 80% en los costes de almacenamiento y memoria.

En el resto de este artículo, explicaremos cómo funciona el almacenamiento por niveles, compartiremos resultados reales de rendimiento y mostraremos dónde este cambio tiene el mayor impacto.

Por qué la carga completa falla a escala

Antes de sumergirnos en la solución, merece la pena echar un vistazo más de cerca a por qué el modo de carga completa utilizado en Milvus 2.5 y versiones anteriores se convirtió en un factor limitante a medida que se ampliaban las cargas de trabajo.

En Milvus 2.5 y versiones anteriores, cuando un usuario emitía una solicitud Collection.load(), cada QueryNode almacenaba en caché localmente toda la colección, incluidos los metadatos, los datos de campo y los índices. Estos componentes se descargan del almacenamiento de objetos y se almacenan completamente en memoria o se mapean en memoria (mmap) en el disco local. Sólo después de que todos estos datos estén disponibles localmente se marca la colección como cargada y lista para servir consultas.

En otras palabras, la colección no es consultable hasta que el conjunto de datos completo -en caliente o en frío- está presente en el nodo.

Nota: Para los tipos de índice que incluyen datos vectoriales sin procesar, Milvus sólo carga los archivos de índice, no el campo vectorial por separado. Aún así, el índice debe estar completamente cargado para servir consultas, independientemente de la cantidad de datos a los que se acceda realmente.

Para ver por qué esto resulta problemático, considere un ejemplo concreto:

Supongamos que tenemos un conjunto de datos vectoriales de tamaño medio con

100 millones de vectores
768 dimensiones (incrustaciones BERT)
precisiónfloat32 (4 bytes por dimensión)
Un índice HNSW

En esta configuración, sólo el índice HNSW -incluidos los vectores incrustados sin procesar- consume aproximadamente 430 GB de memoria. Si se añaden los campos escalares habituales, como los identificadores de usuario, las marcas de tiempo o las etiquetas de categoría, el uso total de recursos locales supera fácilmente los 500 GB.

Esto significa que incluso si el 80% de los datos no se consulta nunca o casi nunca, el sistema debe aprovisionar y mantener más de 500 GB de memoria local o disco sólo para mantener la colección en línea.

Para algunas cargas de trabajo, este comportamiento es aceptable:

Si se accede con frecuencia a casi todos los datos, la carga completa de todos ellos ofrece la menor latencia de consulta posible, pero con el mayor coste.
Si los datos pueden dividirse en subconjuntos calientes y calientes, la asignación de memoria de los datos calientes al disco puede reducir parcialmente la presión de la memoria.

Sin embargo, en las cargas de trabajo en las que el 80% o más de los datos se encuentran en la cola larga, los inconvenientes de la carga completa aparecen rápidamente, tanto en rendimiento como en coste.

Cuellos de botella en el rendimiento

En la práctica, la carga completa no sólo afecta al rendimiento de las consultas, sino que a menudo ralentiza los flujos de trabajo operativos rutinarios:

Actualizaciones continuas más largas: En clústeres grandes, las actualizaciones continuas pueden llevar horas o incluso un día entero, ya que cada nodo debe recargar todo el conjunto de datos antes de volver a estar disponible.
Recuperación más lenta tras los fallos: Cuando un QueryNode se reinicia, no puede servir tráfico hasta que se hayan recargado todos los datos, lo que prolonga significativamente el tiempo de recuperación y amplifica el impacto de los fallos de los nodos.
Iteración y experimentación más lentas: La carga completa ralentiza los flujos de trabajo de desarrollo, obligando a los equipos de IA a esperar horas a que se carguen los datos cuando prueban nuevos conjuntos de datos o configuraciones de índices.

Ineficacia de costes

La carga completa también aumenta los costes de infraestructura. Por ejemplo, en las principales instancias optimizadas para memoria en la nube, almacenar 1 TB de datos localmente cuesta aproximadamente $:$ $70.000 al año**, basándose en precios$ $*, basándose en precios conservadores (AWSr6i$ : $5.000$ $al año$ ).74 / GB / mes; GCP n4-highmem: ~5 $;AzureE-series:$ $5,68 / GB / mes; Azure E-series: ~$ 5, $68/GB/mes; AzureE -$ $series$ : $5,67 / GB / mes).$

Consideremos ahora un patrón de acceso más realista, en el que el 80% de esos datos están fríos y podrían almacenarse en almacenamiento de objetos (a aproximadamente 0,023 $/Gb/mes):

200 GB de datos calientes × 5,68
800 GB de datos fríos × 0,023

Coste anual: (200×5,68+800×0,023)×12≈14.000$.

Esto supone una reducción del 80% del coste total de almacenamiento, sin sacrificar el rendimiento allí donde realmente importa.

¿Qué es el almacenamiento por niveles y cómo funciona?

Para eliminar la compensación, Milvus 2.6 introdujo el almacenamiento por niveles, que equilibra el rendimiento y el coste tratando el almacenamiento local como una caché en lugar de como un contenedor para todo el conjunto de datos.

En este modelo, los QueryNodes sólo cargan metadatos ligeros al inicio. Los datos de campo y los índices se obtienen bajo demanda del almacenamiento de objetos remoto cuando una consulta los requiere, y se almacenan en caché local si se accede a ellos con frecuencia. Los datos inactivos pueden desalojarse para liberar espacio.

Como resultado, los datos calientes permanecen cerca de la capa de cálculo para consultas de baja latencia, mientras que los datos fríos permanecen en el almacenamiento de objetos hasta que se necesitan. Esto reduce el tiempo de carga, mejora la eficiencia de los recursos y permite a los QueryNodes consultar conjuntos de datos mucho mayores que su memoria local o capacidad de disco.

En la práctica, el almacenamiento por niveles funciona de la siguiente manera:

Mantener localmente los datos calientes: Aproximadamente el 20% de los datos a los que se accede con frecuencia permanecen en los nodos locales, lo que garantiza una baja latencia para el 80% de las consultas más importantes.
Cargar los datos fríos bajo demanda: El 80% restante de los datos a los que se accede con poca frecuencia se obtiene sólo cuando es necesario, liberando la mayor parte de los recursos locales de memoria y disco.
Adaptación dinámica con desalojo basado en LRU: Milvus utiliza una estrategia de desalojo LRU (Least Recently Used) para ajustar continuamente qué datos se consideran calientes o fríos. Los datos inactivos se desalojan automáticamente para dejar espacio a los nuevos.

Con este diseño, Milvus ya no está limitado por la capacidad fija de la memoria y el disco locales. En su lugar, los recursos locales funcionan como una caché gestionada dinámicamente, donde el espacio se recupera continuamente de los datos inactivos y se reasigna a las cargas de trabajo activas.

Bajo el capó, este comportamiento es posible gracias a tres mecanismos técnicos básicos:

1. Carga perezosa

En el momento de la inicialización, Milvus sólo carga los metadatos mínimos a nivel de segmento, lo que permite que las colecciones puedan consultarse casi inmediatamente después de la puesta en marcha. Los datos de campo y los archivos de índice permanecen en el almacenamiento remoto y se obtienen bajo demanda durante la ejecución de la consulta, manteniendo bajo el uso de la memoria local y del disco.

Cómo funcionaba la carga de colecciones en Milvus 2.5

Cómo funciona la carga diferida en Milvus 2.6 y posteriores

Los metadatos cargados durante la inicialización se dividen en cuatro categorías clave:

Estadísticas de segmento (información básica como recuento de filas, tamaño de segmento y metadatos de esquema)
Marcas de tiempo (se utilizan para realizar consultas sobre viajes en el tiempo)
Registros de inserción y eliminación (necesarios para mantener la coherencia de los datos durante la ejecución de la consulta)
Filtros Bloom (Utilizados para un prefiltrado rápido que elimine rápidamente los segmentos irrelevantes)

2. Carga parcial

Mientras que la carga lenta controla cuándo se cargan los datos, la carga parcial controla cuántos datos se cargan. 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.

Índices vectoriales: Carga en función del inquilino

Una de las capacidades más impactantes introducidas en Milvus 2.6+ es la carga de índices vectoriales con tenant-aware, diseñada específicamente para cargas de trabajo multi-tenant.

Cuando una consulta accede a los datos de un único arrendatario, Milvus carga sólo la parte del índice vectorial que pertenece a ese arrendatario, omitiendo los datos del índice para todos los demás arrendatarios. De este modo, los recursos locales se concentran en los usuarios activos.

Este diseño ofrece varias ventajas:

Los índices vectoriales de los arrendatarios inactivos no consumen memoria local ni disco.
Los datos de índice de los inquilinos activos permanecen en caché para un acceso de baja latencia.
Una política de desalojo LRU a nivel de inquilino garantiza un uso equitativo de la caché entre los inquilinos.

Campos escalares: Carga parcial a nivel de columna

La carga parcial también se aplica a los campos escalares, permitiendo a Milvus cargar sólo las columnas explícitamente referenciadas por una consulta.

Considere una colección con 50 campos de esquema, como id, vector, title, description, category, price, stock, y tags, y sólo necesita devolver tres campos-id, title, y price.

En Milvus 2.5, se cargan los 50 campos escalares independientemente de los requisitos de la consulta.
En Milvus 2.6+, sólo se cargan los tres campos solicitados. Los 47 campos restantes permanecen sin cargar y sólo se recuperan de forma perezosa si se accede a ellos más tarde.

El ahorro de recursos puede ser considerable. Si cada campo escalar ocupa 20 GB:

Para cargar todos los campos se necesitan 1.000 GB (50 × 20 GB).
Para cargar sólo los tres campos necesarios se necesitan 60 GB

Esto representa una reducción del 94% en la carga de datos escalares, sin afectar a la corrección de la consulta ni a los resultados.

Nota: la carga parcial de campos escalares e índices vectoriales con detección de inquilinos se introducirá oficialmente en una próxima versión. Una vez disponible, reducirá aún más la latencia de carga y mejorará el rendimiento de las consultas en frío en grandes despliegues multiarrendatario.

3. Evacuación de la caché basada en LRU

La carga lenta y la carga parcial reducen significativamente la cantidad de datos que se introducen en la memoria local y en el disco. Sin embargo, en sistemas de larga duración, la caché seguirá creciendo a medida que se acceda a nuevos datos. Cuando se alcanza la capacidad local, se procede a la expulsión de la caché basada en LRU.

El desalojo LRU (Least Recently Used) sigue una regla simple: los datos a los que no se ha accedido recientemente se desalojan primero. De este modo, se libera espacio local para los datos a los que se ha accedido recientemente, al tiempo que se mantienen en la caché los datos utilizados con más frecuencia.

Evaluación del rendimiento: Almacenamiento por niveles frente a carga completa

Para evaluar el impacto en el mundo real del almacenamiento por niveles, creamos un entorno de prueba que refleja fielmente las cargas de trabajo de producción. Comparamos Milvus con y sin almacenamiento por niveles en cinco dimensiones: tiempo de carga, uso de recursos, rendimiento de las consultas, capacidad efectiva y rentabilidad.

Configuración experimental

Conjunto de datos

100 millones de vectores con 768 dimensiones (BERT embeddings)
Tamaño del índice vectorial: aproximadamente 430 GB
10 campos escalares, incluidos ID, marca de tiempo y categoría

Configuración de hardware

1 QueryNode con 4 vCPU, 32 GB de memoria y 1 TB de SSD NVMe
Red de 10 Gbps
Clúster de almacenamiento de objetos MinIO como backend de almacenamiento remoto

Patrón de acceso

Las consultas siguen una distribución de acceso frío-caliente realista:

El 80% de las consultas se dirigen a datos de los 30 días más recientes (≈20% de los datos totales)
el 15% se dirige a datos de entre 30 y 90 días (≈30% de los datos totales)
El 5% se centra en datos de más de 90 días (≈50% de los datos totales).

Resultados clave

1. Tiempo de carga 33 veces más rápido

Etapa	Milvus 2.5	Milvus 2.6+ (Almacenamiento por niveles)	Aceleración
Descarga de datos	22 minutos	28 segundos	47×
Carga del índice	3 minutos	17 segundos	10.5×
Total	25 minutos	45 segundos	33×

En Milvus 2.5, la carga de la colección tardaba 25 minutos. Con Tiered Storage en Milvus 2.6+, la misma carga de trabajo se completa en sólo 45 segundos, lo que representa una mejora radical en la eficiencia de la carga.

2. Reducción del 80% en el uso de recursos locales

Etapa	Milvus 2.5	Milvus 2.6+ (Almacenamiento por niveles)	Reducción
Después de la carga	430 GB	12 GB	-97%
Después de 1 hora	430 GB	68 GB	-84%
Después de 24 horas	430 GB	85 GB	-80%
Estado estable	430 GB	85-95 GB	~80%

En Milvus 2.5, el uso de recursos locales permanece constante en 430 GB, independientemente de la carga de trabajo o del tiempo de ejecución. Por el contrario, Milvus 2.6+ comienza con sólo 12 GB inmediatamente después de la carga.

A medida que se ejecutan las consultas, los datos a los que se accede con frecuencia se almacenan en caché local y el uso de recursos aumenta gradualmente. Al cabo de aproximadamente 24 horas, el sistema se estabiliza en 85-95 GB, lo que refleja el conjunto de datos calientes en funcionamiento. A largo plazo, esto se traduce en una reducción de ~80% en el uso local de memoria y disco, sin sacrificar la disponibilidad de las consultas.

3. Impacto casi nulo en el rendimiento de los datos en caliente

Tipo de consulta	Latencia Milvus 2.5 P99	Milvus 2.6+ Latencia P99	Cambiar
Consultas de datos en caliente	15 ms	16 ms	+6.7%
Consultas de datos en caliente	15 ms	28 ms	+86%
Consultas de datos en frío (primer acceso)	15 ms	120 ms	+700%
Consultas de datos en frío (en caché)	15 ms	18 ms	+20%

Para los datos en caliente, que representan aproximadamente el 80% de todas las consultas, la latencia P99 aumenta sólo un 6,7%, lo que resulta en un impacto prácticamente imperceptible en producción.

Las consultas de datos fríos muestran una latencia mayor en el primer acceso debido a la carga bajo demanda desde el almacenamiento de objetos. Sin embargo, una vez almacenados en caché, su latencia aumenta sólo un 20%. Dada la baja frecuencia de acceso a los datos fríos, esta compensación suele ser aceptable para la mayoría de las cargas de trabajo del mundo real.

4. Capacidad efectiva 4,3 veces mayor

Con el mismo presupuesto de hardware -ocho servidores con 64 GB de memoria cada uno (512 GB en total)- Milvus 2.5 puede cargar como máximo 512 GB de datos, lo que equivale aproximadamente a 136 millones de vectores.

Con el almacenamiento por niveles activado en Milvus 2.6+, el mismo hardware puede soportar 2,2 TB de datos, o aproximadamente 590 millones de vectores. Esto representa un aumento de 4,3 veces en la capacidad efectiva, lo que permite servir conjuntos de datos significativamente mayores sin ampliar la memoria local.

5. Reducción de costes del 80,1

Utilizando como ejemplo un conjunto de datos vectoriales de 2 TB en un entorno de AWS, y suponiendo que el 20% de los datos están en caliente (400 GB), la comparación de costes es la siguiente:

Artículo	Milvus 2.5	Milvus 2.6+ (Almacenamiento por niveles)	Ahorro
Coste mensual	$11,802	$2,343	$9,459
Coste anual	$141,624	$28,116	$113,508
Tasa de ahorro	-	-	80.1%

Resumen de las pruebas

En todas las pruebas, el almacenamiento por niveles ofrece mejoras constantes y cuantificables:

Tiempos de carga 33 veces más rápidos: El tiempo de carga de las colecciones se reduce de 25 minutos a 45 segundos.
80% menos de uso de recursos locales: En funcionamiento estacionario, el uso de memoria y disco local se reduce aproximadamente un 80%.
Impacto casi nulo en el rendimiento de los datos en caliente: La latencia P99 de los datos calientes aumenta menos de un 10%, lo que mantiene el rendimiento de las consultas de baja latencia.
Latencia controlada para los datos fríos: Los datos fríos incurren en una mayor latencia en el primer acceso, pero es aceptable dada su baja frecuencia de acceso.
Capacidad efectiva 4,3 veces superior: El mismo hardware puede servir entre 4 y 5 veces más datos sin memoria adicional.
Más de un 80% de reducción de costes: Los costes anuales de infraestructura se reducen en más de un 80%.

Cuándo utilizar el almacenamiento por niveles en Milvus

Basándonos en los resultados de las pruebas comparativas y en casos de producción del mundo real, agrupamos los casos de uso del almacenamiento por niveles en tres categorías para ayudarle a decidir si es una buena opción para su carga de trabajo.

Casos de uso más adecuados

1. Plataformas de búsqueda vectorial multiusuario

Características: Gran número de inquilinos con actividad muy desigual; la búsqueda vectorial es la carga de trabajo principal.
Patrón de acceso: Menos del 20% de los inquilinos generan más del 80% de las consultas vectoriales.
Beneficios esperados: Reducción de costes del 70-80%; aumento de la capacidad de 3-5×.

2. Sistemas de recomendación de comercio electrónico (cargas de trabajo de búsqueda vectorial)

Características: Fuerte desviación de la popularidad entre los productos principales y la cola larga.
Patrón de acceso: El 10% de los productos más populares representan el 80% del tráfico de búsqueda vectorial.
Ventajas previstas: Sin necesidad de capacidad adicional durante los picos; reducción de costes del 60-70%.

3. Conjuntos de datos a gran escala con una clara separación entre caliente y frío (vector dominante)

Características: Conjuntos de datos a escala TB o superior, con acceso muy sesgado hacia datos recientes.
Patrón de acceso: Una distribución clásica 80/20: el 20% de los datos sirve al 80% de las consultas.
Beneficios esperados: Reducción de costes del 75-85

Casos de uso adecuados

1. Cargas de trabajo sensibles a los costes

Características: Presupuestos ajustados con cierta tolerancia a compensaciones menores de rendimiento.
Patrón de acceso: Las consultas vectoriales están relativamente concentradas.
Beneficios esperados: Reducción de costes del 50-70%; los datos fríos pueden incurrir en una latencia de ~500 ms en el primer acceso, que debe evaluarse en función de los requisitos del SLA.

2. Retención de datos históricos y búsqueda en archivos

Características: Grandes volúmenes de vectores históricos con una frecuencia de consulta muy baja.
Patrón de acceso: Alrededor del 90% de las consultas se dirigen a datos recientes.
Beneficios esperados: Conservar conjuntos de datos históricos completos; mantener los costes de infraestructura predecibles y controlados.

Casos de uso inadecuados

1. Cargas de trabajo de datos uniformemente calientes

Características: Se accede a todos los datos con una frecuencia similar, sin una clara distinción entre caliente y frío.
Razones: Beneficio limitado de la caché; Complejidad añadida del sistema sin ganancias significativas.

2. Cargas de trabajo de latencia ultrabaja

Características: Sistemas extremadamente sensibles a la latencia, como el comercio financiero o las pujas en tiempo real.
Razones: Incluso las pequeñas variaciones de latencia son inaceptables; la carga completa proporciona un rendimiento más predecible

Inicio rápido: Pruebe el almacenamiento por niveles en Milvus 2.6+

# Download Milvus 2.6.1+
$ wget https://github.com/milvus-io/milvus/releases/latest
# Configure Tiered Storage
$ vi milvus.yaml
queryNode.segcore.tieredStorage:
  warmup:
    scalarField: disable
    scalarIndex: disable
    vectorField: disable
    vectorIndex: disable
  evictionEnabled: true
# Launch Milvus
$ docker-compose up -d

Conclusión

El almacenamiento por niveles en Milvus 2.6 aborda un desajuste común entre cómo se almacenan los datos vectoriales y cómo se accede realmente a ellos. En la mayoría de los sistemas de producción, sólo una pequeña fracción de los datos se consulta con frecuencia, pero los modelos de carga tradicionales tratan todos los datos como si estuvieran calientes por igual. Al cambiar a la carga bajo demanda y gestionar la memoria local y el disco como una caché, Milvus alinea el consumo de recursos con el comportamiento real de las consultas en lugar de con las suposiciones del peor de los casos.

Este enfoque permite a los sistemas escalar a conjuntos de datos más grandes sin aumentos proporcionales de los recursos locales, manteniendo prácticamente inalterado el rendimiento de las consultas en caliente. Los datos fríos siguen siendo accesibles cuando se necesitan, con una latencia predecible y limitada, lo que hace que la compensación sea explícita y controlable. A medida que la búsqueda vectorial se adentra en entornos de producción sensibles a los costes, multi-tenant y de larga duración, Tiered Storage proporciona una base práctica para operar eficientemente a escala.

Para obtener más información sobre el almacenamiento por niveles, consulte la documentación siguiente:

Documentación de Milvus

¿Tiene preguntas o desea profundizar en alguna característica del último Milvus? Únase a nuestro canal Discord o presente cuestiones en GitHub. También puede reservar una sesión individual de 20 minutos para obtener información, orientación y respuestas a sus preguntas a través de Milvus Office Hours.