Home
Blog
Presentación de AISAQ en Milvus: la búsqueda vectorial a escala de miles de millones es 3.200 veces más barata en memoria

Presentación de AISAQ en Milvus: la búsqueda vectorial a escala de miles de millones es 3.200 veces más barata en memoria

Engineering

December 10, 2025

Martin Li

Las bases de datos vectoriales se han convertido en la infraestructura central de los sistemas de IA de misión crítica, y sus volúmenes de datos crecen exponencialmente, alcanzando a menudo los miles de millones de vectores. A esa escala, todo se vuelve más difícil: mantener una baja latencia, preservar la precisión, garantizar la fiabilidad y operar a través de réplicas y regiones. Pero hay un reto que suele aparecer pronto y dominar las decisiones arquitectónicas: EL COSTE.

Para ofrecer una búsqueda rápida, la mayoría de las bases de datos vectoriales mantienen las estructuras de indexación clave en DRAM (memoria dinámica de acceso aleatorio), el nivel de memoria más rápido y caro. Este diseño es eficaz en términos de rendimiento, pero su escalabilidad es deficiente. El uso de DRAM aumenta con el tamaño de los datos y no con el tráfico de consultas, e incluso con compresión o descarga parcial de SSD, grandes partes del índice deben permanecer en memoria. A medida que crecen los conjuntos de datos, los costes de memoria se convierten rápidamente en un factor limitante.

Milvus ya es compatible con DISKANN, un enfoque de RNA basado en disco que reduce la presión de la memoria trasladando gran parte del índice a SSD. Sin embargo, DISKANN sigue dependiendo de la DRAM para las representaciones comprimidas utilizadas durante la búsqueda. Milvus 2.6 va más allá con AISAQ, un índice vectorial basado en disco inspirado en DISKANN. Desarrollada por KIOXIA, la arquitectura de AiSAQ se diseñó con una "arquitectura de huella cero de DRAM", que almacena todos los datos críticos para la búsqueda en disco y optimiza la colocación de los datos para minimizar las operaciones de E/S. En una carga de trabajo de mil millones de vectores, esto reduce el uso de memoria de 32 GB a unos 10 MB (una reducción de 3.200 veces),manteniendo un rendimiento práctico.

En las secciones siguientes, explicamos cómo funciona la búsqueda vectorial basada en grafos, de dónde proceden los costes de memoria y cómo AISAQ modifica la curva de costes de la búsqueda vectorial a escala de miles de millones.

Funcionamiento de la búsqueda vectorial convencional basada en grafos

Labúsqueda vectorial es el proceso de encontrar puntos de datos cuyas representaciones numéricas sean las más cercanas a una consulta en un espacio de alta dimensión. "Más cercano" significa simplemente la menor distancia según una función de distancia, como la distancia coseno o la distancia L2. A pequeña escala, esto es sencillo: se calcula la distancia entre la consulta y cada vector y se devuelven los más cercanos. Sin embargo, a gran escala (por ejemplo, a escala de miles de millones), este método se vuelve demasiado lento para ser práctico.

Para evitar las comparaciones exhaustivas, los sistemas modernos de búsqueda aproximada por vecino más próximo (ANNS) se basan en índices gráficos. En lugar de comparar una consulta con cada vector, el índice organiza los vectores en un grafo. Cada nodo representa un vector y las aristas conectan vectores numéricamente próximos. Esta estructura permite reducir drásticamente el espacio de búsqueda.

El grafo se construye de antemano, basándose únicamente en las relaciones entre vectores. No depende de las consultas. Cuando llega una consulta, la tarea del sistema consiste en navegar por el grafo de manera eficiente e identificar los vectores con la menor distancia a la consulta, sin escanear todo el conjunto de datos.

La búsqueda parte de un punto de entrada predefinido en el grafo. Este punto de partida puede estar lejos de la consulta, pero el algoritmo mejora su posición paso a paso moviéndose hacia vectores que parecen estar más cerca de la consulta. Durante este proceso, la búsqueda mantiene dos estructuras de datos internas que funcionan conjuntamente: una lista de candidatos y una lista de resultados.

