Elección de una base de datos vectorial para la búsqueda de RNA en Reddit

Este artículo ha sido escrito por Chris Fournie, ingeniero de software de Reddit, y publicado originalmente en Reddit.

En 2024, los equipos de Reddit utilizaron diversas soluciones para realizar búsquedas vectoriales por aproximación al vecino más cercano (RNA). Desde la búsqueda vectorial de IA Vertex de Google y experimentando con el uso de la búsqueda vectorial de RNA de Apache Solr para algunos conjuntos de datos más grandes, hasta la biblioteca FAISS de Facebook para conjuntos de datos más pequeños (alojados en carros laterales escalados verticalmente). Cada vez más equipos de Reddit querían una solución de búsqueda vectorial de RNA ampliamente compatible que fuera rentable, tuviera las características de búsqueda que deseaban y pudiera escalar a datos del tamaño de Reddit. Para responder a esta necesidad, en 2025 buscamos la base de datos vectorial ideal para los equipos de Reddit.

Este post describe el proceso que utilizamos para seleccionar la mejor base de datos vectorial para las necesidades actuales de Reddit. No describe la mejor base de datos vectorial en general, ni el conjunto más esencial de requisitos funcionales y no funcionales para todas las situaciones. Describe lo que Reddit y su cultura de ingeniería valoraron y priorizaron al seleccionar una base de datos vectorial. Este post puede servir de inspiración para su propia recopilación y evaluación de requisitos, pero cada organización tiene su propia cultura, valores y necesidades.

Proceso de evaluación

En general, los pasos de selección fueron

1. 1. Recopilar el contexto de los equipos

2. Evaluar cualitativamente las soluciones

3. 3. Evaluar cuantitativamente a los principales contendientes

4. Selección final

1. Recopilación del contexto de los equipos

Se recopilaron tres elementos de contexto de los equipos interesados en realizar búsquedas vectoriales de RNA:

• Requisitos funcionales (por ejemplo, ¿búsqueda vectorial y léxica híbrida? ¿Consultas de búsqueda por rango? ¿Filtrado por atributos no vectoriales?)

• Requisitos no funcionales (por ejemplo, ¿puede admitir vectores 1B? ¿puede alcanzar una latencia P99 <100 ms?).

• Las bases de datos vectoriales ya interesaban a los equipos

Entrevistar a los equipos en busca de requisitos no es trivial. Muchos describirán sus necesidades en términos de cómo están resolviendo actualmente un problema, y su reto es comprender y eliminar ese sesgo.

Por ejemplo, un equipo ya utilizaba FAISS para la búsqueda vectorial de RNA y afirmó que la nueva solución debía devolver de forma eficiente 10.000 resultados por llamada de búsqueda. Tras una discusión más profunda, la razón de los 10.000 resultados era que necesitaban realizar un filtrado post-hoc, y FAISS no ofrece filtrado de resultados de RNA en el momento de la consulta. Su problema real era que necesitaban filtrar, por lo que cualquier solución que ofreciera un filtrado eficaz sería suficiente, y devolver 10.000 resultados era simplemente una solución provisional necesaria para mejorar la recuperación. Lo ideal sería prefiltrar toda la colección antes de encontrar los vecinos más próximos.

Preguntar por las bases de datos vectoriales que los equipos ya utilizaban o en las que estaban interesados también fue valioso. Si al menos un equipo tenía una opinión positiva de su solución actual, es señal de que la base de datos vectorial podría ser una solución útil para compartir en toda la empresa. Si los equipos sólo tenían opiniones negativas de una solución, entonces no deberíamos incluirla como opción. Aceptar soluciones en las que los equipos estaban interesados también era una forma de asegurarnos de que los equipos se sentían incluidos en el proceso y nos ayudó a formar una lista inicial de los principales contendientes a evaluar; hay demasiadas soluciones de búsqueda vectorial de RNA en bases de datos nuevas y existentes como para probarlas todas exhaustivamente.

2. Evaluar cualitativamente las soluciones

Partiendo de la lista de soluciones en las que estaban interesados los equipos, para evaluar cualitativamente qué solución de búsqueda vectorial de RNA se ajustaba mejor a nuestras necesidades:

