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 são intensivas em 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.

O espaço de armazenamento é libertado logo após a eliminação de dados no Milvus?

Não, o espaço de armazenamento não será imediatamente libertado quando eliminar dados no Milvus. Embora a eliminação de dados marque as entidades como "logicamente eliminadas", o espaço real pode não ser libertado instantaneamente. Eis o porquê:

• Compactação: O Milvus compacta automaticamente os dados em segundo plano. Este processo junta segmentos de dados mais pequenos em segmentos maiores e remove dados logicamente eliminados (entidades marcadas para eliminação) ou dados que tenham excedido o seu Tempo de Vida (TTL). No entanto, a compactação cria novos segmentos enquanto marca os antigos como "abandonados".
• Recolha de lixo: Um processo separado chamado Garbage Collection (GC) remove periodicamente esses segmentos "Dropped", liberando o espaço de armazenamento que eles ocupavam. Isto assegura uma utilização eficiente do armazenamento, mas pode introduzir um ligeiro atraso entre a eliminação e a recuperação de espaço.

Posso ver os dados inseridos, eliminados ou reinseridos imediatamente após a operação sem esperar por uma descarga?

Sim, no Milvus, a visibilidade dos dados não está diretamente ligada às operações de descarga devido à sua arquitetura de desagregação armazenamento-computador. É possível gerenciar a legibilidade dos dados usando níveis de consistência.

Ao selecionar um nível de consistência, considere as compensações entre consistência e desempenho. Para operações que exigem visibilidade imediata, use um nível de consistência "Forte". Para gravações mais rápidas, dê prioridade a uma consistência mais fraca (os dados podem não ser imediatamente visíveis). Para obter mais informações, consulte Consistência.

A indexação de um campo VARCHAR pode melhorar a velocidade de eliminaçã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 IN ou == expressões em campos VARCHAR de chave não primária.
• Índice Trie: Este índice é útil para 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 obter suporte e envolver-se com a nossa comunidade de código aberto.