Y los dos pasos más importantes durante este proceso son la expansión de la lista de candidatos y la actualización de la lista de resultados.

Ampliar la lista de candidatos

La lista de candidatos representa el siguiente paso de la búsqueda. Se trata de un conjunto priorizado de nodos del grafo que parecen prometedores en función de su distancia a la consulta.

En cada iteración, el algoritmo

Selecciona el candidato más cercano descubierto hasta el momento. De la lista de candidatos, elige el vector con la menor distancia a la consulta.
Recoge los vecinos de ese vector en el gráfico. Estos vecinos son vectores que se identificaron durante la construcción del índice como cercanos al vector actual.
Evalúa los vecinos no visitados y los añade a la lista de candidatos. Para cada vecino que aún no ha sido explorado, el algoritmo calcula su distancia a la consulta. Los vecinos visitados anteriormente se omiten, mientras que los nuevos vecinos se insertan en la lista de candidatos si parecen prometedores.

Al ampliar repetidamente la lista de candidatos, la búsqueda explora regiones cada vez más relevantes del grafo. De este modo, el algoritmo avanza constantemente hacia mejores respuestas mientras examina sólo una pequeña fracción de todos los vectores.

Actualización de la lista de resultados

Al mismo tiempo, el algoritmo mantiene una lista de resultados, que registra los mejores candidatos encontrados hasta el momento para la salida final. A medida que avanza la búsqueda

Rastrea los vectores más cercanos encontrados durante la travesía. Esto incluye los vectores seleccionados para la expansión, así como otros evaluados a lo largo del camino.
Almacena sus distancias a la consulta. Esto permite clasificar a los candidatos y mantener el top-K actual de vecinos más cercanos.

Con el tiempo, a medida que se evalúan más candidatos y se encuentran menos mejoras, la lista de resultados se estabiliza. Cuando es improbable que una mayor exploración del grafo produzca vectores más cercanos, la búsqueda termina y devuelve la lista de resultados como respuesta final.

En términos sencillos, la lista de candidatos controla la exploración, mientras que la lista de resultados recoge las mejores respuestas descubiertas hasta el momento.

El compromiso de la búsqueda vectorial basada en grafos

Este enfoque basado en grafos es lo que hace que la búsqueda vectorial a gran escala sea práctica en primer lugar. Al navegar por el grafo en lugar de escanear cada vector, el sistema puede encontrar resultados de alta calidad tocando sólo una pequeña fracción del conjunto de datos.

Sin embargo, esta eficacia no es gratuita. La búsqueda basada en grafos presenta un equilibrio fundamental entre precisión y coste.

Explorar más vecinos mejora la precisión al abarcar una porción mayor del gráfico y reducir la posibilidad de omitir los verdaderos vecinos más cercanos.
Al mismo tiempo, cada expansión adicional añade trabajo: más cálculos de distancia, más accesos a la estructura del grafo y más lecturas de datos vectoriales. A medida que la búsqueda es más profunda o más amplia, estos costes se acumulan. Dependiendo de cómo esté diseñado el índice, se manifiestan como un mayor uso de la CPU, una mayor presión de la memoria o más E/S de disco.

Equilibrar estas fuerzas opuestas -alta recuperación frente a uso eficiente de los recursos- es fundamental para el diseño de búsquedas basadas en grafos.

Tanto DISKANN como AISAQ se basan en esta misma tensión, pero toman diferentes decisiones arquitectónicas sobre cómo y dónde se pagan estos costes.

Cómo optimiza DISKANN la búsqueda vectorial basada en disco

DISKANN es la solución RNA basada en disco más influyente hasta la fecha y sirve como base oficial para la competición NeurIPS Big ANN, una referencia mundial para la búsqueda vectorial a escala de miles de millones. Su importancia no radica sólo en el rendimiento, sino en lo que ha demostrado: la búsqueda de RNA basada en grafos no tiene por qué vivir enteramente en la memoria para ser rápida.

