Indici e partizionamento geografico

Spanner offre diversi tipi di indici per migliorare le prestazioni delle query. La scelta del tipo di indice corretto per lo schema e i pattern di query è fondamentale, soprattutto per i database che utilizzano il partizionamento geografico. Questa pagina descrive i vantaggi dei diversi tipi di indice e le best practice per la selezione e l'utilizzo degli indici Spanner con il partizionamento geografico.

Tipi di indice

Spanner supporta gli indici globali, locali e remoti. Ogni tipo ha caratteristiche di rendimento e casi d'uso diversi. Per i database con partizionamento geografico, è importante comprendere questi tipi di indice. La scelta dell'indice giusto ti aiuta a ottimizzare lo schema e le query del database, il che può migliorare significativamente la latenza del database partizionato geograficamente. Per i database che non utilizzano il partizionamento geografico, è meno importante comprendere questi tipi di indice perché sono tutti archiviati nel posizionamento predefinito e hanno caratteristiche di rendimento simili.

Indici globali

Un indice globale è il tipo di indice predefinito in Spanner. I dati dell'indice vengono archiviati nella partizione predefinita, che potrebbe non essere colocalizzata con i dati della tabella. La creazione di indici globali su tabelle con partizionamento geografico potrebbe comportare latenze di scrittura notevolmente più elevate per le scritture che coinvolgono le colonne indicizzate, soprattutto se il quorum di scrittura predefinito della partizione per l'indice è molto lontano dal quorum di scrittura delle righe della tabella in fase di scrittura. Puoi ridurre le latenze di lettura degli indici globali utilizzando repliche di sola lettura nelle vicinanze insieme a regioni di lease di lettura o letture non aggiornate.

Gli indici globali hanno le seguenti caratteristiche:

  • Accelerano le query che altrimenti richiederebbero una scansione completa della tabella e impongono l'unicità in tutte le righe della tabella, indipendentemente dalla posizione.
  • Sono adatti a colonne che richiedono valori univoci in un database.
  • Velocizzano le query che filtrano o ordinano in base alle colonne indicizzate.

Di seguito è riportato un esempio di indice univoco globale:

CREATE UNIQUE INDEX idx_customer_email ON customer(email);

Indici locali

Un indice locale è intercalato nella gerarchia principale della tabella indicizzata. I nomi e i tipi delle colonne della chiave primaria devono corrispondere a quelli della tabella indicizzata.

Gli indici locali hanno le seguenti caratteristiche:

  • Memorizzano i dati dell'indice nella stessa partizione dei dati indicizzati. La latenza di scrittura è soggetta al quorum di scrittura del posizionamento specifico, non al quorum di scrittura del posizionamento predefinito.

  • Offrono la latenza più bassa per le query che hanno come target un prefisso di chiave specifico, perché sia l'indice sia i dati della tabella si trovano nello stesso posizionamento.

Per creare un indice locale, inserisci l'indice nella tabella padre. Se utilizzi un indice locale UNIQUE, l'unicità viene applicata solo all'interno di una determinata riga principale, non all'intera tabella.

Di seguito è riportato un esempio di creazione di un indice locale nella tabella customer, interleaved nella tabella padre locations:

GoogleSQL 

-- Create locations placement table
CREATE TABLE locations (
  location STRING(MAX) NOT NULL PLACEMENT KEY,
) PRIMARY KEY(location);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location STRING(MAX) NOT NULL,
  customerId  INT64 NOT NULL,
  email STRING(MAX),
  webcookie STRING(64),
) PRIMARY KEY(location, customerId), INTERLEAVE IN PARENT locations;

-- Create a local index on the interleaved customer table
CREATE INDEX idx_customer_email_local ON customer(location, email),
INTERLEAVE IN locations;

PostgreSQL 

