Las pruebas de referencia de bases de datos vectoriales revelan grandes brechas en tiempo de compilación y concurrencia

Percona publicó una rigurosa prueba de referencia que compara el rendimiento de búsqueda vectorial en seis motores de base de datos, destacando disparidades significativas en la velocidad de indexación, el uso de memoria y la gestión de la concurrencia. El estudio evaluó MariaDB, AliSQL, PostgreSQL con pgvector, Valkey y Percona Search para MongoDB utilizando un corpus de 990.000 embeddings de OpenAI. Los resultados muestran que, si bien algunos motores sobresalen en la rápida construcción de índices, otros ofrecen una superior eficiencia de almacenamiento o un alto rendimiento bajo concurrencia, proporcionando datos críticos para ingenieros que diseñan sistemas de generación aumentada por recuperación (RAG).

Qué ocurrió

La prueba de referencia cargó 990.000 vectores de 1.536 dimensiones en cada motor, construyó un índice HNSW y midió cinco métricas clave: tiempo para crear un índice consultable, huella de almacenamiento y memoria, relación entre recall y throughput, rendimiento bajo clientes concurrentes y comportamiento durante cambios frecuentes de datos. Todas las pruebas se ejecutaron en hardware idéntico, un servidor Intel Xeon Gold 6230 con 80 CPUs lógicas y 187,5 GB de RAM, garantizando una comparación justa. El orquestador aplicó límites de recursos consistentes, como un pool de búfer InnoDB de 42,3 GB y asignaciones específicas de memoria para cachés de grafos, para evitar sesgos de configuración.

Los resultados revelaron variaciones inesperadas en operaciones básicas. El tiempo para construir un índice consultable osciló desde apenas 1,9 minutos para Percona Search hasta 6,7 horas para AliSQL. La eficiencia de almacenamiento también varió ampliamente, con MariaDB produciendo el índice más pequeño de 3,9 GiB, mientras que Percona Search requirió 15,1 GiB. Notablemente, el motor con el índice más pequeño tardó más tiempo en construirlo, ilustrando una compensación común entre compresión y velocidad de construcción. Estos hallazgos sugieren que elegir una base de datos vectorial requiere equilibrar las necesidades operativas inmediatas, como la frecuencia de reindexación, frente a los costos de almacenamiento a largo plazo.

Las pruebas de concurrencia expusieron distinciones adicionales. Bajo una carga de 32 clientes concurrentes, PostgreSQL con pgvector escaló su throughput 21,7 veces en comparación con el rendimiento de un solo cliente. En contraste, los tres motores basados en InnoDB—MariaDB 11.8, MariaDB 12.3 y AliSQL—mostraron casi ningún escalado, manteniendo aproximadamente 1x de throughput. Sin embargo, el equipo de prueba retiró números específicos de eficiencia de concurrencia para estos tres motores tras descubrir una limitación en el entorno de pruebas. El Conector MariaDB/C mantenía el lock del intérprete Python durante las esperas de socket, lo que significaba que algunos clientes estaban esperando el lock en lugar de la base de datos, distorsionando las métricas "en servicio".

Cómo funciona

La prueba de referencia utilizó el conjunto de datos dbpedia-openai-1000k-angular, consistente en 990.000 vectores float32. Cada motor construyó un índice HNSW con M=16, un parámetro estándar que controla la conectividad de la estructura del grafo. El rendimiento de las consultas se midió utilizando diferentes valores de ef_search, que determinan el número de candidatos explorados durante la búsqueda. El recall se calculó utilizando la definición de umbral de distancia de ann-benchmarks, asegurando la comparabilidad con la literatura existente. Para las consultas filtradas, la verdad fundamental (ground truth) se recalculó mediante fuerza bruta solo sobre las filas que satisfacen el predicado, evitando penalizar a los motores por excluir correctamente elementos no coincidentes.

Diferentes motores emplean estrategias distintas para la búsqueda filtrada. PostgreSQL con pgvector utiliza un enfoque de post-filtrado donde recolecta candidatos del grafo y luego descarta los que no cumplen el predicado. Si se descartan demasiados, se detiene prematuramente, pudiendo devolver menos resultados de los solicitados. Percona Search utiliza una estrategia de pre-filtrado, que puede mantener un mayor throughput a medida que los filtros se vuelven más estrictos, pero puede sacrificar el recall. MariaDB y AliSQL también aplican post-filtrado pero continúan buscando, lo que preserva el recall pero puede aumentar significativamente la latencia a medida que disminuye la selectividad del filtro. Estas decisiones arquitectónicas impactan directamente en qué tan bien cada motor maneja consultas complejas del mundo real que involucran filtros de metadatos.

