Visão geral da consulta

Esta página descreve a função SEARCH e o modo de consulta aprimorado, que são usados para executar consultas de pesquisa de texto completo em tabelas do Spanner.

Consultar um índice de pesquisa

O Spanner fornece a função SEARCH para usar em consultas de índice de pesquisa. Um exemplo de caso de uso seria um aplicativo em que os usuários inserem texto em uma caixa de pesquisa, e o aplicativo envia a entrada do usuário diretamente para a função SEARCH. A palavra-chave 'SEARCH' função usaria um índice de pesquisa para encontrar o texto.

A função SEARCH requer dois argumentos:

  • Um nome de índice de pesquisa
  • Uma consulta de pesquisa bruta

A função SEARCH só funciona quando um índice de pesquisa é definido. O SEARCH pode ser combinada com qualquer construção de SQL arbitrária, como filtros, agregações ou mesclagens.

A função SEARCH não pode ser usada com consultas de transação.

A consulta a seguir usa a função SEARCH para retornar todos os álbuns que tenham friday ou monday no título:

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'friday OR monday')

Consultas de pesquisa brutas e a linguagem rquery

O segundo argumento da função SEARCH é uma consulta de pesquisa bruta. O Spanner usa uma linguagem específica de domínio (DSL, na sigla em inglês) chamada rquery.

A linguagem rquery segue as mesmas regras tokenizador de texto simples ao dividir a string de entrada em termos distintos. Isso inclui segmentação de idiomas asiáticos.

Para mais informações sobre como usar o rquery, consulte sintaxe de rquery.

Modo de consulta aprimorado

O Spanner oferece dois modos de pesquisa de texto completo: um modelo pesquisa e um modo mais avançado chamado enhance_query. Quando ativado, enhance_query expande a consulta de pesquisa para incluir termos relacionados e sinônimos, aumentar a probabilidade de encontrar resultados relevantes.

Para ativar essa opção, defina o argumento opcional enhance_query=>true na função SEARCH. Por exemplo, a consulta de pesquisa hotl cal corresponde ao álbum Hotel California.

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'hotl cal', enhance_query=>true)

O modo enhance_query é uma opção de tempo de consulta. Isso não afeta a tokenização. É possível usar o mesmo índice de pesquisa com ou sem enhance_query.

O Google faz melhorias contínuas nos algoritmos de aprimoramento de consultas. Como resultado, uma consulta com enhance_query == true pode ter um resultado ligeiramente diferente resultados ao longo do tempo.

Quando o modo enhance_query está ativado, ele pode aumentar o número de termos que a função SEARCH está procurando, o que pode aumentar um pouco a latência.

Por exemplo, a consulta a seguir usa um tempo limite de três segundos e falha se enhance_query está indisponível:

@{require_enhance_query=true, enhance_query_timeout_ms=3000}
SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'fast car', enhance_query=>true)

Para mais informações sobre como usar a opção enhance_query, consulte a função SEARCH.

Requisitos da consulta SQL

Há várias condições que uma consulta SQL precisa atender para usar um índice de pesquisa. Se essas condições não forem atendidas, a consulta vai usar um plano de consulta alternativo ou falhar se nenhum plano alternativo existir.