-- Create locations placement table
CREATE TABLE locations (
  location varchar NOT NULL PLACEMENT KEY PRIMARY KEY
);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location varchar NOT NULL,
  customerId  BIGINT NOT NULL,
  email varchar(1024),
  webcookie varchar(64),
  PRIMARY KEY(location, customerId)
) INTERLEAVE IN PARENT locations;

-- Create a local index on the interleaved customer table
CREATE INDEX idx_customer_email_local ON customer(location, email)
INTERLEAVE IN locations;

Quando esegui una query sui dati in una transazione di lettura/scrittura, devi specificare il prefisso della chiave primaria della tabella indicizzata nella query. In caso contrario, la query potrebbe richiedere una scansione completa della tabella. Ad esempio:

GoogleSQL 

-- The location (the index key prefix) must be specified
SELECT *
FROM customer
WHERE location= @location AND email= @email;

PostgreSQL 

-- The location (the index key prefix) must be specified
SELECT *
FROM customer
WHERE location= @location AND email= @email;

Per informazioni sull'ottimizzazione che non richiede di specificare la posizione, consulta Utilizzare l'indice univoco globale con l'indice locale o remoto.

Un indice locale è utile anche quando la tabella di posizionamento è basata su entità e vuoi indicizzare i dati all'interno di una determinata entità o sottoentità. Ad esempio:

GoogleSQL 

-- Create entity based customer placement table
CREATE TABLE customer (
  customerId INT64 NOT NULL,
  email STRING(MAX),
  webcookie STRING(64),
  location STRING(MAX) NOT NULL PLACEMENT KEY
) PRIMARY KEY(customerId);

-- Create customerOrders child table
CREATE TABLE customerOrders (
  customerId INT64 NOT NULL,
  orderId INT64 NOT NULL,
  orderName STRING(MAX) NOT NULL
) PRIMARY KEY(customerId, orderId), INTERLEAVE IN PARENT customer;

-- Create a local index on the interleaved child table
CREATE INDEX idx_order_local ON customerOrders(customerId, orderName),
INTERLEAVE IN customer;

PostgreSQL 

-- Create entity based customer placement table
CREATE TABLE customer (
  customerId BIGINT NOT NULL PRIMARY KEY,
  email varchar(1024),
  webcookie varchar(64),
  location varchar NOT NULL PLACEMENT KEY
);

-- Create customerOrders child table
CREATE TABLE customerOrders (
  customerId BIGINT NOT NULL,
  orderId BIGINT NOT NULL,
  orderName varchar(1024) NOT NULL,
  PRIMARY KEY(customerId, orderId)
) INTERLEAVE IN PARENT customer;

-- Create a local index on the interleaved child table
CREATE INDEX idx_order_local ON customerOrders(customerId, orderName)
INTERLEAVE IN customer;

Indici remoti

Un indice remoto interleave i dati dell'indice in una tabella che non è un predecessore nella gerarchia di interleaving della tabella indicizzata. I tipi di chiave primaria devono corrispondere ai tipi delle colonne di indice corrispondenti, ma i nomi possono essere diversi.

Utilizzando il partizionamento geografico, puoi intercalare un indice remoto solo nella tabella di posizionamento principale gestita automaticamente. Questa tabella contiene una riga per ogni posizionamento nel database.

Gli indici remoti hanno le seguenti caratteristiche:

  • Sono particolarmente utili quando la chiave primaria della tabella non ha il prefisso di una chiave di posizionamento, ma vuoi collocare geograficamente le partizioni dell'indice in base alla chiave di posizionamento.
  • Supportano solo l'indicizzazione delle colonne nella tabella di posizionamento e non in nessuna colonna delle tabelle secondarie interleaved.