• Investigamos cada solución y puntuamos lo bien que cumplía cada requisito frente a la importancia ponderada de dicho requisito.

• Eliminamos soluciones basándonos en criterios cualitativos y en el debate.

• Seleccionamos las N mejores soluciones para probarlas cuantitativamente.

Nuestra lista inicial de soluciones de búsqueda vectorial de RNA incluía:

• Milvus

• Qdrant

• Weviate

• Búsqueda abierta

• Pgvector (ya utiliza Postgres como RDBMS)

• Redis (ya se utiliza como almacén y caché de KV)

• Cassandra (ya se utiliza para la búsqueda noANN)

• Solr (ya se utiliza para la búsqueda léxica y se ha experimentado con la búsqueda vectorial)

• Vespa

• Pinecone

• Vertex AI (ya utilizado para la búsqueda vectorial RNA)

A continuación, tomamos todos los requisitos funcionales y no funcionales que mencionaron los equipos, además de algunas restricciones más que representaban nuestros valores y objetivos de ingeniería, hicimos esas filas en una hoja de cálculo y ponderamos su importancia (de 1 a 3; se muestra en la tabla abreviada a continuación).

Para cada solución que comparábamos, evaluábamos (en una escala de 0 a 3) lo bien que cada sistema satisfacía ese requisito (como se muestra en la tabla siguiente). Esta forma de puntuar era un tanto subjetiva, por lo que elegimos un sistema y dimos ejemplos de puntuaciones con una justificación por escrito y pedimos a los revisores que se remitieran a esos ejemplos. También dimos la siguiente orientación para asignar cada valor de puntuación: asigne este valor si:

• 0: No hay apoyo/evidencia de apoyo a los requisitos

• 1: Apoyo básico o inadecuado del requisito

• 2: Requisito razonablemente apoyado

• 3: Apoyo sólido a los requisitos que va más allá de soluciones comparables.

A continuación, creamos una puntuación global para cada solución sumando el producto de la puntuación de un requisito de la solución y la importancia de ese requisito (por ejemplo, Qdrant puntuó 3 para la combinación de re-clasificación/puntuación, que tiene una importancia de 2, por lo que 3 x 2 = 6, se repite para todas las filas y se suman). Al final, tenemos una puntuación global que se puede utilizar como base para clasificar y discutir soluciones, y qué requisitos son más importantes (tenga en cuenta que la puntuación no se utiliza para tomar una decisión final, sino como una herramienta de discusión).

Nota del editor: Esta reseña se basó en Milvus 2.4. Desde entonces hemos lanzado Milvus 2.5, Milvus 2.6, y Milvus 3.0 está a la vuelta de la esquina, por lo que algunos números pueden estar desfasados. Aun así, la comparación sigue siendo muy útil.

