Práticas recomendadas de pesquisa vetorial

Este documento apresenta recomendações para otimizar a performance da pesquisa vetorial no Spanner.

Entender os conceitos básicos do Spanner

Para realizar testes de performance eficazes da pesquisa vetorial do Spanner, entenda os conceitos básicos do Spanner. Por exemplo, a reexecução imediata da mesma consulta pode ser mais rápida devido aos caches. Para testar a performance em um aplicativo que usa principalmente dados ativos, faça uma leitura de aquecimento primeiro.

Consulte os seguintes guias:

O Spanner processa consultas em paralelo com base em divisões de banco de dados. O teste com uma carga de consulta de produção sustentada pode ativar a divisão baseada em carga, o que melhora a performance da consulta com maior paralelismo. Para aumentar o paralelismo para cargas futuras, considere a pré-divisão do banco de dados, especialmente para KNN.

Práticas recomendadas de pesquisa vetorial

Este documento descreve as seguintes práticas recomendadas de pesquisa vetorial:

Anotar a coluna de incorporação

Anote a coluna de incorporação com vector_length. Essa anotação permite otimizações de performance para a pesquisa de vizinhos k-mais próximos (KNN) e é um pré-requisito para a pesquisa de vizinhos mais próximos aproximados (ANN) .

Usar uma consulta top-k

Para encontrar os vizinhos mais próximos, use uma cláusula ORDER BY com LIMIT. As consultas top-k são altamente otimizadas para pesquisa vetorial. Evite filtrar por um limite de distância em uma cláusula WHERE.

Por exemplo, o seguinte não é recomendado:

SELECT d.DocId
FROM Documents AS d
WHERE COSINE_DISTANCE(d.DocEmbedding, @vector) < 1;

Em vez disso, use:

SELECT d.DocId
FROM Documents AS d
ORDER BY COSINE_DISTANCE(d.DocEmbedding, @vector)
LIMIT 10;

O uso de uma consulta top-k não é apenas mais simples porque elimina o ajuste do limite de distância, mas também permite otimizações de performance especializadas para pesquisa vetorial.

Usar literais SQL para a cláusula LIMIT

Se o limite top-k for fixo, use um literal SQL em vez de um parâmetro. Por exemplo, use LIMIT 10 em vez de LIMIT @limit. Isso fornece ao otimizador de consultas do Spanner mais informações para selecionar o melhor plano de execução de consulta.

Usar a verificação orientada a lotes

As consultas de pesquisa vetorial são pesadas. Para consultas KNN, considere usar a verificação orientada a lotes com a scan_method=batch dica de consulta. Esse é o método de verificação padrão para consultas ANN.

Usar KNN para conjuntos de dados pequenos

Se o KNN for suficiente para o orçamento de latência, não crie um índice de vetor. O KNN é mais preciso, evita custos de criação e manutenção de índices e pode ter uma performance melhor do que o ANN quando o número de linhas de entrada após qualquer filtragem é pequeno.

Acelerar o KNN filtrado com um índice secundário

Para melhorar a performance de uma consulta KNN filtrada, crie um índice secundário na coluna de filtragem. Por exemplo, pense na seguinte consulta:

SELECT d.DocId
FROM Documents AS d
WHERE Category = 'toy'
ORDER BY COSINE_DISTANCE(d.DocEmbedding, @vector)
LIMIT 10;

Se o número de documentos por categoria for menor que algumas dezenas de milhares e o aplicativo puder aceitar uma latência de consulta de 100 ms, crie um índice secundário na coluna Category. Armazene a coluna DocEmbedding no índice:

CREATE INDEX ON Documents(Category) STORING (DocEmbedding);

Essa criação de índice ajuda a acelerar a consulta filtrada.

Usar ANN para conjuntos de dados grandes

Se o número de linhas for grande após a avaliação de filtros, crie um índice de vetor e use a pesquisa ANN. Várias técnicas podem acelerar a filtragem com ANN:

  • Armazenar colunas de filtro: para ativar a filtragem durante a travessia da pesquisa vetorial, armazene colunas de filtro no índice de vetor. Isso permite que linhas não qualificadas sejam removidas no início da execução.

    CREATE VECTOR INDEX ON Documents(DocEmbedding) STORING(Category);

  • Colunas de filtragem de chaves: para acelerar a filtragem de colunas altamente seletivas que removem muitos resultados, organize essas colunas como colunas de chave adicionais no índice de vetor. As consultas que especificam igualdade exata (usando o operador =) para essas chaves adicionais aceleram mais. O uso da cláusula IN para qualquer uma dessas chaves adicionais não atinge o mesmo nível de aceleração.

    CREATE VECTOR INDEX ON Documents(DocEmbedding, Category);

  • Evite armazenar colunas grandes ou usá-las como chaves: isso pode diluir os blocos de dados para incorporações, o que pode reduzir a eficiência de leitura. Como alternativa, considere usar uma coluna de hash no índice e usar a coluna grande original como um pós-filtro após o top-k.

  • Criar um índice de vetor filtrado (parcial):se você consultar apenas um subconjunto do conjunto de dados e uma condição de filtragem definir esse subconjunto, como Category = "Tech", crie um índice de vetor filtrado ou parcial.