Per utilizzare gli indici remoti con il partizionamento geografico, crea la tabella di posizionamento radice impostando l'opzione auto_managed_root_placement_table_name nell'istruzione DDL ALTER DATABASE.

  1. Utilizza l'istruzione ALTER DATABASE DDL per creare una tabella di posizionamento principale.

    GoogleSQL 

    ALTER DATABASE DATABASE_NAME SET OPTIONS
  (auto_managed_root_placement_table_name="TABLE_NAME");

    Sostituisci quanto segue:

    • DATABASE_NAME: il nome del database.
    • TABLE_NAME: il nome della tabella da creare. Ti consigliamo di utilizzare il nome root_placement_table.

    Ad esempio, il seguente comando crea una tabella denominata root_placement_table.

    ALTER DATABASE example_db SET OPTIONS
  (auto_managed_root_placement_table_name='root_placement_table');

    Dopo aver creato la tabella di posizionamento radice, Spanner crea una tabella interna e inserisce ed elimina automaticamente le righe quando crei o elimini il posizionamento. Di seguito è riportato un esempio di tabella di posizionamento definita dal sistema creata da Spanner, in cui il nome della tabella di esempio è impostato su root_placement_table. (Non eseguire questo esempio.)

    // Automatically generated after you run the previous example.
// Don't put this in your schema explicitly.
CREATE TABLE root_placement_table (
location STRING(MAX) NOT NULL PLACEMENT KEY
) PRIMARY KEY(location);

    PostgreSQL 

    ALTER DATABASE DATABASE_NAME SET
  spanner.auto_managed_root_placement_table_name='TABLE_NAME';

    Sostituisci quanto segue:

    • DATABASE_NAME: il nome del database.
    • TABLE_NAME: il nome della tabella da creare.

    Ad esempio, per creare una tabella root_placement_table utilizzata come radice di interleaving, esegui:

    ALTER DATABASE example_db SET
  spanner.auto_managed_root_placement_table_name='root_placement_table';

    Dopo aver creato la tabella di posizionamento radice, Spanner crea una tabella interna e inserisce ed elimina automaticamente le righe quando crei o elimini il posizionamento. Di seguito è riportato un esempio di tabella di posizionamento definita dal sistema creata da Spanner, in cui il nome della tabella di esempio è impostato su root_placement_table. (Non eseguire questo esempio.)

    // Automatically generated after you run the previous example.
// Don't put this in your schema explicitly.
CREATE TABLE root_placement_table (
  location varchar NOT NULL PLACEMENT KEY,
  PRIMARY KEY (location)
);

  2. Crea un indice remoto interleaved nella tabella root_placement_table gestita automaticamente.

    GoogleSQL 

    -- Create a customer table with a primary key that is not the location
CREATE TABLE customer (
  customerId INT64 NOT NULL ,
  email STRING(MAX),
  webcookie STRING(64),
  location STRING(MAX) NOT NULL PLACEMENT KEY,
) PRIMARY KEY(customerId);

-- Create a remote index on the customer table
CREATE INDEX idx_customer_email_remote ON customer(location, email),
INTERLEAVE IN root_placement_table;

    PostgreSQL 

    -- Create a customer table with a primary key that is not the location
CREATE TABLE customer (
  customerId BIGINT NOT NULL PRIMARY KEY,
  email varchar(1024),
  webcookie varchar(64),
  location varchar NOT NULL PLACEMENT KEY
);

-- Creates a remote index on the customer table
CREATE INDEX idx_customer_email_remote ON customer(location, email)
INTERLEAVE IN root_placement_table;

  3. Quando esegui una query sui dati in una transazione di lettura/scrittura, specifica il prefisso della chiave dell'indice nel predicato della query in modo che non sia necessaria una scansione completa della tabella. Ad esempio:

    GoogleSQL 

    -- Specify the location (the index key prefix) in query
SELECT *
FROM customer
WHERE location= @location AND email= @email;

    Per informazioni sull'ottimizzazione che non richiede di specificare la posizione, consulta la sezione Indice univoco globale con indice locale o remoto.

    PostgreSQL 

    -- Specify the location (the index key prefix) in query
SELECT *
FROM customer
WHERE location= @location AND email= @email;

    Per informazioni sull'ottimizzazione che non richiede di specificare la posizione, consulta la sezione Indice univoco globale con indice locale o remoto.