Categoría	Importancia	Qdrant	Milvus (2.4)	Cassandra	Weviate	Solr	Vertex AI
Tipo de búsqueda
Búsqueda híbrida	1	3	2	0	2	2	2
Búsqueda por palabra clave	1	2	2	2	2	3	1
Búsqueda aproximada NN	3	3	3	2	2	2	2
Alcance Búsqueda	1	3	3	2	2	0	0
Reordenación/combinación de puntuaciones	2	3	2	0	2	2	1
Método de indexación
HNSW	3	3	3	2	2	2	0
Admite varios métodos de indexación	3	0	3	1	2	1	1
Cuantización	1	3	3	0	3	0	0
Hashing sensible a la localidad (LSH)	1	0	0Nota: Milvus 2.6 lo soporta.	0	0	0	0
Datos
Tipos de vector distintos de float	1	2	2	0	2	2	0
Atributos de metadatos en vectores (admite múltiples atributos, un gran tamaño de registro, etc.)	3	3	2	2	2	2	1
Opciones de filtrado de metadatos (puede filtrar por metadatos, tiene filtrado previo y posterior)	2	3	2	2	2	3	2
Tipos de datos de atributos de metadatos (esquema sólido, por ejemplo, bool, int, string, json, arrays)	1	3	3	2	2	3	1
Límites de atributos de metadatos (consultas de rango, por ejemplo, 10 < x < 15)	1	3	3	2	2	2	1
Diversidad de resultados por atributo (por ejemplo, no obtener más de N resultados de cada subreddit en una respuesta)	1	2	1	2	3	3	0
Escala
Índice vectorial de cientos de millones	3	2	3		1	2	3
Índice vectorial de miles de millones	1	2	2		1	2	2
Vectores soporte al menos 2k	2	2	2	2	2	1	1
Vectores soporte superiores a 2k	2	2	2	2	1	1	1
P95 Latencia 50-100ms @ X QPS	3	2	2	2	1	1	2
P99 Latencia <= 10ms @ X QPS	3	2	2	2	3	1	2
99,9% disponibilidad recuperación	2	2	2	3	2	2	2
99,99% de disponibilidad indexación/almacenamiento	2	1	1	3	2	2	2
Operaciones de almacenamiento
Hospedable en AWS	3	2	2	2	2	3	0
Multi-Región	1	1	2	3	1	2	2
Actualizaciones sin tiempo de inactividad	1	2	2	3	2	2	1
Nube múltiple	1	3	3	3	2	2	0
API/Bibliotecas
gRPC	2	2	2	2	2	0	2
API RESTful	1	3	2	2	2	1	2
Ir a la biblioteca	3	2	2	2	2	1	2
Biblioteca Java	2	2	2	2	2	2	2
Python	2	2	2	2	2	2	2
Otros lenguajes (C++, Ruby, etc.)	1	2	2	3	2	2	2
Operaciones en tiempo de ejecución
Métricas de Prometheus	3	2	2	2	3	2	0
Operaciones básicas de BD	3	2	2	2	2	2	2
Upserts	2	2	2	2	1	2	2
Operador de Kubernetes	2	2	2	2	2	2	0
Paginación de los resultados	2	2	2	2	2	2	0
Incrustación de búsqueda por ID	2	2	2	2	2	2	2
Devuelve Embeddings con ID de candidato y puntuaciones de candidato	1	3	2	2	2	2	2
ID suministrado por el usuario	2	2	2	2	2	2	2
Capaz de buscar en un contexto de lotes a gran escala	1	2	1	1	2	1	2
Copias de seguridad / Instantáneas: permite crear copias de seguridad de toda la base de datos.	1	2	2	2	3	3	2
Soporte eficiente de grandes índices (distinción entre almacenamiento en frío y en caliente)	1	3	2	2	2	1	2
Apoyo/Comunidad
Neutralidad de los proveedores	3	3	2	3	2	3	0
Sólido soporte api	3	3	3	2	2	2	2
Apoyo a proveedores	2	2	2	2	2	2	0
Velocidad comunitaria	2	3	2	2	2	2	0
Base de usuarios de producción	2	3	3	2	2	1	2
Sentimiento comunitario	1	3	2	2	2	2	1
Estrellas de Github	1	2	2	2	2	2	0
Configuración
Manejo de secretos	2	2	2	2	1	2	2
Fuente
Fuente abierta	3	3	3	3	2	3	0
Idioma	2	3	3	2	3	2	0
Liberaciones	2	3	3	2	2	2	2
Pruebas previas	1	2	3	3	2	2	2
Disponibilidad de documentación	3	3	3	2	1	2	1
Coste
Coste Efectivo	2	2	2	2	2	2	1
Rendimiento
Soporte para ajustar la utilización de recursos de CPU, memoria y disco	3	2	2	2	2	2	2
Fragmentación multinodo (pod)	3	2	2	3	2	2	2
Capacidad de ajustar el sistema para equilibrar latencia y rendimiento	2	2	2	3	2	2	2
Partición definida por el usuario (escrituras)	1	3	2	3	1	2	0
Multiinquilino	1	3	2	1	3	2	2
Partición	2	2	2	3	2	2	2
Replicación	2	2	2	3	2	2	2
Redundancia	1	2	2	3	2	2	2
Conmutación automática por error	3	2	0 Nota: Milvus 2.6 lo soporta.	3	2	2	2
Equilibrio de carga	2	2	2	3	2	2	2
Soporte GPU	1	0	2	0	0	0	0
		Qdrant	Milvus	Cassandra	Weviate	Solr	Vertex AI
