O guia do programador para a configuração do Milvus

Introdução

Como programador que trabalha com o Milvus, é provável que já tenha encontrado o assustador ficheiro de configuração milvus.yaml com os seus mais de 500 parâmetros. Lidar com esta complexidade pode ser um desafio quando o que se pretende é otimizar o desempenho da base de dados vetorial.

Boas notícias: não é necessário compreender todos os parâmetros. Este guia elimina o ruído e concentra-se nas configurações críticas que realmente afetam o desempenho, destacando exatamente quais valores devem ser ajustados para o seu caso de uso específico.

Quer esteja a criar um sistema de recomendação que necessita de consultas extremamente rápidas ou a otimizar uma aplicação de pesquisa vetorial com restrições de custos, mostrar-lhe-ei exatamente quais os parâmetros a modificar com valores práticos e testados. No final deste guia, saberá como ajustar as configurações do Milvus para obter o máximo desempenho com base em cenários de implementação do mundo real.

Categorias de configuração

Antes de mergulhar em parâmetros específicos, vamos analisar a estrutura do arquivo de configuração. Ao trabalhar com milvus.yaml, você estará lidando com três categorias de parâmetros:

• Configurações de componentes de dependência: Serviços externos aos quais o Milvus se conecta (etcd, minio, mq) - críticos para a configuração do cluster e persistência de dados

• Configurações de componentes internos: A arquitetura interna do Milvus (proxy, queryNode, etc.) - fundamental para a afinação do desempenho

• Configurações funcionais: Segurança, registo e limites de recursos - importante para implementações de produção

Configurações de componentes de dependência do Milvus

Vamos começar com os serviços externos dos quais o Milvus depende. Estas configurações são particularmente importantes quando se passa do desenvolvimento para a produção.

etcd: Armazenamento de Metadados

O Milvus depende do etcd para a persistência de metadados e coordenação de serviços. Os parâmetros seguintes são cruciais:

• Etcd.endpoints: Especifica o endereço do cluster etcd. Por predefinição, o Milvus lança uma instância agrupada, mas em ambientes empresariais, é melhor ligar-se a um serviço gerido etcd para uma melhor disponibilidade e controlo operacional.

• etcd.rootPath: Define o prefixo da chave para armazenar dados relacionados com o Milvus no etcd. Se estiver a operar múltiplos clusters Milvus no mesmo backend etcd, usar diferentes caminhos de raiz permite um isolamento limpo de metadados.

• etcd.auth: Controla as credenciais de autenticação. Milvus não habilita o etcd auth por padrão, mas se sua instância gerenciada do etcd requer credenciais, você deve especificá-las aqui.

minio: Armazenamento de Objetos

Apesar do nome, esta secção governa todos os clientes de serviços de armazenamento de objectos compatíveis com S3. Ela oferece suporte a provedores como AWS S3, GCS e Aliyun OSS por meio da configuração cloudProvider.

Preste atenção a estas quatro configurações principais:

• minio.address / minio.port: Use-as para especificar o ponto de extremidade do seu serviço de armazenamento de objetos.

• minio.bucketName: Atribua buckets separados (ou prefixos lógicos) para evitar colisões de dados ao executar vários clusters Milvus.

• minio.rootPath: Permite o namespacing intra-bucket para isolamento de dados.

• minio.cloudProvider: Identifica o backend OSS. Para obter uma lista completa de compatibilidade, consulte a documentação do Milvus.

mq: Fila de mensagens

O Milvus usa uma fila de mensagens para propagação interna de eventos - Pulsar (padrão) ou Kafka. Preste atenção aos três parâmetros a seguir.

1. pulsar.address/pulsar.port: Defina esses valores para usar um cluster Pulsar externo.

2. pulsar.tenant: Define o nome do locatário. Quando vários clusters Milvus partilham uma instância Pulsar, isto assegura uma separação limpa dos canais.

3. msgChannel.chanNamePrefix.cluster: Se preferir ignorar o modelo de locatário da Pulsar, ajuste o prefixo do canal para evitar colisões.

Milvus também suporta Kafka como a fila de mensagens. Para usar o Kafka, comente as configurações específicas do Pulsar e descomente o bloco de configuração do Kafka.

Configurações de Componentes Internos do Milvus

rootCoord: Metadados + Carimbos de Tempo

O nó rootCoord trata das alterações de metadados (DDL/DCL) e da gestão de carimbos de data/hora.

