Home
Blog
Pare de pagar por dados frios: 80% de redução de custos com o carregamento de dados quentes e frios a pedido no armazenamento em camadas Milvus

Pare de pagar por dados frios: 80% de redução de custos com o carregamento de dados quentes e frios a pedido no armazenamento em camadas Milvus

Engineering

December 15, 2025

Buqian Zheng

Quantos de vós continuam a pagar facturas de infra-estruturas de alta qualidade por dados que o vosso sistema mal toca? Seja honesto - a maioria das equipas está.

Se você executa a pesquisa de vetores na produção, provavelmente já viu isso em primeira mão. Você provisiona grandes quantidades de memória e SSDs para que tudo fique "pronto para consulta", mesmo que apenas uma pequena parte do seu conjunto de dados esteja realmente ativa. E não é o único. Também vimos muitos casos semelhantes:

Plataformas SaaS de vários inquilinos: Centenas de inquilinos integrados, mas apenas 10-15% activos num determinado dia. Os restantes permanecem inactivos, mas continuam a ocupar recursos.
Sistemas de recomendação de comércio eletrónico: Um milhão de SKUs, mas os 8% principais dos produtos geram a maioria das recomendações e do tráfego de pesquisa.
Pesquisa de IA: Vastos arquivos de embeddings, apesar de 90% das consultas dos utilizadores incidirem sobre itens da semana passada.

É a mesma história em todos os sectores: menos de 10% dos seus dados são consultados frequentemente, mas consomem 80% do seu armazenamento e memória. Toda a gente sabe que o desequilíbrio existe - mas até há pouco tempo, não havia uma forma arquitetónica simples de o resolver.

Isso muda com o Milvus 2.6.

Antes desta versão, o Milvus (tal como a maioria das bases de dados vectoriais) dependia de um modelo de carregamento completo: se os dados precisassem de ser pesquisáveis, tinham de ser carregados nos nós locais. Não importava se os dados eram acessados mil vezes por minuto ou uma vez por trimestre - tudo tinha que permanecer quente. Essa escolha de design garantiu um desempenho previsível, mas também significou o sobredimensionamento de clusters e o pagamento de recursos que os dados frios simplesmente não mereciam.

O armazenamento em camadas é a nossa resposta.

O Milvus 2.6 introduz uma nova arquitetura de armazenamento em camadas com verdadeiro carregamento sob demanda, permitindo que o sistema diferencie automaticamente entre dados quentes e frios:

Os segmentos quentes ficam em cache perto do computador
Os segmentos frios vivem de forma barata no armazenamento de objectos remoto
Os dados são puxados para nós locais apenas quando uma consulta realmente precisa deles

Isto muda a sua estrutura de custos de "quantos dados tem" para "quantos dados utiliza efetivamente". E nas primeiras implantações de produção, essa simples mudança proporciona uma redução de até 80% no custo de armazenamento e memória.

No restante deste post, explicaremos como o armazenamento em camadas funciona, compartilharemos resultados reais de desempenho e mostraremos onde essa mudança causa o maior impacto.

Por que o carregamento total é interrompido em escala

Antes de mergulhar na solução, vale a pena analisar mais de perto por que o modo de carga total usado no Milvus 2.5 e em versões anteriores se tornou um fator limitante à medida que as cargas de trabalho eram dimensionadas.

No Milvus 2.5 e versões anteriores, quando um usuário emitia uma solicitação Collection.load(), cada QueryNode armazenava em cache a coleção inteira localmente, incluindo metadados, dados de campo e índices. Estes componentes são descarregados do armazenamento de objectos e armazenados totalmente na memória ou mapeados na memória (mmap) para o disco local. Só depois de todos estes dados estarem disponíveis localmente é que a coleção é marcada como carregada e pronta para servir consultas.

Por outras palavras, a coleção não é consultável até que o conjunto de dados completo - quente ou frio - esteja presente no nó.

Nota: Para os tipos de índice que incorporam dados vectoriais em bruto, o Milvus carrega apenas os ficheiros de índice e não o campo vetorial separadamente. Mesmo assim, o índice tem de ser totalmente carregado para servir as consultas, independentemente da quantidade de dados que é realmente acedida.