Combinando el almacenamiento basado en SSD con estructuras en memoria cuidadosamente seleccionadas, DISKANN demostró que la búsqueda vectorial a gran escala podía alcanzar una gran precisión y una baja latencia en hardware básico, sin necesidad de ocupar grandes espacios de memoria DRAM. Para ello, se replantea qué partes de la búsqueda deben ser rápidas y qué partes pueden tolerar un acceso más lento.

A un alto nivel, DISKANN mantiene en memoria los datos a los que se accede con más frecuencia, mientras que traslada al disco las estructuras más grandes a las que se accede con menos frecuencia. Este equilibrio se consigue mediante varias opciones de diseño clave.

1. 1. Uso de distancias PQ para ampliar la lista de candidatos

La ampliación de la lista de candidatos es la operación más frecuente en la búsqueda basada en grafos. Cada expansión requiere estimar la distancia entre el vector de consulta y los vecinos de un nodo candidato. Realizar estos cálculos utilizando vectores completos y de alta dimensión requeriría frecuentes lecturas aleatorias del disco, una operación costosa tanto desde el punto de vista computacional como en términos de entrada/salida.

DISKANN evita este coste comprimiendo los vectores en códigos Product Quantization (PQ) y guardándolos en memoria. Los códigos PQ son mucho más pequeños que los vectores completos, pero conservan suficiente información para estimar la distancia de forma aproximada.

Durante la expansión de candidatos, DISKANN calcula las distancias utilizando estos códigos PQ en memoria en lugar de leer los vectores completos del SSD. Esto reduce drásticamente la E/S de disco durante el recorrido del gráfico, lo que permite que la búsqueda amplíe los candidatos de forma rápida y eficiente, manteniendo la mayor parte del tráfico SSD fuera de la ruta crítica.

2. 2. Co-localización de vectores completos y listas de vecinos en disco

No todos los datos pueden comprimirse o accederse de forma aproximada. Una vez identificados los candidatos prometedores, la búsqueda sigue necesitando acceder a dos tipos de datos para obtener resultados precisos:

Listas de vecinos, para seguir recorriendo el gráfico
Vectores completos (sin comprimir), para la clasificación final.

Estas estructuras se acceden con menos frecuencia que los códigos PQ, por lo que DISKANN las almacena en SSD. Para minimizar la sobrecarga del disco, DISKANN coloca la lista de vecinos de cada nodo y su vector completo en la misma región física del disco. Esto garantiza que una única lectura en SSD pueda recuperar ambos datos.

Al ubicar conjuntamente los datos relacionados, DISKANN reduce el número de accesos aleatorios al disco necesarios durante la búsqueda. Esta optimización mejora la eficiencia tanto de la expansión como de la reordenación, especialmente a gran escala.

3. Expansión paralela de nodos para una mejor utilización del SSD

La búsqueda de RNA basada en grafos es un proceso iterativo. Si en cada iteración sólo se expande un nodo candidato, el sistema emite una única lectura de disco cada vez, dejando sin utilizar la mayor parte del ancho de banda paralelo del SSD. Para evitar esta ineficacia, DISKANN expande múltiples candidatos en cada iteración y envía peticiones de lectura paralelas al SSD. Este enfoque aprovecha mucho mejor el ancho de banda disponible y reduce el número total de iteraciones necesarias.

El parámetro beam_width_ratio controla cuántos candidatos se expanden en paralelo: Ancho del haz = número de núcleos de CPU × ratio_ancho_haz. Una relación más alta amplía la búsqueda, lo que puede mejorar la precisión, pero también aumenta el cálculo y la E/S de disco.

Para compensar esto, DISKANN introduce una función search_cache_budget_gb_ratio que reserva memoria para almacenar en caché los datos a los que se accede con más frecuencia, reduciendo así las lecturas repetidas de SSD. Juntos, estos mecanismos ayudan a DISKANN a equilibrar la precisión, la latencia y la eficiencia de E/S.

Por qué es importante y dónde están los límites

El diseño de DISKANN supone un gran paso adelante en la búsqueda vectorial basada en disco. Al mantener los códigos PQ en memoria y enviar las estructuras más grandes a SSD, se reduce significativamente la huella de memoria en comparación con los índices de grafos totalmente en memoria.

