Indici di ricerca delle partizioni

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

Panoramica

Se la clausola PARTITION BY viene omessa in un indice non partizionato, viene creato la definizione dell'indice. In un indice non partizionato, una query deve leggere tutte le suddivisioni dell'indice. Questo limita la potenziale scalabilità della ricerca a testo intero query.

Gli indici partizionati, invece, suddividono l'indice in unità più piccole, una per ogni partizione univoca. Le query possono cercare solo all'interno di una singola partizione in un momento, specificato 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 Google Cloud.

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

È anche possibile forzare una query per 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 partizionare l'indice di ricerca sull'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 inventario di gestione potrebbe dover supportare query filtrate per tipo di prodotto 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