Cómo construimos Elasticsearch SIMDvec

Cada consulta de búsqueda vectorial en Elasticsearch, ya sea un recorrido de mundo pequeño jerárquico navegable (HNSW), un escaneo de archivo invertido (IVF) o una pasada de reclasificación, se reduce al mismo problema: calcular distancias entre vectores, millones de veces por búsqueda. Elasticsearch admite una amplia gama de tipos de datos y estrategias de cuantificación, desde float32 hasta int8, bfloat16, binario y Mejor cuantificación binaria (BBQ). Cada una tiene distintas compensaciones entre memoria, rendimiento y recuperación. Detrás de todo esto hay un único motor: simdvec.

Creamos simdvec para que cada cálculo de distancia sea tan rápido como el hardware lo permita. En esta publicación, explicamos por qué lo creamos, qué contiene y dónde produce el mayor impacto.

Creado como un auto de carreras

Como aficionados a la Fórmula 1, y dado que uno de nosotros trabajó anteriormente con el equipo Ferrari de Fórmula 1, vemos un claro paralelismo. Un auto de Fórmula 1 está diseñado con un solo propósito: lograr el mejor tiempo de vuelta. La potencia del motor, la aerodinámica y el diseño del chasis solo importan en la medida en que contribuyen a ese resultado. Lo mismo ocurre con una base de datos vectorial, donde el rendimiento de indexación, la latencia de búsqueda y la recuperación definen el éxito.

Aunque lo que importa es el resultado final, para alcanzar los máximos niveles de rendimiento es necesario que cada componente funcione a la perfección. No puede ser solo lo suficientemente bueno, tiene que ser el mejor en su categoría. Simdvec está construido con esa mentalidad, que se enfoca en una parte fundamental del sistema: el motor. Es una biblioteca de kernel optimizada para una sola instrucción y múltiples datos (SIMD) diseñada específicamente, que proporciona funciones nativas de distancia en C++ ajustadas a mano, llamadas desde Java a través de la interfaz para funciones externas (FFI) de Panamá. Admite evaluación masiva, precarga de líneas de caché y todos los tipos de vectores y diseños utilizados en Elasticsearch.

Ese es el motor que hay detrás de cada búsqueda.

Por qué creamos nuestro propio motor

Comenzamos en 2023 con la API Panama Vector en Apache Lucene. Funcionaba bien para productos punto float32, pero las necesidades de Elasticsearch superaron rápidamente lo que podía ofrecer. Elasticsearch admite una amplia gama de tipos de vectores cuantificados: int8, int4, bfloat16, de un solo bit y BBQ asimétrico. Cada uno tiene diferentes estrategias SIMD, diseños de empaquetado y requisitos de acumulador. Más allá de la cobertura de tipos, las rutas de puntuación de Elasticsearch exigen algo más que un rendimiento de un solo par: HNSW necesita puntuar varios vecinos del grafo en una sola pasada, IVF necesita puntuar en masa miles de candidatos con precarga y la puntuación basada en disco debe funcionar directamente en la memoria mapeada con mmap sin necesidad de copiar. Examinamos lo que estaba disponible y nada abarcaba el conjunto completo.

Así que construimos simdvec: kerneles C++ nativos ajustados a mano llamados desde Java a través de FFI, con puntuación masiva, precarga y soporte para cada tipo de vector que usa Elasticsearch. Al ser propietarios de la biblioteca, controlamos el stack completo. Cuando añadimos un nuevo tipo de cuantificación, como BBQ, se le asigna un kernel SIMD optimizado que se integra en todo el sistema. No esperamos a que una biblioteca upstream le de soporte y no comprometemos el rendimiento para ningún tipo. Cada consulta vectorial en Elasticsearch, ya sea HNSW, IVF, reranking o híbrida, se ejecuta en este motor, construido en torno a las operaciones y los tipos que realmente usamos.

Simdvec tiene bibliotecas nativas separadas para x86 y ARM, cada una con múltiples niveles de arquitectura de conjunto de instrucciones (ISA) seleccionados al inicio. La sobrecarga de llamadas desde Java vía FFI es muy baja, con nanosegundos de un solo dígito.

El panorama

No somos los únicos que construimos kerneles de distancia vectorial optimizados para SIMD. El ecosistema es rico y queríamos comprender cómo se desempeña simdvec. No para clasificar proyectos, sino para proporcionar contexto y explicar dónde se encuentra el motor de Elasticsearch. Seleccionamos tres proyectos como puntos de referencia, cada uno representando un enfoque diferente:

• jvector: Una biblioteca de Java de vecino más cercano aproximado (ANN) que emplea la API Panama Vector para el cálculo vectorizado de distancias, con aceleración nativa en C opcional en x86.

• FAISS: Un marco de trabajo de búsqueda vectorial de open source ampliamente desplegado, con kerneles AVX2/AVX-512 ajustados a mano.

• NumKong (anteriormente SimSIMD): un conjunto completo de más de 2 000 kerneles SIMD ajustados a mano que abarcan funciones de distancia, operaciones matrices y computación geoespacial.

Cada proyecto cumple un propósito diferente y realiza diferentes concesiones. Incluimos números de referencia de ellos para dar contexto al rendimiento de simdvec en las operaciones específicas que Elasticsearch necesita.

Cómo medimos

Las evaluaciones de simdvec y jvector están escritos en Java con JMH, la microevaluación estándar de JVM, lo que incluye la sobrecarga de FFI. Para las evaluaciones de NumKong y las evaluaciones de FAISS, escribimos pequeños marcos de prueba de C/C++ con Google Benchmark, que es el marco de trabajo estándar para microevaluaciones de C++. Ambos marcos de trabajo reportan nanosegundos por operación con calibración de calentamiento e iteración. Verificamos mediante contadores de rendimiento de hardware que todas las bibliotecas usan SIMD en ambas plataformas. Todo el código de evaluación está disponible públicamente en los repositorios enlazados de GitHub (y, en el caso de simdvec, en el repositorio elasticsearch).

