Desmistifique a divergência nos resultados de benchmarks: Milvus vs. Qdrant
Com a crescente popularidade da GenAI, um número cada vez maior de bancos de dados vetoriais entrou no mercado. No início do ano passado, lançamos o VectorDB Bench para fornecer insights sobre o desempenho das tecnologias emergentes de bancos de dados vetoriais.
Recentemente, desenvolvedores profundamente envolvidos nessa área nos procuraram na Zilliz, buscando entender as disparidades substanciais entre os resultados de benchmark da Qdrant e nossas descobertas no VectorDB Bench. Em particular, eles precisavam de esclarecimentos sobre o desempenho do pool do Milvus nos resultados de benchmark da Qdrant. Em resposta a essas perguntas, nossa equipe de engenharia na Zilliz iniciou uma investigação abrangente para descobrir as causas-raiz dessas disparidades.
Esta postagem do blog fornece uma análise técnica aprofundada das diferenças de benchmark, com atenção específica à discrepância de desempenho do Milvus. Sem mais demora, vamos nos aprofundar nos detalhes desta investigação.
Motivo nº 1: versão desatualizada do Milvus
As disparidades nos resultados de benchmark decorrem principalmente das diferentes versões do Milvus usadas nos testes. O relatório de benchmark da Qdrant, baseado no Milvus v2.1 e publicado em 10 de agosto de 2022, não captura totalmente os avanços significativos feitos nas versões posteriores. Confira os dados brutos deste relatório. Desde então, o Milvus passou por melhorias consideráveis.
No Milvus v2.2.1, atualizamos o mecanismo vetorial (também conhecido como Knowhere) e revisamos a estratégia de paralelismo. Atualizações subsequentes na v2.2.3 trouxeram novas melhorias no desempenho de busca. Nosso white paper destaca esses avanços, demonstrando que o Milvus 2.2.3 é quatro vezes mais rápido que o Milvus 2.0 em desempenho de consultas (latência e throughput) e escalabilidade (coleções em escala de bilhões e múltiplas réplicas).
Depois disso, a v2.2.9 melhorou o desempenho de busca filtrada. Na v2.2.12, introduzimos melhor eficiência de busca com overhead mínimo para valores top-K grandes, desempenho de escrita aprimorado em cenários com partition key habilitada ou multi-partição, e uso de CPU otimizado para máquinas maiores. Além disso, a v2.3.2 marcou uma melhoria significativa de desempenho com cópia de dados minimizada durante o carregamento e melhores inserções em lote.
Essas melhorias contínuas transformaram substancialmente as capacidades do Milvus. Como resultado, benchmarks baseados no Milvus 2.1 não refletem mais com precisão o desempenho atual da tecnologia. Para entender melhor as capacidades mais recentes do Milvus, os desenvolvedores são incentivados a consultar o VectorDB Bench, que emprega o Milvus 2.3 para testes.
Motivo nº 2: uso inadequado do Milvus
O benchmark da Qdrant sobre o desempenho do Milvus resulta parcialmente de como ele usou apenas Growing Segments. Como o nome sugere, o Milvus otimiza com dois tipos de segment: Growing e Sealed Segments. Growing Segments ainda estão recebendo dados até atingirem um limite predefinido. Esses segmentos priorizam a entrada rápida de dados e utilizam uma estratégia de busca por força bruta, o que leva a um desempenho de consulta mais lento.
Por outro lado, os Segmentos Selados não recebem mais dados e, portanto, têm um índice, resultando em ganhos significativos de desempenho. O Milvus sela automaticamente os Segmentos em Crescimento quando atinge um limite predefinido, permitindo assim que esses dados também vejam os ganhos de desempenho quando usados com um índice.
O benchmark do Qdrant focou apenas no uso de Segmentos em Crescimento, o que naturalmente levou ao desempenho mais lento relatado. Concentrar-se apenas em Segmentos em Crescimento difere de como o Milvus é usado em aplicações do mundo real e frustra o propósito da estratégia de segmentos contida no Milvus.
Além disso, para ajudar os usuários a equilibrar atualização dos dados e eficiência de busca, o Milvus v2.3 introduziu suporte ao índice IVF-FLAT para índices em crescimento. Além disso, o Milvus v2.3.4 introduziu o índice Binlog para Segmentos em Crescimento. Esta atualização permite o uso de índices avançados, como IVF ou Fast Scan, nesses segmentos, potencialmente melhorando o desempenho de busca em até dez vezes. Como resultado, essa melhoria de recurso tornou os resultados anteriores do benchmark do Qdrant ainda menos relevantes.
Motivo nº 3: otimização orientada por benchmark para o Qdrant
O desempenho excepcional do Qdrant em benchmarks contra outros fornecedores decorre do uso de segmentos supergrandes para benchmarking. Embora essa estratégia tenha produzido resultados notáveis nos benchmarks, sua aplicabilidade no mundo real é questionável. Em bancos de dados vetoriais, o tamanho dos segmentos é crucial. O foco do Qdrant em segmentos grandes impulsionou as pontuações nos benchmarks, mas pode comprometer a flexibilidade operacional no uso cotidiano.
Bancos de dados vetoriais eficazes devem lidar com cargas de trabalho diversas e requisitos de dados em evolução. Segmentos supergrandes, embora eficazes em benchmarks, podem ter dificuldade com as consultas variadas típicas de situações do mundo real. Eles introduzem complexidade no gerenciamento e podem aumentar as demandas por recursos.
Embora as otimizações orientadas por benchmark do Qdrant, como segmentos supergrandes, demonstrem desempenho impressionante, sua praticidade em ambientes dinâmicos do mundo real levanta preocupações. Isso questiona a relevância geral desses resultados de benchmark em implantações reais de bancos de dados vetoriais.
Considerações finais: um caminho para decisões justas e informadas
Quando se trata de bancos de dados vetoriais, um benchmarking confiável e abrangente é vital. O VectorDB Bench, criado pela Zilliz, contribui com dados de desempenho do mundo real para desenvolvedores. Reconhecendo o desafio de alcançar imparcialidade absoluta em benchmarks, compartilhamos nossos insights para enriquecer o conhecimento coletivo neste domínio.
O ANN Benchmark é uma ferramenta valiosa para quem procura avaliações imparciais, fornecendo avaliações padronizadas de bancos de dados vetoriais. À medida que a tecnologia avança neste campo, enfatizamos a necessidade de esforços de benchmarking claros, transparentes e colaborativos. Os desenvolvedores devem acessar benchmarks verdadeiros e precisos ou conduzir seus próprios testes com seus dados para tomar decisões informadas ao escolher um banco de dados vetorial.
Continue lendo
Data Deduplication at Trillion Scale: How to Solve the Biggest Bottleneck of LLM Training
Explore how MinHash LSH and Milvus handle data deduplication at the trillion-scale level, solving key bottlenecks in LLM training for improved AI model performance.
What is the K-Nearest Neighbors (KNN) Algorithm in Machine Learning?
KNN is a supervised machine learning technique and algorithm for classification and regression. This post is the ultimate guide to KNN.
Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.