1. rootCoord.maxPartitionNum： Define o limite superior do número de partições por coleção. Embora o limite rígido seja 1024, este parâmetro serve principalmente como uma salvaguarda. Para sistemas com vários inquilinos, evite usar partições como limites de isolamento - em vez disso, implemente uma estratégia de chave de inquilino que seja dimensionada para milhões de inquilinos lógicos.

2. rootCoord.enableActiveStandby：Ativa a alta disponibilidade através da ativação de um nó em espera. Isto é fundamental, uma vez que os nós coordenadores do Milvus não escalam horizontalmente por defeito.

proxy: Gateway API + Router de pedidos

O proxy lida com pedidos virados para o cliente, validação de pedidos e agregação de resultados.

• proxy.maxFieldNum: Limita o número de campos (escalar + vetor) por coleção. Mantenha-o abaixo de 64 para minimizar a complexidade do esquema e reduzir a sobrecarga de E/S.

• proxy.maxVectorFieldNum: Controla o número de campos vetoriais em uma coleção. Milvus suporta pesquisa multimodal, mas na prática, 10 campos vetoriais é um limite superior seguro.

• proxy.maxShardNumDefine o número de shards de ingestão. Como regra geral:

  • < 200M registos → 1 shard

  • 200-400M registos → 2 shards

  • Escalar linearmente além disso

• proxy.accesslog: Quando ativado, isso registra informações detalhadas da solicitação (usuário, IP, ponto de extremidade, SDK). Útil para auditoria e depuração.

queryNode: Execução da consulta

Trata da execução da pesquisa vetorial e do carregamento de segmentos. Preste atenção ao seguinte parâmetro.

• queryNode.mmap: Alterna a E/S mapeada na memória para carregar campos escalares e segmentos. A ativação de mmap ajuda a reduzir o espaço de memória, mas pode degradar a latência se a E/S do disco se tornar um gargalo.

dataCoord: Gerenciamento de segmento + índice

Este parâmetro controla a segmentação de dados, a indexação, a compactação e a recolha de lixo (GC). Os principais parâmetros de configuração incluem:

1. dataCoord.segment.maxSize: Especifica o tamanho máximo de um segmento de dados na memória. Segmentos maiores geralmente significam menos segmentos totais no sistema, o que pode melhorar o desempenho da consulta, reduzindo a indexação e a sobrecarga de pesquisa. Por exemplo, alguns usuários que executam instâncias do queryNode com 128 GB de RAM relataram que aumentar essa configuração de 1 GB para 8 GB levou a um desempenho de consulta cerca de 4 vezes mais rápido.

2. dataCoord.segment.diskSegmentMaxSize: Semelhante ao anterior, este parâmetro controla especificamente o tamanho máximo dos índices de disco (índice diskann).

3. dataCoord.segment.sealProportion: Determina quando um segmento crescente é selado (ou seja, finalizado e indexado). O segmento é selado quando atinge maxSize * sealProportion. Por predefinição, com maxSize = 1024MB e sealProportion = 0.12, um segmento será selado com cerca de 123MB.

• Valores mais baixos (por exemplo, 0,12) acionam o selamento mais cedo, o que pode ajudar na criação mais rápida de índices - útil em cargas de trabalho com atualizações frequentes.

• Valores mais altos (por exemplo, 0,3 a 0,5) atrasam o selamento, reduzindo a sobrecarga de indexação - mais adequado para cenários de ingestão offline ou em lote.

4. dataCoord.segment.expansionRate: Define o fator de expansão permitido durante a compactação. Milvus calcula o tamanho máximo permitido do segmento durante a compactação como maxSize * expansionRate.

5. dataCoord.gc.dropTolerance: Depois que um segmento é compactado ou uma coleção é descartada, o Milvus não exclui imediatamente os dados subjacentes. Em vez disso, ele marca os segmentos para exclusão e espera que o ciclo de coleta de lixo (GC) seja concluído. Este parâmetro controla a duração desse atraso.

Outras Configurações Funcionais

log: Observabilidade e Diagnóstico

Logging robusto é uma pedra angular de qualquer sistema distribuído, e Milvus não é exceção. Uma configuração de log bem feita não só ajuda a depurar problemas quando eles surgem, mas também garante uma melhor visibilidade da saúde e comportamento do sistema ao longo do tempo.

Para implementações de produção, recomendamos a integração dos registos do Milvus com ferramentas de registo e monitorização centralizadas - como o Loki - para simplificar a análise e os alertas. As principais configurações incluem:

