Índices de búsqueda de particiones

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

Descripción general

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 la búsqueda en el texto completo. para tus consultas.

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 datos de una sola partición. La partición del índice de búsqueda es análoga al prefijo clave de una consulta secundaria índice.

Por ejemplo, supongamos que hay 1,000,000 SingerIds en una base de datos y la 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 usar AlbumsUnpartitionedIndex y mostrar 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 buscar 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 mayor nivel de detalle de la partición que sea práctica y adecuada 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.

Ciertas aplicaciones pueden requerir múltiples estrategias de partición para según sus requisitos específicos de búsqueda. 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, es se recomienda crear varios índices de búsqueda, cada uno optimizado para la las consultas correspondientes.

¿Qué sigue?