O Spanner oferece suporte a índices de pesquisa não particionados e particionados. Esta página descreve como criar um índice de pesquisa particionado no no Spanner.
Visão geral
Um índice não particionado é criado quando a cláusula PARTITION BY
é omitida na
definição do índice. Em um índice não particionado, uma consulta precisa ler de
todas as divisões de índice. Isso limita a escalonabilidade potencial da pesquisa de texto completo
consultas.
Os índices particionados, por outro lado, subdividem o índice em unidades menores,
uma para cada partição exclusiva. As consultas só podem pesquisar em uma única partição
por vez, especificada por uma condição de igualdade na cláusula WHERE
. As consultas
em índices particionados geralmente são mais eficientes do que as consultas em índices
não particionados, porque o Spanner só precisa ler dados de uma
única partição.
O particionamento do índice de pesquisa é análogo ao prefixo de chave de um índice
índice.
Por exemplo, suponha que haja 1.000.000 SingerIds
em um banco de dados e o
dois índices a seguir:
CREATE TABLE Albums (
AlbumId STRING(MAX) NOT NULL,
SingerId STRING(MAX) NOT NULL,
ReleaseTimestamp INT64 NOT NULL,
AlbumTitle STRING(MAX),
AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN,
SingerId_Tokens TOKENLIST AS (TOKEN(SingerId)) HIDDEN
) PRIMARY KEY(SingerId, AlbumId);
CREATE SEARCH INDEX AlbumsUnpartitionedIndex
ON Albums(AlbumTitle_Tokens, SingerId_Tokens);
CREATE SEARCH INDEX AlbumsIndexBySingerId
ON Albums(AlbumTitle_Tokens)
PARTITION BY SingerId;
A consulta a seguir seleciona o índice AlbumsIndexBySingerId
porque ele só
pesquisa dados de um único cantor. Esse tipo de consulta normalmente usa menos
do Google Cloud.
SELECT AlbumId
FROM Albums
WHERE SingerId = "singer1"
AND SEARCH(AlbumTitle_Tokens, 'happy')
Também é possível forçar
uma consulta para usar AlbumsUnpartitionedIndex
para retornar os mesmos resultados.
No entanto, ele usa mais recursos, porque a consulta precisa acessar todas as divisões
de índice e filtrar todos os álbuns de todos os cantores para encontrar o token "happy",
em vez de apenas as divisões correspondentes ao cantor singer1
.
No entanto, há momentos em que o aplicativo precisa pesquisar em todos os álbuns de um cantor específico. Nesses casos, você deve usar um índice não particionado:
SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'piano concerto 1')
A recomendação geral é usar a granularidade mais fina de particionamento que seja prática e adequada para a consulta. Por exemplo, se o aplicativo consulta uma caixa de correio de e-mail em que cada consulta é restrita a uma caixa de correio específica, particionar o índice de pesquisa no ID da caixa de correio. No entanto, se a consulta precisar pesquisar em todas as caixas de e-mail, um índice não particionado é mais adequado.
Alguns aplicativos podem exigir várias estratégias de particionamento para acomodar seus requisitos de pesquisa específicos. Por exemplo, um inventário sistema de gerenciamento de projetos pode precisar oferecer suporte a consultas filtradas por tipo de produto ou fabricante. Além disso, alguns aplicativos podem precisar de várias pré-ordenações, como classificação por tempo de criação ou modificação. Nesses cenários, recomendamos criar vários índices de pesquisa, cada um otimizado para o consultas correspondentes.
A seguir
- Saiba mais sobre tokenização e tokenizadores do Spanner.
- Saiba mais sobre índices de pesquisa.
- Saiba mais sobre índices numéricos.