Puntuación global de las soluciones		292	281	264	250	242	173

Debatimos las puntuaciones generales y por requisitos de los distintos sistemas y tratamos de entender si habíamos ponderado adecuadamente la importancia de los requisitos y si algunos de ellos eran tan importantes que debían considerarse limitaciones básicas. Uno de los requisitos que identificamos fue si la solución era de código abierto o no, porque deseábamos una solución con la que pudiéramos involucrarnos, a la que pudiéramos contribuir y que solucionara rápidamente pequeños problemas si los experimentábamos a nuestra escala. Contribuir y utilizar software de código abierto es una parte importante de la cultura de ingeniería de Reddit. Esto eliminó las soluciones alojadas (Vertex AI, Pinecone) de nuestra consideración.

Durante las discusiones, nos dimos cuenta de que algunos otros requisitos clave eran de gran importancia para nosotros:

• Escala y fiabilidad: queríamos ver pruebas de otras empresas que utilizaran la solución con más de 100 millones de vectores o incluso 1.000 millones.

• Comunidad: Queríamos una solución con una comunidad saludable con mucho ímpetu en este espacio de rápida maduración

• Tipos de metadatos expresivos y filtrado para permitir más de nuestros casos de uso (filtrado por fecha, booleano, etc.)

• Compatibilidad con múltiples tipos de índices (no sólo HNSW o DiskANN) para adaptar mejor el rendimiento a nuestros numerosos y exclusivos casos de uso.

El resultado de nuestros debates y el perfeccionamiento de los requisitos clave nos llevaron a elegir probar (por orden) cuantitativamente:

1. Qdrant

2. Milvus

3. Vespa y

4. Weviate

Por desgracia, este tipo de decisiones requieren tiempo y recursos, y ninguna organización dispone de una cantidad ilimitada de ambos. Dado nuestro presupuesto, decidimos probar Qdrant y Milvus, y dejar las pruebas de Vespa y Weviate como objetivos a largo plazo.

Qdrant frente a Milvus fue también una prueba interesante de dos arquitecturas diferentes:

• Qdrant: Tipos de nodos homogéneos que realizan todas las operaciones de la base de datos vectorial de RNA.

• Milvus: Tipos de nodos heterogéneos (Milvus; uno para consultas, otro para indexación, otro para ingesta de datos, un proxy, etc.)

¿Cuál fue fácil de configurar (una prueba de su documentación)? ¿Cuál era fácil de ejecutar (una prueba de sus características de resistencia y pulido)? ¿Y cuál funcionaba mejor para los casos de uso y la escala que nos interesaban? Estas son las preguntas que tratamos de responder al comparar cuantitativamente las soluciones.

3. Evaluar cuantitativamente a los principales contendientes

Queríamos comprender mejor el grado de escalabilidad de cada solución y, de paso, experimentar cómo sería instalar, configurar, mantener y ejecutar cada una de ellas a gran escala. Para ello, recopilamos tres conjuntos de datos de documentos y vectores de consulta para tres casos de uso diferentes, configuramos cada solución con recursos similares dentro de Kubernetes, cargamos documentos en cada solución y enviamos cargas de consulta idénticas utilizando K6 de Grafana con un ejecutor de tasa de llegada de rampa para calentar los sistemas antes de alcanzar un rendimiento objetivo (por ejemplo, 100 QPS).

Probamos el rendimiento, el punto de ruptura de cada solución, la relación entre rendimiento y latencia, y cómo reaccionan a la pérdida de nodos bajo carga (tasa de error, impacto de latencia, etc.). Lo más interesante fue el efecto del filtrado en la latencia. También realizamos pruebas simples de sí/no para verificar que una capacidad de la documentación funcionaba tal y como se describía (por ejemplo, upserts, delete, get by ID, administración de usuarios, etc.) y para experimentar la ergonomía de esas API.

Las pruebas se realizaron en Milvus v2.4 y Qdrant v1.12. Debido a las limitaciones de tiempo, no ajustamos ni probamos exhaustivamente todos los tipos de configuraciones de índices; se utilizaron configuraciones similares con cada solución, con un sesgo hacia una alta recuperación de RNA, y las pruebas se centraron en el rendimiento de los índices HNSW. También se asignaron recursos de CPU y memoria similares a cada solución.