Ottimizzazioni per gli indici univoci globali

Quando utilizzi un indice univoco globale, Spanner può attivare miglioramenti della latenza delle query con ottimizzazioni basate sull'euristica nei seguenti casi d'uso:

  • Quando utilizzi un indice univoco globale con un indice locale o remoto
  • Quando utilizzi un indice univoco globale con chiavi primarie parziali

Le sezioni seguenti descrivono come Spanner può applicare le ottimizzazioni in ogni caso d'uso.

Indice univoco globale con un indice locale o remoto

Per migliorare la latenza delle query locali, Spanner potrebbe avviare un'ottimizzazione basata sull'euristica quando un indice univoco globale viene combinato con un indice locale o remoto.

Questa ottimizzazione riduce al minimo la latenza per le query intra-regionali, anche quando la posizione dei dati con partizionamento geografico non è specificata, ipotizzando che il posizionamento sia lo stesso in cui si trova il client e ignorando la partizione predefinita dell'indice globale oppure eliminando la necessità di scansioni complete della tabella filtrate. Questo approccio è particolarmente vantaggioso quando i client accedono principalmente a dati archiviati nella propria regione.

L'utilizzo di una combinazione di diversi tipi di indice è utile se la latenza delle query all'interno della regione è il problema principale e puoi tollerare un aumento della latenza di scrittura. La combinazione di diversi tipi di indice migliora anche il rendimento delle query intraregionali, anche quando non specifichi la località nella query.

Questa ottimizzazione richiede la creazione di un indice univoco globale e di un indice locale o remoto corrispondente nella stessa colonna. I dati indicizzati devono essere univoci a livello globale. Spanner applica questa ottimizzazione alla tua query se sono vere le seguenti condizioni:

  • Non conosci il prefisso della chiave primaria e non specifichi la posizione dei dati.
  • La tua richiesta ha origine dalla stessa regione del leader predefinito del posizionamento dei dati, che contiene lo shard dell'indice locale o remoto.

Spanner applica l'ottimizzazione nei seguenti modi:

  • Se l'ottimizzazione viene attivata e la riga viene trovata nel posizionamento locale: dato l'indice univoco globale, Spanner non deve cercare in altre posizioni. La query ha una latenza intra-regionale.
  • Se la ricerca iniziale della località non restituisce una riga: ciò indica che non si tratta di una query intraregionale. Spanner torna a utilizzare l'indice globale.

L'esempio seguente crea un indice univoco globale e un indice locale:

GoogleSQL 

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_local ON customer(location, email), INTERLEAVE IN locations;

PostgreSQL 

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_local ON customer(location, email) INTERLEAVE IN locations;

L'esempio seguente crea un indice univoco globale e un indice remoto:

GoogleSQL 

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_remote ON customer(location, email), INTERLEAVE IN root_placement_table;

PostgreSQL 

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_remote ON customer(location, email) INTERLEAVE IN root_placement_table;

In base agli indici dell'esempio precedente, la seguente query di esempio ha una latenza intra-regionale:

GoogleSQL 

SELECT *
FROM customer
WHERE email= @email;

PostgreSQL 

SELECT *
FROM customer
WHERE email= @email;

Indice univoco globale sulle chiavi primarie parziali

Spanner può applicare un'ottimizzazione simile a quella descritta in Utilizzare un indice univoco globale con un indice locale o remoto quando si utilizza un indice univoco globale su chiavi primarie parziali.

L'esempio seguente crea una tabella customer intercalata nella tabella principale locations, quindi crea un indice univoco globale nella colonna customerId.

GoogleSQL 

-- Create locations placement table
CREATE TABLE locations (
location STRING(MAX) NOT NULL PLACEMENT KEY,
) PRIMARY KEY(location);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location STRING(MAX) NOT NULL,
  customerId  INT64 NOT NULL,
  email STRING(MAX),
  webcookie STRING(64),
) PRIMARY KEY(location, customerId), INTERLEAVE IN PARENT locations;