Para ver por que isso se torna problemático, considere um exemplo concreto:

Suponha que tem um conjunto de dados vectoriais de média dimensão com:

100 milhões de vectores
768 dimensões (BERT embeddings)
precisãofloat32 (4 bytes por dimensão)
Um índice HNSW

Nesta configuração, só o índice HNSW - incluindo os vectores brutos incorporados - consome aproximadamente 430 GB de memória. Depois de adicionar campos escalares comuns, como IDs de utilizador, carimbos de data/hora ou etiquetas de categoria, a utilização total de recursos locais ultrapassa facilmente os 500 GB.

Isto significa que, mesmo que 80% dos dados sejam raramente ou nunca consultados, o sistema tem de fornecer e manter mais de 500 GB de memória local ou disco apenas para manter a coleção online.

Para algumas cargas de trabalho, este comportamento é aceitável:

Se quase todos os dados são acedidos frequentemente, carregar tudo proporciona a latência de consulta mais baixa possível - com o custo mais elevado.
Se os dados puderem ser divididos em subconjuntos quentes e mornos, o mapeamento de memória dos dados quentes para o disco pode reduzir parcialmente a pressão da memória.

No entanto, em cargas de trabalho em que 80% ou mais dos dados se encontram na cauda longa, as desvantagens do carregamento completo surgem rapidamente, tanto em termos de desempenho como de custo.

Gargalos de desempenho

Na prática, o carregamento completo afecta mais do que o desempenho das consultas e, muitas vezes, torna mais lentos os fluxos de trabalho operacionais de rotina:

Actualizações contínuas mais longas: Em grandes clusters, as actualizações contínuas podem demorar horas ou mesmo um dia inteiro, uma vez que cada nó tem de recarregar todo o conjunto de dados antes de ficar novamente disponível.
Recuperação mais lenta após falhas: Quando um QueryNode é reiniciado, ele não pode atender ao tráfego até que todos os dados sejam recarregados, prolongando significativamente o tempo de recuperação e ampliando o impacto das falhas de nós.
Iteração e experimentação mais lentas: O carregamento completo torna os fluxos de trabalho de desenvolvimento mais lentos, obrigando as equipas de IA a esperar horas pelo carregamento dos dados quando testam novos conjuntos de dados ou configurações de índices.

Ineficiências de custo