En nuestra experimentación, encontramos algunas diferencias interesantes entre las dos soluciones. En los siguientes experimentos, cada solución tenía aproximadamente 340M de postvectores Reddit de 384 dimensiones cada uno, para HNSW, M=16, y efConstruction=100.

En un experimento, descubrimos que para el mismo rendimiento de consulta (100 QPS sin ingestión al mismo tiempo), añadir filtrado afectaba más a la latencia de Milvus que a la de Qdrant.

Puestos de latencia de consulta con filtrado

Por otro lado, observamos que la interacción entre la ingesta y la carga de consulta era mucho mayor en Qdrant que en Milvus (como se muestra a continuación con un rendimiento constante). Esto se debe probablemente a su arquitectura; Milvus divide gran parte de su ingesta en tipos de nodos separados de los que sirven al tráfico de consulta, mientras que Qdrant sirve tanto a la ingesta como al tráfico de consulta desde los mismos nodos.

Puestos de latencia de consulta a 100 QPS durante la ingesta

Al probar la diversidad de resultados por atributo (por ejemplo, no obtener más de N resultados de cada subreddit en una respuesta), descubrimos que para el mismo rendimiento, Milvus tenía peor latencia que Qdrant (a 100 QPS).

Latencia posterior a la consulta con diversidad de resultados

También queríamos ver la eficacia de cada solución cuando se añadían más réplicas de datos (es decir, el factor de replicación, RF, se incrementaba de 1 a 2). Inicialmente, con RF=1, Qdrant fue capaz de ofrecernos una latencia satisfactoria a cambio de un mayor rendimiento que Milvus (no se muestran los QPS más altos porque las pruebas no se completaron sin errores).

Qdrant presenta una latencia RF=1 para un rendimiento variable

Milvus registra una latencia RF=1 para un rendimiento variable.

Sin embargo, al aumentar el factor de replicación, la latencia p99 de Qdrant mejoró, pero Milvus fue capaz de mantener un mayor rendimiento que Qdrant, con una latencia aceptable (Qdrant 400 QPS no se muestra porque la prueba no se completó debido a la alta latencia y los errores).

Milvus registra una latencia RF=2 para un rendimiento variable

Qdrant registra una latencia RF=2 para un rendimiento variable.

Debido a las limitaciones de tiempo, no tuvimos tiempo suficiente para comparar la recuperación de la RNA entre soluciones en nuestros conjuntos de datos, pero sí tuvimos en cuenta las mediciones de recuperación de la RNA para soluciones proporcionadas por https://ann-benchmarks.com/ en conjuntos de datos disponibles públicamente.

4. Selección final

En cuanto al rendimiento, sin mucho ajuste y utilizando únicamente HNSW, Qdrant parecía tener mejor latencia bruta en muchas pruebas que Milvus. Sin embargo, Milvus parecía escalar mejor con un aumento de la replicación y tenía un mejor aislamiento entre la carga de ingesta y la de consulta debido a su arquitectura de nodos múltiples.

Desde el punto de vista operativo, a pesar de la complejidad de la arquitectura de Milvus (múltiples tipos de nodos, dependencia de un registro externo de escritura anticipada como Kafka y un almacén de metadatos como etcd), nos resultó más fácil depurar y reparar Milvus que Qdrant cuando cualquiera de las dos soluciones entraba en mal estado. Milvus también tiene un reequilibrio automático al aumentar el factor de replicación de una colección, mientras que en Qdrant de código abierto, se requiere la creación manual o la eliminación de fragmentos para aumentar el factor de replicación (una característica que habríamos tenido que construir nosotros mismos o utilizar la versión que no es de código abierto).

Milvus es una tecnología más "en forma de Reddit" que Qdrant; comparte más similitudes con el resto de nuestra pila tecnológica. Milvus está escrito en Golang, nuestro lenguaje de programación backend preferido, y por lo tanto es más fácil para nosotros contribuir que Qdrant, que está escrito en Rust. Milvus tiene una velocidad de proyecto excelente para su oferta de código abierto en comparación con Qdrant, y cumplía más de nuestros requisitos clave.