Software: JDK 25.0.2, JMH 1.37, GCC 14, Google Benchmark (última versión).

Un vector a la vez

La operación más básica en la búsqueda vectorial es calcular la distancia entre dos vectores. Cada evaluación de un vecino de HNSW, cada puntaje de un candidato a IVF, cada comparación de reclasificación se reduce a este bucle interno.

Medimos el rendimiento de un solo par en 1024 dimensiones en ambas plataformas, empezando por float32, el tipo base y el donde el ecosistema es más competitivo. Comparamos simdvec con FAISS y jvector; hemos excluido NumKong porque utiliza acumuladores float64 para float32, lo que lo hace entre 3,2 y 5,3 veces más lento (dependiendo de la plataforma), ya que prioriza la precisión numérica por encima del rendimiento. Para mantener la comparación de igual a igual, evaluamos NumKong en int8 en su lugar, donde utiliza la misma estrategia de acumulador que simdvec.

En la arquitectura x86, FAISS AVX-512 es el kernel de par único más rápido, con un tiempo de ejecución de 23 ns. A continuación, se ejecuta Simdvec AVX-512 a los 28 ns, un intervalo que refleja la sobrecarga de la llamada FFI. Ambos emplean FMA de 512 bits con desenrollado de múltiples acumuladores. A nivel AVX2, los dos valores son mucho más similares, 36 ns y 39 ns respectivamente, ambos limitados por el ancho de carga de memoria y registro de 256 bits. jvector tarda 44 ns usando la API de Java Panama Vector. Panamá genera buen código SIMD, pero las funciones intrínsecas de C++ ajustadas manualmente siguen teniendo ventaja.

En ARM, simdvec lidera a 70 ns, muy por delante de jvector a 110 ns y FAISS a 156 ns. Simdvec tiene kernels NEON ajustados a mano para aarch64. Jvector no tiene código ARM nativo y depende de Panama. FAISS se basa en la auto-vectorización del compilador en lugar de en las intrínsecas NEON explícitas, lo que explica la mayor brecha. Esto refleja una ventaja práctica de poseer la biblioteca del kernel: cuando Elasticsearch se expandió a Graviton, agregamos kerneles NEON especialmente diseñados. Ni jvector ni FAISS priorizaron el código nativo de ARM en la misma medida.

Sin embargo, Elasticsearch no solo puntúa float32. La cuantificación Int8 reduce la memoria en 4x, bfloat16 en 2x y BBQ en 32x. Cada tipo necesita su propia estrategia SIMD, y simdvec proporciona kernels nativos ajustados a mano para todos ellos.

De todas las bibliotecas que comparamos, solo NumKong tiene kernels comparables para int8. Medimos el producto escalar int8, la distancia euclidiana al cuadrado y el coseno en 1024 dimensiones.

Puntuación de par único Int8 (1024 dimensiones, ns/vec op — cuanto más bajo, mejor)

En ambas arquitecturas, NumKong es igual o más rápido en dimensiones pequeñas y medias, donde la diferencia se debe en gran parte a una menor sobrecarga de llamadas (llamada C directa vs FFI en Java). En dimensiones mayores, simdvec se pone al día, donde la implementación más eficiente del kernel (que emplea desenrollamiento en cascada) amortiza el costo de llamada: a medida que aumenta la dimensión, esta brecha se cierra y finalmente se revierte. El cruce está en dimensiones entre 768 y 1536, dependiendo de la función y la arquitectura.

A pesar de la sobrecarga ligeramente mayor de Java FFI, simdvec está a la par con las bibliotecas altamente optimizadas de C/C++. No solo es la única librería con kernels optimizados tanto para float32 como para int8, sino que también lidera en ARM y solo está ligeramente por detrás de FAISS en x86 (para float32), y muy cerca de NumKong en ambas arquitecturas (para int8). Y en el caso de bfloat16, int4, binary y BBQ, aunque existen alternativas, simdvec se distingue por su SIMD ajustado manualmente y adaptado a la estructura de datos de cada tipo.

Pero un motor de búsqueda en producción no califica un vector a la vez; califica miles por consulta. La siguiente pregunta es qué sucede a esa escala.

Miles a la vez

El rendimiento de un solo par es solo una parte del panorama. Lo que importa en la práctica es cómo se comportan los sistemas bajo carga. Una sola consulta HNSW puede puntuar cientos de vecinos de grafos. Un escaneo de IVF puede puntuar miles de entradas en la lista de publicaciones. Un paso de reclasificación puede puntuar decenas de miles de candidatos. El rendimiento por par individual es importante, pero lo que más importa es la rapidez con la que puedes puntuar muchos vectores, y cómo se degrada el rendimiento de forma gradual a medida que el conjunto de trabajo se desborda de las cachés de la CPU.

Simdvec proporciona evaluación masiva para todos los tipos de datos. No son solo bucles sobre kernels de un solo par; usan bucles internos de varios acumuladores que cargan el vector de búsqueda una vez por paso de dimensión y lo comparten entre varios vectores de documentos, con precarga explícita de líneas de caché para el siguiente batch. Ni jvector ni FAISS ofrecen un equivalente (en el momento de redacción de esta publicación). Jvector no tiene una API de bulk, así que quien llama puntúa un par a la vez en un bucle. FAISS expone fvec_inner_products_ny que, en el momento de redacción de esta publicación, está implementado como un bucle sobre su función de distancia de un solo par, sin amortización de la búsqueda ni precarga.

Float32. Para medir el impacto a nivel del kernel, puntuamos una sola consulta contra un número creciente de vectores de documentos float32 de 1024 dimensiones con patrones de acceso aleatorio que simulan búsquedas de vecinos de grafos dispersos similares a HNSW. Los tres tamaños de sets de datos, 32, 625 y 32 500 vectores, se eligen para que el conjunto de trabajo supere la caché L1, L2 y L3, respectivamente.

