Particionar índices de pesquisa

O Spanner oferece suporte a índices de pesquisa particionados e não 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 todas as divisões do índice. Isso limita a escalonabilidade potencial das consultas de pesquisa em 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 de SingerIds em um banco de dados e os dois índices a seguir:

GoogleSQL 

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;

PostgreSQL 

CREATE TABLE albums (
  albumid character varying NOT NULL,
  singerid character varying NOT NULL,
  releasetimestamp bigint NOT NULL,
  albumtitle character varying,
  albumtitle_tokens spanner.tokenlist GENERATED ALWAYS AS (spanner.tokenize_fulltext(albumtitle)) VIRTUAL HIDDEN,
  singerid_tokens spanner.tokenlist GENERATED ALWAYS AS (spanner.token(singerid)) VIRTUAL 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 recursos.

GoogleSQL 

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

PostgreSQL 

SELECT albumid
FROM albums
WHERE singerid = 'singer1'
AND spanner.search(albumtitle_tokens, 'happy')

Também é possível forçar uma consulta a usar AlbumsUnpartitionedIndex para retornar os mesmos resultados. No entanto, ela 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 todos os álbuns, em vez dos álbuns de um cantor específico. Nesses casos, é necessário usar um índice não particionado:

GoogleSQL 

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'piano concerto 1')

PostgreSQL 

SELECT albumid
FROM albums
WHERE spanner.search(albumtitle_tokens, 'piano concerto 1')

A recomendação geral é usar a melhor granularidade 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 seja 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 e-mail, um índice não particionado será 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é-classificações, como classificação por hora de criação ou modificação. Nesses cenários, é recomendável criar vários índices de pesquisa, cada um otimizado para as consultas correspondentes. O otimizador de consultas do Spanner seleciona automaticamente um índice para cada consulta.

A seguir