Home
Blog
Apresentamos o AISAQ em Milvus: a pesquisa de vectores à escala de milhares de milhões acaba de ficar 3.200 vezes mais barata em termos de memória

Apresentamos o AISAQ em Milvus: a pesquisa de vectores à escala de milhares de milhões acaba de ficar 3.200 vezes mais barata em termos de memória

Engineering

December 10, 2025

Martin Li

As bases de dados vectoriais tornaram-se a infraestrutura central dos sistemas de IA de missão crítica, e os seus volumes de dados estão a crescer exponencialmente - muitas vezes atingindo milhares de milhões de vectores. Nessa escala, tudo se torna mais difícil: manter a baixa latência, preservar a precisão, garantir a fiabilidade e operar entre réplicas e regiões. Mas há um desafio que tende a surgir cedo e a dominar as decisões de arquitetura: o custo.

Para proporcionar uma pesquisa rápida, a maioria das bases de dados vectoriais mantém as principais estruturas de indexação em DRAM (Dynamic Random Access Memory), o nível de memória mais rápido e mais caro. Este design é eficaz em termos de desempenho, mas é pouco escalável. O uso de DRAM escala com o tamanho dos dados e não com o tráfego de consulta, e mesmo com compressão ou descarregamento parcial de SSD, grandes porções do índice devem permanecer na memória. À medida que os conjuntos de dados crescem, os custos de memória rapidamente se tornam um fator limitante.

O Milvus já oferece suporte ao DISKANN, uma abordagem ANN baseada em disco que reduz a pressão da memória ao mover grande parte do índice para o SSD. No entanto, DISKANN ainda depende de DRAM para representações comprimidas usadas durante a pesquisa. O Milvus 2.6 leva isso adiante com o AISAQ, um índice vetorial baseado em disco inspirado no DISKANN. Desenvolvido pela KIOXIA, a arquitetura do AiSAQ foi concebida com uma "Arquitetura Zero-DRAM-Footprint", que armazena todos os dados críticos de pesquisa no disco e optimiza a colocação de dados para minimizar as operações de E/S. Numa carga de trabalho de mil milhões de vectores, isto reduz a utilização de memória de 32 GB para cerca de 10 MB - uma redução de 3.200 vezes -mantendo o desempenho prático.

Nas secções que se seguem, explicamos como funciona a pesquisa vetorial baseada em grafos, de onde vêm os custos de memória e como o AISAQ reformula a curva de custos da pesquisa vetorial à escala de mil milhões.

Como funciona a pesquisa vetorial convencional baseada em grafos

A pesquisa vetorial é o processo de encontrar pontos de dados cujas representações numéricas estão mais próximas de uma consulta em um espaço de alta dimensão. "Mais próximo" significa simplesmente a menor distância de acordo com uma função de distância, como a distância cosseno ou a distância L2. Em pequena escala, isto é simples: calcular a distância entre a consulta e cada vetor e, em seguida, devolver os mais próximos. No entanto, a uma grande escala, digamos à escala de mil milhões, esta abordagem torna-se rapidamente demasiado lenta para ser prática.

Para evitar comparações exaustivas, os sistemas modernos de pesquisa do vizinho mais próximo aproximado (ANNS) baseiam-se em índices baseados em grafos. Em vez de comparar uma consulta com cada vetor, o índice organiza os vectores num grafo. Cada nó representa um vetor e as arestas ligam vectores que estão numericamente próximos. Esta estrutura permite que o sistema reduza drasticamente o espaço de pesquisa.

O gráfico é construído antecipadamente, com base apenas nas relações entre os vectores. Não depende de consultas. Quando chega uma consulta, a tarefa do sistema é navegar no gráfico de forma eficiente e identificar os vectores com a distância mais pequena à consulta - sem analisar todo o conjunto de dados.

A pesquisa começa a partir de um ponto de entrada predefinido no gráfico. Este ponto de partida pode estar longe da consulta, mas o algoritmo melhora a sua posição passo a passo, movendo-se para vectores que parecem mais próximos da consulta. Durante esse processo, a pesquisa mantém duas estruturas de dados internas que funcionam em conjunto: uma lista de candidatos e uma lista de resultados.