Cuando los datos caben en la caché, simdvec es el más rápido en ambas plataformas, pero las diferencias son modestas, ya que predomina la aritmética del kernel. La separación real se nota cuando el conjunto de trabajo supera el tamaño de L3. En x86, simdvec alcanza los 95 ns por vector, mientras que FAISS necesita 165 ns y jvector 412 ns. En ARM, la tendencia es la misma: simdvec se mantiene en 162 ns, mientras que FAISS sube a 347 ns y jvector a 476 ns. La precarga y la amortización de búsquedas en simdvec mantienen la latencia de memoria oculta de una manera que un bucle simple sobre kerneles de par único no puede coincidir y el beneficio se amplía precisamente donde operan las cargas de búsqueda reales, en lo profundo de la memoria principal.

Int8. Lo mismo ocurre con los tipos cuantificados. Medimos el rendimiento del cálculo del producto escalar int8 en 1024 dimensiones con sets de datos de un tamaño tal que superaran los límites de las cachés L1, L2 y L3, en comparación con el cálculo en bloque de simdvec con el cálculo de pares individuales de NumKong en un bucle.

En x86, simdvec es entre 1,2 y 1,9 veces más rápido, impulsado por la combinación de precarga explícita y procesamiento por lotes. En ARM, simdvec gana de nuevo (1,7 a 1,9 veces más rápido) en todos los tamaños de sets de datos. La ventaja radica en el procesamiento por lotes de cuatro vectores a la vez, lo que proporciona paralelismo a nivel de memoria mediante un patrón de acceso intercalado. En ambos casos, el resultado más llamativo es lo que ocurre en el mayor tamaño de set de datos, donde más importa.

Los resultados para la distancia al cuadrado y el coseno muestran un patrón similar, con aceleraciones de 1,4 a 1,8 veces para ARM, y de 1,3 a 3,0 veces para x86 (detalles aquí).

Cuando la memoria importa

Los índices de vectores de producción normalmente no caben en la caché de la CPU. Un índice de 10M-vectores int8 a 1024 dimensiones es de 10 GB. La evaluación de candidatos implica el procesamiento en flujo continuo de datos desde la DRAM y ahí es donde la arquitectura de evaluación masiva marca la diferencia.

Usamos contadores de rendimiento de hardware para medir lo que sucede dentro de la CPU durante la puntuación masiva y descubrimos que ocultar la latencia de la memoria requiere dos estrategias fundamentalmente diferentes, una por arquitectura.

En x86, la precarga explícita elimina los fallos de caché. El kernel masivo procesa los vectores secuencialmente, uno completamente calculado antes del siguiente, mientras emite instrucciones de precarga para el siguiente batch. Los datos futuros se cargan en la L1 antes de que la CPU los necesite.

En ARM, el mismo enfoque secuencial tuvo un rendimiento deficiente, incluso con precarga. En cambio, el kernel masivo entrelaza las cargas de cuatro vectores en cada posición de zancada, lo que proporciona al motor fuera de orden cuatro flujos de memoria independientes. La CPU no recoge datos más rápido, sino que espera menos al tener siempre algo más que calcular mientras las solicitudes de memoria están en curso. Puedes encontrar un análisis detallado en este ticket de GitHub.

Los números cuentan dos historias diferentes:

1. En x86, la precarga convierte 139K fallos de caché en 19K y las instrucciones por ciclo (IPC) se duplican más de dos veces. La ventaja de masa crece con el tamaño de los sets de datos, de 1,2 veces en L2 a 2,8 veces más allá de L3, porque la precarga oculta progresivamente viajes de ida y vuelta de DRAM más costosos.

2. En ARM, los fallos de caché apenas cambian. Lo que cambia es la utilización: las interrupciones del backend disminuyen un 40 % porque el patrón de acceso intercalado mantiene el pipeline alimentado. Esta ventaja se mantiene en un consistente 1,8 veces independientemente del tamaño del sets de datos, porque el paralelismo a nivel de memoria se aplica tanto si los datos provienen de la caché como de la DRAM.

Dos arquitecturas, dos estrategias y un resultado: a escala de producción, simdvec mantiene la pipeline de la CPU ocupada incluso cuando los vectores están dispersos por la memoria principal.

Qué significa esto para los usuarios de Elasticsearch

Estas capacidades a nivel de kernel se potencian entre sí. Una única consulta de búsqueda vectorial puede calcular millones de operaciones de distancia: recorrido del grafo HNSW, puntuación de candidatos, reclasificación. En miles de búsquedas concurrentes, los nanosegundos por operación se traducen directamente en latencia de búsqueda y rendimiento del cluster. Tanto si usas float32, int8, bfloat16 o BBQ, tanto si tu índice está en la memoria como en el disco, simdvec es el motor subyacente, y cada una de esas operaciones pasa por el mismo motor, lo que optimiza hasta el último nanosegundo.

La conclusión clave es que, a escala de producción, el rendimiento de la búsqueda vectorial no está determinado principalmente por el rendimiento bruto de SIMD. Lo que marca la diferencia es la eficiencia con la que el sistema oculta la latencia de la memoria mientras mantiene el rendimiento computacional en millones de operaciones pequeñas.

Los kerneles de simdvec mejoran prácticamente con cada versión de Elasticsearch. Cuando surgen nuevos tipos de cuantización y plataformas de hardware, reciben kerneles ajustados desde el primer día. Y los tipos existentes siguen ganando velocidad a medida que perfeccionamos las implementaciones que ya están disponibles.

¿Por qué importa esto?

La mayoría de los flujos de trabajo analíticos típicos acaban reduciéndose a agrupar datos. Ya sea para calcular el promedio de bytes por host, contar eventos por usuario o agregar métricas en diferentes dimensiones, la operación de núcleo es la misma: asignar claves a grupos y actualizar los agregados en ejecución.

