O Couchbase 7.6 apresenta Vector Search na arquitetura do CouchbaseO Google está expandindo seus recursos de pesquisa aos trancos e barrancos. Este artigo mostra como isso afeta as consultas de pesquisa, como temos que nos adaptar em determinadas situações e como usar esse recurso mais recente de forma eficiente. Para garantir que suas pesquisas vetoriais sejam as melhores possíveis, você precisa estar ciente de problemas como consultas lentas causadas por índices ineficientes, consultas ineficientes ou dados que mudam com frequência, bem como outros casos de falha, como timeouts, erros de consistência, app herder etc.
Apresentando as consultas vetoriais
As consultas de pesquisa tiveram que ser adaptadas para permitir o uso de vetores. Trata-se essencialmente de um novo tipo de consulta que permite pesquisa de similaridade em vez da pesquisa exata. A diferença é que não estamos mais procurando correspondências exatas quando se trata de vetores, mas as mais próximas do vetor especificado na consulta:
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "query" (consulta): { "match_none": {} }, "knn": [ { "campo": "vetor", "vetor": [0.04603520780801773, ..., -0.08424953371286392], "k": 3 } ] } |
Essa é uma consulta vetorial. Ela difere um pouco de uma consulta normal. Todas as partes vetoriais da consulta estão em uma nova chave chamada knnintroduzido com o único propósito de consultas vetoriais. O k na consulta determina o número de documentos que você deseja nos resultados. Isso é necessário porque, em vez de procurar a correspondência exata, estamos preocupados em encontrar a k vetores mais próximos do vetor de consulta. Essa consulta acabará retornando três vetores que a pesquisa julga ser o mais próximo do vetor de consulta.
1 2 3 4 5 6 7 8 9 10 |
{ "query" (consulta): "conteúdo:carro", "knn": [ { "campo": "vetor", "vetor": [0.04603520780801773, ..., -0.08424953371286392], "k": 3 } ] } |
Você também pode combinar uma consulta vetorial com uma consulta regular para uma pesquisa híbrida. Nesse caso, a pesquisa faz a consulta em duas fases. A primeira fase fará a pesquisa vetorial, mesclando todos os resultados das diferentes partições, e a segunda fase é onde ocorre a pesquisa regular, utilizando os resultados da primeira fase. Essa abordagem permite um melhor desempenho em termos de tempo e quantidade de dados transmitidos entre os nós.
Agora que sabemos como consultar vetores, vamos analisar os cenários de falha mais comuns. O que pode dar errado durante uma consulta de vetor?
Identificação de consultas lentas
Um dos tipos mais comuns de falha de consulta é uma consulta lenta. Uma consulta que fica parada no processamento do sistema por um longo período é chamada de consulta lenta. Dependendo do tempo limite definido para essa consulta, ela pode permanecer em execução por um longo período.
Há muitos motivos para isso acontecer. Um dos motivos mais simples para uma consulta lenta é que ela é muito cara para ser executada. Isso pode ocorrer porque ela faz referência a muitos documentos, o número de documentos indexados é enorme ou o tipo de consulta é comparativamente ineficiente.
Em termos vetoriais, as causas mais comuns de uma consulta lenta se devem a um grande tamanho de índice com um número insuficiente de partições, um grande valor K na consulta ou até mesmo uma alta taxa de ingestão de dados.
Agora que sabemos o que é uma consulta lenta, a próxima pergunta que vem à mente é: como saber se ainda há uma consulta lenta em execução? Uma das melhores maneiras de fazer isso é verificar os registros. Uma consulta lenta será registrada a cada 5 segundos. Esse cronômetro pode ser alterado usando as opções do gerenciador e a linha de registro será semelhante a:
Outra maneira é dar uma olhada nas estatísticas. Há uma estatística disponível na seção /api/nsstats chamado total_queries_slow que registrará o número de vezes que uma consulta lenta foi detectada:
Há também mais algumas estatísticas que podem ser observadas no mesmo endpoint e que podem nos dar alguma pista sobre o que está acontecendo com a consulta internamente e onde pode estar o problema:
-
- avg_grpc_internal_queries_latency - Tempo médio gasto no nível do grpc para processar uma consulta proveniente de um nó diferente
- avg_grpc_queries_latency - Tempo médio gasto no nível do grpc para processar uma consulta originada no mesmo nó
- latência média de consultas internas - Tempo médio necessário para processar uma consulta proveniente de um nó diferente
- latência média de consultas - Tempo médio gasto para processar uma consulta originada no mesmo nó
Fatores que contribuem para consultas lentas
Agora que sabemos como identificar uma consulta lenta, a próxima etapa é entender por que isso acontece e o que podemos fazer para minimizá-la.
Índice Ineficiente
Um dos principais fatores é o próprio índice, o número de vetores indexados, o número de partições ou o número de nós. Cada um desses fatores é crucial quando se trata do desempenho da consulta.
O número de vetores indexados é um fator bastante autoexplicativo: quanto maior o número de vetores, mais tempo levará para consultá-los. A partir da versão 7.6.0, isso pode ser inferido aproximadamente a partir do número de documentos, mas o patch de manutenção seguinte terá uma estatística que nos dará o valor exato.
O número de partições e nós pode ser explicado de forma intuitiva. Vejamos o exemplo de uma pessoa que está examinando um monte de papéis em sua mesa.
Como há muitos papéis e apenas uma pessoa, ele leva mais tempo para encontrar o que deseja. Agora vamos acrescentar mais uma pessoa na mesma mesa, examinando metade dos documentos. Isso obviamente reduz o tempo para encontrar os documentos corretos.
Podemos continuar adicionando mais pessoas na mesma mesa, mas depois de um certo ponto, você fica sem espaço na mesa para as pessoas, algumas delas ficam esperando porque a mesa está muito cheia.
A solução mais simples é simplesmente adicionar outra mesa ou comprar uma mesa maior, o que permite que mais pessoas se sentem e analisem os papéis de uma só vez.
Esse exemplo é semelhante ao ecossistema de pesquisa. As pessoas são as partições, os papéis são os vetores e as mesas são os nós. Um número maior de mesas significa uma quantidade maior de recursos para lidar com mais pessoas. Mais pessoas significam uma busca mais rápida, mas um número excessivo de pessoas significa mais comunicação entre elas para obter os resultados, o que, mais uma vez, será contraproducente. Há um equilíbrio certo para cada sistema e é importante encontrá-lo para obter eficiência.
Consulta ineficiente
Outro fator importante que determina o tempo que uma consulta vetorial gasta no sistema é o valor K. Um valor K maior significa que cada partição do índice leva mais tempo para processar a consulta, uma quantidade maior de dados precisa ser transferida entre os nós, buffers maiores são necessários para manter todos esses dados e condensar os resultados K de cada partição (total K * número de partições com valor de resultados) nos resultados finais de K. Cada uma dessas etapas leva cada vez mais tempo à medida que o valor de K aumenta.
Voltando ao exemplo anterior, um valor K grande significa que cada pessoa precisará rastrear uma pilha maior de documentos e, quando todos terminarem, precisarão comparar todas as pilhas de documentos que selecionaram para encontrar os K melhores documentos.
Dados em constante mudança
A peça final desse quebra-cabeça são os próprios documentos. A pesquisa segue uma arquitetura somente de acréscimo. Isso significa que cada alteração no documento é anexada, indexada e armazenada separadamente, em vez de reescrever a entrada do documento existente. Com um grande número de alterações nos documentos reais, obtemos um índice muito ocupado com a criação constante de segmentos e a fusão constante desses segmentos. Essas operações consomem muitos recursos, o que afetará as consultas, pois elas não terão muito com o que trabalhar.
Pense nisso como se as pessoas lhe trouxessem novas pilhas de papéis enquanto você tenta encontrar o que está procurando. É uma bagunça, você não tem espaço suficiente na mesa, novos papéis chegam constantemente e você precisa rastrear as duplicatas, caso se trate de um papel atualizado.
Outras questões
Consultas lentas não são o único motivo pelo qual uma consulta pode falhar. Alguns dos outros cenários de falha incluem:
Tempo limite da consulta
Essa é uma consulta lenta que atinge o limite máximo de tempo definido pelo usuário. Ela é causada pelos mesmos motivos das consultas lentas e é rastreada por total_queries_timeout.
Janela de resultado máximo excedido
Isso acontece quando você tem uma consulta que precisa de mais ocorrências do que o limite maxResultWindow definido para o cluster. Por padrão, esse valor é 10000, mas pode ser configurado por meio da API de opções do gerenciador. Ele existe para evitar o fluxo acidental de grandes quantidades de dados.
Resultados parciais
Isso acontece quando uma das partições não está disponível e não enviou seus resultados para o nó que recebeu a consulta.
Rejeitado pelo pastor de aplicativos
O app herder é o ponto de verificação final em vigor para garantir que os recursos do sistema permaneçam dentro dos limites determinados. Quando uma consulta ameaça exceder o limite, o que pode ocorrer devido a uma grande carga de consulta ou de indexação ou a uma operação de rebalanceamento ou a uma combinação dos três, o app herder encerra preventivamente a consulta, impedindo sua execução.
Falha na pesquisa no contexto
Isso abrange todos os possíveis erros que podem ocorrer no bleve, como problemas de interação com os arquivos de índice e outros.
Erros de consistência
Erros na especificação dos parâmetros de consistência fazem com que uma consulta falhe. Esses parâmetros incluem o nível de consistência dos dados, os resultados e outras variáveis relacionadas.
Solicitações ruins
Esse é o mais simples, que é basicamente um erro do usuário ao fazer uma consulta. Pode ser desde um erro de digitação, uma estrutura json ruim até cadeias de caracteres de consulta inválidas.
A introdução da pesquisa vetorial expande os recursos de pesquisa do Couchbase para além dos limites e casos de uso anteriores. Para aproveitar esse recurso de forma eficaz, os usuários precisam entender suas funcionalidades, incluindo consultas, indexação de dados e gerenciamento de comportamentos do sistema sob várias condições. Para obter uma compreensão ainda mais profunda da pesquisa vetorial, de sua funcionalidade e de seus recursos, explore alguns dos outros blogs em nosso site.
Próximas etapas
-
- Leia mais sobre Conceitos do Vector Search em nossos blogs, incluindo tutoriais e conceitos.
- Avaliação gratuita do Couchbase Capella inclui pesquisa de vetores, entre muitos outros recursos. Experimente hoje mesmo.
Conteúdo brilhante
Muito informativo
Ajudou-me a otimizar meu índice de pesquisa para meu aplicativo.
Obrigado, Likith B