Al final, ambas soluciones cumplían la mayoría de nuestros requisitos y, en algunos casos, Qdrant tenía una ventaja de rendimiento, pero pensamos que podíamos escalar más Milvus, nos sentíamos más cómodos ejecutándolo y se adaptaba mejor a nuestra organización que Qdrant. Nos hubiera gustado disponer de más tiempo para probar Vespa y Weaviate, pero es posible que también los hubiéramos seleccionado por su adecuación a la organización (Vespa se basa en Java) y su arquitectura (Weaviate es de tipo nodo único, como Qdrant).

Puntos clave

• Desafía los requisitos que te dan e intenta eliminar los prejuicios existentes sobre las soluciones.

• Puntúa las soluciones candidatas y utilízalas para fundamentar el debate sobre los requisitos esenciales, no como una regla de oro.

• Evalúe cuantitativamente las soluciones, pero a lo largo del proceso, tome nota de cómo es trabajar con la solución.

• Elija la solución que mejor se adapte a su organización desde el punto de vista del mantenimiento, el coste, la facilidad de uso y el rendimiento, y no sólo porque sea la mejor.

Agradecimientos

Este trabajo de evaluación ha sido realizado por Ben Kochie, Charles Njoroge, Amit Kumar y yo. Gracias también a otras personas que han contribuido a este trabajo, como Annie Yang, Konrad Reiche, Sabrina Kong y Andrew Johnson, por la investigación cualitativa de soluciones.

Notas del editor

Queremos agradecer sinceramente al equipo de ingeniería de Reddit, no sólo por elegir Milvus para sus cargas de trabajo de búsqueda vectorial, sino por tomarse el tiempo de publicar una evaluación tan detallada y justa. Es raro ver este nivel de transparencia en la forma en que los equipos de ingeniería reales comparan las bases de datos, y su escrito será útil para cualquier persona en la comunidad Milvus (y más allá) que está tratando de dar sentido al creciente panorama de las bases de datos vectoriales.

Como Chris menciona en el post, no existe una única "mejor" base de datos vectorial. Lo que importa es si un sistema se adapta a tu carga de trabajo, limitaciones y filosofía operativa. La comparación de Reddit refleja bien esa realidad. Milvus no encabeza todas las categorías, y eso es totalmente esperable dadas las compensaciones entre los diferentes modelos de datos y objetivos de rendimiento.

Vale la pena aclarar una cosa: La evaluación de Reddit utilizó Milvus 2.4, que era la versión estable en ese momento. Algunas características - como LSH y varias optimizaciones de índice - no existían todavía o no estaban maduras en 2.4, por lo que algunas puntuaciones reflejan naturalmente esa línea de base más antigua. Desde entonces, hemos lanzado Milvus 2.5 y luego Milvus 2.6, y es un sistema muy diferente en términos de rendimiento, eficiencia y flexibilidad. La respuesta de la comunidad ha sido fuerte y muchos equipos ya se han actualizado.

He aquí un rápido vistazo a las novedades de Milvus 2.6:

• Hasta un 72% menos de uso de memoria y consultas 4 veces más rápidas con la cuantización RaBitQ de 1 bit.

• Reducción de costes del 50% con almacenamiento inteligente por niveles

• Búsqueda de texto completo BM25 4 veces más rápida en comparación con Elasticsearch

• Filtrado JSON 100 veces más rápido con el nuevo Path Index

• Una nueva arquitectura de disco cero para búsquedas más frescas a menor coste

• Un flujo de trabajo "data-in, data-out" más sencillo para la integración de pipelines

• Compatibilidad con más de 100.000 colecciones para gestionar grandes entornos multiusuario.

Si desea conocer el desglose completo, aquí tiene un par de buenos artículos de seguimiento:

• Blog: Presentación de Milvus 2.6: Búsqueda vectorial asequible a escala de miles de millones

• Notas de la versión de Milvus 2.6:

• VDBBench 1.0: Benchmarking del mundo real para bases de datos vectoriales - Milvus Blog

¿Tiene alguna pregunta o desea profundizar en alguna función? Únase a nuestro canal Discord o presente incidencias 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.