-- Create global unique index on customerId column
CREATE UNIQUE INDEX idx_customer_customerid ON customer(customerId);

PostgreSQL 

-- Create locations placement table
CREATE TABLE locations (
  location varchar NOT NULL PLACEMENT KEY PRIMARY KEY
);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location varchar NOT NULL,
  customerId  BIGINT NOT NULL,
  email varchar(1024),
  webcookie varchar(64),
  PRIMARY KEY(location, customerId)
) INTERLEAVE IN PARENT locations;

-- Create global unique index on customerId column
CREATE UNIQUE INDEX idx_customer_customerid ON customer(customerId);

L'ottimizzazione si applica a query come le seguenti:

GoogleSQL 

SELECT * FROM customer WHERE customerId= @customerId;

PostgreSQL 

SELECT * FROM customer WHERE customerId= @customerId;

Se non crei l'indice univoco globale, questa query potrebbe richiedere una scansione completa della tabella. Se non utilizzi l'indice univoco globale, devi aggiungere il filtro della località alla query per ottenere una buona latenza della query:

GoogleSQL 

SELECT * FROM customer WHERE location = @location AND customerId= @customerId;

PostgreSQL 

SELECT * FROM customer WHERE location = @location AND customerId= @customerId;

Linee guida generali per la scelta di un tipo di indice per una latenza ottimale

Il tipo di indice scelto influisce direttamente sulla latenza delle query. La posizione dei dati dell'indice rispetto ai dati della tabella è un fattore primario per il rendimento dei carichi di lavoro con partizionamento geografico.

Questa sezione descrive come scegliere tra indici globali, locali e remoti.

Quando scegliere gli indici globali

Utilizza gli indici globali se il tuo workload può tollerare la latenza di lettura e scrittura associata o se richiedi l'unicità globale forzata nelle colonne indicizzate.