A pequeña escala, casi cualquier tabla hash razonable funciona bien. A gran escala (cientos de millones de documentos y millones de grupos distintos), los detalles empiezan a importar. Los factores de carga, la estrategia de sondeo, el diseño de la memoria y el comportamiento de la memoria caché pueden marcar la diferencia entre un rendimiento lineal y una barrera de fallos de caché.

Elasticsearch ha soportado estas cargas de trabajo durante años, pero siempre estamos buscando oportunidades para modernizar los algoritmos de núcleo. Por lo tanto, evaluamos un enfoque más reciente inspirado en las tablas suizas y lo aplicamos a cómo ES|QL calcula las estadísticas.

¿Qué son realmente las tablas suizas?

Las tablas suizas son una familia de tablas hash modernas popularizadas por la SwissTable de Google y posteriormente adoptadas en Abseil y otras bibliotecas.

Las tablas hash tradicionales pasan mucho tiempo persiguiendo punteros o cargando claves solo para descubrir que no coinciden. La característica definitoria de las tablas suizas es la capacidad de rechazar la mayoría de las sondas usando una pequeña estructura de matriz residente en caché, almacenada separadamente de las claves y valores, llamadas bytes de control, para reducir significativamente el tráfico de memoria.

Cada byte de control representa un solo slot y, en nuestro caso, codifica dos cosas: si el slot está vacío y una huella corta derivada del hash. Estos bytes de control están dispuestos de forma continua en la memoria, típicamente en grupos de 16, lo que los hace ideales para el procesamiento de una sola instrucción y múltiples datos (SIMD).

En lugar de sondear una ranura a la vez, las tablas suizas escanean todo un bloque de bytes de control utilizando instrucciones vectoriales. En una sola operación, la CPU compara la huella digital de la clave entrante con 16 ranuras y filtra las entradas vacías. Solo los pocos candidatos que sobreviven a esta ruta rápida requieren cargar y comparar las claves reales.

Este diseño intercambia una pequeña cantidad de metadatos adicionales por una mejor localización de caché y muchas menos cargas aleatorias. A medida que la tabla crece y las cadenas de sonda se alargan, esas propiedades se vuelven cada vez más valiosas.

SIMD en el centro

La verdadera estrella del espectáculo es SIMD.

Los bytes de control no solo son compactos, sino que también están diseñados explícitamente para ser procesados con instrucciones vectoriales. Una sola comparación SIMD puede verificar 16 huellas dactilares a la vez, lo que convierte lo que normalmente sería un bucle en un puñado de operaciones amplias. Por ejemplo:

En la práctica, esto significa:

• Menos ramas.

• Cadenas de sondeo más cortas.

• Menos cargas de la memoria de claves y valores.

• Mucho mejor utilización de las unidades de ejecución de la CPU.

La mayoría de las búsquedas nunca pasan del escaneo de bytes de control. Cuando lo hacen, el trabajo restante es enfocado y previsible. Este es precisamente el tipo de carga de trabajo en el que destacan las CPU modernas.

SIMD bajo el capó

Para los lectores a quienes les gusta echar un vistazo por dentro, aquí está lo que sucede al insertar una nueva clave en la tabla. Utilizamos la API Panama Vector con vectores de 128 bits, por lo que opera en 16 bytes de control en paralelo.

El siguiente fragmento muestra el código generado en un Intel Rocket Lake con AVX-512. Aunque las instrucciones reflejan ese entorno, el diseño no depende de AVX-512. Las mismas operaciones vectoriales de alto nivel se emiten en otras plataformas usando instrucciones equivalentes (por ejemplo, AVX2, SSE o NEON).

Cada instrucción tiene una función clara en el proceso de inserción:

• vmovdqu: Carga 16 bytes de control consecutivos en el registro xmm0 de 128 bits.

• vpbroadcastb:Replica la huella digital de 7 bits de la nueva clave en todos los carriles del registro xmm1.

• vpcmpeqb: Compara cada byte de control con la huella digital transmitida, lo que genera una máscara de posibles coincidencias.

• kmovq + test: Mueve la máscara a un registro de propósito general y comprueba rápidamente si existe una coincidencia.

Finalmente, decidimos sondear grupos de 16 bytes de control a la vez, ya que las pruebas de rendimiento mostraron que expandirse a 32 o 64 bytes con registros más amplios no proporcionaba ningún beneficio de rendimiento medible.

Integración en ES|QL

Adoptar el hash al estilo suizo en Elasticsearch no fue solo un reemplazo inmediato. ES|QL tiene exigencias estrictas en cuanto a contabilidad de memoria, seguridad e integración con el resto del motor de cálculo.

Integramos la nueva tabla hash estrechamente con la gestión de memoria de Elasticsearch, que incluye el reciclador de páginas y la contabilidad del interruptor de circuito, lo que garantiza que las asignaciones permanezcan visibles y limitadas. Las agregaciones de Elasticsearch se almacenan densamente y se indexan por un ID de grupo, lo que mantiene el diseño de memoria compacto y rápido para la iteración, además de habilitar ciertas optimizaciones de rendimiento al permitir el acceso aleatorio.

Para las claves de bytes de longitud variable, almacenamos en caché el hash completo junto con el ID del grupo. Esto evita la recomputación de costosos códigos hash durante el sondeo y mejora la localidad de la caché al mantener los metadatos relacionados juntos. Durante el reprocesamiento, podemos confiar en el hash en caché y en los bytes de control sin inspeccionar los valores en sí, lo que mantiene bajos los costos de redimensionamiento.

Una simplificación importante en nuestra implementación es que las entradas nunca se eliminan. Esto elimina la necesidad de marcadores (marcadores para identificar ranuras previamente ocupadas) y permite que las ranuras vacías permanezcan verdaderamente vacías, lo que mejora aún más el comportamiento de la sonda y mantiene eficientes los escaneos de bytes de control.

El resultado es un diseño que se ajusta naturalmente al modelo de ejecución de Elasticsearch a la vez que preserva las características de rendimiento que hacen atractivas a las tablas suizas.

¿Cómo funciona?