E as duas etapas mais importantes durante esse processo são a expansão da lista de candidatos e a atualização da lista de resultados.

Expansão da lista de candidatos

A lista de candidatos representa onde a pesquisa pode ir em seguida. É um conjunto priorizado de nós do gráfico que parecem promissores com base em sua distância para a consulta.

A cada iteração, o algoritmo

Seleciona o candidato mais próximo descoberto até o momento. Da lista de candidatos, ele escolhe o vetor com a menor distância para a consulta.
Recupera os vizinhos desse vetor a partir do gráfico. Estes vizinhos são vectores que foram identificados durante a construção do índice como estando próximos do vetor atual.
Avalia os vizinhos não visitados e adiciona-os à lista de candidatos. Para cada vizinho que ainda não tenha sido explorado, o algoritmo calcula a sua distância à consulta. Os vizinhos visitados anteriormente são ignorados, enquanto os novos vizinhos são inseridos na lista de candidatos se parecerem promissores.

Ao expandir repetidamente a lista de candidatos, a pesquisa explora regiões cada vez mais relevantes do gráfico. Isso permite que o algoritmo se mova constantemente em direção a melhores respostas enquanto examina apenas uma pequena fração de todos os vetores.

Atualização da lista de resultados

Ao mesmo tempo, o algoritmo mantém uma lista de resultados, que regista os melhores candidatos encontrados até ao momento para a saída final. À medida que a pesquisa progride, ele:

Rastreia os vetores mais próximos encontrados durante a travessia. Estes incluem os vectores selecionados para expansão, bem como outros avaliados ao longo do caminho.
Armazena as suas distâncias em relação à consulta. Isso permite classificar os candidatos e manter os top-K vizinhos mais próximos atuais.

Com o tempo, à medida que mais candidatos são avaliados e menos melhorias são encontradas, a lista de resultados se estabiliza. Quando é improvável que uma maior exploração do grafo produza vectores mais próximos, a pesquisa termina e devolve a lista de resultados como a resposta final.

Em termos simples, a lista de candidatos controla a exploração, enquanto a lista de resultados captura as melhores respostas descobertas até o momento.

O trade-off na pesquisa vetorial baseada em grafos

Esta abordagem baseada em grafos é o que torna a pesquisa vetorial em grande escala prática em primeiro lugar. Ao navegar no grafo em vez de analisar cada vetor, o sistema pode encontrar resultados de alta qualidade tocando apenas numa pequena fração do conjunto de dados.

No entanto, esta eficiência não é gratuita. A pesquisa baseada em grafos expõe um compromisso fundamental entre precisão e custo.

Explorar mais vizinhos melhora a precisão, cobrindo uma parte maior do gráfico e reduzindo a hipótese de faltarem os verdadeiros vizinhos mais próximos.
Ao mesmo tempo, cada expansão adicional adiciona trabalho: mais cálculos de distância, mais acessos à estrutura do grafo e mais leituras de dados vetoriais. À medida que a pesquisa explora mais profundamente ou mais amplamente, esses custos se acumulam. Dependendo de como o índice é projetado, eles aparecem como maior uso da CPU, maior pressão na memória ou E/S adicional em disco.

Equilibrar essas forças opostas - alta recuperação versus uso eficiente de recursos - é fundamental para o projeto de pesquisa baseada em grafos.

Tanto o DISKANN quanto o AISAQ foram criados com base nessa mesma tensão, mas fazem escolhas arquitetônicas diferentes sobre como e onde esses custos são pagos.

Como o DISKANN otimiza a pesquisa vetorial baseada em disco

O DISKANN é a solução ANN baseada em disco mais influente até à data e serve como linha de base oficial para a competição NeurIPS Big ANN, uma referência global para pesquisa vetorial à escala de mil milhões. A sua importância não reside apenas no desempenho, mas no que provou: a pesquisa ANN baseada em grafos não tem de viver inteiramente na memória para ser rápida.