1. log.level: Controla a verbosidade da saída do registo. Para ambientes de produção, mantenha o nível info para capturar detalhes essenciais de tempo de execução sem sobrecarregar o sistema. Durante o desenvolvimento ou a resolução de problemas, pode mudar para debug para obter informações mais detalhadas sobre as operações internas. ⚠️ Tenha cuidado com o nível debug na produção - ele gera um grande volume de registos, que podem consumir rapidamente espaço em disco e degradar o desempenho de E/S se não for verificado.

2. log.file: Por padrão, o Milvus grava os logs na saída padrão (stdout), o que é adequado para ambientes em contêineres onde os logs são coletados por meio de sidecars ou agentes de nó. Para ativar o registro baseado em arquivo, é possível configurar:

• Tamanho máximo do arquivo antes da rotação

• Período de retenção do arquivo

• Número de arquivos de log de backup a serem mantidos

Isso é útil em ambientes bare-metal ou locais em que o envio de logs stdout não está disponível.

security: Autenticação e controlo de acesso

O Milvus suporta autenticação de utilizadores e controlo de acesso baseado em funções (RBAC), ambos configurados no módulo common. Estas definições são essenciais para proteger ambientes multi-tenant ou qualquer implementação exposta a clientes externos.

Os principais parâmetros incluem:

1. common.security.authorizationEnabled: Esta opção ativa ou desactiva a autenticação e o RBAC. Está desativado por predefinição, o que significa que todas as operações são permitidas sem verificações de identidade. Para impor um controlo de acesso seguro, defina este parâmetro para true.

2. common.security.defaultRootPassword: Quando a autenticação está activada, esta definição define a palavra-passe inicial para o utilizador incorporado root.

Certifique-se de que altera a palavra-passe predefinida imediatamente após ativar a autenticação para evitar vulnerabilidades de segurança em ambientes de produção.

quotaAndLimits: Limitação da taxa e controlo de escrita

A secção quotaAndLimits em milvus.yaml desempenha um papel crítico no controlo da forma como os dados fluem através do sistema. Ela governa os limites de taxa para operações como inserções, exclusões, descargas e consultas - garantindo a estabilidade do cluster sob cargas de trabalho pesadas e evitando a degradação do desempenho devido à amplificação de gravação ou compactação excessiva.

Os principais parâmetros incluem:

quotaAndLimits.flushRate.collection: Controla a frequência com que o Milvus faz flushes de dados de uma coleção.

• Valor padrão: 0.1, o que significa que o sistema permite uma descarga a cada 10 segundos.

• A operação de flush sela um segmento crescente e o persiste da fila de mensagens para o armazenamento de objetos.

• A descarga muito frequente pode gerar muitos segmentos selados pequenos, o que aumenta a sobrecarga de compactação e prejudica o desempenho da consulta.

Melhores práticas: Na maioria dos casos, deixe o Milvus lidar com isso automaticamente. Um segmento em crescimento é selado quando atinge maxSize * sealProportion, e os segmentos selados são descarregados a cada 10 minutos. As descargas manuais só são recomendadas após inserções em massa quando você sabe que não há mais dados chegando.

Tenha também em mente: a visibilidade dos dados é determinada pelo nível de consistência da consulta, não pelo tempo de descarga - portanto, a descarga não torna os novos dados imediatamente consultáveis.

quotaAndLimits.upsertRate/quotaAndLimits.deleteRate: Estes parâmetros definem a taxa máxima permitida para as operações de upsert e delete.

• O Milvus baseia-se numa arquitetura de armazenamento LSM-Tree, o que significa que as actualizações e eliminações frequentes desencadeiam a compactação. Isso pode consumir muitos recursos e reduzir a taxa de transferência geral se não for gerenciado com cuidado.

• Recomenda-se limitar upsertRate e deleteRate a 0,5 MB/s para evitar sobrecarregar o pipeline de compactação.

Precisa de atualizar rapidamente um grande conjunto de dados? Use uma estratégia de alias de coleção:

• Insira novos dados em uma nova coleção.

• Quando a atualização estiver concluída, reponha o alias para a nova coleção. Isso evita a penalidade de compactação das atualizações in-loco e permite a troca instantânea.

Exemplos de configuração do mundo real