Al mismo tiempo, esta arquitectura sigue dependiendo de la memoria DRAM permanente para los datos críticos de la búsqueda. Los códigos PQ, las memorias caché y las estructuras de control deben permanecer residentes en memoria para mantener la eficiencia de la búsqueda. A medida que los conjuntos de datos crecen hasta alcanzar miles de millones de vectores y los despliegues añaden réplicas o regiones, este requisito de memoria puede convertirse en un factor limitante.

Esta es la carencia que AISAQ pretende resolver.

Cómo funciona AISAQ y por qué es importante

AISAQ se basa directamente en las ideas centrales de DISKANN, pero introduce un cambio fundamental: elimina la necesidad de mantener los datos PQ en DRAM. En lugar de tratar los vectores comprimidos como estructuras críticas para la búsqueda, siempre en memoria, AISAQ los traslada a SSD y rediseña la disposición de los datos gráficos en el disco para preservar una navegación eficiente.

Para que esto funcione, AISAQ reorganiza el almacenamiento de nodos de modo que los datos necesarios durante la búsqueda de grafos (vectores completos, listas de vecinos e información PQ) se dispongan en el disco en patrones optimizados para la localidad de acceso. El objetivo no es sólo enviar más datos al disco, más económico, sino hacerlo sin interrumpir el proceso de búsqueda descrito anteriormente.

Para responder a los distintos requisitos de las aplicaciones, AISAQ ofrece dos modos de almacenamiento en disco: Rendimiento y Escala. Desde una perspectiva técnica, estos modos difieren principalmente en cómo se almacenan los datos comprimidos PQ y cómo se accede a ellos durante la búsqueda. Desde el punto de vista de la aplicación, estos modos responden a dos tipos de requisitos distintos: requisitos de baja latencia, típicos de los sistemas de búsqueda semántica y recomendación en línea, y requisitos de escala ultraelevada, típicos de RAG.

Rendimiento de AISAQ: Optimizado para la velocidad

AISAQ-performance mantiene todos los datos en disco y reduce la sobrecarga de E/S mediante la colocación de datos.

En este modo:

El vector completo de cada nodo, la lista de aristas y los códigos PQ de sus vecinos se almacenan juntos en el disco.
La visita a un nodo sólo requiere una única lectura de SSD, ya que todos los datos necesarios para la expansión y evaluación de candidatos están ubicados en el mismo lugar.

Desde la perspectiva del algoritmo de búsqueda, esto refleja fielmente el patrón de acceso de DISKANN. La expansión de candidatos sigue siendo eficiente y el rendimiento en tiempo de ejecución es comparable, a pesar de que todos los datos críticos para la búsqueda se encuentran ahora en el disco.

La contrapartida es la sobrecarga de almacenamiento. Dado que los datos PQ de un vecino pueden aparecer en las páginas de disco de varios nodos, esta disposición introduce redundancia y aumenta significativamente el tamaño total del índice.

Por lo tanto, el modo AISAQ-Performance prioriza la baja latencia de E/S sobre la eficiencia del disco. Desde el punto de vista de la aplicación, el modo AiSAQ-Performance puede ofrecer una latencia en el rango de los 10 mSeg, como se requiere para la búsqueda semántica en línea.

Escala AISAQ: Optimizado para la eficiencia del almacenamiento

AISAQ-Scale adopta el enfoque opuesto. Está diseñado para minimizar el uso del disco y, al mismo tiempo, mantener todos los datos en SSD.

En este modo

Los datos PQ se almacenan en disco por separado, sin redundancia.
Esto elimina la redundancia y reduce drásticamente el tamaño del índice.

La contrapartida es que el acceso a los códigos PQ de un nodo y sus vecinos puede requerir múltiples lecturas de SSD, lo que aumenta las operaciones de E/S durante la expansión de candidatos. Si no se optimiza, la búsqueda se ralentizará considerablemente.

Para controlar esta sobrecarga, el modo AISAQ-Scale introduce dos optimizaciones adicionales:

Reorganización de datos PQ, que ordena los vectores PQ por prioridad de acceso para mejorar la localidad y reducir las lecturas aleatorias.
Una caché PQ en DRAM (pq_read_page_cache_size), que almacena los datos PQ a los que se accede con frecuencia y evita lecturas repetidas en disco para las entradas calientes.

Con estas optimizaciones, el modo AISAQ-Scale logra una eficiencia de almacenamiento mucho mejor que AISAQ-Performance, al tiempo que mantiene un rendimiento de búsqueda práctico. Ese rendimiento sigue siendo inferior al de DISKANN, pero no hay sobrecarga de almacenamiento (el tamaño del índice es similar al de DISKANN) y la huella de memoria es drásticamente menor. Desde el punto de vista de la aplicación, AiSAQ proporciona los medios para cumplir los requisitos de RAG a escala ultraelevada.

Principales ventajas de AISAQ

Al trasladar al disco todos los datos críticos para la búsqueda y rediseñar la forma de acceder a ellos, AISAQ cambia radicalmente el perfil de coste y escalabilidad de la búsqueda vectorial basada en grafos. Su diseño ofrece tres ventajas significativas.

1. Uso de DRAM hasta 3.200 veces menor

La cuantificación de productos reduce significativamente el tamaño de los vectores de alta dimensión, pero a escala de miles de millones, la huella de memoria sigue siendo considerable. Incluso después de la compresión, los códigos PQ deben mantenerse en memoria durante la búsqueda en diseños convencionales.

Por ejemplo, en SIFT1B, una prueba con mil millones de vectores de 128 dimensiones, los códigos PQ requieren por sí solos entre 30 y 120 GB de memoria DRAM, dependiendo de la configuración. Almacenar los vectores completos sin comprimir requeriría unos 480 GB adicionales. Aunque PQ reduce el uso de memoria entre 4 y 16 veces, la huella restante sigue siendo lo suficientemente grande como para dominar el coste de la infraestructura.

AISAQ elimina este requisito por completo. Al almacenar los códigos PQ en SSD en lugar de DRAM, la memoria ya no es consumida por datos de índice persistentes. La DRAM sólo se utiliza para estructuras ligeras y transitorias, como las listas de candidatos y los metadatos de control. En la práctica, esto reduce el uso de memoria de decenas de gigabytes a unos 10 MB. En una configuración representativa a escala de miles de millones, la DRAM pasa de 32 GB a 10 MB, lo que supone una reducción de 3.200 veces.

Dado que el almacenamiento SSD cuesta aproximadamente 1/30 del precio por unidad de capacidad en comparación con la DRAM, este cambio tiene un impacto directo y dramático en el coste total del sistema.

2. Sin sobrecarga adicional de E/S

Trasladar los códigos PQ de la memoria al disco normalmente aumentaría el número de operaciones de E/S durante la búsqueda. AISAQ evita esto controlando cuidadosamente la disposición de los datos y los patrones de acceso. En lugar de dispersar los datos relacionados por el disco, AISAQ ubica los códigos PQ, los vectores completos y las listas de vecinos de forma que puedan recuperarse juntos. Esto garantiza que la expansión de candidatos no introduzca lecturas aleatorias adicionales.

Para que los usuarios puedan controlar el equilibrio entre el tamaño del índice y la eficiencia de E/S, AISAQ introduce el parámetro inline_pq, que determina cuántos datos PQ se almacenan en línea con cada nodo:

menor inline_pq: menor tamaño del índice, pero puede requerir más E/S
Mayor inline_pq: mayor tamaño de índice, pero conserva el acceso de lectura única.

Cuando se configura con inline_pq = max_degree, AISAQ lee el vector completo de un nodo, la lista de vecinos y todos los códigos PQ en una sola operación de disco, coincidiendo con el patrón de E/S de DISKANN y manteniendo todos los datos en SSD.

3. El Acceso PQ Secuencial Mejora la Eficiencia Computacional

En DISKANN, la expansión de un nodo candidato requiere R accesos aleatorios a la memoria para obtener los códigos PQ de sus R vecinos. AISAQ elimina esta aleatoriedad recuperando todos los códigos PQ en una única E/S y almacenándolos secuencialmente en el disco.