Ao combinar o armazenamento baseado em SSD com estruturas na memória cuidadosamente escolhidas, o DISKANN demonstrou que a pesquisa vetorial em grande escala pode atingir uma precisão elevada e uma baixa latência em hardware de base - sem necessitar de grandes volumes de DRAM. Ele faz isso repensando quais partes da pesquisa devem ser rápidas e quais partes podem tolerar um acesso mais lento.

Em alto nível, o DISKANN mantém os dados acessados com mais freqüência na memória, enquanto move estruturas maiores e acessadas com menos freqüência para o disco. Este equilíbrio é conseguido através de várias escolhas de design importantes.

1. Usando distâncias PQ para expandir a lista de candidatos

A expansão da lista de candidatos é a operação mais frequente na pesquisa baseada em grafos. Cada expansão requer a estimativa da distância entre o vetor de consulta e os vizinhos de um nó candidato. A realização destes cálculos utilizando vectores completos e de elevada dimensão exigiria leituras aleatórias frequentes do disco - uma operação dispendiosa, tanto em termos computacionais como de E/S.

O DISKANN evita este custo comprimindo os vectores em códigos de Quantização do Produto (PQ) e mantendo-os na memória. Os códigos PQ são muito mais pequenos do que os vectores completos, mas ainda preservam informação suficiente para estimar aproximadamente a distância.

Durante a expansão de candidatos, o DISKANN calcula as distâncias utilizando estes códigos PQ na memória em vez de ler vectores completos do SSD. Isso reduz drasticamente a E/S do disco durante a travessia do grafo, permitindo que a pesquisa expanda candidatos de forma rápida e eficiente, mantendo a maior parte do tráfego do SSD fora do caminho crítico.

2. Co-localização de vetores completos e listas de vizinhos no disco

Nem todos os dados podem ser compactados ou acessados aproximadamente. Uma vez identificados os candidatos promissores, a pesquisa ainda precisa de acesso a dois tipos de dados para obter resultados precisos:

Listas de vizinhos, para continuar a travessia do gráfico
Vectores completos (não comprimidos), para o reranking final

Estas estruturas são acedidas com menos frequência do que os códigos PQ, pelo que o DISKANN as armazena em SSD. Para minimizar a sobrecarga do disco, o DISKANN coloca a lista de vizinhos de cada nó e o seu vetor completo na mesma região física do disco. Isso garante que uma única leitura de SSD possa recuperar ambos.

Ao co-localizar dados relacionados, o DISKANN reduz o número de acessos aleatórios ao disco necessários durante a pesquisa. Esta otimização melhora a eficiência da expansão e da nova classificação, especialmente em grande escala.

3. Expansão de nós paralelos para melhor utilização de SSD

A pesquisa ANN baseada em gráficos é um processo iterativo. Se cada iteração expande apenas um nó candidato, o sistema emite apenas uma única leitura de disco por vez, deixando a maior parte da largura de banda paralela do SSD sem uso. Para evitar essa ineficiência, o DISKANN expande vários candidatos em cada iteração e envia solicitações de leitura paralela para o SSD. Essa abordagem utiliza muito melhor a largura de banda disponível e reduz o número total de iterações necessárias.

O parâmetro beam_width_ratio controla quantos candidatos são expandidos em paralelo: Largura do feixe = número de núcleos da CPU × razão_de_largura_do_feixe. Um rácio mais elevado alarga a pesquisa - melhorando potencialmente a precisão - mas também aumenta a computação e a E/S do disco.

Para compensar esta situação, o DISKANN introduz um search_cache_budget_gb_ratio que reserva memória para armazenar em cache os dados acedidos frequentemente, reduzindo as leituras repetidas do SSD. Em conjunto, estes mecanismos ajudam o DISKANN a equilibrar a precisão, a latência e a eficiência de E/S.

Porque é que isto é importante - e onde surgem os limites

