pgvector vs Aerospike: Escolhendo o banco de dados vetorial certo para seus aplicativos de IA
O que é um Banco de Dados Vetorial?
Antes de compararmos pgvector e Aerospike, vamos primeiro explorar o conceito de bancos de dados vetoriais.
Um banco de dados vetorial é especificamente projetado para armazenar e consultar vetores de alta dimensionalidade, que são representações numéricas de dados não estruturados. Esses vetores codificam informações complexas, como o significado semântico de textos, as características visuais de imagens ou atributos de produtos. Ao permitir buscas por similaridade eficientes, os bancos de dados vetoriais desempenham um papel fundamental em aplicações de IA, possibilitando análise e recuperação de dados mais avançadas.
Casos de uso comuns para bancos de dados vetoriais incluem recomendações de produtos em e-commerce, plataformas de descoberta de conteúdo, detecção de anomalias em cibersegurança, análise de imagens médicas e tarefas de processamento de linguagem natural (NLP). Eles também desempenham um papel crucial na Geração Aumentada por Recuperação (RAG), uma técnica que melhora o desempenho de grandes modelos de linguagem (LLMs) ao fornecer conhecimento externo para reduzir problemas como alucinações de IA.
Há muitos tipos de bancos de dados vetoriais disponíveis no mercado, incluindo:
- Bancos de dados vetoriais criados especificamente para esse fim como Milvus, Zilliz Cloud (Milvus totalmente gerenciado)
- Bibliotecas de busca vetorial como Faiss e Annoy.
- Bancos de dados vetoriais leves como Chroma e Milvus Lite.
- Bancos de dados tradicionais com complementos de busca vetorial capazes de realizar buscas vetoriais em pequena escala.
pgvector é um banco de dados tradicional e Aerospike é um banco de dados NoSQL distribuído e escalável. Ambos têm recursos de busca vetorial como complemento. Este post compara seus recursos de busca vetorial.
pgvector: Visão geral e tecnologia central
pgvector é uma extensão para PostgreSQL que adiciona suporte a operações vetoriais. Ela permite que os usuários armazenem e consultem embeddings vetoriais diretamente em seu banco de dados PostgreSQL, fornecendo recursos de busca por similaridade vetorial sem a necessidade de um banco de dados vetorial separado.
Os principais recursos do pgvector incluem:
- Suporte para busca exata e aproximada pelo vizinho mais próximo
- Integração com os mecanismos de indexação do PostgreSQL
- Capacidade de realizar operações vetoriais como adição e subtração
- Suporte a várias métricas de distância (euclidiana, cosseno, produto interno)
pgvector, por padrão, emprega busca exata pelo vizinho mais próximo, o que garante recall perfeito, mas pode ser mais lento para grandes conjuntos de dados. Para otimizar o desempenho, o pgvector oferece a opção de criar índices para busca aproximada pelo vizinho mais próximo. Essa abordagem troca um pouco de precisão por velocidade significativamente melhorada, o que costuma ser uma compensação vantajosa em muitas aplicações do mundo real.
É importante observar que adicionar um índice aproximado pode alterar os resultados das suas consultas. Isso é diferente dos índices típicos de banco de dados, que não afetam os resultados reais retornados. Os dois tipos de índices aproximados compatíveis com o pgvector são:
- HNSW (Hierarchical Navigable Small World): Introduzido na versão 0.5.0 do pgvector, o HNSW é conhecido por seu alto desempenho e pela qualidade dos resultados. Ele constrói uma estrutura de grafo em múltiplas camadas que permite uma navegação rápida durante as buscas.
- IVFFlat (Inverted File Flat): Este método divide o espaço vetorial em clusters. Durante uma busca, ele primeiro identifica os clusters mais relevantes e, em seguida, realiza uma busca exata dentro desses clusters. Isso pode acelerar significativamente as buscas em grandes conjuntos de dados.
A escolha entre esses tipos de índice depende do seu caso de uso específico, considerando fatores como tamanho do conjunto de dados, velocidade de consulta necessária e compromisso aceitável em precisão. O HNSW geralmente oferece melhor desempenho, mas pode usar mais memória, enquanto o IVFFlat pode ser mais eficiente em termos de memória, mas pode ser um pouco mais lento ou menos preciso em alguns casos.
Ao implementar o pgvector em seu projeto, tente experimentar ambos os tipos de índice e seus parâmetros para encontrar a configuração ideal para suas necessidades específicas. Esse processo de ajuste fino pode impactar o desempenho e a precisão das suas operações de busca vetorial.
Quer aprender como começar a usar o pgvector? Confira este tutorial!
O que é Aerospike? Uma visão geral
Aerospike é um banco de dados NoSQL para aplicações em tempo real de alto desempenho. Ele adicionou suporte para indexação e busca vetorial, por isso é adequado para casos de uso de bancos de dados vetoriais. O recurso vetorial é chamado Aerospike Vector Search (AVS) e está em Preview. Você pode solicitar acesso antecipado à Aerospike.
O AVS oferece suporte apenas a índices Hierarchical Navigable Small World (HNSW) para busca vetorial. Quando atualizações ou inserções são feitas no AVS, os dados do registro, incluindo o vetor, são gravados no Aerospike Database (ASDB) e ficam imediatamente visíveis. Para a indexação, cada registro deve ter pelo menos um vetor no campo vetorial especificado de um índice. Você pode ter vários vetores e índices para um único registro, de modo que possa buscar nos mesmos dados de maneiras diferentes. A Aerospike recomenda atribuir registros inseridos ou atualizados via upsert a um conjunto específico para que você possa monitorá-los e operar sobre eles.
O AVS tem uma forma única de construir o índice: ela é concorrente em todos os nós AVS. Enquanto as atualizações de registros vetoriais são gravadas diretamente no ASDB, os registros de índice são processados de forma assíncrona a partir de uma fila de indexação. Isso é feito em lotes e distribuído por todos os nós AVS, de modo que utiliza todos os núcleos de CPU no cluster AVS e é escalável. O desempenho de ingestão depende muito da memória do host e da configuração da camada de armazenamento.
Para cada item na fila de indexação, o AVS processa o vetor para indexação, constrói os clusters para cada vetor e grava esses dados no ASDB. Um registro de índice contém uma cópia do próprio vetor e os clusters desse vetor em uma determinada camada do grafo HNSW. A indexação usa extensões vetoriais (AVX) para processamento paralelo de instrução única e múltiplos dados.
O AVS realiza consultas durante a ingestão para “pré-hidratar” o cache do índice, porque os registros nos clusters são interconectados. Essas consultas não são contabilizadas como solicitações de consulta, mas aparecem como leituras na camada de armazenamento. Dessa forma, o cache é preenchido com dados relevantes e pode melhorar o desempenho das consultas. Isso mostra como o AVS lida com dados vetoriais e constrói índices para busca por similaridade, de modo que possa escalar para buscas vetoriais de alta dimensionalidade.
Principais diferenças
Ao decidir entre pgvector e Aerospike para busca vetorial, aqui estão os principais fatores a considerar.
Metodologia de busca:
pgvector oferece suporte à busca exata e aproximada de vizinhos mais próximos. Ele tem dois tipos de índices aproximados: HNSW (Hierarchical Navigable Small World) e IVFFlat (Inverted File Flat). O HNSW constrói um grafo de várias camadas para travessia rápida, o IVFFlat divide o espaço vetorial em clusters. O Aerospike Vector Search (AVS) oferece suporte apenas a índices HNSW para busca vetorial.
Tratamento de Dados:
pgvector integra-se ao PostgreSQL para que você possa armazenar e consultar embeddings vetoriais junto com seus dados relacionais tradicionais. Se você precisa combinar busca vetorial com operações de dados estruturados, isso pode ser útil. O Aerospike, por ser um banco de dados NoSQL, é projetado para aplicações em tempo real de alto desempenho e pode ser mais adequado para dados semiestruturados ou não estruturados em escala.
Escalabilidade e Desempenho:
pgvector usa os mecanismos de indexação do PostgreSQL, que podem ser bons para muitos casos de uso. Mas, para conjuntos de dados muito grandes, talvez seja necessário ajustar seus índices e consultas cuidadosamente. O Aerospike é projetado para alta escalabilidade e tem um processo exclusivo de indexação concorrente em todos os nós do cluster. Essa abordagem distribuída pode ser melhor para operações de busca vetorial em grande escala.
Flexibilidade e Personalização:
pgvector permite que você execute várias operações vetoriais, como adição e subtração, e oferece suporte a múltiplas métricas de distância (euclidiana, cosseno, produto interno). Ele se integra perfeitamente ao rico conjunto de recursos e extensões do PostgreSQL. O Aerospike pode ter menos flexibilidade em termos de operações semelhantes a SQL, mas mais opções para ajuste fino de desempenho em escala.
Integração e Ecossistema:
pgvector tem o benefício do grande ecossistema de ferramentas e integrações do PostgreSQL. Se sua stack existente investe fortemente em PostgreSQL, então pgvector pode ser uma escolha natural. O Aerospike, embora menos comum, pode ter integrações específicas que são valiosas para aplicações em tempo real de alto desempenho.
Facilidade de Uso:
pgvector pode ser fácil de configurar e usar se você já estiver familiarizado com PostgreSQL. A curva de aprendizado pode ser mais íngreme para o Aerospike se você for novo em bancos de dados NoSQL. No entanto, ambos exigem consideração cuidadosa dos tipos e parâmetros de índice para otimizar o desempenho.
Custo:
pgvector é uma extensão open-source para PostgreSQL, então pode ter custo menor. O Aerospike oferece edições open-source e enterprise, AVS está atualmente em preview. O custo total dependerá da sua implantação e escala específicas.
Segurança:
Ambos têm recursos de segurança, mas os detalhes são diferentes. O PostgreSQL tem um conjunto robusto de mecanismos de autenticação e controle de acesso que o pgvector pode usar. O Aerospike tem recursos de segurança, mas você precisaria verificar a documentação deles para obter as informações mais atualizadas sobre criptografia, autenticação e controle de acesso para a busca vetorial deles.
Quando Escolher Cada Tecnologia
Use pgvector:
pgvector é uma boa escolha quando você já tem PostgreSQL e quer adicionar busca vetorial ao seu banco de dados relacional existente. É bom para projetos que precisam combinar operações vetoriais com consultas SQL ou quando você tem dados estruturados com um componente vetorial. pgvector é bom para busca exata de vizinhos mais próximos ou conjuntos de dados pequenos a médios onde o desempenho das consultas não é um gargalo.
Use Aerospike:
Aerospike com Vector Search (AVS) é mais adequado para aplicações em tempo real de alto desempenho que precisam lidar com busca vetorial em grande escala. É uma boa opção quando você está construindo sistemas que exigem busca de similaridade vetorial de baixa latência em conjuntos de dados enormes. A indexação distribuída do Aerospike é particularmente útil para aplicações em áreas como sistemas de recomendação, detecção de fraude em tempo real ou busca de similaridade de imagens ou textos em grande escala, onde velocidade e escalabilidade são essenciais.
Conclusão:
pgvector se destaca por sua integração com PostgreSQL, um ambiente familiar para desenvolvedores que trabalham com bancos de dados relacionais, e pela flexibilidade para combinar busca vetorial com operações de dados estruturados. Aerospike oferece busca vetorial de alto desempenho e escalável para grandes conjuntos de dados, com indexação distribuída potencialmente melhor para escala massiva. Sua escolha entre esses dois deve se basear no seu caso de uso, na infraestrutura existente, no volume de dados e nos requisitos de desempenho. Considere a expertise da sua equipe, a natureza dos seus dados (estruturados vs semiestruturados), a escala das suas necessidades de busca vetorial e o desempenho em tempo real da sua aplicação ao tomar sua decisão.
Embora este artigo forneça uma visão geral do pgvector e do Aerospike, é essencial avaliar esses bancos de dados com base no seu caso de uso específico. Uma ferramenta que pode ajudar nesse processo é o VectorDBBench, uma ferramenta de benchmarking open-source projetada para comparar o desempenho de bancos de dados vetoriais. Em última análise, um benchmarking completo com conjuntos de dados e padrões de consulta específicos será essencial para tomar uma decisão informada entre essas duas abordagens poderosas, porém distintas, para busca vetorial em sistemas de bancos de dados distribuídos.
Usando o VectorDBBench open-source para avaliar e comparar bancos de dados vetoriais por conta própria
VectorDBBench é uma ferramenta de benchmarking open-source projetada para usuários que exigem sistemas de armazenamento e recuperação de dados de alto desempenho, particularmente bancos de dados vetoriais. Essa ferramenta permite que os usuários testem e comparem o desempenho de diferentes sistemas de bancos de dados vetoriais, como Milvus e Zilliz Cloud (o Milvus gerenciado), usando seus próprios conjuntos de dados e determinem o mais adequado para seus casos de uso. Usando o VectorDBBench, os usuários podem tomar decisões informadas com base no desempenho real dos bancos de dados vetoriais, em vez de depender de afirmações de marketing ou evidências anedóticas.
O VectorDBBench é escrito em Python e licenciado sob a licença open-source MIT, o que significa que qualquer pessoa pode usá-lo, modificá-lo e distribuí-lo livremente. A ferramenta é mantida ativamente por uma comunidade de desenvolvedores comprometidos em melhorar seus recursos e desempenho.
Baixe o VectorDBBench de seu repositório no GitHub para reproduzir nossos resultados de benchmark ou obter resultados de desempenho em seus próprios conjuntos de dados.
Dê uma olhada rápida no desempenho dos principais bancos de dados vetoriais no Leaderboard do VectorDBBench.
Leia os blogs a seguir para saber mais sobre avaliação de bancos de dados vetoriais.
Recursos adicionais sobre VectorDB, GenAI e ML
Continue lendo
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.
Our Journey to 35K+ GitHub Stars: The Real Story of Building Milvus from Scratch
Join us in celebrating Milvus, the vector database that hit 35.5K stars on GitHub. Discover our story and how we’re making AI solutions easier for developers.
The Definitive Guide to Choosing a Vector Database
Overwhelmed by all the options? Learn key features to look for & how to evaluate with your own data. Choose with confidence.