Detalles clave

• Tiempo de construcción del índice: Percona Search fue el más rápido con 1,9 minutos, mientras que AliSQL fue el más lento con 6,7 horas.
• Eficiencia de almacenamiento: MariaDB 11.8 y 12.3 produjeron los índices más pequeños con 3,9 GiB, comparados con 15,1 GiB para Percona Search.
• Throughput de un solo cliente: A un recall de 0,99, MariaDB 12.3 lideró con 277 QPS, seguido por Valkey con 264 QPS y PostgreSQL con 210 QPS.
• Escalado de concurrencia: El throughput de PostgreSQL aumentó 21,7x con 32 clientes, mientras que los motores basados en InnoDB mostraron un escalado mínimo debido al encolamiento en el lado del servidor.
• Búsqueda filtrada: El método predeterminado de post-filtrado de PostgreSQL causó que el recall cayera a 0,1034 al 1% de selectividad porque se detuvo temprano después de descartar candidatos no coincidentes.
• Cambios de datos: MHNSW y VIDX actualizan el grafo en cada inserción, haciendo que su tiempo de carga sea equivalente al tiempo de construcción del índice, a diferencia de pgvector que separa la copia y la construcción.

Por qué importa

Para los ingenieros de software que construyen aplicaciones de IA, estas pruebas de referencia destacan que ningún motor domina todas las categorías. Si su aplicación requiere reindexación frecuente o actualizaciones de modelos, la diferencia entre un tiempo de construcción de 40 minutos para PostgreSQL y una ventana de 6,7 horas para AliSQL es operativamente significativa. Por el contrario, si el costo de almacenamiento es la restricción principal, el índice compacto de 3,9 GiB de MariaDB ofrece ahorros sustanciales sobre otras opciones, a pesar de su proceso de construcción más lento. Comprender estas compensaciones ayuda a los equipos a seleccionar infraestructura que se alinee con sus patrones de carga de trabajo específicos, ya sea que prioricen la velocidad de escritura, el throughput de lectura o la densidad de almacenamiento.

Los resultados de concurrencia son particularmente relevantes para servicios de alto tráfico. La capacidad de PostgreSQL y Valkey para escalar el throughput linealmente con el número de clientes sugiere que están mejor adaptados para entornos con muchos usuarios simultáneos. El rendimiento plano de los motores basados en InnoDB bajo carga concurrente indica posibles cuellos de botella en sus implementaciones vectoriales actuales o bibliotecas de conectores. Los ingenieros deben tener en cuenta estas características de escalado al diseñar la arquitectura del sistema, potencialmente requiriendo estrategias adicionales de balanceo de carga o agrupación de conexiones para motores que no escalan bien nativamente.

Qué puede hacer

• Evalúe su frecuencia de reindexación; si actualiza embeddings a menudo, priorice motores con tiempos de construcción más rápidos como PostgreSQL o Valkey.
• Pruebe el rendimiento de la búsqueda filtrada con su distribución específica de metadatos, ya que las configuraciones predeterminadas pueden llevar a un mal recall o alta latencia.
• Considere los costos de almacenamiento versus el tiempo de construcción; si el espacio en disco es costoso, los índices más pequeños de MariaDB pueden justificar ventanas de construcción más largas.
• Realice pruebas de concurrencia para su carga de usuarios esperada, teniendo en cuenta que algunos motores pueden requerir más instancias para manejar consultas paralelas de manera efectiva.
• Revise las bibliotecas de conectores para clientes específicos de lenguaje, ya que las limitaciones del entorno de pruebas en este estudio sugieren que los cuellos de botella a nivel de driver pueden enmascarar el rendimiento de la base de datos.
• Monitoree el uso de memoria durante las construcciones de índices, ya que el RSS pico varió de 14,3 GB a 48,8 GB, impactando los requisitos de aprovisionamiento de infraestructura.