Í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 Spanner.

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 possível escalabilidade das consultas de pesquisa de texto completo.

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. A partição do índice de pesquisa é análoga ao prefixo de chave de um índice secundário.

Por exemplo, suponha que haja 1.000.000 SingerIds em um banco de dados e os 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 só procura dados de um único cantor. Esse tipo de consulta geralmente usa menos recursos.

SELECT AlbumId
FROM Albums
WHERE SingerId = "singer1"
AND SEARCH(AlbumTitle_Tokens, 'happy')

Também é possível forçar uma consulta a usar AlbumsUnpartitionedIndex para retornar os mesmos resultados. No entanto, ele usa mais recursos, porque a consulta precisa acessar todas as divisões do í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, em vez de procurar um cantor específico. Nesses casos, é necessário 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 consultar uma caixa de e-mail em que cada consulta for restrita a uma caixa de e-mail específica, particione o índice de pesquisa no ID da caixa de e-mail. No entanto, se a consulta precisar pesquisar em todas as caixas de correio, um índice não particionado é mais adequado.

Alguns aplicativos podem exigir várias estratégias de particionamento para atender aos requisitos de pesquisa específicos. Por exemplo, um sistema de gerenciamento de inventário 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, é recomendado criar vários índices de pesquisa, cada um otimizado para as consultas correspondentes.

A seguir