FAQ sobre desempenho
Como definir nlist e nprobe para índices IVF?
A definição de nlist é específica do cenário. Como regra geral, o valor recomendado de nlist é 4 × sqrt(n), em que n é o número total de entidades num segmento.
O tamanho de cada segmento é determinado pelo parâmetro datacoord.segment.maxSize, que é definido para 512 MB por padrão. O número total de entidades num segmento n pode ser estimado dividindo datacoord.segment.maxSize pelo tamanho de cada entidade.
A definição de nprobe é específica do conjunto de dados e do cenário, e envolve um compromisso entre a precisão e o desempenho da consulta. Recomendamos que encontre o valor ideal através de experiências repetidas.
Os gráficos a seguir são resultados de um teste executado no conjunto de dados sift50m e no índice IVF_SQ8, que compara a recuperação e o desempenho da consulta de diferentes pares nlist/nprobe.
Teste de precisão 
Teste de desempenho
Porque é que as consultas por vezes demoram mais tempo em conjuntos de dados mais pequenos?
As operações de consulta são efectuadas em segmentos. Os índices reduzem o tempo necessário para consultar um segmento. Se um segmento não tiver sido indexado, o Milvus recorre à pesquisa de força bruta nos dados em bruto - aumentando drasticamente o tempo de consulta.
Portanto, normalmente demora mais tempo a consultar um pequeno conjunto de dados (coleção) porque não tem um índice construído. Isto deve-se ao facto de os tamanhos dos seus segmentos não terem atingido o limiar de construção de índices definido por rootCoord.minSegmentSizeToEnableindex. Chame create_index() para forçar o Milvus a indexar os segmentos que atingiram o limiar mas ainda não foram indexados automaticamente, melhorando significativamente o desempenho da consulta.
Que factores afectam a utilização da CPU?
O uso da CPU aumenta quando o Milvus está construindo índices ou executando consultas. Em geral, a construção de índices é intensiva em CPU, exceto quando se usa Annoy, que é executado em um único thread.
Ao executar consultas, o uso da CPU é afetado por nq e nprobe. Quando nq e nprobe são pequenos, a concorrência é baixa e o uso da CPU permanece baixo.
A inserção simultânea de dados e a pesquisa afectam o desempenho da consulta?
As operações de inserção não consomem muita CPU. No entanto, como os novos segmentos podem não ter atingido o limite para a construção do índice, o Milvus recorre à pesquisa de força bruta - afetando significativamente o desempenho da consulta.
O parâmetro rootcoord.minSegmentSizeToEnableIndex determina o limite de construção de índice para um segmento, e é definido para 1024 linhas por padrão. Consulte Configuração do sistema para obter mais informações.
A indexação de um campo VARCHAR pode melhorar a velocidade de exclusão?
A indexação de um campo VARCHAR pode acelerar as operações "Eliminar por expressão", mas apenas em determinadas condições:
- Índice INVERTED: Este índice ajuda para
INou==expressões em campos VARCHAR de chave não primária. - Índice Trie: Este índice ajuda nas consultas de prefixo (por exemplo,
LIKE prefix%) em campos VARCHAR não primários.
No entanto, a indexação de um campo VARCHAR não acelera:
- Eliminação por IDs: Quando o campo VARCHAR é a chave primária.
- Expressões não relacionadas: Quando o campo VARCHAR não faz parte da expressão de exclusão.
Ainda tem dúvidas?
Você pode:
- Verificar o Milvus no GitHub. Sinta-se à vontade para fazer perguntas, compartilhar ideias e ajudar outras pessoas.
- Junte-se ao nosso Canal Slack para encontrar suporte e envolver-se com a nossa comunidade de código aberto.
