This page explores the results of our MongoDB Vector Search performance benchmark. MongoDB offers a range of solutions that support various implementation needs. Customers can choose the levels of performance and accuracy that are suited to their specific business setup.
Resumo dos resultados
Em vetores 15.3M usando
voyage-3-largeincorporações em 2048 dimensões, o MongoDB Vector Search com quantização configurada retém 90-95% de precisão com latência de consulta < 50ms.A Quantização binária oferece uma solução mais barata, a cerca de um quarto do preço de servir o índice. Como ele é atualizado com vetores de fidelidade total, ele pode ser uma opção preferível para muitos volumes de trabalho de grande escala, embora seja recomendável executar testes no conjunto de dados de amostra para garantir que o desempenho atenda às suas necessidades.
Recomendamos mais de 1024 dimensões ao executar cargas de trabalho maiores com quantização.
Os filtros seletivos podem melhorar ou piorar o desempenho dependendo do valor selecionado para
numCandidates.O custo adicional da rescoring para quantização binária se manifesta na redução da taxa de transferência ao executar cargas de trabalho altamente concorrentes.
A fragmentação melhora ligeiramente a taxa de transferência, mas ainda recomendamos o dimensionamento do número de nós de pesquisa ou o número de núcleos disponíveis em um nó de pesquisa para melhorar a taxa de transferência.
Análise de recuperação e latência no benchmark multidimensional
O primeiro conjunto de resultados mostra os testes que executamos em um conjunto de dados de 5,5 mi documentos contendo múltiplas dimensionalidades de vetores (256, 512, 1024, 2048), todos produzidos usando voyage-3-large em cada documento.
Todos os resultados quantizados escalares começam em níveis mais altos do que os resultados quantizados binários, mas permanecem em seu nível assintético mesmo com o aumento de numCandidates. Por outro lado, as queries quantizadas binárias produzem resultados mais precisos à medida que mais numCandidates são solicitadas, abordando a assíntota da quantização escalar e, em alguns casos, passando-a, ao custo de maior latência, especialmente acima de numCandidates de 1000.
Valores mais baixos de limit geralmente exigem numCandidates mais alto para se aproximar da precisão 100%, porque a query é mais seletiva em relação aos resultados principais. Este efeito é particularmente visível no gráfico de quantização binária. Os vetores de dimensionamento mais alto (1024d e acima) atingem o intervalo alvo de 90-95% em numCandidates mais baixo, pois a representação mais rica facilita a distinção entre vizinhos próximos. Os testes que limit os resultados para 100 atingem o intervalo alvo 90-95% com numCandidates menor do que os testes que limit os resultados para 10, porque o conjunto de resultados maior fornece o pesquisar mais oportunidades de encontrar vizinhos relevantes.
Com essas informações, determinamos que, ao trabalhar com um grande conjunto de dados, é recomendável ter uma dimensionalidade de pelo menos 1024d e aplicar a quantização para dimensionar, em vez de ter uma dimensionalidade mais baixa e não usar a quantização, sendo a quantidade de vetores solicitados para o caso de uso também um fator.
Resultados de benchmark maiores
Para o maior conjunto de dados vetoriais de 15,3 milhões, fixamos a dimensionalidade em 2048d e examinamos o impacto da quantização, filtro e simultaneidade no desempenho. Escolhemos fixar em 2048d com base nos resultados do conjunto anterior de testes, que mostraram que dimensões maiores mantiveram a recuperação de modo mais favorável, embora 1024d provavelmente teria servido igualmente bem para atingir a meta de recuperação de 90-95%.
Análise de recall e latência
Observamos que é necessário significativamente mais numCandidates ao utilizar a quantização binária para alcançar a meta de recall de 90–95% em comparação com a linha de base. Valores mais altos de numCandidates geralmente significam maior latência, mas isso pode variar.
Filtragem
Observamos o que acontece com a recuperação e a latência ao usar um filtro seletivo no conjunto de dados para ~500 mil dos 15,3 milhões de itens da categoria de suprimentos para animais (~3% do corpus):
Um filtro seletivo é um filtro que corresponde apenas a uma pequena parte dos dados (neste caso, ~3%. Como o mecanismo de busca agora deve encontrar os vizinhos mais próximos dentro desse pequeno subconjunto, ele precisa explorar mais o índice e avaliar mais candidatos para alcançar o mesmo recall. Cada query faz mais trabalho do que uma query não filtrada.
Conforme esperado, podemos ver que o filtro seletivo 3% pode fazer com que as queries façam mais trabalho. Para a quantização binária em valores de limit mais baixos, isso exigiu aproximadamente 4x de trabalho para alcançar 90-95% de recuperação em comparação com as queries não filtradas.
Melhorias futuras no Lucene 10, que suportam estratégias de pesquisa Acorn-1 para Mundos Pequenos Hierárquicos Navegáveis, podem melhorar esse processo. No entanto, a execução de ENN quando o número de candidatos solicitados excede o número de vetores correspondentes ao filtro de metadados dentro de um segmento demonstra que a seletividade do filtro desempenho um papel importante no desempenho da query, independentemente do esquema de quantização selecionado.
Concurrency
Esses testes dimensionam solicitações simultâneas entre 1, 10 e 100 nos vários valores de limit ao usar quantização escalar e binária. numCandidates são selecionados escolhendo valores que permitem alcançar uma recuperação de 90–95%:
Observamos que a quantização escalar atinge um QPS mais alto em todos os valores de limit, provavelmente porque cada query pode ser concluída com numCandidates mais baixo e sem reclassificação. Em simultaneidades mais altas, as curvas de QPS para simultaneidade 10 e simultaneidade 100 estão próximas, sugerindo que o sistema está usando eficientemente os recursos disponíveis da CPU e que a simultaneidade extra afeta principalmente a latência.
One exceptional data point is limit 10, concurrency 100 for scalar quantization yielding significantly higher QPS. This is likely because no rescoring and lower limit values means fewer comparisons are performed for this query, allowing each request to return more quickly and make the cores available to serve other queries.
O dimensionamento do número de vCPUs disponíveis para servir solicitações, aumentando o nível do nó de pesquisa ou o número de nós de pesquisa do mínimo de 2 até 32 nós, pode ajudar a resolver gargalos de simultaneidade e permitir que você dimensione bem até milhares de QPS.
Fragmentação
Também observamos o que aconteceria se o cluster e a coleção fossem fragmentados (em _id) e queries não filtradas fossem emitidas contra um índice quantizado binário.
Aqui, vemos que os resultados fragmentados têm um QPS mais alto no limite 10, pois o valor mais baixo de numCandidates pode ser fornecido para produzir resultados no intervalo de recuperação 90-95%. Isso ocorre porque o conjunto de dados 15.3M é divisão em três fragmentos, cada um dos quais tem seus próprios índices preenchidos com vetores 5.1M espalhados por segmentos contendo gráficos HNSW. Funcionalmente, estamos fazendo uma pesquisa menos avançada, em que é mais provável que cada dispersão de consulta reunida em fragmentos 3 simultaneamente possa encontrar os vetores n mais próximos. Por esse motivo, o QPS é um pouco maior ao fragmentar, pois você pode reduzir numCandidates e ter mais núcleos disponíveis para atender às queries, mas a diferença não é muito significativa. Como o desempenho da pesquisa vetorial permanece confiável, você não precisa fragmentar seu cluster para escalar sua taxa de transferência.
Observação
Os valores são semelhantes para o limite 100 e o número de candidatos 200. Podemos esperar que isso tenha um desempenho melhor para consultas filtradas com uma correspondência inteligente da chave de fragmento usada como filtro.