Entendendo Modelos de Consistência para Bancos de Dados Vetoriais
Sistemas distribuídos para suas aplicações de busca vetorial estão se tornando indispensáveis, abrangendo desde escalabilidade e tolerância a falhas até desempenho aprimorado e acessibilidade global. Os princípios fundamentais que tornam os sistemas distribuídos a espinha dorsal de aplicações resilientes e de alto desempenho exigem que consideremos as compensações entre consistência, disponibilidade e latência.
Por exemplo, a consistência é crítica para certos casos de uso de busca vetorial em sua aplicação distribuída. Não seria péssimo se você consultasse dados que esperava que estivessem lá, mas não estivessem? Isso aconteceria se seus dados não fossem consistentes em todas as réplicas que você tem em seus sistemas distribuídos. À primeira vista, parece simples. Claro, meus dados deveriam estar lá depois que eu os coloquei lá e os repliquei em vários nós. Mas quando eles deveriam estar lá? Como você garante isso?
Em resposta ao problema de consistência, o banco de dados vetorial totalmente distribuído Milvus oferece Consistência Ajustável. O Milvus tem uma arquitetura única que permite escalar horizontalmente a forma como você grava seus dados e garantir consistência sem precisar usar ferramentas extras. Aproveitando uma infraestrutura distribuída, o Milvus é um sistema pub-sub fracamente acoplado, o que significa que a consistência pode ser facilmente gerenciada e ajustada por meio de timestamps.
Neste artigo, veremos:
O que é Consistência?
- Requisitos de Consistência de Bancos de Dados Vetoriais
Consistência, Disponibilidade e Partições
Quais Níveis de Consistência o Milvus Oferece?
Consistência Eventual
Consistência de Sessão
Consistência Limitada
Consistência Forte
Resumo sobre Como Entender a Consistência para Bancos de Dados Vetoriais
O que é consistência?
Uma das definições de consistência é “a obtenção de um nível de desempenho que não varia muito em qualidade ao longo do tempo.” Em relação à consistência para seu banco de dados distribuído, ela fornece os dados mais precisos e atualizados que você solicita. É por isso que o Milvus oferece a capacidade de “ajustar” sua consistência com base em quão recentes os dados aos quais você deseja acesso precisam ser.
Diferentes tipos de bancos de dados têm requisitos adicionais de consistência. Por exemplo, bancos de dados não relacionais frequentemente têm requisitos ACID (atomicidade, consistência, isolamento e durabilidade) “eventuais” ou relaxados. Você pode receber dados parcialmente atualizados ao trabalhar com bancos de dados NoSQL.
Por outro lado, bancos de dados SQL compatíveis com ACID, como o Postgres, têm requisitos de consistência diferentes. Esses bancos de dados garantem que você não receberá dados parcialmente atualizados, aplicando consistência no nível de alteração. Portanto, quando você consulta, precisa esperar que toda a sua alteração seja concluída para obter de volta os dados dessa alteração.
Requisitos de consistência de bancos de dados vetoriais
Enquanto isso, bancos de dados vetoriais têm requisitos de consistência diferentes dos bancos de dados relacionais ou não relacionais. Você pode ter dados válidos mesmo antes de uma alteração em lote ser totalmente concluída. No entanto, você não pode ter dados parcialmente atualizados. Bancos de dados vetoriais operam sob o teorema PACELC. É exatamente isso que o Milvus faz por meio de sua configuração pub-sub. Cada linha é “publicada” por meio do pipeline de gravação e “assinada” pelos nós necessários. Essa configuração permite pesquisar ou consultar o Milvus e obter resultados com base nas diferenças nos timestamps.
Consistência, disponibilidade e partições (CAP)
O teorema CAP é um conceito da ciência da computação que afirma que há uma compensação entre consistência, disponibilidade e tolerância a partições. Você só pode escolher dois dos três. Quando há uma partição de rede, você deve escolher entre disponibilidade e consistência. Um sistema que exige alta disponibilidade de dados requer réplicas, o que torna a consistência mais difícil.
O teorema PACELC é uma extensão do teorema CAP. É o teorema CAP + else + latência + consistência. Ele afirma que você não precisa se preocupar com compromissos entre disponibilidade e consistência em um sistema sem partições de rede. No entanto, você ainda precisa escolher entre latência e consistência, pois precisa esperar que os dados sejam sincronizados.
Quais níveis de consistência o Milvus oferece?
O Milvus oferece quatro níveis diferentes de consistência. Em ordem do menos para o mais consistente, são: Eventual, Session, Bounded e Strong. Consistência eventual significa que você está disposto a esperar até que “... quando quer que” aconteça. Consistência forte significa que você quer incluir todos os dados no momento em que envia a consulta. Session e Bounded ficam no meio. Vamos analisar mais a fundo.
Você consegue adivinhar quais emojis representam quais níveis?
Consistência Eventual
Consistência eventual (ou “Eventually”) significa que os dados acabarão sendo consistentes em todas as réplicas. Usamos consistência eventual quando nos importamos mais com a velocidade de uma aplicação do que em ter os dados mais atualizados ou consultas repetíveis. Para o Milvus, esse tipo de consistência significa que implementamos o requisito de consistência pulando a verificação de timestamp ao ler.
Um exemplo de caso de uso desse tipo de nível de consistência pode ser ao buscar avaliações de produtos. A maioria dos usuários não lerá todas as avaliações de um produto, portanto obter as avaliações mais atualizadas não é de alta importância. Se você quiser criar uma coleção com esse nível de consistência, o código abaixo mostra como criar uma coleção com consistência no nível “Eventually” no Milvus. É importante observar que consistency_level está procurando a palavra-chave “Eventually.”
Consistência de Sessão
Consistência de sessão significa que cada sessão está pelo menos atualizada com base em suas próprias gravações. Uma sessão pode ter várias réplicas, então esse é o primeiro compromisso entre latência e consistência. Usamos consistência de sessão quando só precisamos salvar nosso estado uma vez por sessão. O Milvus implementa esse tipo de consistência definindo o timestamp necessário para o momento da última gravação.
Na prática, você pode usar consistência de sessão quando precisa que cada instância cliente-servidor tenha consistência de dados. Um exemplo disso é um servidor de videogame. Você não quer permitir que os jogadores façam glitches infinitos, então deve garantir consistência dentro de cada instância ou sessão. O código abaixo mostra como fazer uma busca vetorial usando um nível de consistência “Session.”
Consistência Limitada
Consistência limitada (ou bounded staleness) é um passo “mais consistente” do que a consistência de sessão. Com consistência no nível “Session”, as outras instâncias, ou sessões, são tratadas como eventualmente consistentes. Bounded staleness força cada instância e réplica a sincronizar dentro de um determinado período.
Um exemplo de bounded staleness poderia ser um mecanismo de recomendação de vídeos. Os usuários não precisarão dos vídeos mais recentes imediatamente, mas devem vê-los em breve. As alterações de um usuário também devem proliferar prontamente para fora de sua sessão. O código abaixo mostra como pesquisar no Milvus com um requisito de consistência limitada.
Consistência Forte
Consistência forte disponibiliza os dados no momento em que você os insere. É claro que essa consistência vem com um compromisso de latência — precisamos esperar o sistema mudar. Na prática, o Milvus implementa essa consistência definindo o timestamp de leitura necessário para a atualização mais recente no sistema. Isso eleva nossa latência de busca a um mínimo de 200 ms.
Um exemplo de consistência forte poderia ser a detecção de fraudes. Se alguém usar sua conta bancária para fraude, você deve saber e impedir isso imediatamente. Aplicações que precisam de uma configuração do tipo leitura-após-escrita precisam de consistência forte. O código abaixo mostra como consultar uma coleção (busca filtrada sem vetores) com um requisito de consistência Forte.
Resumo sobre a compreensão da consistência para bancos de dados vetoriais
A consistência de dados é uma das coisas mais importantes a considerar ao criar sua aplicação distribuída. Toda aplicação precisa de dados, e todos os dados precisam de alguns requisitos de consistência. Em relação aos dados vetoriais, devemos avaliar a consistência dos dados considerando requisitos de consistência baseados em linhas.
Em alinhamento com esses requisitos, o Milvus oferece quatro níveis de consistência com base na atribuição de timestamps aos dados. Observe que isso é possível apenas para consistência baseada em linhas e não é implementado em bancos de dados SQL ou NoSQL. Os quatro níveis de consistência, do mais ao menos consistente, são forte, limitada, de sessão e eventual.
A consistência forte garante que tenhamos todos os dados mais atualizados disponíveis em todo o sistema (quase) imediatamente. Esse nível de consistência é alcançado atualizando o timestamp para o timestamp da inserção mais recente, garantindo que possamos consultar todos os dados inseridos até o momento da solicitação.
A consistência limitada garante que tenhamos todos os dados mais atualizados em todo o sistema dentro de um período fixo. A consistência limitada define o timestamp a ser verificado dentro de um determinado período a partir da solicitação. Dessa forma, temos todos os dados dentro de um período limitado. A consistência limitada é a configuração padrão no Milvus.
A consistência de sessão garante que tenhamos todos os dados mais atualizados na sessão atual em que estamos trabalhando. O Milvus alcança esse nível de consistência definindo o timestamp de cada instância para o último momento em que essa instância inseriu dados. Dessa forma, temos todos os dados inseridos em (pelo menos) a instância que usamos.
Por fim, a consistência eventual (palavra-chave “Eventually”) garante que, eventualmente, os dados em todo o sistema serão todos consistentes. Os dados podem se proliferar e são sincronizados com réplicas na taxa que fizer sentido. Embora sacrifiquemos alguma consistência de dados, obtemos melhor disponibilidade e desempenho em troca. Na prática, esse nível de consistência não demora muito. O Milvus implementa a consistência eventual pulando a verificação de timestamp e executando buscas ou consultas imediatamente.
Continue lendo
VDBBench Adds Cost-Aware Benchmarking for Vector Databases
Compare Zilliz Cloud, Pinecone, and turbopuffer with VDBBench cost-aware vector database benchmarks across latency, freshness, multitenancy, and cold starts.
Zilliz Cloud Delivers Better Performance and Lower Costs with Arm Neoverse-based AWS Graviton
Zilliz Cloud adopts Arm-based AWS Graviton3 CPUs to cut costs, speed up AI vector search, and power billion-scale RAG and semantic search workloads.
The Great AI Agent Protocol Race: Function Calling vs. MCP vs. A2A
Compare Function Calling, MCP, and A2A protocols for AI agents. Learn which standard best fits your development needs and future-proof your applications.