Routing consapevole del leader

Questa pagina descrive il routing sensibile al leader in Spanner e come utilizzarlo. Spanner utilizza il routing basato su leader per instradare dinamicamente le transazioni di lettura e scrittura nelle configurazioni di istanze a due regioni e multiregionali per ridurre la latenza e migliorare le prestazioni del database. Il routing basato sul leader è abilitato per impostazione predefinita.

Routing di Spanner per le transazioni di lettura/scrittura

Spanner replica i dati per fornire una maggiore disponibilità dei dati e una località geografica. Nelle configurazioni di istanze a due regioni e multiregionali di Spanner, una regione nella configurazione di istanze a due regioni e multiregionali è designata come regione leader e contiene le repliche leader del database. Quando utilizzi una configurazione di istanza a due regioni o multiregionale e il tuo client invia una transazione di lettura/scrittura al database da una regione non leader, la scrittura viene sempre elaborata nella regione leader e poi inviata nuovamente alla regione non leader. Pertanto, i commit delle transazioni di lettura/scrittura da una regione non leader richiedono più round trip alla replica leader per essere eseguiti correttamente.

Il routing basato sul leader è un meccanismo che migliora la latenza per le transazioni di lettura e scrittura instradandole in modo intelligente. Se il routing sensibile al leader è abilitato, anche se la scrittura non proviene dalla regione leader, le richieste di creazione della sessione vengono indirizzate alla regione leader per allineare il frontend dell'API Spanner con la regione leader. Questo meccanismo di routing migliora la latenza per le transazioni di lettura e scrittura riducendo a due il numero di andate e ritorno di rete richiesti tra la regione non leader (dove si trova l'applicazione client) e la regione leader.

Screenshot del routing di Spanner con il routing basato sul leader abilitato. Figura 1. Esempio di routing di Spanner con il routing basato sul leader abilitato.

Se il routing basato su leader è disattivato, l'applicazione client instrada prima la richiesta a un servizio frontend dell'API Spanner all'interno della regione dell'applicazione client (regione non leader). Poi, dal frontend dell'API Spanner nella regione dell'applicazione client, vengono effettuati tre o più round trip al server Spanner (SpanServer) nella regione leader per eseguire il commit della scrittura, aumentando la latenza. Questi round trip aggiuntivi sono necessari per supportare gli indici secondari, i controlli dei vincoli e la lettura delle scritture.

Screenshot del routing di Spanner con il routing basato sul leader disattivato. Figura 2. Esempio di routing di Spanner con il routing basato sul leader disattivato.

Casi d'uso

Grazie all'utilizzo del routing basato su leader, i seguenti casi d'uso beneficiano di una latenza inferiore:

  • Aggiornamenti collettivi: esecuzione di importazioni Dataflow o di modifiche in background (ad esempio, DML batch) da una regione non leader.
  • Tolleranza ai disastri e maggiore disponibilità: esegui il deployment delle applicazioni client sia nelle regioni leader che in quelle non leader per tollerare le interruzioni a livello di regione, avviando al contempo le scritture dalle regioni non leader.
  • Applicazione globale: deployment di applicazioni client a livello globale con località di regioni diffuse che eseguono il commit dei dati.

Limitazioni

Se l'applicazione client è distribuita al di fuori della regione leader e scrivi valori senza leggere i dati ("scritture cieche"), potresti osservare una regressione della latenza se il routing basato sul leader è abilitato. Questo perché, quando il routing sensibile al leader è abilitato, esistono due round trip tra regioni (beginTransaction e la richiesta commit) tra l'applicazione client nella regione non leader e il frontend dell'API Spanner nella regione leader. Tuttavia, con il routing sensibile al leader disattivato, le scritture senza letture richiedono un solo round trip tra regioni per la richiesta commit (beginTransaction viene elaborata nel frontend dell'API Spanner locale). Ad esempio, se carichi dati in blocco in una tabella appena creata, è improbabile che le transazioni leggano i dati dalla tabella. Se esegui spesso commit di operazioni di scrittura senza leggerle nella tua applicazione, ti consigliamo di disattivare il routing basato sul leader. Per saperne di più, consulta Disabilita il routing basato su leader.

Utilizza il routing basato sul leader

Il routing basato su leader è abilitato per impostazione predefinita nelle librerie client di Spanner.

Ti consigliamo di elaborare le richieste di lettura e scrittura con il routing basato sul leader abilitato. Puoi disattivarla per confrontare le differenze di rendimento.

Routing basato sul leader con partizionamento geografico

Quando utilizzi il partizionamento geografico per partizionare il database in più posizionamenti dei dati, Spanner valuta tutte le configurazioni delle istanze utilizzate dai posizionamenti del database, incluso il posizionamento predefinito, durante il routing delle richieste. Spanner seleziona un frontend dell'API Cloud Spanner collocato nella regione di posizionamento più vicina al client. Questa selezione è indipendente dall'utilizzo o meno del posizionamento o dei relativi dati in una determinata transazione. Spanner instrada le transazioni di lettura/scrittura nel seguente modo:

  • Con il routing basato su leader abilitato: ogni posizionamento ha la propria regione leader (o la regione leader predefinita per le configurazioni a due regioni e multiregionali). Spanner indirizza le transazioni di lettura/scrittura al frontend dell'API Cloud Spanner nella regione leader più vicina al client.
  • Con il routing sensibile al leader disabilitato: Spanner instrada le transazioni di lettura e scrittura al frontend dell'API Cloud Spanner nella regione di pubblicazione più vicina in tutti i posizionamenti del database.