La disposición secuencial ofrece dos ventajas importantes:

Laslecturas secuenciales en SSD son mucho más rápidas que las lecturas aleatorias dispersas.
Los datos contiguos son más fáciles de almacenar en caché, lo que permite a las CPU calcular las distancias PQ de forma más eficiente.

Esto mejora tanto la velocidad como la previsibilidad de los cálculos de distancias PQ y ayuda a compensar el coste de rendimiento de almacenar códigos PQ en SSD en lugar de DRAM.

AISAQ frente a DISKANN: evaluación del rendimiento

Tras comprender las diferencias arquitectónicas entre AISAQ y DISKANN, la siguiente pregunta es sencilla: ¿cómo afectan estas decisiones de diseño al rendimiento y al uso de recursos en la práctica? Esta evaluación compara AISAQ y DISKANN en las tres dimensiones más importantes a escala de miles de millones: rendimiento de búsqueda, consumo de memoria y uso de disco.

En concreto, examinamos cómo se comporta AISAQ a medida que cambia la cantidad de datos PQ en línea (INLINE_PQ). Este parámetro controla directamente el equilibrio entre el tamaño del índice, la E/S de disco y la eficiencia en tiempo de ejecución. También evaluamos ambos enfoques en cargas de trabajo vectoriales de baja y alta dimensión, ya que la dimensionalidad influye mucho en el coste del cálculo de distancias y en los requisitos de almacenamiento.

Configuración

Todos los experimentos se realizaron en un sistema de nodo único para aislar el comportamiento del índice y evitar interferencias de efectos de red o de sistemas distribuidos.

Configuración de hardware:

CPU: CPU Intel® Xeon® Platinum 8375C a 2,90GHz
Memoria: Velocidad: 3200 MT/s, Tipo: DDR4, Tamaño: 32 GB
Disco: SSD NVMe de 500 GB

Parámetros de creación de índices

{
  "max_degree": 48,
  "search_list_size": 100,
  "inline_pq": 0/12/24/48,  // AiSAQ only
  "pq_code_budget_gb_ratio": 0.125,
  "search_cache_budget_gb_ratio": 0.0,
  "build_dram_budget_gb": 32.0
}

Parámetros de consulta

{
  "k": 100,
  "search_list_size": 100,
  "beamwidth": 8
}

Método de referencia

Tanto DISKANN como AISAQ se probaron utilizando Knowhere, el motor de búsqueda vectorial de código abierto utilizado en Milvus. En esta evaluación se utilizaron dos conjuntos de datos:

SIFT128D (1M de vectores): una conocida referencia de 128 dimensiones utilizada habitualmente para la búsqueda de descriptores de imágenes. (Tamaño bruto del conjunto de datos ≈ 488 MB).
Cohere768D (1M de vectores): un conjunto de incrustación de 768 dimensiones típico de la búsqueda semántica basada en transformadores. (Tamaño bruto del conjunto de datos ≈ 2930 MB)

Estos conjuntos de datos reflejan dos escenarios distintos del mundo real: características de visión compactas e incrustaciones semánticas de gran tamaño.

Resultados

Sift128D1M (vector completo ~488 MB)

Cohere768D1M (vector completo ~2930 MB)

Análisis

Conjunto de datos SIFT128D

En el conjunto de datos SIFT128D, AISAQ puede igualar el rendimiento de DISKANN cuando se alinean todos los datos PQ de forma que los datos necesarios de cada nodo quepan por completo en una única página SSD de 4 KB (INLINE_PQ = 48). Con esta configuración, toda la información necesaria para la búsqueda está colocada:

Vector completo: 512B
Lista de vecinos: 48 × 4 + 4 = 196B
Códigos PQ de vecinos: 48 × (512B × 0,125) ≈ 3072B
Total: 3780B

Como todo el nodo cabe en una página, sólo se necesita una E/S por acceso, y AISAQ evita las lecturas aleatorias de datos PQ externos.