O design do DISKANN é um grande passo em frente para a pesquisa vetorial baseada em disco. Ao manter os códigos PQ na memória e empurrar estruturas maiores para SSD, ele reduz significativamente o espaço ocupado na memória em comparação com índices de gráficos totalmente na memória.

Ao mesmo tempo, essa arquitetura ainda depende da DRAM sempre ativa para dados críticos de pesquisa. Os códigos PQ, caches e estruturas de controlo devem permanecer residentes na memória para manter a eficiência da travessia. À medida que os conjuntos de dados aumentam para milhares de milhões de vectores e as implementações adicionam réplicas ou regiões, esse requisito de memória pode continuar a ser um fator limitativo.

Essa é a lacuna que o AISAQ foi projetado para resolver.

Como o AISAQ funciona e por que é importante

O AISAQ se baseia diretamente nas idéias centrais do DISKANN, mas introduz uma mudança crítica: ele elimina a necessidade de manter os dados de PQ na DRAM. Em vez de tratar os vectores comprimidos como estruturas críticas para a pesquisa e sempre na memória, o AISAQ move-os para SSD e redesenha a forma como os dados do grafo são dispostos no disco para preservar uma travessia eficiente.

Para que isso funcione, o AISAQ reorganiza o armazenamento de nós para que os dados necessários durante a pesquisa de grafos - vetores completos, listas de vizinhos e informações de PQ - sejam organizados no disco em padrões otimizados para a localidade de acesso. O objetivo não é apenas enviar mais dados para o disco mais econômico, mas fazer isso sem interromper o processo de busca descrito anteriormente.

Para atender a diferentes requisitos de aplicativos, o AISAQ fornece dois modos de armazenamento baseados em disco: Desempenho e Escala. De uma perspetiva técnica, estes modos diferem principalmente na forma como os dados comprimidos PQ são armazenados e acedidos durante a pesquisa. Do ponto de vista da aplicação, estes modos respondem a dois tipos distintos de requisitos: requisitos de baixa latência, típicos da pesquisa semântica em linha e dos sistemas de recomendação, e requisitos de escala ultra-alta, típicos do RAG.

Desempenho do AISAQ: Optimizado para velocidade

O AISAQ-performance mantém todos os dados no disco enquanto mantém uma baixa sobrecarga de E/S através da colocação de dados.

Neste modo:

O vetor completo de cada nó, a lista de arestas e os códigos PQ dos seus vizinhos são armazenados em conjunto no disco.
A visita a um nó continua a exigir apenas uma única leitura de SSD, porque todos os dados necessários para a expansão e avaliação dos candidatos estão colocados.

Do ponto de vista do algoritmo de pesquisa, isto reflecte de perto o padrão de acesso do DISKANN. A expansão de candidatos continua a ser eficiente e o desempenho em tempo de execução é comparável, apesar de todos os dados críticos para a pesquisa residirem agora no disco.

A contrapartida é a sobrecarga de armazenamento. Como os dados PQ de um vizinho podem aparecer em páginas de disco de vários nós, esse layout introduz redundância e aumenta significativamente o tamanho geral do índice.

Por conseguinte, o modo AISAQ-Performance dá prioridade à baixa latência de E/S em detrimento da eficiência do disco. Do ponto de vista da aplicação, o modo AiSAQ-Performance pode fornecer uma latência na ordem dos 10 mSec, conforme necessário para a pesquisa semântica em linha.

Escala AISAQ: Optimizado para eficiência de armazenamento

O AISAQ-Scale adopta a abordagem oposta. Foi concebido para minimizar a utilização do disco, mantendo todos os dados no SSD.

Neste modo:

Os dados PQ são armazenados no disco separadamente, sem redundância.
Isto elimina a redundância e reduz drasticamente o tamanho do índice.

A desvantagem é que o acesso aos códigos PQ de um nó e dos seus vizinhos pode exigir várias leituras em SSD, aumentando as operações de E/S durante a expansão dos candidatos. Se não for optimizado, isto tornaria a pesquisa significativamente mais lenta.

