Enrutamiento que tiene en cuenta el líder

En esta página, se describe el enrutamiento adaptado al líder en Spanner y cómo usarlo. Spanner usa el enrutamiento adaptado al líder para enrutar de forma dinámica las transacciones de lectura y escritura en configuraciones de instancias birregionales y multirregionales para reducir la latencia y mejorar el rendimiento en tu base de datos. El enrutamiento con reconocimiento de líderes está habilitado de forma predeterminada.

Enrutamiento de Spanner para transacciones de lectura y escritura

Spanner replica los datos para proporcionar disponibilidad de datos y localidad geográfica adicionales. En las configuraciones de instancias birregionales y multirregionales de Spanner, una región de la configuración de instancias birregionales y multirregionales se designa como la región líder y contiene las réplicas líderes de la base de datos. Cuando usas una configuración de instancia birregional o multirregional, y tu cliente emite una transacción de lectura y escritura en tu base de datos desde una región no líder, la escritura siempre se procesa en la región líder y, luego, se envía de vuelta a la región no líder. Por lo tanto, las transacciones de lectura y escritura confirmadas desde una región que no es líder requieren varios viajes de ida y vuelta a la réplica líder para confirmarse correctamente.

El enrutamiento adaptado al líder es un mecanismo que mejora la latencia de las transacciones de lectura y escritura enrutando estas transacciones de forma inteligente. Si el enrutamiento adaptado al líder está habilitado, incluso si la escritura no se origina en la región líder, las solicitudes de creación de sesiones se enrutan a la región líder para alinear el frontend de la API de Spanner con la región líder. Este mecanismo de enrutamiento mejora la latencia de las transacciones de lectura y escritura, ya que reduce a dos la cantidad de recorridos de ida y vuelta de red necesarios entre la región no líder (donde se encuentra la aplicación cliente) y la región líder.

Captura de pantalla del enrutamiento de Spanner con el enrutamiento que reconoce al líder habilitado. Figura 1. Ejemplo de enrutamiento de Spanner con el enrutamiento que reconoce al líder habilitado.

Si el enrutamiento adaptado al líder está inhabilitado, la aplicación cliente primero enruta la solicitud a un servicio de frontend de la API de Spanner dentro de la región de la aplicación cliente (región que no es líder). Luego, desde el frontend de la API de Spanner en la región de la aplicación cliente, se realizan tres o más viajes de ida y vuelta al servidor de Spanner (SpanServer) en la región líder para confirmar la escritura, lo que aumenta la latencia. Estas idas y vueltas adicionales son necesarias para admitir índices secundarios, verificaciones de restricciones y leer tus escrituras.

Captura de pantalla del enrutamiento de Spanner con el enrutamiento adaptado al líder inhabilitado. Figura 2. Ejemplo de enrutamiento de Spanner con el enrutamiento adaptado al líder inhabilitado.

Casos de uso

Como resultado del uso del enrutamiento con reconocimiento de líderes, los siguientes casos de uso se benefician de una latencia más baja:

  • Actualizaciones masivas: Ejecutar importaciones de Dataflow o cambios en segundo plano (por ejemplo, DML por lotes) desde una región que no es líder.
  • Tolerancia a desastres y mayor disponibilidad: Implementa aplicaciones cliente en regiones líderes y no líderes para tolerar interrupciones regionales mientras inicias operaciones de escritura desde regiones no líderes.
  • Aplicación global: Implementa aplicaciones cliente de forma global con ubicaciones de regiones extendidas que confirman datos.

Limitaciones

Si tu aplicación cliente se implementa fuera de la región líder y escribes valores sin leer los datos ("escrituras ciegas"), es posible que observes una regresión de latencia si el enrutamiento con reconocimiento de líder está habilitado. Esto se debe a que, cuando se habilita el enrutamiento adaptado al líder, hay dos viajes de ida y vuelta entre regiones (beginTransaction y la solicitud commit) entre la aplicación cliente en la región que no es líder y el frontend de la API de Spanner en la región líder. Sin embargo, con el enrutamiento adaptado al líder inhabilitado, las escrituras sin lecturas solo requieren un viaje de ida y vuelta entre regiones para la solicitud commit (beginTransaction se procesa en el frontend de la API de Spanner local). Por ejemplo, si cargas datos de forma masiva en una tabla recién creada, es poco probable que las transacciones lean datos de la tabla. Si con frecuencia confirmas operaciones de escritura sin leerlas en tu aplicación, te recomendamos que inhabilites el enrutamiento con reconocimiento de líder. Para obtener más información, consulta Inhabilita el enrutamiento adaptado al líder.