En cardinalidades pequeñas, las tablas suizas rinden aproximadamente al mismo nivel que la implementación existente. Esto es lo que se espera: cuando las tablas son pequeñas, los efectos de la caché tienen menos importancia y hay poco que optimizar.

A medida que aumenta la cardinalidad, la imagen cambia rápidamente.

El mapa de calor anterior traza los factores de mejora del tiempo para diferentes tamaños de clave (8, 32, 64 y 128 bytes) en cardinalidades desde 1,000 hasta 10,000,000 de grupos. A medida que aumenta la cardinalidad, el factor de mejora aumenta constantemente, y llega a hasta 2–3x para distribuciones uniformes.

Esta tendencia es exactamente lo que predice el diseño. Una cardinalidad más alta conduce a cadenas de sondeo más largas en las tablas hash tradicionales, mientras que el sondeo de estilo suizo continúa resolviendo la mayoría de las búsquedas dentro de los bloques de bytes de control amigables con SIMD.

El comportamiento de la caché cuenta la historia

Para comprender mejor las aceleraciones, ejecutamos el mismo JMH benchmarks en Linux perf y capturamos estadísticas de caché y TLB.

En comparación con la implementación original, la versión suiza realiza aproximadamente un 60% menos de referencias de caché en general. Las cargas de la caché de último nivel disminuyen más de 4 veces, y los fallos de carga de la LLC caen en más de 6 veces. Dado que las omisiones de LLC a menudo se traducen directamente en accesos a la memoria principal, esta reducción por sí sola explica una gran parte de la mejora de extremo a extremo.

Más cerca de la CPU, vemos menos pérdidas de caché de datos L1 y casi 6 veces menos pérdidas TLB de datos, lo que apunta a una localidad espacial más estrecha y patrones de acceso a la memoria más predecibles.

Esta es la recompensa práctica de los bytes de control compatibles con SIMD. En lugar de cargar repetidamente claves y valores desde ubicaciones de memoria dispersas, la mayoría de las pruebas se resuelven escaneando una estructura compacta residente en la caché. Menos memoria afectada significa menos fallos, y menos fallos significan consultas más rápidas.

Resumen

Al adoptar un diseño de tabla hash al estilo suizo y al inclinarnos por el sondeo amigable con SIMD, logramos una velocidad de 2 a 3 veces mayor para cargas de trabajo de estadísticas ES|QL de alta cardinalidad, junto con un rendimiento más estable y predecible.

Este trabajo destaca cómo las estructuras de datos modernas con conocimiento de CPU pueden desbloquear ganancias sustanciales, incluso para problemas bien conocidos, como las tablas hash. Hay más para explorar aquí, como especializaciones adicionales de tipo primitivo y el uso en otras rutas de alta cardinalidad, como las uniones, que son solo parte del esfuerzo más amplio y continuo para modernizar continuamente los internos de Elasticsearch.

Si te interesan los detalles o quieres seguir el trabajo, echa un vistazo a esta solicitud de extracción y problema meta en Github.

¡Feliz hash!

Resumen

Primero, pongámonos al día. Elasticsearch se consolidó como una poderosa base de datos vectorial, que ofrece un amplio conjunto de características y un sólido rendimiento para la búsqueda de similitudes a gran escala. Con capacidades como la cuantificación escalar, Better Binary Quantization (BBQ), operaciones vectoriales SIMD y algoritmos más eficientes en disco como DiskBBQ, ya ofrece opciones eficientes y flexibles para gestionar cargas de trabajo vectoriales.

Al integrar NVIDIA cuVS como un módulo invocable para tareas de búsqueda vectorial, nuestro objetivo es ofrecer beneficios significativos en el rendimiento y la eficiencia de la indexación vectorial para soportar mejor las cargas de trabajo vectoriales a gran escala.

El desafío

Uno de los mayores desafíos al construir una base de datos vectorial de alto rendimiento es construir el índice vectorial: el grafo HNSW. La construcción de índices se ve dominada con rapidez por millones o incluso miles de millones de operaciones aritméticas a medida que cada vector se compara con muchos otros. Además, las operaciones del ciclo de vida del índice, como la compactación y las fusiones, pueden aumentar aún más la sobrecarga total de cálculo de la indexación. A medida que los volúmenes de datos y las incrustaciones vectoriales asociadas crecen de manera exponencial, las GPU de cómputo acelerado, diseñadas para el paralelismo masivo y las matemáticas de alto rendimiento, se posicionan idealmente para manejar estas cargas de trabajo.

Ingresa al plugin Elasticsearch-GPU

NVIDIA cuVS es una biblioteca open source de CUDA-X para la búsqueda vectorial acelerada por GPU y la agrupación de datos, que permite una rápida construcción de índices y recuperación de incrustaciones para cargas de trabajo de AI y de sistemas de recomendación.

Elasticsearch utiliza cuVS a través de cuvs-java, una biblioteca open source desarrollada por la comunidad y que mantiene NVIDIA. La biblioteca cuvs-java es ligera, se basa en la API C de cuVS y usa la función externa del Proyecto Panamá para exponer las características de cuVS de una manera idiomática en Java, al tiempo que es moderna y presenta un alto rendimiento.

La biblioteca cuvs-java está integrada en un nuevo plugin de Elasticsearch; por lo tanto, la indexación vectorial en la GPU puede ocurrir en el mismo nodo y proceso de Elasticsearch, sin la necesidad de provisionar ningún código o hardware externo. Durante la construcción del índice, si se instala la biblioteca cuVS y hay una GPU presente y configurada, Elasticsearch usará la GPU para acelerar el proceso de indexación vectorial. Los vectores se asignan a la GPU, que construye un grafo CAGRA. Este grafo se convierte entonces al formato HNSW, y hace que esté disponible de inmediato para la búsqueda vectorial en la CPU. El formato final del grafo construido es el mismo que el que se construiría en la CPU; esto permite a Elasticsearch aprovechar las GPU para indexar vectores de alto rendimiento cuando el hardware subyacente lo admite, al tiempo que libera poder de la CPU para otras tareas (búsqueda simultánea, procesamiento de datos, etc.).