Para controlar esta sobrecarga, o modo AISAQ-Scale introduz duas optimizações adicionais:

Reorganização de dados PQ, que ordena os vectores PQ por prioridade de acesso para melhorar a localidade e reduzir as leituras aleatórias.
Uma cache PQ na DRAM (pq_read_page_cache_size), que armazena dados PQ frequentemente acedidos e evita leituras repetidas no disco para entradas quentes.

Com estas optimizações, o modo AISAQ-Scale consegue uma eficiência de armazenamento muito melhor do que o AISAQ-Performance, mantendo o desempenho prático da pesquisa. Esse desempenho continua a ser inferior ao do DISKANN, mas não há sobrecarga de armazenamento (o tamanho do índice é semelhante ao do DISKANN) e a pegada de memória é muito menor. Do ponto de vista da aplicação, o AiSAQ fornece os meios para cumprir os requisitos RAG em escala ultraelevada.

Principais vantagens do AISAQ

Ao mover todos os dados críticos de pesquisa para o disco e ao redesenhar a forma como esses dados são acedidos, o AISAQ altera fundamentalmente o perfil de custo e escalabilidade da pesquisa vetorial baseada em grafos. O seu design oferece três vantagens significativas.

1. Uso de DRAM até 3.200 vezes menor

A Quantização de Produtos reduz significativamente o tamanho de vectores de elevada dimensão, mas à escala de mil milhões, o espaço de memória continua a ser substancial. Mesmo após a compressão, os códigos PQ têm de ser mantidos na memória durante a pesquisa em concepções convencionais.

Por exemplo, no SIFT1B, um parâmetro de referência com mil milhões de vectores de 128 dimensões, os códigos PQ requerem, por si só, cerca de 30-120 GB de DRAM, dependendo da configuração. Armazenar os vectores completos e não comprimidos exigiria cerca de 480 GB adicionais. Embora o PQ reduza a utilização de memória em 4-16×, a pegada restante continua a ser suficientemente grande para dominar o custo da infraestrutura.

O AISAQ elimina totalmente este requisito. Ao armazenar códigos PQ em SSD em vez de DRAM, a memória deixa de ser consumida por dados de índice persistentes. A DRAM é utilizada apenas para estruturas leves e transitórias, como listas de candidatos e metadados de controlo. Na prática, isso reduz o uso de memória de dezenas de gigabytes para cerca de 10 MB. Numa configuração representativa à escala de mil milhões, a DRAM cai de 32 GB para 10 MB, uma redução de 3200 vezes.

Dado que o armazenamento SSD custa cerca de 1/30 do preço por unidade de capacidade em comparação com a DRAM, esta mudança tem um impacto direto e dramático no custo total do sistema.

2. Sem sobrecarga adicional de E/S

Mover os códigos PQ da memória para o disco normalmente aumentaria o número de operações de E/S durante a pesquisa. O AISAQ evita isso controlando cuidadosamente a disposição dos dados e os padrões de acesso. Em vez de espalhar os dados relacionados pelo disco, o AISAQ coloca os códigos PQ, os vectores completos e as listas de vizinhos de forma a poderem ser recuperados em conjunto. Isto garante que a expansão de candidatos não introduz leituras aleatórias adicionais.

Para dar aos utilizadores controlo sobre o compromisso entre o tamanho do índice e a eficiência de E/S, o AISAQ introduz o parâmetro inline_pq, que determina a quantidade de dados PQ armazenados em linha com cada nó:

Menor inline_pq: menor tamanho do índice, mas pode exigir E/S extra
Inline_pq mais alto: tamanho de índice maior, mas preserva o acesso de leitura única

Quando configurado com inline_pq = max_degree, o AISAQ lê o vetor completo de um nó, a lista de vizinhos e todos os códigos PQ numa única operação de disco, correspondendo ao padrão de E/S do DISKANN e mantendo todos os dados no SSD.

3. O acesso sequencial a PQ melhora a eficiência da computação

