Índices de pesquisa de partição

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