Aceleración en la generación de índices

Como parte de la integración de la aceleración de GPU en Elasticsearch, se realizaron varias mejoras en cuvs-java, centradas en la entrada/salida eficiente de datos y la invocación de funciones. Una mejora clave es el uso de cuVSMatrix para modelar vectores de forma transparente, ya sea que residan en la memoria heap de Java, fuera de la memoria heap o en la memoria de la GPU. Esto permite que los datos se muevan de manera eficiente entre la memoria y la GPU, lo que evita copias innecesarias de potencialmente miles de millones de vectores.

Gracias a esta abstracción subyacente de copia cero, tanto la transferencia a la memoria de la GPU como la recuperación del grafo se pueden realizar directamente. Durante la indexación, los vectores se almacenan primero en búfer en la memoria heap de Java, y luego se envían a la GPU para construir el grafo CAGRA. Después, el grafo se recupera de la GPU, se convierte al formato HNSW y se mantiene en el disco.

En el momento de la fusión, los vectores ya están almacenados en disco, sin pasar por la memoria heap de Java. Los archivos de índice se mapean en memoria, y los datos se transfieren directamente a la memoria de la GPU. El diseño también se adapta fácilmente a diferentes anchos de bits, como float32 o int8, y se extiende de forma natural a otros esquemas de cuantificación.

Redoble de tambores… entonces, ¿cómo se funciona?

Antes de entrar en los números, un poco de contexto es útil. La fusión de segmentos en Elasticsearch suele ejecutarse automáticamente en segundo plano durante la indexación, lo que dificulta hacer benchmarks de forma aislada. Para obtener resultados reproducibles, utilizamos la fusión forzosa para activar explícitamente la combinación de segmentos en un experimento controlado. Dado que la fusión forzosa hace las mismas operaciones de fusión subyacentes que la fusión en segundo plano, su rendimiento sirve como un indicador útil de las mejoras esperadas, aunque las ganancias exactas pueden diferir en las cargas de trabajo de indexación del mundo real.

Ahora, veamos los números.

Nuestros resultados iniciales de evaluaciones comparativas son muy prometedores. Ejecutamos la evaluación comparativa en una instancia de AWS g6.4xlarge con almacenamiento NVMe conectado a nivel local. Se configuró un único nodo de Elasticsearch para que use el número predeterminado y óptimo de subprocesos de indexación (8, uno por cada núcleo físico) y deshabilite la limitación de la fusión (que es menos aplicable con discos NVMe rápidos).

Para el conjunto de datos, utilizamos 2,6 millones de vectores con 1536 dimensiones del vector de pista de Rally de OpenAI, codificados como cadenas de texto base64 e indexados como float32 hnsw. En todos los escenarios, los grafos construidos alcanzan niveles de recuperación de hasta el 95 %. A continuación, presentamos nuestros hallazgos:

• Rendimiento de indexación: al trasladar la construcción de grafos a la GPU durante los vaciados de búferes en memoria, aumentamos el rendimiento en aproximadamente 12 veces.

• Fusión forzada: una vez que finaliza la indexación, la GPU continúa acelerando la fusión de segmentos, lo que acelera la fase de fusión forzada en alrededor de 7 veces.

• Uso de la CPU: descargar la construcción de grafos a la GPU reduce de manera significativa el uso promedio y máximo de la CPU. Los grafos a continuación ilustran el uso de la CPU durante la indexación y la fusión, y permiten ver cuánto menor es cuando estas operaciones se ejecutan en la GPU. Un menor uso de la CPU durante la indexación por GPU libera ciclos de CPU que pueden redirigirse para mejorar el rendimiento de la búsqueda.

• Recuperación: la precisión se mantiene prácticamente igual entre las ejecuciones de CPU y GPU, y el grafo construido por la GPU alcanza una recuperación un poco mayor.

Comparación en otra dimensión: el precio

La comparación anterior utilizaba intencionalmente hardware idéntico, y la única diferencia era si se usaba la GPU durante la indexación o no. Esa configuración es útil para aislar los efectos de la computación en bruto, pero también podemos analizar la comparación desde una perspectiva de costos.

A un precio horario similar al de la configuración acelerada por GPU, se puede provisionar una configuración de solo CPU con aproximadamente el doble de recursos comparables de CPU y memoria: 32 vCPUs (AMD EPYC) y 64 GB de RAM, lo que permite duplicar el número de hilos de indexación a 16.

Para mantener la comparación justa y consistente, ejecutamos este experimento solo de CPU en una instancia AWS g6.8xlarge, con la GPU explícitamente desactivada. Esto nos permitió mantener constantes todas las demás características del hardware mientras evaluábamos la compensación entre costo y rendimiento de la aceleración de GPU frente al indexado solo con CPU.

Como era de esperar, la instancia de CPU más potente sí muestra un mejor rendimiento en comparación con las evaluaciones comparativas de la sección anterior. Sin embargo, cuando comparamos esta instancia de CPU más potente con los resultados acelerados por GPU originales, la GPU aún ofrece beneficios sustanciales en cuanto al rendimiento: ~ 5 veces de mejora en el rendimiento de indexación y ~ 6 veces en la fusión forzada, todo ello mientras se construyen grafos que alcanzan niveles de recuperación de hasta un 95 %.

Conclusión

En escenarios completos, la aceleración por GPU con NVIDIA cuVS ofrece una mejora de casi 12 veces en el rendimiento de la indexación y una disminución de 7 veces en la latencia de fusión forzada, con un uso de CPU significativamente menor. Esto demuestra que la indexación vectorial y las cargas de trabajo de fusión se benefician de manera significativa de la aceleración por GPU. En una comparación ajustada por costos, la aceleración por GPU continúa mostrando beneficios sustanciales en cuanto al rendimiento, con alrededor de 5 veces más rendimiento de indexación y 6 veces más rapidez en las operaciones de fusión forzada.