Usa el enrutamiento con reconocimiento de líderes

El enrutamiento adaptado al líder está habilitado de forma predeterminada en las bibliotecas cliente de Spanner.

Te recomendamos que proceses tus solicitudes de lectura y escritura con el enrutamiento adaptado al líder habilitado. Puedes inhabilitarla para comparar las diferencias de rendimiento.

Enrutamiento con reconocimiento de líderes con particionamiento geográfico

Cuando usas la partición geográfica para particionar tu base de datos en varias ubicaciones de datos, Spanner evalúa todos los parámetros de configuración de instancias que usan las ubicaciones de tu base de datos, incluida la ubicación predeterminada, cuando enruta las solicitudes. Spanner selecciona un frontend de la API de Cloud Spanner ubicado en la región de ubicación más cercana al cliente. Esta selección es independiente de si esa posición o sus datos se utilizan en una transacción en particular. Spanner enruta las transacciones de lectura y escritura de la siguiente manera:

  • Con el enrutamiento adaptado al líder habilitado: Cada ubicación tiene su propia región líder (o región líder predeterminada para las configuraciones birregionales y multirregionales). Spanner enruta las transacciones de lectura y escritura al frontend de la API de Cloud Spanner en la región líder más cercana al cliente.
  • Con el enrutamiento adaptado al líder inhabilitado: Spanner enruta las transacciones de lectura y escritura al frontend de la API de Cloud Spanner en la región de entrega más cercana en todas las ubicaciones de tu base de datos.

Habilita el enrutamiento con reconocimiento de líder

Puedes usar las bibliotecas cliente de Spanner para habilitar el enrutamiento adaptado al líder de forma manual.

C++

Usa la estructura RouteToLeaderOption para configurar tu aplicación cliente con el enrutamiento adaptado al líder habilitado:

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#

Usa EnableLeaderRouting para configurar tu aplicación cliente con el enrutamiento adaptado al líder habilitado:

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

Go

Usa ClientConfig para configurar tu aplicación cliente con el enrutamiento adaptado al líder habilitado:

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

Usa SpannerOptions.Builder para configurar tu aplicación cliente con el enrutamiento adaptado al líder habilitado:

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

Node.js

Usa SpannerOptions para configurar tu aplicación cliente con el enrutamiento adaptado al líder habilitado:

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

PHP

Usa routeToLeader para configurar tu aplicación cliente con el enrutamiento adaptado al líder habilitado:

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

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

Python

Usa route_to_leader_enabled para configurar tu aplicación cliente con el enrutamiento adaptado al líder habilitado:

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

Ruby

Usa self.new para configurar tu aplicación cliente con el enrutamiento adaptado al líder habilitado:

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

Inhabilita el enrutamiento con reconocimiento de líderes

Puedes usar las bibliotecas cliente de Spanner para inhabilitar el enrutamiento basado en el líder.

C++

Usa la estructura RouteToLeaderOption para configurar tu aplicación cliente con el enrutamiento adaptado al líder inhabilitado:

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#

Usa EnableLeaderRouting para configurar tu aplicación cliente con el enrutamiento adaptado al líder inhabilitado:

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

Go

Usa ClientConfig para configurar tu aplicación cliente con el enrutamiento adaptado al líder inhabilitado:

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

Usa SpannerOptions.Builder para crear una conexión a una base de datos de Spanner con el enrutamiento basado en el líder inhabilitado:

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

Node.js

Usa SpannerOptions para configurar tu aplicación cliente con el enrutamiento adaptado al líder inhabilitado:

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

PHP

Usa routeToLeader para configurar tu aplicación cliente con el enrutamiento adaptado al líder inhabilitado:

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

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

Python

Usa route_to_leader_enabled para configurar tu aplicación cliente con el enrutamiento adaptado al líder inhabilitado:

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

Ruby

Usa self.new para configurar tu aplicación cliente con el enrutamiento adaptado al líder inhabilitado:

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

¿Qué sigue?