Cómo particionar índices de búsqueda

Spanner admite índices de búsqueda particionados y no particionados. En esta página, se describe cómo crear un índice de búsqueda particionado en Spanner.

Se crea un índice no particionado cuando se omite la cláusula PARTITION BY en la definición del índice. En un índice no particionado, una consulta debe leer de todas las divisiones del índice. Esto limita la escalabilidad potencial de las consultas de búsqueda en el texto completo.

Por otro lado, los índices particionados subdividen el índice en unidades más pequeñas, una para cada partición única. Las consultas solo pueden buscar dentro de una sola partición a la vez, especificada por una condición de igualdad en la cláusula WHERE. Por lo general, las consultas a índices particionados son más eficientes que las consultas a índices no particionados, ya que Spanner solo necesita leer los datos de una sola partición. El particionamiento del índice de búsqueda es análogo al prefijo de clave de un índice secundario.

Por ejemplo, supongamos que hay 1,000,000 de SingerIds en una base de datos y los siguientes dos índices:

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;

En la siguiente consulta, se selecciona el índice AlbumsIndexBySingerId porque solo busca datos de un solo cantante. Por lo general, este tipo de consulta usa menos recursos.

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

También es posible forzar una consulta para que use AlbumsUnpartitionedIndex y devuelva los mismos resultados. Sin embargo, usa más recursos, ya que la consulta debe acceder a todas las divisiones del índice y filtrar todos los álbumes de todos los cantantes para encontrar el token "happy", en lugar de solo las divisiones correspondientes al cantante singer1.

Sin embargo, hay ocasiones en las que la aplicación debe buscar en todos los álbumes en lugar de hacerlo en los álbumes de un cantante específico. En estos casos, debes usar un índice no particionado:

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

La recomendación general es usar el nivel de detalle más detallado de la partición que sea práctico y adecuado para la consulta. Por ejemplo, si la aplicación consulta un buzón de correo electrónico en el que cada consulta está restringida a un buzón específico, particiona el índice de búsqueda en el ID del buzón. Sin embargo, si la consulta necesita buscar en todos los buzones, un índice no particionado es una mejor opción.

Algunas aplicaciones pueden requerir varias estrategias de partición para adaptarse a sus requisitos de búsqueda específicos. Por ejemplo, un sistema de administración de inventario podría necesitar admitir consultas filtradas por tipo de producto o fabricante. Además, es posible que algunas aplicaciones necesiten varios ordenes previos, como ordenar por fecha de creación o modificación. En estos casos, se recomienda que crees varios índices de búsqueda, cada uno optimizado para las consultas correspondientes.

¿Qué sigue?