La indexación vectorial acelerada por GPU tiene planificada hoy en día una vista previa técnica en Elasticsearch 9.3, cuyo lanzamiento está programado para principios de 2026.

Mantente atento a lo que viene.

Como parte de nuestra misión de no dejar atrás la eficiencia, estamos explorando oportunidades de aceleramiento con estos curiosos chips de computadora, de los que quizás oíste hablar: ¡las GPU NVIDIA! (En serio, ¿no es así?).

Cuando nos obsesionamos con el rendimiento, tenemos varios espacios problemáticos para explorar: cómo indexar exponencialmente más datos, cómo recuperar información de ellos y cómo hacerlo cuando sus modelos de ML están involucrados. Debería poder obtener hasta el último beneficio disponible cuando tenga GPU.

En esta publicación, nos sumergimos en nuestra colaboración con el equipo de búsqueda vectorial de NVIDIA mientras exploramos la búsqueda vectorial acelerada por GPU en Elasticsearch. Este trabajo allana el camino para casos de uso en los que los desarrolladores podrían usar una combinación de GPU y CPU para aplicaciones con tecnología de Elasticsearch del mundo real. ¡Tiempos emocionantes!

GPU de Elasticsearch

Nos complace compartir que el equipo de ingeniería de Elasticsearch está ayudando a crear la experiencia de la API de Java cuVS de código abierto para desarrolladores, que expone enlaces para algoritmos de búsqueda vectorial. Este trabajo aprovecha nuestra experiencia previa con Panama FFI. Elasticsearch y Apache Lucene emplean la API NVIDIA cuVS para crear el gráfico durante la indexación. Bien, estamos saltando hacia adelante; Rebobinemos un poco.

NVIDIA cuVS, una biblioteca de C++ de código abierto, está en el corazón de esta colaboración. Su objetivo es llevar el aceleramiento de GPU a la búsqueda vectorial al proporcionar un mayor rendimiento, menor latencia y tiempos de compilación de índices más rápidos. Pero Elasticsearch y Apache Lucene están escritos en Java; ¿Cómo funcionará esto?

Ingrese lucene-cuvs y la colaboración Elastic-NVIDIA-SearchScale para llevarlo al ecosistema de Lucene para explorar la búsqueda vectorial acelerada por GPU en Elasticsearch. En la reciente versión 25.02 de NVIDIA cuVS, agregamos una API de Java para cuVS. La nueva API es experimental y seguirá evolucionando, pero actualmente está disponible para su uso. Puede surgir la pregunta: ¿no son lentas las llamadas de Java a funciones nativas? ¡Ya no! Estamos usando la nueva FFI (interfaz de funciones externas) de Panamá para los enlaces, que tiene una sobrecarga mínima para Java a las llamadas descendentes nativas.

Estuvimos usando Panama FFI en Elasticsearch y Lucene desde hace un tiempo. ¡Es asombroso! Pero... Siempre hay un "pero", ¿no? FFI tiene desafíos de disponibilidad en todas las versiones de Java. Superamos esto compilando la API de cuVS en Java 21 y encapsulando la implementación dentro de un jar de varias versiones dirigido a Java 22. Esto permite el uso de cuVS Java directamente en Lucene y Elasticsearch.

Ok, ahora que tenemos la API de Java de cuVS, ¿qué más necesitaríamos?

Una historia de dos algoritmos para CPU

Elasticsearch admite el algoritmo HNSW para una búsqueda KNN aproximada escalable. Sin embargo, para sacar el máximo provecho de la GPU, empleamos un algoritmo diferente, CAGRA [CUDA ANN GRAph], que fue diseñado específicamente para los altos niveles de paralelismo que ofrece la GPU.

Antes de entrar en cómo buscamos agregar soporte para CAGRA, veamos cómo Elasticsearch y Lucene acceden a los datos del índice a través de un "formato de códec". Consiste en

1. la representación en disco,

2. las interfaces para leer y escribir datos,

3. y la maquinaria para lidiar con la arquitectura basada en segmentos de Lucene.

Estamos implementando un nuevo formato vectorial KNN (k-vecinos más cercanos) que emplea internamente la API de Java de cuVS para indexar y buscar en la GPU. A partir de aquí, "sondeamos" este tipo de códec a través de las asignaciones de Elasticsearch a un tipo de campo en el índice. Como resultado, las consultas KNN existentes siguen funcionando independientemente de si el índice de respaldo emplea un gráfico CAGRA o HNSW. Por supuesto, esto pasa por alto muchos detalles, que planeamos cubrir en un blog futuro. La siguiente es la arquitectura de alto nivel para un Elasticsearch acelerado por GPU.

Este nuevo formato de códec tiene como valor predeterminado CAGRA. Sin embargo, también admite la conversión de un gráfico CAGRA en un gráfico HNSW para la búsqueda en la CPU.

Indexación y búsqueda en la GPU: Tomar algunas decisiones "básicas"

Con la arquitectura sin estado de Elasticsearch Serverless, que separa la indexación y la búsqueda, ahora hay una clara delimitación de responsabilidades. Elegimos el mejor perfil de hardware para cumplir con cada una de estas responsabilidades independientes.

Anticipamos que los usuarios considerarán dos estrategias de implementación principales:

1. Indexación y búsqueda en la GPU: durante la indexación, cree un gráfico CAGRA y empléelo durante la búsqueda, ideal cuando se requiere una búsqueda de latencia extremadamente baja.

2. Indexar en GPU y buscar en CPU: durante la indexación, cree un gráfico CAGRA y conviértalo en un gráfico HNSW. El gráfico HNSW se almacena en el índice, que luego se puede usar en la CPU para la búsqueda.

Esta flexibilidad proporciona diferentes modelos de implementación, ofreciendo compensaciones entre costo y rendimiento. Por ejemplo, un servicio de indexación podría usar GPU para compilar y combinar gráficos de manera eficiente de manera oportuna mientras usa una CPU de menor potencia para la búsqueda.

