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.
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.
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
- Saiba mais sobre configurações regionais, birregionais e multirregionais.
- Saiba mais sobre a replicação.
- Saiba como modificar a região líder de um banco de dados.