O carregamento completo também aumenta os custos de infraestrutura. Por exemplo, em instâncias otimizadas para memória na nuvem convencional, armazenar 1 TB de dados localmente custa cerca de $**70 . 000 por ano **, com base em preços conservadores (AWSr6i :$ $70.000 por ano**, com base em preços conservadores (AWS r6i: ~$ $*, com base em preços conservadores (AWSr6i$ : $5.74 / GB / mês; GCP n4-highmem: ~5$ $, 68/GB/mês; AzureE-series :$ 5 $,68 / GB / mês; Azure E-series: ~$ 5 $, 68/GB/mês; AzureE -$ $series$ : $5,67 / GB / mês).$

Agora considere um padrão de acesso mais realista, em que 80% desses dados são frios e podem ser armazenados no armazenamento de objectos (a cerca de $0,023 / GB / mês):

200 GB de dados quentes × $5,68
800 GB de dados frios × $0,023

Custo anual: (200×5,68+800×0,023)×12≈$14.000

Isso representa uma redução de 80% no custo total de armazenamento, sem sacrificar o desempenho onde ele realmente importa.

O que é o armazenamento em camadas e como ele funciona?

Para eliminar o compromisso, o Milvus 2.6 introduziu o armazenamento em camadas, que equilibra o desempenho e o custo ao tratar o armazenamento local como uma cache em vez de um contentor para todo o conjunto de dados.

Nesse modelo, os QueryNodes carregam apenas metadados leves na inicialização. Os dados de campo e os índices são obtidos a pedido do armazenamento de objectos remoto quando uma consulta os requer, e colocados em cache localmente se forem acedidos frequentemente. Os dados inactivos podem ser evacuados para libertar espaço.

Como resultado, os dados quentes permanecem perto da camada de computação para consultas de baixa latência, enquanto os dados frios permanecem no armazenamento de objectos até serem necessários. Isso reduz o tempo de carregamento, melhora a eficiência dos recursos e permite que os QueryNodes consultem conjuntos de dados muito maiores do que sua memória local ou capacidade de disco.

Na prática, o armazenamento em camadas funciona da seguinte forma:

Manter os dados quentes locais: Cerca de 20% dos dados frequentemente acedidos permanecem residentes nos nós locais, garantindo uma baixa latência para os 80% das consultas que mais importam.
Carregar dados frios sob demanda: Os restantes 80% dos dados raramente acedidos são obtidos apenas quando necessário, libertando a maior parte da memória local e dos recursos do disco.
Adaptar-se dinamicamente com o despejo baseado em LRU: O Milvus usa uma estratégia de despejo LRU (Least Recently Used) para ajustar continuamente quais dados são considerados quentes ou frios. Os dados inactivos são automaticamente eliminados para dar lugar a dados recentemente acedidos.

Com esse design, o Milvus não é mais limitado pela capacidade fixa da memória local e do disco. Em vez disso, os recursos locais funcionam como um cache gerenciado dinamicamente, onde o espaço é continuamente recuperado de dados inativos e realocado para cargas de trabalho ativas.

Na sua essência, esse comportamento é possibilitado por três mecanismos técnicos principais:

1. Carga preguiçosa

Na inicialização, o Milvus carrega apenas metadados mínimos ao nível do segmento, permitindo que as colecções se tornem consultáveis quase imediatamente após o arranque. Os dados de campo e os ficheiros de índice permanecem no armazenamento remoto e são obtidos a pedido durante a execução da consulta, mantendo a memória local e a utilização do disco baixos.

Como funcionava o carregamento de colecções no Milvus 2.5

Como o lazy loading funciona no Milvus 2.6 e posteriores

Os metadados carregados durante a inicialização se dividem em quatro categorias principais:

Estatísticas do segmento (Informações básicas como contagem de linhas, tamanho do segmento e metadados do esquema)
Carimbos de data e hora (usados para suportar consultas de viagem no tempo)
Registos de inserção e eliminação (necessários para manter a consistência dos dados durante a execução da consulta)
Filtros Bloom (Utilizados para pré-filtragem rápida para eliminar rapidamente segmentos irrelevantes)

2. Carregamento parcial

Enquanto o carregamento lento controla quando os dados são carregados, o carregamento parcial controla a quantidade de dados carregados. Uma vez iniciadas as consultas ou pesquisas, o QueryNode efectua um carregamento parcial, obtendo apenas os pedaços de dados necessários ou ficheiros de índice do armazenamento de objectos.

Índices vectoriais: Carregamento com reconhecimento de locatário

Uma das capacidades mais impactantes introduzidas no Milvus 2.6+ é o carregamento de índices vectoriais com conhecimento do inquilino, concebido especificamente para cargas de trabalho multi-tenant.

Quando uma consulta acede a dados de um único inquilino, o Milvus carrega apenas a parte do índice vetorial pertencente a esse inquilino, ignorando os dados do índice para todos os outros inquilinos. Isso mantém os recursos locais concentrados nos locatários ativos.

Esse design oferece vários benefícios:

Os índices vetoriais para locatários inativos não consomem memória local ou disco
Os dados de índice para locatários ativos permanecem em cache para acesso de baixa latência
Uma política de despejo LRU no nível do locatário garante o uso justo do cache entre os locatários

Campos escalares: Carregamento parcial ao nível da coluna

O carregamento parcial também se aplica a campos escalares, permitindo que o Milvus carregue apenas as colunas explicitamente referenciadas por uma consulta.

Considere uma coleção com 50 campos de esquema, como id, vector, title, description, category, price, stock, e tags, e você só precisa retornar três campos -id, title, e price.

No Milvus 2.5, todos os 50 campos escalares são carregados independentemente dos requisitos da consulta.
No Milvus 2.6+, apenas os três campos solicitados são carregados. Os restantes 47 campos não são carregados e só são obtidos de forma preguiçosa se forem acedidos mais tarde.

A economia de recursos pode ser substancial. Se cada campo escalar ocupar 20 GB:

Carregar todos os campos requer 1.000 GB (50 × 20 GB)
Carregar apenas os três campos necessários usa 60 GB

Isto representa uma redução de 94% no carregamento de dados escalares, sem afetar a correção da consulta ou os resultados.

Nota: o carregamento parcial com reconhecimento de locatário para campos escalares e índices vetoriais será oficialmente introduzido em uma próxima versão. Uma vez disponível, ele reduzirá ainda mais a latência de carga e melhorará o desempenho da consulta a frio em grandes implantações de vários locatários.

3. Evicção de cache baseada em LRU

O carregamento preguiçoso e o carregamento parcial reduzem significativamente a quantidade de dados que são trazidos para a memória local e para o disco. No entanto, em sistemas de longa duração, a cache continuará a crescer à medida que novos dados são acedidos ao longo do tempo. Quando a capacidade local é atingida, o despejo de cache baseado em LRU entra em vigor.

O despejo LRU (Least Recently Used) segue uma regra simples: os dados que não foram acedidos recentemente são despejados primeiro. Isto liberta espaço local para dados recentemente acedidos, mantendo os dados frequentemente utilizados residentes na cache.

Avaliação de desempenho: Armazenamento em camadas vs. Carregamento total

Para avaliar o impacto do armazenamento em camadas no mundo real, configuramos um ambiente de teste que espelha de perto as cargas de trabalho de produção. Comparámos o Milvus com e sem armazenamento em camadas em cinco dimensões: tempo de carregamento, utilização de recursos, desempenho de consultas, capacidade efectiva e eficiência de custos.

Configuração experimental

Conjunto de dados

100 milhões de vectores com 768 dimensões (BERT embeddings)
Tamanho do índice do vetor: aproximadamente 430 GB
10 campos escalares, incluindo ID, registo de data e hora e categoria

Configuração de hardware

1 QueryNode com 4 vCPUs, 32 GB de memória e 1 TB de SSD NVMe
Rede de 10 Gbps
Cluster de armazenamento de objetos MinIO como back-end de armazenamento remoto

Padrão de acesso

As consultas seguem uma distribuição realista de acesso quente-frio:

80% das consultas têm como alvo os dados dos 30 dias mais recentes (≈20% do total de dados)
15% têm como objetivo dados de 30-90 dias (≈30% do total de dados)
5% direcionam os dados com mais de 90 dias (≈50% do total de dados)

Resultados principais

1. Tempo de carregamento 33× mais rápido

Fase	Milvus 2.5	Milvus 2.6+ (armazenamento em camadas)	Aceleração
Descarregamento de dados	22 minutos	28 segundos	47×
Carregamento do índice	3 minutos	17 segundos	10.5×
total	25 minutos	45 segundos	33×

No Milvus 2.5, o carregamento da coleção demorava 25 minutos. Com o armazenamento em camadas no Milvus 2.6+, a mesma carga de trabalho é concluída em apenas 45 segundos, o que representa uma melhoria significativa na eficiência do carregamento.

2. 80% de redução no uso de recursos locais

Estágio	Milvus 2.5	Milvus 2.6+ (Armazenamento em camadas)	Redução
Após o carregamento	430 GB	12 GB	-97%
Após 1 hora	430 GB	68 GB	-84%
Após 24 horas	430 GB	85 GB	-80%
Estado estável	430 GB	85-95 GB	~80%

No Milvus 2.5, o uso de recursos locais permanece constante em 430 GB, independentemente da carga de trabalho ou tempo de execução. Em contraste, o Milvus 2.6+ começa com apenas 12 GB imediatamente após o carregamento.

À medida que as consultas são executadas, os dados frequentemente acedidos são armazenados em cache localmente e a utilização de recursos aumenta gradualmente. Após cerca de 24 horas, o sistema estabiliza em 85-95 GB, reflectindo o conjunto de trabalho de dados quentes. A longo prazo, isto resulta numa redução de ~80% na memória local e na utilização do disco, sem sacrificar a disponibilidade das consultas.

3. Impacto quase nulo no desempenho dos dados quentes

Tipo de consulta	Latência do Milvus 2.5 P99	Latência do Milvus 2.6+ P99	Alterar
Consultas de dados quentes	15 ms	16 ms	+6.7%
Consultas de dados quentes	15 ms	28 ms	+86%
Consultas de dados frios (primeiro acesso)	15 ms	120 ms	+700%
Consultas de dados frios (em cache)	15 ms	18 ms	+20%

Para dados quentes, que representam cerca de 80% de todas as consultas, a latência do P99 aumenta apenas 6,7%, resultando em praticamente nenhum impacto percetível na produção.

As consultas de dados frios apresentam uma latência mais elevada no primeiro acesso devido ao carregamento a pedido a partir do armazenamento de objectos. No entanto, uma vez armazenadas em cache, sua latência aumenta em apenas 20%. Dada a baixa frequência de acesso dos dados frios, este compromisso é geralmente aceitável para a maioria das cargas de trabalho do mundo real.

4. Capacidade efectiva 4,3× maior

Com o mesmo orçamento de hardware - oito servidores com 64 GB de memória cada (512 GB no total) - o Milvus 2.5 pode carregar no máximo 512 GB de dados, o equivalente a aproximadamente 136 milhões de vetores.

Com o armazenamento em camadas ativado no Milvus 2.6+, o mesmo hardware pode suportar 2,2 TB de dados, ou seja, cerca de 590 milhões de vectores. Isto representa um aumento de 4,3 vezes na capacidade efectiva, permitindo servir conjuntos de dados significativamente maiores sem expandir a memória local.

5. Redução de custos de 80,1%

Utilizando um conjunto de dados vectoriais de 2 TB num ambiente AWS como exemplo, e assumindo que 20% dos dados são quentes (400 GB), a comparação de custos é a seguinte:

Item	Milvus 2.5	Milvus 2.6+ (armazenamento em camadas)	Poupança
Custo mensal	$11,802	$2,343	$9,459
Custo anual	$141,624	$28,116	$113,508
Taxa de poupança	-	-	80.1%

Resumo do benchmark

Em todos os testes, o armazenamento em camadas oferece melhorias consistentes e mensuráveis:

Tempos de carregamento 33 vezes mais rápidos: O tempo de carregamento da coleção é reduzido de 25 minutos para 45 segundos.
80% menos uso de recursos locais: Em operação estável, o uso de memória e disco local cai em aproximadamente 80%.
Impacto quase nulo no desempenho dos dados quentes: A latência do P99 para dados quentes aumenta em menos de 10%, preservando o desempenho da consulta de baixa latência.
Latência controlada para dados frios: Os dados frios incorrem em maior latência no primeiro acesso, mas isso é aceitável dada a sua baixa frequência de acesso.
Capacidade efectiva 4,3 vezes superior: O mesmo hardware pode servir 4-5 vezes mais dados sem memória adicional.
Mais de 80% de redução de custos: Os custos anuais de infraestrutura são reduzidos em mais de 80%.

Quando utilizar o armazenamento em camadas no Milvus

Com base em resultados de benchmark e casos de produção reais, agrupamos os casos de utilização do armazenamento em camadas em três categorias para o ajudar a decidir se é adequado para a sua carga de trabalho.

Casos de uso mais adequados

1. Plataformas de pesquisa vetorial multilocatário

Caraterísticas: Grande número de locatários com atividade altamente desigual; a pesquisa vetorial é a carga de trabalho principal.
Padrão de acesso: Menos de 20% dos inquilinos geram mais de 80% das consultas vectoriais.
Benefícios esperados: Redução de custos de 70-80%; expansão de capacidade de 3-5×.

2. Sistemas de recomendação de comércio eletrónico (cargas de trabalho de pesquisa vetorial)

Caraterísticas: Forte distorção da popularidade entre os produtos de topo e a cauda longa.
Padrão de acesso: Os 10% de produtos de topo representam ~80% do tráfego de pesquisa vetorial.
Benefícios esperados: Sem necessidade de capacidade extra durante os picos de tráfego; redução de custos de 60-70%.

3. Conjuntos de dados em grande escala com uma separação clara entre quente e frio (predominância de vectores)

Caraterísticas: Conjuntos de dados de escala TB ou superior, com acesso fortemente orientado para dados recentes.
Padrão de acesso: Uma distribuição 80/20 clássica: 20% dos dados servem 80% das consultas
Benefícios esperados: 75-85% de redução de custos

Casos de utilização adequados

1. Cargas de trabalho sensíveis ao custo

Caraterísticas: Orçamentos apertados com alguma tolerância para pequenas compensações de desempenho.
Padrão de acesso: As consultas vectoriais são relativamente concentradas.
Benefícios esperados: Redução de custos de 50-70%; os dados frios podem incorrer numa latência de cerca de 500 ms no primeiro acesso, que deve ser avaliada em função dos requisitos do SLA.

2. Retenção de dados históricos e pesquisa em arquivo

Caraterísticas: Grandes volumes de vectores históricos com uma frequência de consulta muito baixa.
Padrão de acesso: Cerca de 90% das consultas visam dados recentes.
Benefícios esperados: Manter conjuntos de dados históricos completos; manter os custos de infraestrutura previsíveis e controlados

Casos de utilização pouco adequados

1. Cargas de trabalho de dados uniformemente quentes

Caraterísticas: Todos os dados são acedidos com uma frequência semelhante, sem distinção clara entre quente e frio.
Por que não é adequado: Benefício limitado da cache; complexidade adicional do sistema sem ganhos significativos

2. Cargas de trabalho de latência ultrabaixa

Caraterísticas: Sistemas extremamente sensíveis à latência, como comércio financeiro ou licitações em tempo real
Por que não é adequado: Mesmo pequenas variações de latência são inaceitáveis; o carregamento completo proporciona um desempenho mais previsível

Início rápido: Experimente o armazenamento em camadas no Milvus 2.6+

# Download Milvus 2.6.1+
$ wget https://github.com/milvus-io/milvus/releases/latest
# Configure Tiered Storage
$ vi milvus.yaml
queryNode.segcore.tieredStorage:
  warmup:
    scalarField: disable
    scalarIndex: disable
    vectorField: disable
    vectorIndex: disable
  evictionEnabled: true
# Launch Milvus
$ docker-compose up -d

Conclusão

O Tiered Storage no Milvus 2.6 aborda uma incompatibilidade comum entre como os dados vetoriais são armazenados e como eles são realmente acessados. Na maioria dos sistemas de produção, apenas uma pequena fração dos dados é consultada com frequência, mas os modelos de carregamento tradicionais tratam todos os dados como igualmente quentes. Ao mudar para o carregamento sob demanda e gerenciar a memória local e o disco como um cache, o Milvus alinha o consumo de recursos com o comportamento real de consulta em vez de suposições de pior caso.

Essa abordagem permite que os sistemas sejam dimensionados para conjuntos de dados maiores sem aumentos proporcionais nos recursos locais, mantendo o desempenho da consulta quente praticamente inalterado. Os dados frios permanecem acessíveis quando necessário, com latência previsível e limitada, tornando o compromisso explícito e controlável. À medida que a pesquisa vetorial se aprofunda em ambientes de produção sensíveis a custos, multilocatários e de longa duração, o Armazenamento em camadas fornece uma base prática para operar com eficiência em escala.

Para obter mais informações sobre o armazenamento em camadas, consulte a documentação abaixo:

Tiered Storage | Documentação Milvus

Tem dúvidas ou deseja aprofundar qualquer recurso do Milvus mais recente? Junte-se ao nosso canal Discord ou registe problemas no GitHub. Também pode reservar uma sessão individual de 20 minutos para obter informações, orientação e respostas às suas perguntas através do Milvus Office Hours.