Roteamento com reconhecimento de líder

Esta página descreve o roteamento ciente do líder no Spanner e como usá-lo. O Spanner usa o roteamento com reconhecimento de líder para rotear dinamicamente transações de leitura e gravação em configurações de instâncias dual-region e multirregionais para reduzir a latência e melhorar o desempenho no seu banco de dados. O roteamento ciente do líder é ativado por padrão.

Roteamento do Spanner para transações de leitura e gravação

O Spanner replica dados para oferecer mais disponibilidade de dados e localidade geográfica. Nas configurações de instâncias birregionais e multirregionais do Spanner, uma região é designada como líder e contém as réplicas líderes do banco de dados. Quando você usa uma configuração de instância dual-região ou multirregional e o cliente emite uma transação de leitura e gravação no banco de dados de uma região que não é líder, a gravação é sempre processada na região líder e em seguida enviada de volta para a região que não é líder. Portanto, as transações de leitura e gravação confirmadas em uma região que não é líder exigem várias viagens de ida e volta para que a réplica líder seja confirmada.

O roteamento ciente do líder é um mecanismo que melhora a latência das transações de leitura e gravação por meio de um roteamento inteligente. Se o roteamento com suporte a líder estiver ativado, mesmo que a gravação não seja originada na região líder, as solicitações de criação de sessão serão roteadas para a região líder para alinhar o front-end da API Spanner com a região líder. Esse mecanismo de roteamento melhora a latência para transações de leitura e gravação reduzindo o número de viagens de ida e volta de rede necessárias entre a região não líder (onde o aplicativo cliente está localizado) e a região líder para duas.

Captura de tela do roteamento do Spanner com o roteamento ciente do líder ativado. Figura 1. Exemplo de roteamento do Spanner com o roteamento ciente do líder ativado.

Se o roteamento ciente do líder estiver desativado, o aplicativo cliente vai rotear a solicitação primeiro para um serviço de front-end da API Spanner na região do aplicativo cliente (região não líder). Em seguida, do front-end da API do Spanner na região do aplicativo cliente, três ou mais viagens de ida e volta são feitas para o servidor do Spanner (SpanServer) na região líder para confirmar a gravação, aumentando a latência. Essas viagens de ida e volta adicionais são necessárias para oferecer suporte a índices secundários, verificações de restrição e leitura de gravações.

Captura de tela do roteamento Spanner com o roteamento ciente do líder desativado. Figura 2. Exemplo de roteamento do Spanner com o roteamento ciente do líder desativado.

Casos de uso

Como resultado do uso do roteamento ciente do líder, os seguintes casos de uso se beneficiam de uma latência menor:

  • Atualizações em massa: execução de importações do Dataflow ou de mudanças em segundo plano (por exemplo, DMLs em lote) de uma região que não é líder.
  • Tolerância a desastres e maior disponibilidade: implantar aplicativos clientes em regiões líderes e não líderes para tolerar interrupções regionais ao iniciar gravações em regiões não líderes.
  • Aplicativo global: implantação de aplicativos cliente globalmente com locais de região disseminados que confirmam dados.

Limitações

Se o aplicativo cliente for implantado fora da região líder e você gravar valores sem ler os dados ("gravações cegas"), poderá observar regressão de latência se o roteamento ciente do líder estiver ativado. Isso ocorre porque, quando o roteamento ciente do líder está ativado, há duas viagens de ida e volta entre regiões (beginTransaction e a solicitação commit) entre o aplicativo cliente na região que não é líder e o front-end da API Spanner na região líder. No entanto, com o roteamento ciente do líder desativado, as gravações sem leituras exigem apenas uma ida e volta entre regiões para a solicitação commit (beginTransaction é processado no front-end da API Spanner local). Por exemplo, se você carregar dados de arquivos em massa em uma tabela recém-criada, é improvável que as transações leiam dados da tabela. Se você frequentemente confirma operações de gravação sem ler no aplicativo, considere desativar o roteamento ciente do líder. Para mais informações, consulte Desativar o roteamento ciente do líder.

Usar o roteamento com reconhecimento de líder

O roteamento ciente do líder é ativado por padrão nas bibliotecas de cliente do Spanner.

Recomendamos processar suas solicitações de leitura e gravação com o roteamento ciente do líder ativado. Você pode desativar esse recurso para comparar as diferenças de performance.

Ativar o roteamento com conhecimento do líder

É possível usar as bibliotecas de cliente do Spanner para ativar manualmente o roteamento com suporte a líder.

Use a estrutura RouteToLeaderOption para configurar o aplicativo cliente com o roteamento ciente do líder ativado:

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));

Use EnableLeaderRouting para configurar o aplicativo cliente com o roteamento ciente do líder ativado:

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

Use ClientConfig para configurar o aplicativo cliente com o roteamento ciente do líder ativado:

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
}

Use SpannerOptions.Builder para configurar o aplicativo cliente com o roteamento ciente do líder ativado:

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

Use SpannerOptions para configurar o aplicativo cliente com o roteamento ciente do líder ativado:

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

Use routeToLeader para configurar o aplicativo cliente com o roteamento ciente do líder ativado:

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

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

Use route_to_leader_enabled para configurar o aplicativo cliente com o roteamento ciente do líder ativado:

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

Use self.new para configurar o aplicativo cliente com o roteamento ciente do líder ativado:

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

Desativar o roteamento com conhecimento do líder

É possível usar as bibliotecas de cliente do Spanner para desativar o roteamento com líder.

Use a estrutura RouteToLeaderOption para configurar o aplicativo cliente com o roteamento ciente do líder desativado:

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));

Use EnableLeaderRouting para configurar o aplicativo cliente com o roteamento ciente do líder desativado:

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

Use ClientConfig para configurar o aplicativo cliente com o roteamento ciente do líder desativado:

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
}

Use SpannerOptions.Builder para criar uma conexão com um banco de dados do Spanner com o roteamento do líder desativado:

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

Use SpannerOptions para configurar o aplicativo cliente com o roteamento ciente do líder desativado:

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

Use routeToLeader para configurar o aplicativo cliente com o roteamento ciente do líder desativado:

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

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

Use route_to_leader_enabled para configurar o aplicativo cliente com o roteamento ciente do líder desativado:

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

Use self.new para configurar o aplicativo cliente com o roteamento ciente do líder desativado:

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

A seguir