Na DISKANN, a expansão de um nó candidato requer R acessos aleatórios à memória para obter os códigos PQ dos seus R vizinhos. O AISAQ elimina esta aleatoriedade recuperando todos os códigos PQ numa única E/S e armazenando-os sequencialmente no disco.

A disposição sequencial oferece duas vantagens importantes:

As leituras sequenciais em SSD são muito mais rápidas do que as leituras aleatórias dispersas.
Os dados contíguos são mais fáceis de armazenar em cache, permitindo que as CPUs calculem as distâncias PQ com mais eficiência.

Isso melhora a velocidade e a previsibilidade dos cálculos de distância PQ e ajuda a compensar o custo de desempenho do armazenamento de códigos PQ em SSD em vez de DRAM.

AISAQ vs. DISKANN: Avaliação do desempenho

Depois de compreender como o AISAQ difere arquitetonicamente do DISKANN, a próxima questão é simples: como é que estas escolhas de design afectam o desempenho e a utilização de recursos na prática? Esta avaliação compara o AISAQ e o DISKANN em três dimensões que são mais importantes numa escala de mil milhões: desempenho de pesquisa, consumo de memória e utilização de disco.

Em particular, examinamos como o AISAQ se comporta à medida que a quantidade de dados PQ embutidos (INLINE_PQ) muda. Este parâmetro controla diretamente o compromisso entre o tamanho do índice, a E/S do disco e a eficiência do tempo de execução. Também avaliamos ambas as abordagens em cargas de trabalho vectoriais de baixa e alta dimensão, uma vez que a dimensionalidade influencia fortemente o custo do cálculo da distância e os requisitos de armazenamento.

Configuração

Todas as experiências foram realizadas num sistema de nó único para isolar o comportamento do índice e evitar a interferência de efeitos de rede ou de sistema distribuído.

Configuração de hardware:

CPU: CPU Intel® Xeon® Platinum 8375C @ 2,90GHz
Memória: Velocidade: 3200 MT/s, Tipo: DDR4, Tamanho: 32 GB
Disco: SSD NVMe de 500 GB

Parâmetros de criação de índice

{
  "max_degree": 48,
  "search_list_size": 100,
  "inline_pq": 0/12/24/48,  // AiSAQ only
  "pq_code_budget_gb_ratio": 0.125,
  "search_cache_budget_gb_ratio": 0.0,
  "build_dram_budget_gb": 32.0
}

Parâmetros de consulta

{
  "k": 100,
  "search_list_size": 100,
  "beamwidth": 8
}

Método de referência

Tanto o DISKANN quanto o AISAQ foram testados usando o Knowhere, o mecanismo de pesquisa vetorial de código aberto usado no Milvus. Dois conjuntos de dados foram usados nesta avaliação:

SIFT128D (1M de vectores): um conhecido parâmetro de referência de 128 dimensões normalmente utilizado para a pesquisa de descritores de imagem. (Tamanho do conjunto de dados em bruto ≈ 488 MB)
Cohere768D (1M vectores): um conjunto de incorporação de 768 dimensões típico da pesquisa semântica baseada em transformadores. (Tamanho do conjunto de dados em bruto ≈ 2930 MB)

Estes conjuntos de dados reflectem dois cenários distintos do mundo real: caraterísticas de visão compactas e grandes incorporações semânticas.

Resultados

Sift128D1M (Vetor completo ~488MB)

Cohere768D1M (Vetor completo ~2930MB)

Análise

Conjunto de dados SIFT128D

No conjunto de dados SIFT128D, o AISAQ pode igualar o desempenho do DISKANN quando todos os dados PQ são alinhados de modo a que os dados necessários de cada nó caibam inteiramente numa única página SSD de 4 KB (INLINE_PQ = 48). Com esta configuração, todas as informações necessárias durante a pesquisa são colocalizadas:

Vetor completo: 512B
Lista de vizinhos: 48 × 4 + 4 = 196B
Códigos PQ dos vizinhos: 48 × (512B × 0,125) ≈ 3072B
Total: 3780B

