Í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 necesita leer 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. Consultas según índices particionados en general son más eficientes que las consultas con í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;

La siguiente consulta selecciona el índice AlbumsIndexBySingerId porque solo busca datos de un solo cantante. Este tipo de consulta suele usar menos de Google Cloud.

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 necesita acceder a todos divide los álbumes y filtra todos los álbumes de todos los cantantes hasta encontrar el token en lugar de solo los splits correspondientes al cantante singer1.

Sin embargo, hay ocasiones en las que la aplicación necesita realizar una búsqueda en todos los en lugar de 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áctico y adecuado para la consulta. Por ejemplo, si la aplicación consulta un buzón de correo electrónico donde cada consulta se restringe a un buzón específico 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 inventario de administración de productos podría necesitar admitir consultas filtradas por tipo de producto o fabricante. Además, algunas aplicaciones pueden necesitar múltiples clasificaciones previas, como como el ordenamiento 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?