Cette page décrit le routage basé sur le leader dans Spanner et comment l'utiliser. Spanner utilise le routage optimisé vers la région responsable pour acheminer de manière dynamique les transactions en lecture-écriture dans les configurations d'instances birégionales et multirégionales afin de réduire la latence et d'améliorer les performances de votre base de données. Le routage basé sur le leader est activé par défaut.
Routage Spanner pour les transactions en lecture-écriture
Spanner réplique les données pour offrir une disponibilité et une localisation géographique supplémentaires. Dans les configurations d'instances birégionales et multirégionales de Spanner, une région de la configuration d'instance birégionale et multirégionale est 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 biré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 vers la région non principale. Par conséquent, les transactions en lecture/écriture validées à partir d'une région non principale nécessitent plusieurs allers-retours vers l'instance répliquée principale pour être validées.
Le routage basé sur le leader est un mécanisme qui améliore la latence des transactions en lecture-écriture en les routant de manière intelligente. Si le routage basé sur le leader est activé, même si l'écriture ne provient pas de la région leader, les requêtes de création de session sont acheminées vers la région leader pour aligner l'interface de l'API Spanner avec la région leader. Ce mécanisme de routage améliore la latence des transactions en lecture-écriture en réduisant à deux le nombre d'allers-retours réseau requis entre la région non leader (où se trouve l'application cliente) et la région leader.
Figure 1. Exemple de routage Spanner avec le routage basé sur le leader activé.
Si le routage basé sur le leader est désactivé, l'application cliente achemine d'abord la requête vers un service d'interface de l'API Spanner dans la région de l'application cliente (région non leader). Ensuite, à partir de l'interface de l'API Spanner 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 principale 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 basé sur le leader désactivé.
Cas d'utilisation
Grâce au routage basé sur le leader, les cas d'utilisation suivants bénéficient d'une latence plus faible :
- Mises à jour groupées : exécution d'importations Dataflow ou de modifications en arrière-plan (par exemple, des 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 initiant des écritures à partir de régions non leader.
- Application mondiale : 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 du 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 basé sur le leader est activé. En effet, lorsque le routage basé sur le leader est activé, il y a deux allers-retours interrégionaux (beginTransaction et la requête commit) entre l'application cliente dans la région non leader et l'interface de l'API Spanner dans la région leader. Toutefois, lorsque le routage basé sur le leader est désactivé, les écritures sans lecture ne nécessitent qu'un seul aller-retour interrégional pour la requête commit (beginTransaction est traité dans l'interface de l'API Spanner locale). Par exemple, si vous chargez des données de manière groupée dans une table nouvellement créée, il est peu probable que les transactions lisent les 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 basé sur le leader. Pour en savoir plus, consultez Désactiver le routage basé sur le leader.
Utiliser le routage basé sur le leader
Le routage basé sur le 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 basé sur le leader activé. Vous pouvez la désactiver pour comparer les différences de performances.
Routage basé sur le leader avec partitionnement géographique
Lorsque vous utilisez le partitionnement géographique pour partitionner votre base de données sur plusieurs emplacements de données, Spanner évalue toutes les configurations d'instance utilisées par les emplacements de votre base de données, y compris l'emplacement par défaut, lors du routage des requêtes. Spanner sélectionne une interface d'API Cloud Spanner colocalisée avec la région de placement la plus proche du client. Cette sélection est indépendante de l'utilisation de cet emplacement ou de ses données dans une transaction particulière. Spanner achemine les transactions en lecture-écriture comme suit :
- Avec le routage basé sur le leader activé : chaque emplacement possède sa propre région leader (ou région leader par défaut pour les configurations birégionales et multirégionales). Spanner achemine les transactions en lecture-écriture vers l'interface de l'API Cloud Spanner dans la région principale la plus proche du client.
- Avec le routage basé sur le leader désactivé : Spanner achemine les transactions en lecture-écriture vers l'interface de l'API Cloud Spanner dans la région de diffusion la plus proche de tous les emplacements de votre base de données.
Activer le routage basé sur le leader
Vous pouvez utiliser les bibliothèques clientes Spanner pour activer manuellement le routage basé sur le leader.
C++
Utilisez la structure RouteToLeaderOption pour configurer votre application cliente avec le routage basé sur le 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 basé sur le 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 basé sur le 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
Utilisez SpannerOptions.Builder pour configurer votre application cliente avec le routage basé sur le leader activé :
SpannerOptions options = SpannerOptions.newBuilder().enableLeaderAwareRouting.build();
Spanner spanner = options.getService();
String instance = "my-instance";
String database = "my-database";
Node.js
Utilisez SpannerOptions pour configurer votre application cliente avec le routage basé sur le leader 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 basé sur le leader activé :
// Instantiates a client with leader-aware routing enabled
use Google\Cloud\Spanner\SpannerClient;
$routeToLeader = true;
$spanner = new SpannerClient($routeToLeader);
Python
Utilisez route_to_leader_enabled pour configurer votre application cliente avec le routage basé sur le leader activé :
spanner_client = spanner.Client(
route_to_leader_enabled=true
)
instance = spanner_client.instance(instance_id)
database = instance.database(database_id)
Ruby
Utilisez self.new pour configurer votre application cliente avec le routage basé sur le leader 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 basé sur le leader
Vous pouvez utiliser les bibliothèques clientes Spanner pour désactiver le routage basé sur le leader.
C++
Utilisez la structure RouteToLeaderOption pour configurer votre application cliente avec le routage basé sur le 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#
Utilisez EnableLeaderRouting pour configurer votre application cliente avec le routage basé sur le leader désactivé :
// Create a client with leader-aware routing disabled.
SpannerConnectionStringBuilder builder = new
SpannerConnectionStringBuilder();
Builder.EnableLeaderRouting = false;
Go
Utilisez ClientConfig pour configurer votre application cliente avec le routage basé sur le leader désactivé :
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
Utilisez SpannerOptions.Builder pour créer une connexion à une base de données Spanner avec le routage basé sur le leader désactivé :
SpannerOptions options = SpannerOptions.newBuilder().disableLeaderAwareRouting.build();
Spanner spanner = options.getService();
String instance = "my-instance";
String database = "my-database";
Node.js
Utilisez SpannerOptions pour configurer votre application cliente avec le routage basé sur le leader désactivé :
// Instantiates a client with routeToLeaderEnabled disabled
const spanner = new Spanner({
projectId: projectId,
routeToLeaderEnabled: false;
});
PHP
Utilisez routeToLeader pour configurer votre application cliente avec le routage basé sur le leader désactivé :
// Instantiates a client with leader-aware routing disabled
use Google\Cloud\Spanner\SpannerClient;
$routeToLeader = false;
$spanner = new SpannerClient($routeToLeader);
Python
Utilisez route_to_leader_enabled pour configurer votre application cliente avec le routage basé sur le leader désactivé :
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 basé sur le 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
Étapes suivantes
- En savoir plus sur les configurations régionales, birégionales et multirégionales
- En savoir plus sur la réplication
- Découvrez comment modifier la région leader d'une base de données.