Spanner est compatible avec les tables index de recherche. Cette page explique comment créer un index de recherche partitionné dans Spanner.
Présentation
Un index non partitionné est créé lorsque la clause PARTITION BY
est omise dans
la définition de l'index. Dans un index non partitionné, une requête doit lire
toutes les divisions d'index. Cela limite l'évolutivité potentielle de la recherche en texte intégral
requêtes.
Les index partitionnés subdivisent l'index en unités plus petites,
un pour chaque partition unique. Les requêtes ne peuvent effectuer une recherche que dans une seule partition
à la fois, spécifiée par une condition d'égalité dans la clause WHERE
. Requêtes
sur des index partitionnés sont généralement plus efficaces que les requêtes
les index non partitionnés, car Spanner n'a besoin de lire que les données
une seule partition.
Le partitionnement de l'index de recherche est similaire au préfixe de clé d'une adresse
de l'index.
Par exemple, supposons qu'une base de données contienne 1 000 000 SingerIds
et que
les deux index suivants:
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 requête suivante sélectionne l'index AlbumsIndexBySingerId
, car il ne fait
recherche les données d'un seul chanteur. Ce type de requête utilise généralement moins
ressources.
SELECT AlbumId
FROM Albums
WHERE SingerId = "singer1"
AND SEARCH(AlbumTitle_Tokens, 'happy')
Il est également possible de forcer
une requête pour utiliser AlbumsUnpartitionedIndex
pour renvoyer les mêmes résultats.
Toutefois, il utilise davantage de ressources, car la requête doit accéder à toutes les ressources d'index
divise et filtre tous les albums afin que tous les chanteurs trouvent le jeton "happy"
et pas seulement les partitions correspondant à l'artiste singer1
.
Cependant, il peut arriver que l'application doive rechercher plutôt que les albums d'un chanteur spécifique. Dans ces cas, vous devez Utilisez un index non partitionné:
SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'piano concerto 1')
En règle générale, nous vous recommandons d'utiliser la granularité de partitionnement la plus fine qui soit pratique et appropriée pour la requête. Par exemple, si l'application interroge une boîte aux lettres électronique où chaque requête est limitée à une boîte aux lettres spécifique, partitionner l'index de recherche sur l'ID de boîte aux lettres. Toutefois, si la requête doit effectuer une recherche dans toutes les boîtes aux lettres, un index non partitionné est mieux adapté.
Certaines applications peuvent nécessiter plusieurs stratégies de partitionnement pour répondre à leurs besoins spécifiques en termes de recherche. Par exemple, un inventaire votre système de gestion de contenu peut avoir besoin d'accepter les requêtes filtrées par type de produit ou fabricant. En outre, certaines applications peuvent nécessiter plusieurs prétris, comme comme le tri par date de création ou de modification. Dans ces scénarios, il est nous vous recommandons de créer plusieurs index de recherche, chacun étant optimisé pour le les requêtes correspondantes.
Étape suivante
- Apprenez-en plus sur la tokenisation et les générateurs de jetons Spanner.
- En savoir plus sur les index de recherche
- Apprenez-en plus sur les index numériques.