As consultas precisam atender aos seguintes requisitos:

  • As funções SEARCH e SEARCH_SUBSTRING exigem um índice de pesquisa. O Spanner não oferece suporte a essas funções em consultas na tabela base ou em índices secundários.

  • Índices particionados precisa ter todas as colunas de partição vinculadas por uma condição de igualdade na WHERE da consulta.

    Por exemplo, se um índice de pesquisa for definido como PARTITION BY x, y, o consulta precisa ter um conjunto na cláusula WHERE de x = <parameter or constant> AND y = <parameter or constant>. Esse índice de pesquisa não é considerado pelo otimizador de consulta se essa condição estiver ausente.

  • Todas as colunas TOKENLIST referenciadas por SEARCH e SEARCH_SUBSTRING operadores precisam ser indexados no mesmo índice de pesquisa.

    Por exemplo, considere a seguinte definição de tabela e índice:

    CREATE TABLE Albums (
    AlbumId STRING(MAX) NOT NULL,
    AlbumTitle STRING(MAX),
    AlbumStudio STRING(MAX),
    AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN,
    AlbumStudio_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumStudio)) HIDDEN
  ) PRIMARY KEY(AlbumId);

  CREATE SEARCH INDEX AlbumsTitleIndex ON Albums(AlbumTitle_Tokens);
  CREATE SEARCH INDEX AlbumsStudioIndex ON Albums(AlbumStudio_Tokens);

    A consulta a seguir falha porque não há um único índice de pesquisa que indexe AlbumTitle_Tokens e AlbumStudio_Tokens:

    SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, @p1) AND SEARCH(AlbumStudio_Tokens, @p2)

  • Se a coluna de ordem de classificação for anulável, tanto o esquema quanto a consulta precisarão excluir linhas em que a coluna da ordem de classificação é NULL. Para mais detalhes, consulte Ordem de classificação do índice de pesquisa.

  • Se o índice de pesquisa for filtrado por NULL, a consulta precisará incluir a mesma expressão de filtragem por NULL usada em um índice. Consulte Índices de pesquisa filtrados por NULL para mais detalhes.

  • Pesquisar índices e funções de pesquisa não são aceitos em DML, DML particionada ou consultas particionadas.

  • Pesquisar índices e funções de pesquisa são normalmente usados transações somente leitura. Se os requisitos do aplicativo permitirem resultados desatualizados, recomendamos executar consultas de pesquisa com uma duração desatualizada de 10 segundos ou mais. Para mais informações, consulte Leia dados desatualizados. Isso é especialmente útil para consultas de pesquisa grandes que se espalham para vários grupos Paxos.

    Índices de pesquisa e funções de pesquisa não são recomendados em transações de leitura e gravação. Durante a execução, as consultas de pesquisa bloqueiam uma partição de índice inteira. como resultado, uma alta taxa de consultas de pesquisa em transações de leitura/gravação pode causar conflitos de bloqueio que levam a picos de latência. Por padrão, os índices de pesquisa não são selecionadas automaticamente nas transações de leitura/gravação. Se uma consulta for forçada a usar um índice de pesquisa em uma transação de leitura/gravação ele falhará por padrão. Ela também vai falhar se a consulta contiver alguma das funções de pesquisa. Esse comportamento pode ser substituído pelo @{ALLOW_SEARCH_INDEXES_IN_TRANSACTION=TRUE}. dica no nível da instrução (mas as consultas ainda tendem a bloquear conflitos).

Depois que as condições de qualificação do índice são atendidas, o otimizador de consulta tenta acelerar as condições de consulta que não são de texto (como Rating > 4). Se o índice de pesquisa não incluir a coluna TOKENLIST adequada, a condição não será acelerada e permanecerá como uma condição residual.

Parâmetros de consulta

A rquery e outros parâmetros, como OFFSET, são especificados como um literal ou um parâmetro de consulta. Recomendamos o uso de parâmetros de consulta para pesquisa de texto completo em vez de string literais.

Seleção de índice

O Spanner normalmente seleciona o índice mais eficiente para uma consulta usando modelagem baseada em custo. No entanto, a dica FORCE_INDEX instrui Spanner para usar um índice de pesquisa específico. Por exemplo, o a seguir, mostramos como forçar o Spanner a usar o AlbumsIndex:

SELECT AlbumId
FROM Albums @{FORCE_INDEX=AlbumsIndex}
WHERE SEARCH(AlbumTitle_Tokens, "fifth symphony")

Se o índice de pesquisa especificado não estiver qualificado, o a consulta vai falhar, mesmo se houver outros índices de pesquisa qualificados.

Snippets nos resultados da pesquisa

Um snippet é um texto extraído de uma determinada string que oferece aos usuários do que um resultado de pesquisa contém e o motivo pelo qual o resultado foi relevantes para a consulta.

Por exemplo, o Gmail usa snippets para indicar a parte de um e-mail que corresponde à consulta de pesquisa:

Lista de snippets

Fazer com que o banco de dados gere um snippet traz vários benefícios:

  1. Conveniência: não é necessário implementar a lógica para gerar snippets. de uma consulta de pesquisa.
  2. Eficiência: os snippets reduzem o tamanho da saída do servidor.

A função SNIPPET cria o snippet. Ela retorna a parte relevante o valor original da string, junto com as posições dos caracteres a serem destacados. O cliente pode escolher como mostrar o snippet para o usuário final (por exemplo, usando texto em negrito ou realçado). A função SNIPPET remove todas as tags HTML da string original.

Por exemplo, o código a seguir usa SNIPPET para extrair texto de AlbumTitle:

SELECT AlbumId, SNIPPET(AlbumTitle, "Fast Car")
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, "Fast Car")

A seguir