Uma Introdução à Arquitetura do Milvus
Em uma pesquisa com mais de 1200 usuários, encontramos um desafio-chave recorrente: escalabilidade. Como podemos escalar nossas operações vetoriais? Essa pergunta leva ao desenvolvimento do Milvus como um sistema distribuído. Bancos de dados vetoriais, diferentemente dos bancos de dados tradicionais, têm requisitos de uso diferentes. Três diferenças principais nos motivaram a criar um banco de dados vetorial nativo da nuvem do zero.
Primeiro, dados vetoriais não exigem transações complexas.
Segundo, a diversidade dos casos de uso exige um equilíbrio ajustável entre desempenho e consistência.
Terceiro, algumas operações com dados vetoriais são computacionalmente caras, exigindo alocação elástica de recursos.
O Milvus alcança escalabilidade horizontal por meio de seu design deliberado como um sistema distribuído. Embora bancos de dados de instância única possam escalar até certo ponto, eles logo se tornam limitados pelo hardware. A capacidade de escalabilidade horizontal do Milvus supera esse problema, permitindo que o banco de dados se estenda por várias instâncias. Há duas maneiras de escalar um banco de dados horizontalmente: integrando diretamente a funcionalidade ao banco de dados ou implementando manualmente processos de escalabilidade.
Com o Milvus, a funcionalidade de escalabilidade é incorporada ao sistema. Embora você possa lidar com a escalabilidade por conta própria, essa não é uma solução ideal, a menos que seu trabalho de missão crítica envolva escalar bancos de dados. Vamos examinar três arquiteturas e duas escolhas de design de busca que tornam o Milvus tão escalável.
Arquitetura de sistema nativa da nuvem
A maioria das equipes de software não implanta mais em servidores na sala de servidores. Por quê? As nuvens públicas disponíveis (AWS, Azure, GCP etc.) permitem que as equipes de software avancem mais rápido. O Milvus foi criado para aproveitar a flexibilidade que trabalhar na nuvem proporciona.
O Milvus contém quatro camadas: acesso, coordenação, worker e armazenamento. Nós de acesso sem estado dão acesso ao sistema. Os workers e coordenadores são projetados em um padrão serverless. Coordenadores com estado ativam e desativam workers sem estado conforme necessário. A camada de armazenamento armazena os dados vetoriais e todas as informações necessárias para o sistema funcionar.
Separação de responsabilidades
Ao trabalhar com um banco de dados vetorial, há três áreas principais de preocupação: consulta, ingestão de dados e indexação. Essas três funcionalidades sempre escalarão em medidas diferentes em momentos diferentes. O Milvus fornece três tipos diferentes de nós que podem escalar independentemente.
Nós de consulta lidam com a funcionalidade de consulta, o que significa que devem ter memória suficiente para manter os índices em memória de vários segmentos. Segmentos são blocos de dados de tamanho predefinido que o Milvus usa para eficiência e escalabilidade. Nós de consulta também ajudam a paralelizar a busca usando parte de sua computação e memória para delegar, agregar e processar resultados de busca de vários segmentos, muitos dos quais podem estar em outros nós.
À medida que os dados entram, eles vão tanto para os nós de consulta quanto para os nós de dados. Esses nós mantêm dados em segmentos em crescimento que ainda não atingiram seu limite de tamanho. Depois que o segmento atinge a capacidade, o nó de consulta libera esses dados e os substitui pelo índice gerado.
Nós de dados lidam com a ingestão de dados. Depois que um segmento atinge seu limite de tamanho em um nó de dados, ele é “selado.” Segmentos selados são então descarregados para armazenamento permanente a partir dos nós de dados e de consulta. Uma vez que os dados são descarregados para a camada de armazenamento, os coordenadores notificam um nó de índice.
Nós de índice constroem índices. Quando um nó de índice é notificado, ele lê o segmento de dados da camada de armazenamento. Essa configuração naturalmente nos permite trabalhar com menos dados ao criar o índice. Como o nó de índice lê dados do armazenamento, ele pode ler apenas os atributos de que precisa para desenvolver índices.
Consistência de gravação em larga escala
Uma parte natural do escalonamento é se deparar com problemas de consistência. Assim que você inicia a segunda réplica ou instância do Milvus ou de qualquer outro sistema de banco de dados, você se depara instantaneamente com um problema de consistência de dados. Você deve garantir um acordo em todo o sistema sobre quão consistentes os dados devem ser.
O Milvus tem muitas opções para ajustar a consistência dos seus dados integradas ao sistema. O Milvus é um sistema pub/sub. O bloco de armazenamento de mensagens atua como um sistema de publicação, registrando com timestamp cada parte dos dados que passa por ele. Os nós de consulta e de dados então leem esse log de publicação como assinantes.
Escalonar a escrita envolve escalonar o número de shards que atuam como gravadores. À medida que os dados entram, seu ID é submetido a hash, e o hash determina qual shard gravará aquela parte dos dados.
Segmentos de dados para busca paralela
Como mencionado anteriormente, o Milvus cria índices individuais em quantidades predefinidas de dados chamadas “segmentos.” Por padrão, o Milvus cria segmentos em 512 MB de dados, o que você pode ajustar para atender às suas necessidades.
Por que criamos segmentos e construímos índices dessa forma? Para mais flexibilidade, escalabilidade e facilidade de mutação. Índices são formas de acessar dados. Imagine que você construa um índice em algum conjunto de dados inicial. Em um cenário do mundo real, seus dados mudam ao longo do tempo, então você terá que continuar adicionando dados. Como o índice inicial foi construído apenas sobre os dados iniciais, ele não ajuda com os novos dados.
A solução racional para esse problema de indexação seria construir continuamente novos índices em algum intervalo predefinido (como a quantidade de novos dados adicionados). O Milvus implementa essa solução em várias instâncias e réplicas.
Essa configuração de segmentos fornece uma solução eficiente para a indexação ineficiente e torna as consultas mais escaláveis. Como os índices construídos em segmentos de dados separados não dependem uns dos outros, podemos pesquisá-los em paralelo, limitados apenas pelo hardware.
Optar por um tamanho de segmento maior aumenta a eficiência de cada operação de busca; no entanto, é essencial observar que essa escolha também resulta em custos maiores associados à compactação e à reconstrução de índices.
Busca de metadados com pré-filtragem
A filtragem de metadados é um recurso importante para muitas pessoas. Esse recurso permite que você procure apenas vetores de datas específicas, de autores específicos ou com valores de atributos específicos. Ao projetar uma aplicação de busca vetorial, você pode colocar a filtragem de metadados antes ou depois da funcionalidade de busca vetorial.
Antes de realizar uma busca vetorial, o Milvus gera uma máscara de bits nos metadados. Essa operação de pré-filtragem é linear no tempo. O Milvus revisa os dados uma vez e verifica se os metadados correspondem ou não à expressão de filtro fornecida. A pré-filtragem dos metadados diminui o volume de dados submetidos à busca vetorial, o que torna a operação de busca vetorial mais eficiente.
Na próxima versão do Milvus 2.4, ofereceremos suporte ao índice invertido com tantivy, e a velocidade da pré-filtragem aumentará drasticamente.
Resumo
O Milvus adota uma arquitetura de sistema distribuído composta por quatro camadas: acesso, coordenação, worker e armazenamento. Dados os diversos casos de uso de bancos de dados vetoriais, uma infraestrutura adaptável e em evolução é essencial. O Milvus modela seu componente de ingestão de dados de acordo com esse requisito como um sistema pub/sub (publish-subscribe).
Modelar a ingestão de dados como um serviço pub/sub nos dá flexibilidade ao permitir um paradigma de serviço desacoplado e ajuda na consistência dos dados. O serviço de “publicação” marca cada parte dos dados com um timestamp como parte da funcionalidade de consistência.
Quando se trata das três preocupações (consulta, ingestão de dados e indexação) em um banco de dados vetorial, o Milvus separa todas elas. Cada uma das três operações tem seu nó dedicado. Você pode ativar e desativar os nós de forma independente, permitindo que o Milvus escale com a quantidade de dados que você tem e o padrão de uso.
Garantir a consistência dos dados é uma das tarefas mais desafiadoras à medida que a quantidade de dados que você possui aumenta. O Milvus enfrenta esse desafio por meio do uso de “shards”. Os dados recebidos são submetidos a hash e, em seguida, divididos em um shard com base em seu hash. O Milvus tem uma consistência ajustável com quatro níveis para escolher, permitindo equilibrar a rapidez com que sua busca responde e a rapidez com que os dados são replicados entre as muitas instâncias do banco de dados.
Escrever dados em escala usa múltiplos shards. Ler dados em escala usa segmentos. Índices são criados em segmentos individuais. Cada segmento agora pode ser pesquisado em paralelo no momento da consulta, reduzindo massivamente o tempo de busca para grandes quantidades de dados.
Ao buscar dados, você provavelmente vai querer conseguir filtrá-los de alguma forma. O Milvus implementa a filtragem de metadados como uma operação de pré-filtragem. Em seguida, aplica uma máscara de bits ao conjunto de dados durante a busca vetorial e ignora quaisquer vetores que não se encaixem. Essa abordagem pode reduzir significativamente o tempo de busca se muitos vetores forem filtrados.
A arquitetura exclusiva do Milvus oferece muitos benefícios, especialmente o dimensionamento horizontal. Ela é meticulosamente criada como um banco de dados vetorial nativo da nuvem para um rápido dimensionamento horizontal, mantendo o desempenho ideal. O design de arquitetura deliberadamente desacoplado facilita a evolução do Milvus ao longo do tempo e permite flexibilidade. Essa adaptabilidade se mostra crucial diante da crescente importância dos bancos de dados vetoriais e da gama cada vez maior de casos de uso que eles atendem.
Continue lendo
Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing
Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.
DeepSeek Always Busy? Deploy It Locally with Milvus in Just 10 Minutes—No More Waiting!
Learn how to set up DeepSeek-R1 on your local machine using Ollama, AnythingLLM, and Milvus in just 10 minutes. Bypass busy servers and enhance AI responses with custom data.
AI Integration in Video Surveillance Tools: Transforming the Industry with Vector Databases
Discover how AI and vector databases are revolutionizing video surveillance with real-time analysis, faster threat detection, and intelligent search capabilities for enhanced security.