Así que aquí está el plan para la búsqueda vectorial acelerada por GPU en Elasticsearch

Esperamos brindar ganancias de rendimiento y flexibilidad con estrategias de implementación a los usuarios, ofreciendo varias perillas para equilibrar el costo y el rendimiento. Aquí está la sesión de NVIDIA GTC 2025 donde se presentó este trabajo en detalle.

Nos gustaría agradecer a los equipos de ingeniería de NVIDIA y SearchScale por su fantástica colaboración. En un próximo blog, exploraremos los detalles de implementación y el análisis de rendimiento con mayor profundidad. ¡Agárrate a tus sombreros de 🎩 curiosidad!

Lucene y la comunidad

Un proyecto solo es tan fuerte como la comunidad que lo apoya. A pesar de más de 20 años de desarrollo, el proyecto Lucene sigue siendo vibrante y prospera gracias a sus colaboradores apasionados y activos.

En 2024, el proyecto Lucene recibió más de 2.000 commits de 98 colaboradores únicos y casi 800 pull requests. El número de colaboradores sigue creciendo, con nuevos comprometedores y afiliados a PMC que se unen al proyecto y contribuyen a su éxito.

Lucene 10

En 2024 se produjo el primer gran lanzamiento en casi 3 años: Lucene 10, con más de 2.000 commits de 185 colaboradores únicos. Aunque el modelo de desarrollo que sigue Lucene permite ofrecer muchas mejoras y características en lanzamientos menores, un lanzamiento importante ofrece la oportunidad de aportar funciones y modernizaciones más grandes. Por ejemplo, Lucene 10 requiere un mínimo de Java 21. Aumentar la versión mínima de Java garantiza que Lucene pueda seguir aprovechando las mejoras que ofrece Java moderno.

El objetivo principal de Lucene 10 es aprovechar mejor el hardware sobre el que se ejecuta. Echemos un vistazo rápido a algunos de los principales puntos destacados:

• Más paralelismo en la búsqueda : aunque la ejecución de búsqueda ya está paralelizada entre segmentos, ahora vamos más allá, paralelizando dentro de los segmentos. Esto desacopla la representación en disco del rendimiento de ejecución, permitiendo que incluso segmentos individuales se beneficien del número de núcleos en sistemas modernos.

• Mejor paralelismo de E/S : el modelo sincrónico de E/S sencillo que emplea Lucene fue mejorado con una etapa de prelectura. Esto informa al sistema operativo de que se necesitará una región de un archivo índice en un futuro muy próximo, sin bloquear el hilo que llama.

• Mejor eficiencia de CPU y almacenamiento con indexación dispersa - Lucene 10 introduce soporte para indexación dispersa, a veces llamada indexación de clave primaria o indexación por zonas en otros almacenes de datos.

Para más información sobre Lucene 10, consulta el artículo dedicado a Lucene 10.

Investigación e innovación de Lucene

En 2024, Lucene experimentó un auge de investigación e innovación, especialmente en las áreas de integración de aprendizaje automático, búsqueda vectorial y optimización para conjuntos de datos a gran escala, con 10 artículos y publicaciones de investigación de referencia separados. Algunas de las áreas y desarrollos clave de investigación incluyen:

• Soporte para búsqueda vectorial e incrustación - Lucene ofrece una solución poderosa y escalable para la búsqueda basada en vectores, permitiendo la recuperación semántica a gran escala. Aprovechando la robusta infraestructura de indexación y búsqueda de Lucene, los usuarios pueden combinar lo mejor de la búsqueda tradicional de texto con las avanzadas capacidades de la búsqueda vectorial moderna, convirtiendo Lucene en una solución integral para una amplia gama de tareas de búsqueda y recuperación de información.

• Modelos de búsqueda híbrida - La investigación también profundizó en técnicas de búsqueda híbrida, donde Lucene combina la búsqueda tradicional basada en palabras clave con la recuperación moderna basada en vectores. Al combinar índices basados en términos con representaciones vectoriales densas, Lucene puede ofrecer resultados de búsqueda más precisos y contextualmente relevantes, cerrando la brecha entre la precisión de los motores de búsqueda tradicionales y la flexibilidad de la búsqueda semántica.

Los esfuerzos de investigación en curso en 2024 demuestran la adaptabilidad de Lucene a las necesidades cambiantes de las tecnologías de búsqueda modernas, especialmente en el contexto de la IA, la búsqueda semántica y las aplicaciones de big data. El proyecto sigue creciendo como una plataforma poderosa, flexible y eficiente tanto para casos de búsqueda tradicionales como de vanguardia.

Lanzamientos de Lucene en 2024

Aunque no es un reflejo exacto, el gran volumen de lanzamientos pone de manifiesto la dedicación y energía continua de la comunidad. Estas actualizaciones incluyen mejoras importantes en el rendimiento y eficiencia de la búsqueda vectorial, soporte para madvise, optimizaciones para la decodificación de listas de anuncios, mejoras de velocidad adicionales mediante SIMD y mucho más.

Aquí tienes la lista completa de lanzamientos:

• 10.1.0 (2024-12-20)

• 9.12.1 (2024-12-13)

• 10.0.0 (2024-10-14)

• 9.12.0 (28-09-2024)

• 8.11.4 (2024-09-24)

• 9.11.1 (27-06-2024)

• 9.11.0 (2024-06-06)

• 9.10.0 (2024-02-20)

• 8.11.3 (2024-02-08)

• 9.9.2 (29-01-2024)

Puedes encontrar más información y notas de lanzamiento en la página de Lucene Core . Además, existen ediciones equivalentes de PyLucene .

Concluyendo

A medida que Lucene madura, sigue prosperando gracias a su comunidad dedicada y vibrante. Como vimos, 2024 fue un año increíblemente productivo, y ahora miramos hacia adelante los emocionantes desarrollos que traerá 2025.