Como todo o nó cabe numa página, só é necessária uma E/S por acesso e o AISAQ evita leituras aleatórias de dados PQ externos.

No entanto, quando apenas uma parte dos dados PQ é inlined, os restantes códigos PQ têm de ser obtidos a partir de outro local no disco. Isso introduz operações de E/S aleatórias adicionais, que aumentam drasticamente a demanda de IOPS e levam a quedas significativas no desempenho.

Conjunto de dados Cohere768D

No conjunto de dados Cohere768D, o AISAQ tem um desempenho pior do que o DISKANN. A razão é que um vetor de 768 dimensões simplesmente não cabe numa página SSD de 4 KB:

Vetor completo: 3072B
Lista de vizinhos: 48 × 4 + 4 = 196B
Códigos PQ dos vizinhos: 48 × (3072B × 0,125) ≈ 18432B
Total: 21.700 B (≈ 6 páginas)

Neste caso, mesmo que todos os códigos PQ sejam inlined, cada nó abrange várias páginas. Embora o número de operações de E/S se mantenha consistente, cada E/S tem de transferir muito mais dados, consumindo a largura de banda do SSD muito mais rapidamente. Quando a largura de banda se torna o fator limitante, o AISAQ não consegue acompanhar o ritmo do DISKANN - especialmente em cargas de trabalho de alta dimensão, em que as pegadas de dados por nó crescem rapidamente.

Observação:

O layout de armazenamento do AISAQ normalmente aumenta o tamanho do índice no disco em 4× a 6×. Trata-se de um compromisso deliberado: vectores completos, listas de vizinhos e códigos PQ são colocados no disco para permitir um acesso eficiente de página única durante a pesquisa. Embora isso aumente o uso de SSD, a capacidade do disco é significativamente mais barata do que a DRAM e é mais fácil de escalar em grandes volumes de dados.

Na prática, os utilizadores podem ajustar este compromisso ajustando as taxas de compressão INLINE_PQ e PQ. Esses parâmetros possibilitam equilibrar o desempenho da pesquisa, o espaço ocupado em disco e o custo geral do sistema com base nos requisitos da carga de trabalho, em vez de serem restringidos por limites fixos de memória.

Conclusão

A economia do hardware moderno está a mudar. Os preços da DRAM continuam altos, enquanto o desempenho da SSD avançou rapidamente - as unidades CIe 5.0 agora oferecem largura de banda superior a 14 GB/s. Como resultado, as arquiteturas que transferem dados críticos de pesquisa da cara DRAM para um armazenamento SSD muito mais acessível estão se tornando cada vez mais atraentes. Com a capacidade da SSD custando menos de 30 vezes mais por gigabyte do que a DRAM, essas diferenças não são mais marginais - elas influenciam significativamente o design do sistema.

O AISAQ reflete essa mudança. Ao eliminar a necessidade de grandes alocações de memória sempre ativa, ele permite que os sistemas de pesquisa vetorial sejam dimensionados com base no tamanho dos dados e nos requisitos de carga de trabalho, e não nos limites de DRAM. Essa abordagem está alinhada com uma tendência mais ampla de arquiteturas "all-in-storage", em que SSDs rápidas desempenham um papel central não apenas na persistência, mas na computação e pesquisa ativas. Ao oferecer dois modos de operação - Desempenho e Escala - o AiSAQ atende aos requisitos da pesquisa semântica (que exige a menor latência) e do RAG (que exige escala muito alta, mas latência moderada).

É pouco provável que esta mudança se limite às bases de dados vectoriais. Já estão a surgir padrões de conceção semelhantes no processamento de grafos, na análise de séries temporais e até mesmo em partes dos sistemas relacionais tradicionais, à medida que os programadores repensam os pressupostos de longa data sobre o local onde os dados devem residir para obter um desempenho aceitável. À medida que a economia do hardware continua a evoluir, as arquitecturas de sistemas seguir-se-ão.

Para obter mais detalhes sobre os projetos discutidos aqui, consulte a documentação:

Tem dúvidas ou deseja aprofundar qualquer caraterística 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.