Sin embargo, cuando sólo una parte de los datos PQ está en línea, los códigos PQ restantes deben obtenerse de otra parte del disco. Esto introduce operaciones de E/S aleatorias adicionales, que aumentan drásticamente la demanda de IOPS y provocan caídas significativas del rendimiento.

Conjunto de datos Cohere768D

En el conjunto de datos Cohere768D, el rendimiento de AISAQ es peor que el de DISKANN. La razón es que un vector de 768 dimensiones simplemente no cabe en una página SSD de 4 KB:

Vector completo: 3072B
Lista de vecinos: 48 × 4 + 4 = 196B
Códigos PQ de vecinos: 48 × (3072B × 0,125) ≈ 18432B
Total: 21.700 B (≈ 6 páginas)

En este caso, aunque todos los códigos PQ estén inline, cada nodo abarca varias páginas. Mientras que el número de operaciones de E/S se mantiene constante, cada E/S debe transferir muchos más datos, consumiendo el ancho de banda SSD mucho más rápido. Una vez que el ancho de banda se convierte en el factor limitante, AISAQ no puede seguir el ritmo de DISKANN, especialmente en cargas de trabajo de alta dimensión en las que las huellas de datos por nodo crecen rápidamente.

Nota:

La disposición de almacenamiento de AISAQ suele aumentar el tamaño del índice en disco entre 4 y 6 veces. Se trata de una compensación deliberada: los vectores completos, las listas de vecinos y los códigos PQ se colocan en el disco para permitir un acceso eficiente de una sola página durante la búsqueda. Aunque esto incrementa el uso de SSD, la capacidad de disco es significativamente más barata que la DRAM y se escala más fácilmente a grandes volúmenes de datos.

En la práctica, los usuarios pueden ajustar este equilibrio modificando los ratios de compresión de INLINE_PQ y PQ. Estos parámetros permiten equilibrar el rendimiento de la búsqueda, la huella de disco y el coste global del sistema en función de los requisitos de la carga de trabajo, en lugar de estar constreñidos por límites fijos de memoria.

Conclusión

La economía del hardware moderno está cambiando. Los precios de la DRAM siguen siendo elevados, mientras que el rendimiento de las SSD ha avanzado rápidamente: las unidadesCIe 5.0 ofrecen ahora un ancho de banda superior a 14 GB/s. Como resultado, las arquitecturas que trasladan los datos críticos para la búsqueda de la costosa DRAM a un almacenamiento SSD mucho más asequible son cada vez más atractivas. Con una capacidad SSD que cuesta menos de 30 veces más por gigabyte que la DRAM, estas diferencias ya no son marginales, sino que influyen significativamente en el diseño del sistema.

AISAQ refleja este cambio. Al eliminar la necesidad de grandes asignaciones de memoria siempre activas, permite a los sistemas de búsqueda vectorial escalar en función del tamaño de los datos y los requisitos de la carga de trabajo, en lugar de los límites de la DRAM. Este enfoque se alinea con una tendencia más amplia hacia las arquitecturas "todo almacenamiento", en las que las unidades SSD rápidas desempeñan un papel central no sólo en la persistencia, sino también en el cálculo y la búsqueda activos. Al ofrecer dos modos de funcionamiento, Rendimiento y Escala, AiSAQ satisface los requisitos tanto de la búsqueda semántica (que requiere la latencia más baja) como de la RAG (que requiere una escala muy alta, pero una latencia moderada).

Es poco probable que este cambio se limite a las bases de datos vectoriales. Ya están surgiendo patrones de diseño similares en el procesamiento de grafos, el análisis de series temporales e incluso en partes de los sistemas relacionales tradicionales, a medida que los desarrolladores se replantean los antiguos supuestos sobre dónde deben residir los datos para lograr un rendimiento aceptable. A medida que la economía del hardware siga evolucionando, también lo harán las arquitecturas de los sistemas.

Para obtener más detalles sobre los diseños que se analizan aquí, consulte la documentación:

¿Tiene alguna pregunta o desea profundizar en alguna característica del último Milvus? Únase a nuestro canal de Discord o envíe problemas a 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.