Abilita il routing basato sul leader

Puoi utilizzare le librerie client di Spanner per abilitare manualmente il routing basato su leader.

C++

Utilizza la struttura RouteToLeaderOption per configurare l'applicazione client con il routing leader-aware abilitato:

void RouteToLeaderOption(std::string const& project_id, std::string const& instance_id,
              std::string const& database_id) {
namespace spanner = ::google::cloud::spanner;

// Create a client with RouteToLeaderOption enabled.
auto client = spanner::Client(
  spanner::MakeConnection(
      spanner::Database(project_id, instance_id, database_id)),
  google::cloud::Options{}.set<spanner::RouteToLeaderOption>(
      spanner::true));

C#

Utilizza EnableLeaderRouting per configurare l'applicazione client con il routing leader-aware abilitato:

// Create a client with leader-aware routing enabled.
SpannerConnectionStringBuilder builder = new
SpannerConnectionStringBuilder();
Builder.EnableLeaderRouting = true;

Vai

Utilizza ClientConfig per configurare l'applicazione client con il routing leader-aware abilitato:

type ClientConfig struct {
    // DisableRouteToLeader specifies if all the requests of type read-write
    // and PDML need to be routed to the leader region.
    // Default: false
    DisableRouteToLeader false
}

Java

Utilizza SpannerOptions.Builder per configurare l'applicazione client con il routing leader-aware abilitato:

SpannerOptions options = SpannerOptions.newBuilder().enableLeaderAwareRouting.build();
Spanner spanner = options.getService();
String instance = "my-instance";
String database = "my-database";

Node.js

Utilizza SpannerOptions per configurare l'applicazione client con il routing leader-aware abilitato:

// Instantiates a client with routeToLeaderEnabled enabled
const spanner = new Spanner({
projectId: projectId,
routeToLeaderEnabled: true;
});

PHP

Utilizza routeToLeader per configurare l'applicazione client con il routing sensibile al leader abilitato:

// Instantiates a client with leader-aware routing enabled
use Google\Cloud\Spanner\SpannerClient;

$routeToLeader = true;
$spanner = new SpannerClient($routeToLeader);

Python

Utilizza route_to_leader_enabled per configurare l'applicazione client con il routing leader-aware abilitato:

spanner_client = spanner.Client(
route_to_leader_enabled=true
)
instance = spanner_client.instance(instance_id)
database = instance.database(database_id)

Ruby

Utilizza self.new per configurare l'applicazione client con il routing leader-aware abilitato:

def self.new(project_id: nil, credentials: nil, scope: nil, timeout: nil,
     endpoint: nil, project: nil, keyfile: nil, emulator_host: nil,
    lib_name: nil, lib_version: nil, enable_leader_aware_routing: true) ->
    Google::Cloud::Spanner::Project

Disattiva il routing leader-aware

Puoi utilizzare le librerie client di Spanner per disattivare il routing sensibile al leader.

C++

Utilizza la struttura RouteToLeaderOption per configurare l'applicazione client con il routing leader-aware disabilitato:

void RouteToLeaderOption(std::string const& project_id, std::string const& instance_id,
              std::string const& database_id) {
namespace spanner = ::google::cloud::spanner;

// Create a client with RouteToLeaderOption disabled.
auto client = spanner::Client(
  spanner::MakeConnection(
      spanner::Database(project_id, instance_id, database_id)),
  google::cloud::Options{}.set<spanner::RouteToLeaderOption>(
      spanner::false));

C#

Utilizza EnableLeaderRouting per configurare l'applicazione client con il routing basato su leader disabilitato:

// Create a client with leader-aware routing disabled.
SpannerConnectionStringBuilder builder = new
SpannerConnectionStringBuilder();
Builder.EnableLeaderRouting = false;

Vai

Utilizza ClientConfig per configurare l'applicazione client con il routing basato su leader disabilitato:

type ClientConfig struct {
    // DisableRouteToLeader specifies if all the requests of type read-write
    // and PDML need to be routed to the leader region.
    // Default: false
    DisableRouteToLeader true
}

Java

Utilizza SpannerOptions.Builder per creare una connessione a un database Spanner con il routing sensibile al leader disattivato:

SpannerOptions options = SpannerOptions.newBuilder().disableLeaderAwareRouting.build();
Spanner spanner = options.getService();
String instance = "my-instance";
String database = "my-database";

Node.js

Utilizza SpannerOptions per configurare l'applicazione client con il routing basato su leader disabilitato:

// Instantiates a client with routeToLeaderEnabled disabled
const spanner = new Spanner({
projectId: projectId,
routeToLeaderEnabled: false;
});

PHP

Utilizza routeToLeader per configurare l'applicazione client con il routing basato su leader disattivato:

// Instantiates a client with leader-aware routing disabled
use Google\Cloud\Spanner\SpannerClient;

$routeToLeader = false;
$spanner = new SpannerClient($routeToLeader);

Python

Utilizza route_to_leader_enabled per configurare l'applicazione client con il routing basato su leader disabilitato:

spanner_client = spanner.Client(
route_to_leader_enabled=false
)
instance = spanner_client.instance(instance_id)
database = instance.database(database_id)

Ruby

Utilizza self.new per configurare l'applicazione client con il routing basato su leader disabilitato:

def self.new(project_id: nil, credentials: nil, scope: nil, timeout: nil,
     endpoint: nil, project: nil, keyfile: nil, emulator_host: nil,
    lib_name: nil, lib_version: nil, enable_leader_aware_routing: false) ->
    Google::Cloud::Spanner::Project

Passaggi successivi