Cette page décrit le routage tenant compte du leader dans Spanner et son utilisation. Spanner utilise le routage optimisé vers la région responsable pour router dynamiquement les transactions en lecture-écriture dans les configurations d'instance birégionale et multirégionale afin de réduire la latence et d'améliorer les performances de votre base de données. Le routage basé sur les leaders est est activée par défaut.
Routage Spanner pour les transactions en lecture-écriture
Spanner réplique les données pour fournir une disponibilité et une localité géographique supplémentaires. Dans Spanner des configurations d'instances birégionales et multirégionales, une région dans la configuration d'instance birégionale et multirégionale désignée comme région principale et contient les instances répliquées principales de la base de données. Lorsque vous utilisez une configuration d'instance bi-régionale ou multirégionale et que votre client émet une transaction en lecture/écriture vers votre base de données à partir d'une région non principale, l'écriture est toujours traitée dans la région principale, puis renvoyée à la région non principale. Par conséquent, les transactions en lecture/écriture effectuées à partir d'une région non principale nécessitent plusieurs aller-retours vers l'instance dupliquée principale pour être validées.
Le routage basé sur les leaders est un mécanisme qui améliore la latence des opérations de lecture/écriture en les acheminant intelligemment. Si les dirigeants sont sensibles le routage est activé, même si l'écriture ne provient pas de la région principale, les requêtes de création de session sont acheminées vers la région principale Spanner Front End (SpanFE) avec la région principale. Ce routage améliore la latence des transactions en lecture/écriture en réduisant le nombre d'aller-retours réseau requis entre la région non principale (où le client où se trouve votre application) et la région principale sur 2.
Figure 1. Exemple de routage Spanner avec le routage tenant compte du leader activé.
Si le routage basé sur les leaders est désactivé, l'application cliente redirige d'abord la requête à un service SpanFE dans la région de l'application cliente (région non principale). Ensuite, à partir du SpanFE dans la région de l'application cliente, trois allers-retours ou plus sont effectués vers le serveur Spanner (SpanServer) dans la région leader pour valider l'écriture, ce qui augmente la latence. Ces allers-retours supplémentaires sont nécessaires pour prendre en charge les index secondaires, les vérifications de contraintes et la lecture de vos écritures.
Figure 2. Exemple de routage Spanner avec le routage tenant compte du leader désactivé.
Cas d'utilisation
En raison de l'utilisation du routage avec leader, les cas d'utilisation suivants bénéficient d'une latence réduite :
- Mises à jour groupées : exécution d'importations Dataflow ou d'exécution de modifications en arrière-plan (par exemple, LMD par lot) à partir d'une région non leader.
- Tolérance aux sinistres et disponibilité accrue : déploiement d'applications clientes dans les régions leader et non leader pour tolérer les pannes régionales tout en déclenchant des écritures à partir des régions non leader.
- Application globale : déploiement d'applications clientes à l'échelle mondiale avec des emplacements régionaux étendus qui valident les données.
Limites
Si votre application cliente est déployée en dehors de la région leader et que vous écrivez des valeurs sans lire les données ("écritures aveugles"), vous pouvez observer une régression de la latence si le routage tenant compte du leader est activé. En effet, lorsque le routage tenant compte du leader est activé, il existe deux aller-retour interrégionaux (beginTransaction
et la requête commit
) entre l'application cliente dans la région non leader et le SpanFE dans la région leader. Toutefois, avec le routage basé sur les responsables,
désactivée, les écritures sans lecture ne nécessitent qu'un aller-retour interrégional pour
Requête commit
(beginTransaction
est traité dans le délai local). Par exemple, si vous chargez des données de fichier de manière groupée dans une table nouvellement créée, il est peu probable que les transactions lisent des données de la table. Si vous effectuez fréquemment des opérations d'écriture sans les lire dans votre application, vous pouvez envisager de désactiver le routage tenant compte du leader. Pour en savoir plus, consultez
Désactivez le routage basé sur les responsables.
Utiliser le routage avec leader
Le routage tenant compte du leader est activé par défaut dans les bibliothèques clientes Spanner.
Nous vous recommandons de traiter vos requêtes en lecture-écriture avec le routage tenant compte du leader activé. Vous pouvez le désactiver pour comparer les différences de performances.
Activer le routage tenant compte du leader
Vous pouvez utiliser les bibliothèques clientes Spanner pour activer manuellement le routage tenant compte du leader.
C++
Utilisez la structure RouteToLeaderOption
pour configurer votre application cliente avec le routage tenant compte du leader activé :
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#
Utilisez EnableLeaderRouting
pour configurer votre application cliente avec le routage tenant compte du leader activé :
// Create a client with leader-aware routing enabled.
SpannerConnectionStringBuilder builder = new
SpannerConnectionStringBuilder();
Builder.EnableLeaderRouting = true;
Go
Utilisez ClientConfig
pour configurer votre application cliente avec le routage tenant compte du leader activé :
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
Utiliser SpannerOptions.Builder
pour configurer votre application cliente avec le routage basé sur les responsables activé:
SpannerOptions options = SpannerOptions.newBuilder().enableLeaderAwareRouting.build();
Spanner spanner = options.getService();
String instance = "my-instance";
String database = "my-database";
Node.js
Utiliser SpannerOptions
pour configurer votre application cliente avec le routage basé sur les responsables activé:
// Instantiates a client with routeToLeaderEnabled enabled
const spanner = new Spanner({
projectId: projectId,
routeToLeaderEnabled: true;
});
PHP
Utilisez routeToLeader
pour configurer votre application cliente avec le routage tenant compte du leader activé :
// Instantiates a client with leader-aware routing enabled
use Google\Cloud\Spanner\SpannerClient;
$routeToLeader = true;
$spanner = new SpannerClient($routeToLeader);
Python
Utiliser route_to_leader_enabled
pour configurer votre application cliente avec le routage basé sur les responsables activé:
spanner_client = spanner.Client(
route_to_leader_enabled=true
)
instance = spanner_client.instance(instance_id)
database = instance.database(database_id)
Ruby
Utiliser self.new
pour configurer votre application cliente avec le routage basé sur les responsables activé:
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
Désactiver le routage avec connaissance du leader
Vous pouvez utiliser les bibliothèques clientes Spanner pour désactiver la détection des leaders le routage.
C++
Utilisez la structure RouteToLeaderOption
pour configurer votre application cliente avec le routage tenant compte du leader désactivé :
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#
Utiliser EnableLeaderRouting
pour configurer votre application cliente en désactivant le routage basé sur les responsables:
// Create a client with leader-aware routing disabled.
SpannerConnectionStringBuilder builder = new
SpannerConnectionStringBuilder();
Builder.EnableLeaderRouting = false;
Go
Utiliser ClientConfig
pour configurer votre application cliente en désactivant le routage basé sur les responsables:
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
Utiliser SpannerOptions.Builder
pour créer une connexion à une base de données Spanner avec une variante optimale
le routage compatible est désactivé:
SpannerOptions options = SpannerOptions.newBuilder().disableLeaderAwareRouting.build();
Spanner spanner = options.getService();
String instance = "my-instance";
String database = "my-database";
Node.js
Utiliser SpannerOptions
pour configurer votre application cliente en désactivant le routage basé sur les responsables:
// Instantiates a client with routeToLeaderEnabled disabled
const spanner = new Spanner({
projectId: projectId,
routeToLeaderEnabled: false;
});
PHP
Utiliser routeToLeader
pour configurer votre application cliente en désactivant le routage basé sur les responsables:
// Instantiates a client with leader-aware routing disabled
use Google\Cloud\Spanner\SpannerClient;
$routeToLeader = false;
$spanner = new SpannerClient($routeToLeader);
Python
Utiliser route_to_leader_enabled
pour configurer votre application cliente en désactivant le routage basé sur les responsables:
spanner_client = spanner.Client(
route_to_leader_enabled=false
)
instance = spanner_client.instance(instance_id)
database = instance.database(database_id)
Ruby
Utilisez self.new
pour configurer votre application cliente avec le routage tenant compte du leader désactivé :
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
Étape suivante
- Découvrez les configurations régionales, birégionales et multirégionales.
- En savoir plus sur la réplication
- Découvrez comment modifier la région principale d'une base de données.