Partiziona gli indici di ricerca

Spanner supporta gli indici di ricerca sia non partizionati che partizionati. Questa pagina descrive come creare un indice di ricerca partizionato in Spanner.

Viene creato un indice non partizionato quando la clausola PARTITION BY viene omessa nella definizione dell'indice. In un indice non partizionato, una query deve leggere da tutte le suddivisioni dell'indice. Ciò limita la potenziale scalabilità delle query di ricerca a testo intero.

Gli indici partizionati, invece, suddividono l'indice in unità più piccole, una per ogni partizione univoca. Le query possono eseguire ricerche solo all'interno di una singola partizione alla volta, specificata da una condizione di uguaglianza nella clausola WHERE. Le query contro gli indici partizionati sono in genere più efficienti delle query contro gli indici non partizionati perché Spanner deve leggere solo i dati per una singola partizione. La partizione dell'indice di ricerca è analoga al prefisso della chiave di un indice secondario.

Ad esempio, supponiamo che in un database siano presenti 1.000.000 di SingerIds e i seguenti due indici:

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 seguente query seleziona l'indice AlbumsIndexBySingerId perché cerca solo i dati di un singolo cantante. Questo tipo di query in genere utilizza meno risorse.

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

È anche possibile obbligare una query a utilizzare AlbumsUnpartitionedIndex per restituire gli stessi risultati. Tuttavia, utilizza più risorse, perché la query deve accedere a tutte le suddivisioni dell'indice e filtrare tutti gli album di tutti i cantanti per trovare il token "happy", piuttosto che solo le suddivisioni corrispondenti al cantante singer1.

Tuttavia, a volte l'applicazione deve cercare in tutti gli album anziché solo in quelli di un cantante specifico. In questi casi, devi utilizzare un indice non partizionato:

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

Il consiglio generale è di utilizzare la granularità più fine del partizionamento pratica e appropriata per la query. Ad esempio, se l'applicazione esegue query su una casella di posta email in cui ogni query è limitata a una casella di posta specifica, partiziona l'indice di ricerca in base all'ID casella di posta. Tuttavia, se la query deve eseguire ricerche in tutte le cassette postali, è preferibile un indice non partizionato.

Alcune applicazioni potrebbero richiedere più strategie di partizione per soddisfare i loro requisiti di ricerca specifici. Ad esempio, un sistema di gestione dell'inventario potrebbe dover supportare le query filtrate per tipo di prodotto o produttore. Inoltre, alcune applicazioni potrebbero richiedere più pre-ordinamenti, ad esempio l'ordinamento per data di creazione o modifica. In questi scenari, è consigliabile creare più indici di ricerca, ciascuno ottimizzato per le query corrispondenti.

Passaggi successivi