Visão geral do armazenamento em camadasCompatible with Milvus 2.6.4+
No Milvus, o modo tradicional de carga completa requer que cada QueryNode carregue todos os campos de dados e índices de um segmento na inicialização, mesmo os dados que podem nunca ser acedidos. Isso garante a disponibilidade imediata dos dados, mas muitas vezes leva ao desperdício de recursos, incluindo alto uso de memória, atividade pesada de disco e sobrecarga significativa de E/S, especialmente ao lidar com conjuntos de dados de grande escala.
O Armazenamento em camadas resolve esse desafio desacoplando o cache de dados do carregamento de segmentos. Em vez de carregar todos os dados de uma vez, o Milvus introduz uma camada de cache que distingue entre dados quentes (armazenados em cache localmente) e dados frios (armazenados remotamente). O QueryNode agora carrega apenas metadados leves inicialmente e dinamicamente puxa ou evita dados de campo sob demanda. Isso reduz significativamente o tempo de carregamento, otimiza a utilização de recursos locais e permite que os QueryNodes processem conjuntos de dados que excedem em muito sua memória física ou capacidade de disco.
Considere ativar o armazenamento em camadas em cenários como:
Coleções que excedem a memória disponível ou a capacidade NVMe de um único QueryNode
Cargas de trabalho analíticas ou em lote em que o carregamento mais rápido é mais importante do que a latência da primeira consulta
Cargas de trabalho mistas que podem tolerar falhas ocasionais de cache para dados acedidos com menos frequência
Os metadados incluem esquema, definições de índice, mapas de partes, contagens de linhas e referências a objectos remotos. Esse tipo de dados é pequeno, sempre armazenado em cache e nunca evacuado.
Para obter mais detalhes sobre segmentos e pedaços, consulte Segmento.
Como funciona
O armazenamento em camadas altera a forma como o QueryNode gerencia os dados do segmento. Em vez de armazenar em cache todos os campos e índices no momento do carregamento, o QueryNode agora carrega apenas metadados e usa uma camada de cache para buscar e despejar dados dinamicamente.
Modo de carga completa vs. modo de armazenamento em camadas
Embora os modos de carregamento completo e de armazenamento em camadas lidem com os mesmos dados, diferem em quando e como o QueryNode coloca estes componentes em cache.
Modo de carga completa: No momento do carregamento, o QueryNode coloca em cache os dados da coleção completa, incluindo metadados, dados de campo e índices, a partir do armazenamento de objectos.
Modo de armazenamento em camadas: No momento do carregamento, o QueryNode coloca em cache apenas os metadados. Os dados de campo são extraídos sob demanda na granularidade de partes. Os arquivos de índice permanecem remotos até que a primeira consulta precise deles; então, todo o índice por segmento é obtido e armazenado em cache.
O diagrama abaixo mostra essas diferenças.
Modo de carga total versus modo de armazenamento em camadas
Fluxo de trabalho de carregamento do QueryNode
No armazenamento em camadas, o fluxo de trabalho tem as seguintes fases:
Fluxo de trabalho de carregamento do Querynode
Fase 1: Carregamento lento
Na inicialização, Milvus executa uma carga preguiçosa, armazenando em cache apenas metadados de nível de segmento, como definições de esquema, informações de índice e mapeamentos de pedaços.
Nenhum dado de campo real ou arquivos de índice são armazenados em cache neste estágio. Isso permite que as coleções se tornem consultáveis quase imediatamente após a inicialização, mantendo o consumo mínimo de memória e disco.
Como os dados de campo e os ficheiros de índice permanecem no armazenamento remoto até serem acedidos pela primeira vez, a primeira consulta pode sofrer latência adicional, uma vez que os dados necessários têm de ser obtidos a pedido. Para atenuar esse efeito para campos ou índices críticos, você pode usar a estratégia Warm Up para pré-carregá-los proativamente antes que o segmento se torne consultável.
Configuração
Aplicado automaticamente quando o armazenamento em camadas está ativado. Nenhuma configuração manual é necessária.
Fase 2: Aquecimento
Para reduzir a latência de primeiro acesso introduzida pela carga preguiçosa, o Milvus fornece um mecanismo de Warm Up.
Antes que um segmento se torne consultável, o Milvus pode buscar e armazenar em cache proativamente campos ou índices específicos do armazenamento de objetos, garantindo que a primeira consulta atinja diretamente os dados em cache em vez de acionar o carregamento sob demanda.
Durante o warmup, os campos serão pré-carregados no nível do chunk, enquanto os índices serão pré-carregados no nível do segmento.
Configuração
As configurações de aquecimento são definidas na seção Armazenamento em camadas de milvus.yaml. É possível ativar ou desativar o pré-carregamento para cada campo ou tipo de índice e especificar a estratégia preferida. Consulte Warm Up para obter configurações detalhadas.
Fase 3: Carregamento parcial
Quando as consultas ou pesquisas começam, o QueryNode executa um carregamento parcial, obtendo apenas os blocos de dados ou arquivos de índice necessários do armazenamento de objetos.
Campos: Carregados a pedido ao nível do bloco. Somente os pedaços de dados que correspondem às condições de consulta atuais são obtidos, minimizando o uso de E/S e memória.
Índices: Carregados sob demanda no nível do segmento. Os ficheiros de índice têm de ser obtidos como unidades completas e não podem ser divididos em blocos.
Configuração
A carga parcial é aplicada automaticamente quando o armazenamento em camadas está ativado. Nenhuma configuração manual é necessária. Para minimizar a latência de primeiro acesso para dados críticos, combine com Warm Up.
Fase 4: Evicção
Para manter o uso saudável dos recursos, Milvus libera automaticamente os dados em cache não utilizados quando limites específicos são atingidos.
A evicção segue uma política de Menos Utilizados Recentemente (LRU), garantindo que os dados acessados com pouca frequência sejam removidos primeiro, enquanto os dados ativos permanecem no cache.
O despejo é regido pelos seguintes itens configuráveis:
Marcas d'água: Define os limites de memória ou disco que acionam e interrompem o despejo.
TTL da cache: remove dados obsoletos da cache após uma duração definida de inatividade.
Configuração
Habilite e ajuste os parâmetros de despejo em milvus.yaml. Consulte Evicção para obter uma configuração detalhada.
Introdução
Pré-requisitos
Milvus 2.6.4+
QueryNodes com memória dedicada e recursos de disco
Backend de armazenamento de objetos (S3, MinIO, etc.)
Os recursos do QueryNode não devem ser compartilhados com outras cargas de trabalho. Os recursos compartilhados podem fazer com que o armazenamento em camadas avalie incorretamente a capacidade disponível, levando a falhas.
Modelo de configuração básica
Edite o arquivo de configuração do Milvus (milvus.yaml) para definir as configurações do Tiered Storage:
# milvus.yaml
queryNode:
segcore:
tieredStorage:
# Warm Up Configuration
warmup:
scalarField: sync # Preload scalar field data
scalarIndex: sync # Preload scalar indexes
vectorField: disable # Don't preload vector field data (large)
vectorIndex: sync # Preload vector indexes
# Eviction Configuration
evictionEnabled: true
backgroundEvictionEnabled: true
# Memory Watermarks
memoryLowWatermarkRatio: 0.75 # Stop evicting at 75%
memoryHighWatermarkRatio: 0.80 # Start evicting at 80%
# Disk Watermarks
diskLowWatermarkRatio: 0.75
diskHighWatermarkRatio: 0.80
# Cache TTL (7 days)
cacheTtl: 604800
Próximas etapas
Configure o Warm Up - otimize o pré-carregamento para seus padrões de acesso. Consulte Warm Up.
Ajuste o Eviction - Defina marcas d'água e TTL apropriados para suas restrições de recursos. Consulte Evicção.
Monitorar o desempenho - Acompanhe as taxas de acerto do cache, a frequência de despejo e os padrões de latência de consulta.
Iterar a configuração - Ajuste as configurações com base nas caraterísticas observadas da carga de trabalho.
PERGUNTAS FREQUENTES
Posso alterar os parâmetros do Armazenamento em camadas em tempo de execução?
Não. Todos os parâmetros devem ser definidos em milvus.yaml antes de iniciar o Milvus. As alterações exigem uma reinicialização para entrar em vigor.
O armazenamento em camadas afeta a durabilidade dos dados?
Não. A persistência dos dados continua a ser gerida pelo armazenamento remoto de objectos. O armazenamento em camadas só gerencia o armazenamento em cache nos QueryNodes.
As consultas serão sempre mais rápidas com o Armazenamento em camadas?
Não necessariamente. O Armazenamento em camadas reduz o tempo de carregamento e o uso de recursos, mas as consultas que tocam em dados não armazenados em cache (frios) podem ter uma latência maior. Para cargas de trabalho sensíveis à latência, recomenda-se o modo de carga total.
Porque é que um QueryNode continua a ficar sem recursos mesmo com o Armazenamento em camadas ativado?
Duas causas comuns:
O QueryNode foi configurado com muito poucos recursos. As marcas d'água são relativas aos recursos disponíveis, portanto, o provisionamento insuficiente amplifica os erros de avaliação.
Os recursos do QueryNode são compartilhados com outras cargas de trabalho, portanto, o Armazenamento em camadas não pode avaliar corretamente a capacidade disponível real.
Para resolver isso, recomendamos que você aloque recursos dedicados para QueryNodes.
Por que algumas consultas falham com alta simultaneidade?
Se muitas consultas atingirem os dados quentes ao mesmo tempo, os limites de recursos do QueryNode ainda poderão ser excedidos. Alguns threads podem falhar devido a tempos limite de reserva de recursos. Tentar novamente depois que a carga diminuir, ou alocar mais recursos, pode resolver isso.
Por que a latência de pesquisa/consulta aumenta depois de ativar o armazenamento em camadas?
As possíveis causas incluem:
Consultas frequentes a dados frios, que devem ser obtidos do armazenamento.
Marcas d'água definidas muito próximas umas das outras, causando despejo síncrono frequente.