Desmitifica la divergencia de resultados de benchmarks: Milvus vs. Qdrant
Con la creciente popularidad de GenAI, un número cada vez mayor de bases de datos vectoriales ha entrado en el mercado. A principios del año pasado, presentamos VectorDB Bench para proporcionar información sobre el rendimiento de las tecnologías emergentes de bases de datos vectoriales.
Recientemente, desarrolladores profundamente involucrados en este campo se acercaron a nosotros en Zilliz, buscando comprender las disparidades sustanciales entre los resultados del benchmark de Qdrant y nuestros hallazgos en VectorDB Bench. En particular, necesitaban aclaración sobre el bajo rendimiento de Milvus en los resultados del benchmark de Qdrant. En respuesta a estas consultas, nuestro equipo de ingeniería en Zilliz inició una investigación exhaustiva para descubrir las causas raíz de estas disparidades.
Esta publicación de blog proporciona un análisis técnico en profundidad de las diferencias del benchmark, con atención específica a la discrepancia de rendimiento de Milvus. Sin más demora, profundicemos en los detalles de esta investigación.
Razón #1: versión obsoleta de Milvus
Las disparidades en los resultados del benchmark se deben principalmente a las diferentes versiones de Milvus utilizadas en las pruebas. El informe de benchmark de Qdrant, basado en Milvus v2.1 y publicado el 10 de agosto de 2022, no captura completamente los avances significativos realizados en versiones posteriores. Consulta los datos sin procesar de este informe. Desde entonces, Milvus ha experimentado mejoras considerables.
En Milvus v2.2.1, actualizamos el motor vectorial (también conocido como Knowhere) y revisamos la estrategia de paralelismo. Las actualizaciones posteriores en v2.2.3 trajeron más mejoras en el rendimiento de búsqueda. Nuestro white paper destaca estos avances, demostrando que Milvus 2.2.3 es cuatro veces más rápido que Milvus 2.0 en rendimiento de consultas (latencia y throughput) y escalabilidad (colecciones a escala de miles de millones y múltiples réplicas).
Después de esto, v2.2.9 mejoró el rendimiento de búsqueda filtrada. En v2.2.12, introdujimos una mayor eficiencia de búsqueda con sobrecarga mínima para valores top-K grandes, un rendimiento de escritura mejorado en escenarios con clave de partición habilitada o múltiples particiones, y un uso de CPU optimizado para máquinas más grandes. Además, v2.3.2 marcó una mejora significativa del rendimiento con una copia de datos minimizada durante la carga y mejores inserciones masivas.
Estas mejoras continuas han transformado sustancialmente las capacidades de Milvus. Como resultado, los benchmarks basados en Milvus 2.1 ya no reflejan con precisión el rendimiento actual de la tecnología. Para comprender mejor las capacidades más recientes de Milvus, se anima a los desarrolladores a consultar VectorDB Bench, que emplea Milvus 2.3 para las pruebas.
Razón #2: uso inadecuado de Milvus
El benchmark de Qdrant sobre el rendimiento de Milvus se debe en parte a que solo utilizó Growing Segments. Como su nombre sugiere, Milvus optimiza con dos tipos de segment: Growing y Sealed Segments. Los Growing Segments aún están recibiendo datos hasta alcanzar un umbral predefinido. Estos segmentos priorizan la entrada rápida de datos y utilizan una estrategia de búsqueda de fuerza bruta, lo que conduce a un rendimiento de consulta más lento.
Por otro lado, los Segmentos Sellados ya no reciben datos y, por lo tanto, tienen un índice, lo que da lugar a mejoras significativas de rendimiento. Milvus sella automáticamente los Segmentos en Crecimiento cuando alcanzan un umbral predefinido, permitiendo así que estos datos también vean las mejoras de rendimiento cuando se utilizan con un índice.
El benchmark de Qdrant se centró únicamente en el uso de Segmentos en Crecimiento, lo que naturalmente condujo al rendimiento más lento reportado. Concentrarse solo en los Segmentos en Crecimiento difiere de cómo se utiliza Milvus en aplicaciones del mundo real y frustra el propósito de la estrategia de segmentos contenida en Milvus.
Además, para ayudar a los usuarios a equilibrar la frescura de los datos y la eficiencia de búsqueda, Milvus v2.3 introdujo soporte para el índice IVF-FLAT para índices en crecimiento. Además, Milvus v2.3.4 introdujo el índice Binlog para Segmentos en Crecimiento. Esta actualización permite el uso de índices avanzados como IVF o Fast Scan en estos segmentos, lo que potencialmente mejora el rendimiento de búsqueda hasta diez veces. Como resultado, esta mejora de la función ha hecho que los resultados anteriores del benchmark de Qdrant sean aún menos relevantes.
Razón #3: optimización impulsada por benchmarks para Qdrant
El rendimiento excepcional de Qdrant en benchmarks frente a otros proveedores se debe a su uso de segmentos supergrandes para benchmarking. Si bien esta estrategia ofreció resultados notables en los benchmarks, su aplicabilidad en el mundo real está en duda. En las bases de datos vectoriales, el tamaño de los segmentos es crucial. El enfoque de Qdrant en segmentos grandes impulsó las puntuaciones de los benchmarks, pero podría comprometer la flexibilidad operativa en el uso cotidiano.
Las bases de datos vectoriales eficaces deben manejar cargas de trabajo diversas y requisitos de datos en evolución. Los segmentos supergrandes, aunque eficaces en benchmarks, pueden tener dificultades con las consultas variadas típicas de situaciones del mundo real. Introducen complejidad en la gestión y podrían aumentar las demandas de recursos.
Si bien las optimizaciones de Qdrant impulsadas por benchmarks, como los segmentos supergrandes, muestran un rendimiento impresionante, su practicidad en entornos dinámicos del mundo real genera preocupaciones. Esto cuestiona la relevancia general de dichos resultados de benchmark en implementaciones reales de bases de datos vectoriales.
Reflexiones finales: un camino hacia decisiones justas e informadas
Cuando se trata de bases de datos vectoriales, un benchmarking confiable y completo es vital. VectorDB Bench, creado por Zilliz, aporta datos de rendimiento del mundo real para los desarrolladores. Reconociendo el desafío de lograr una imparcialidad absoluta en los benchmarks, compartimos nuestras ideas para enriquecer el conocimiento colectivo en este ámbito.
El ANN Benchmark es una herramienta valiosa para quienes buscan evaluaciones imparciales, ya que proporciona evaluaciones estandarizadas de bases de datos vectoriales. A medida que la tecnología avanza en este campo, enfatizamos la necesidad de esfuerzos de benchmarking claros, transparentes y colaborativos. Los desarrolladores deben acceder a benchmarks veraces y precisos o realizar sus propias pruebas con sus datos para tomar decisiones informadas al elegir una base de datos vectorial.
Sigue leyendo
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Top 10 Context Engineering Techniques You Should Know for Production RAG
A practical guide to context engineering for production LLM systems, covering RAG, context processing, memory, agents, and multimodal context.
Balancing Precision and Performance: How Zilliz Cloud's New Parameters Help You Optimize Vector Search
Optimize vector search with Zilliz Cloud’s level and recall features to tune accuracy, balance performance, and power AI applications.