Vamos percorrer dois cenários de implantação comuns para ilustrar como as definições de configuração do Milvus podem ser ajustadas para atender a diferentes objetivos operacionais.

Exemplo 1: Configuração de alto desempenho

Quando a latência da consulta é crítica para a missão - pense em mecanismos de recomendação, plataformas de pesquisa semântica ou pontuação de risco em tempo real - cada milissegundo conta. Nesses casos de uso, você normalmente se apoia em índices baseados em gráficos, como HNSW ou DISKANN, e otimiza o uso da memória e o comportamento do ciclo de vida do segmento.

Principais estratégias de ajuste:

• Aumente dataCoord.segment.maxSize e dataCoord.segment.diskSegmentMaxSize: Aumente esses valores para 4 GB ou até 8 GB, dependendo da RAM disponível. Segmentos maiores reduzem o número de construções de índice e melhoram o rendimento da consulta, minimizando o fanout do segmento. No entanto, segmentos maiores consomem mais memória no momento da consulta - portanto, certifique-se de que as instâncias indexNode e queryNode tenham espaço suficiente.

• Diminuir dataCoord.segment.sealProportion e dataCoord.segment.expansionRate: Almeje um tamanho de segmento crescente em torno de 200 MB antes de selar. Isso mantém o uso da memória do segmento previsível e reduz a carga sobre o Delegator (o líder do queryNode que coordena a pesquisa distribuída).

Regra de ouro: Prefira segmentos menores e maiores quando a memória for abundante e a latência for uma prioridade. Seja conservador com os limites de selagem se a atualização do índice for importante.

Exemplo 2: Configuração com custo otimizado

Se você estiver priorizando a eficiência de custo em relação ao desempenho bruto - comum em pipelines de treinamento de modelos, ferramentas internas de baixo QPS ou pesquisa de imagens de cauda longa - você pode trocar a recuperação ou a latência para reduzir significativamente as demandas de infraestrutura.

Estratégias recomendadas:

• Utilizar a quantização de índices: Tipos de índice como SCANN, IVF_SQ8, ou HNSW_PQ/PRQ/SQ (introduzidos no Milvus 2.5) reduzem drasticamente o tamanho do índice e o espaço de memória. Eles são ideais para cargas de trabalho em que a precisão é menos crítica do que a escala ou o orçamento.

• Adotar uma estratégia de indexação apoiada em disco: Defina o tipo de índice como DISKANN para permitir a pesquisa puramente baseada em disco. Habilite mmap para descarregamento seletivo de memória.

Para uma poupança extrema de memória, active mmap para o seguinte: vectorField, vectorIndex, scalarField, e scalarIndex. Isso descarrega grandes blocos de dados para a memória virtual, reduzindo significativamente o uso de RAM residente.

⚠️ Advertência: Se a filtragem escalar for uma parte importante da sua carga de trabalho de consulta, considere desativar mmap para vectorIndex e scalarIndex. O mapeamento de memória pode degradar o desempenho da consulta escalar em ambientes com restrições de E/S.

Sugestão de utilização do disco

• Os índices HNSW criados com mmap podem expandir o tamanho total dos dados em até 1,8×.

• Um disco físico de 100 GB pode, de forma realista, acomodar apenas ~50 GB de dados efectivos quando se considera a sobrecarga do índice e o armazenamento em cache.

• Providencie sempre armazenamento extra quando trabalhar com mmap, especialmente se também guardar em cache os vectores originais localmente.

Conclusão

Ajustar o Milvus não é perseguir números perfeitos - é moldar o sistema em torno do comportamento real da sua carga de trabalho. As otimizações mais impactantes geralmente vêm do entendimento de como o Milvus lida com I/O, ciclo de vida do segmento e indexação sob pressão. Estes são os caminhos onde a má configuração prejudica mais - e onde o ajuste cuidadoso produz os maiores retornos.

Se for novo no Milvus, os parâmetros de configuração que abordámos cobrirão 80-90% das suas necessidades de desempenho e estabilidade. Comece por aí. Depois de criar alguma intuição, aprofunde-se nas especificações completas do site milvus.yaml e na documentação oficial - descobrirá controlos minuciosos que podem levar a sua implementação de funcional a excecional.

Com as configurações corretas, estará pronto para criar sistemas de pesquisa vetorial escaláveis e de elevado desempenho que se alinham com as suas prioridades operacionais - quer isso signifique um serviço de baixa latência, armazenamento rentável ou cargas de trabalho analíticas de elevado teste.