Quando scegli gli indici globali, tieni presente quanto segue:

  • La distanza tra il client e il leader del quorum di scrittura predefinito, insieme alla latenza predefinita del quorum, determina l'aumento della latenza di scrittura. Questo effetto è limitato specificamente alle operazioni che coinvolgono colonne indicizzate, come inserimenti di righe o aggiornamenti di colonne indicizzate.
  • L'aggiunta di repliche di sola lettura o l'utilizzo di lease di lettura può ridurre l'aumento della latenza di lettura:
    • L'aggiunta di una replica di sola lettura in prossimità geografica può ridurre la latenza di lettura dati inattivi.
    • L'aggiunta di una replica di sola lettura e l'utilizzo di regioni di lease di lettura possono ridurre la latenza di lettura coerente. Se aggiungi una replica di sola lettura senza utilizzare una regione di lease di lettura, la latenza di lettura coerente non viene ridotta, ma la velocità effettiva di lettura può aumentare.
    • Spanner esegue sempre letture transazionali pessimistiche dal leader. L'aggiunta di repliche al posizionamento predefinito non è utile per le letture transazionali pessimistiche dei dati nei posizionamenti predefiniti.
  • Gli indici globali (incluse le chiavi e l'archiviazione dei valori) vengono inseriti nel posizionamento predefinito, che non fornisce la residenza dei dati a livello di posizionamento. Per saperne di più, consulta la panoramica della residenza dei dati di Spanner.

Quando scegliere gli indici locali e remoti

Quando scegli gli indici locali e remoti, tieni presente quanto segue:

  • Gli indici locali e remoti offrono prestazioni di lettura e scrittura locali per il posizionamento, ma sacrificano le proprietà di unicità e ordinamento globali delle colonne dell'indice univoco. Gli indici locali e remoti forniscono invece l'ordinamento e l'unicità delle colonne indicizzate all'interno della riga principale in cui sono intercalati.
  • Quando utilizzi indici locali o remoti, devi includere la posizione del posizionamento nel predicato della query, tranne nei casi in cui esiste anche un indice univoco globale che consente a Spanner di indovinare la posizione del posizionamento locale. In caso contrario, il piano di query e le prestazioni non sono deterministici. Spanner potrebbe eseguire la scansione della tabella di base o la dispersione e la raccolta dall'indice nelle posizioni di posizionamento in base alle statistiche delle query, aumentando la latenza.

Quando scegliere indici univoci globali con indici locali o remoti

Quando scegli una combinazione di indici univoci globali insieme a indici locali o remoti, tieni presente quanto segue:

  • Quando la posizione specifica del posizionamento non è nota, utilizza una combinazione di indici univoci globali con indici locali o remoti. Questo approccio è ideale quando la maggior parte delle query proviene da servizi situati geograficamente nella stessa regione del posizionamento dei dati richiesti.
  • Quando scrivi indici globali, la latenza di scrittura è soggetta a una latenza di quorum di scrittura predefinita aggiuntiva.
  • Con l'ottimizzazione basata sull'euristica, le query vengono pubblicate da shard dell'indice locale e mostrano una latenza intra-regione la maggior parte delle volte.

Linee guida dettagliate per la scelta di un indice per schemi specifici

La strategia di indicizzazione ottimale dipende dalla struttura della chiave primaria della tabella e dai pattern di query dell'applicazione. Questa sezione fornisce indicazioni per la selezione del tipo di indice appropriato per tre progetti di schema comuni:

  • Schemi che utilizzano un'entità come chiave primaria
  • Schemi che utilizzano la posizione come chiave primaria
  • Schemi che utilizzano valori correlati alla posizione come chiave primaria

Progettazione dello schema: l'entità come chiave primaria

Se lo schema utilizza un'entità come chiave primaria, scegli la strategia di indicizzazione in base al fatto che la località sia specificata o meno nelle query.

Nei casi in cui un'entità come customerID è la chiave primaria e una colonna non chiave separata come location è la chiave di posizionamento, determina la strategia di indicizzazione per la tabella dei posizionamenti in base ai pattern di query. Non utilizzare un'entità come chiave primaria della tabella dei posizionamenti se la latenza di inserimento è un problema per le entità.

Se vuoi indicizzare i dati in una determinata entità, ad esempio customerID, utilizza un indice locale. I dati vengono indicizzati e ordinati all'interno dell'entità, ma non tra le entità. Ad esempio, se vuoi indicizzare gli ordini di ogni cliente in base alla data, puoi creare un indice locale intercalato nell'identità customerID.

Quando la posizione è sempre nota nelle query, utilizza una delle seguenti strategie:

  • Se la località è nota in modo coerente nelle tue query e non è necessario applicare l'unicità globale, utilizza gli indici remoti. Questi indici forniscono la latenza intra-regione per le operazioni di lettura e scrittura.

    Gli indici remoti supportano solo l'indicizzazione delle colonne nella tabella di posizionamento, non nelle colonne delle tabelle interleaved. L'indice remoto deve essere intercalato nella tabella di posizionamento principale. L'indice remoto indicizza i dati in tutte le righe di posizionamento per il posizionamento.

Nei casi in cui la posizione non è sempre nota nelle query, utilizza una delle seguenti strategie:

  • Se la colonna indicizzata è univoca a livello globale, crea un indice univoco globale per imporre l'unicità.

    Per ottenere letture coerenti a bassa latenza, crea un indice remoto oltre a un indice univoco globale.

    Con questa combinazione, le scritture potrebbero comportare una latenza cross-region, mentre le query con una località specificata (con WHERE location= @location) beneficiano della latenza intraregionale utilizzando l'indice remoto. Per le query senza una località specificata, Spanner utilizza un'ottimizzazione basata sull'euristica eseguendo prima la ricerca in locale. Se i dati non vengono trovati, viene utilizzato l'indice globale.

    Se utilizzi regioni di lease di lettura e disponi di una replica di sola lettura della partizione predefinita nella stessa regione dei tuoi dati, un indice remoto non è necessario perché le regioni di lease di lettura forniscono già una bassa latenza di lettura coerente per le letture di un indice globale.

  • Se la query non specifica una località e le colonne indicizzate non sono univoche a livello globale, crea solo un indice globale (non univoco). L'aggiunta di un indice locale o remoto non migliora la latenza di lettura in questo caso perché Spanner non può determinare se esistono dati corrispondenti in un altro posizionamento, anche se Spanner trova dati nel posizionamento locale.

Progettazione dello schema: posizione come chiave primaria

Quando una colonna location funge sia da chiave primaria sia da chiave di posizionamento, la selezione dell'indice è influenzata da problemi di latenza incrociata e dal fatto che le query specificano sempre la posizione.

  • Se la latenza tra regioni non è un problema o se hai bisogno di unicità globale, utilizza gli indici globali.
  • Se la latenza tra regioni è un problema, le query includono sempre la posizione e non è necessario che Spanner applichi l'unicità globale, utilizza solo gli indici locali. In questo modo si garantisce la latenza locale sia per le letture che per le scritture.

  • Se la latenza delle query tra regioni è un problema, la latenza di scrittura tra regioni è accettabile e la posizione non è sempre nota, si applicano le seguenti strategie:

    Condizione Suggerimento
    Esegui query in base alla chiave primaria parziale univoca a livello globale

    Crea un indice globale univoco per garantire l'univocità. Un indice locale non è necessario perché la chiave primaria svolge una funzione simile. Viene applicata l'ottimizzazione basata sull'euristica. Innanzitutto, Spanner controlla la chiave primaria completa con la posizione locale prima di eseguire il failover all'indice globale.

    Per un esempio, vedi Indice univoco globale su chiavi primarie parziali.

    Eseguire query in base a una colonna univoca a livello globale non chiave

    Crea un indice globale univoco per garantire l'univocità.

    Per la latenza all'interno della regione, sono possibili i seguenti scenari:

    • Crea un indice locale sulla stessa colonna dell'indice globale. Viene applicata l'ottimizzazione basata sull'euristica. La combinazione di indici globali e locali offre una latenza ridotta per le query coerenti e obsolete all'interno della regione, mentre le scritture e le query e le scritture tra regioni hanno una latenza tra regioni.
    • Se esiste una replica di lettura/scrittura o di sola lettura della partizione predefinita nella stessa regione dei tuoi dati, allora:
      • Se hai bisogno della latenza intraregionale solo per le letture obsolete, ma non per le letture coerenti, non hai bisogno di un indice locale. La replica locale fornisce la latenza all'interno della regione.
      • Se hai bisogno di una latenza intra-regionale per letture coerenti, puoi creare un indice locale sulla stessa colonna dell'indice globale o utilizzare le regioni di lease di lettura. Le regioni con lease di lettura forniscono una latenza di lettura bassa e coerente a scapito della latenza di scrittura.
    La colonna indicizzata non è univoca a livello globale Crea solo un indice globale. Un indice locale non migliora la latenza di lettura perché Spanner potrebbe dover controllare tutte le posizioni.

Se questi tre scenari non si applicano al tuo caso d'uso, probabilmente devi sacrificare la semplicità dell'applicazione o la latenza di scrittura fornendo costantemente la posizione.

Se la chiave primaria della tabella si basa su valori correlati alla località, ma non è direttamente la colonna della chiave di posizionamento (ad esempio, utilizzando country come chiave primaria quando hai meno posizionamenti rispetto ai paesi), puoi utilizzare un indice globale o un indice locale (interleaved nella colonna country). Tuttavia, gli indici remoti non sono supportati per le tabelle interleaved in questo tipo di tabella di posizionamento.

L'ottimizzazione basata sull'euristica non è supportata per gli indici locali in questo scenario. Pertanto, ottieni la latenza locale solo quando la query specifica esplicitamente il prefisso della chiave primaria.