Avec CockroachDB version 21.1, un nouveau concept de « tables globales » a été introduit. Cette fonctionnalité convient parfaitement aux situations où la latence de lecture sur une table doit être très faible et la latence d’écriture peut être beaucoup plus élevée que la normale. [read: it needs to be fast when doing lookups, but we can tolerate lengthy writes]. Cela convient également lorsque les lectures doivent être à jour pour des raisons commerciales ou parce que la table est référencée par des clés étrangères ou lorsque les lectures critiques en matière de latence ne peuvent pas être liées à des régions spécifiques. Ainsi, l’utilisation de la fonctionnalité des tables globales est idéale pour tout type de table de référence, où nous voulons extraire les données très rapidement, mais nous pouvons gérer de longues insertions et mises à jour.
Avec les tables globales, les longues écritures font tout le travail préalable pour éviter toute contention et erreurs sérialisables que nous verrions traditionnellement. Lorsque nous lisons à partir de la table, tout le travail a déjà été fait pour éviter toute contention et nous pouvons accéder à la réplique la plus proche et lire à partir de celle-ci, comme si nous faisions une lecture de suiveur mais en temps réel.
Auparavant, ce même type de scénario était réalisé en utilisant des copies en double des index de couverture, où chaque copie de l’index était épinglée dans une région spécifique. Ensuite, les lectures de suiveurs pourraient être utilisées pour accélérer encore plus les recherches en dehors des index si l’obsolescence liée inhérente aux lectures de suiveurs pouvait être tolérée.
L’inconvénient, du moins avec les grandes entreprises clientes, est la nouvelle syntaxe. Avec la version 21.1, la nouvelle syntaxe multi-régions est déclarative. Vous spécifiez la région principale pour votre base de données ou votre table, vous spécifiez l’objectif de survie et vous définissez une table pour avoir une localité de global. Tout cela est beaucoup plus simple que l’ancienne syntaxe pour spécifier les configurations de zone. Mais si vous devez être précis et précis quant à l’endroit où vous placez les réplicas et les baux, comme dans les applications ayant des besoins commerciaux spécifiques ou parce que la disposition multirégionale du cluster n’est pas triviale, la spécificité de l’ancienne syntaxe est préférée.
Alors pourquoi n’utilisons-nous pas à la fois l’ancienne et la nouvelle syntaxe ? CRDB en interne va supposer que les choses ont été configurées en utilisant soit l’ancienne syntaxe, soit la nouvelle syntaxe. Et une fois que nous touchons à une configuration de zone avec l’ancienne syntaxe, nous ne pouvons pas être certains que la nouvelle syntaxe sera capable de prendre en compte toutes ces situations. Mais… nous pouvons utiliser la nouvelle syntaxe pour créer une table, puis l’inspecter avec notre ancien jeu de commandes et utiliser les nouvelles variables dans les configurations de zone.
Allumons un cluster de test et créons une table.
root@localhost:26257/defaultdb> create table postal_codes ( id int primary key, code string) locality global;
ERROR: cannot set LOCALITY on a table in a database that is not multi-region enabled
SQLSTATE: 42P16Bon, ça ne s’est pas passé comme prévu. Nous devons d’abord définir une région principale pour notre base de données.
root@localhost:26257/defaultdb> alter database defaultdb primary region "us-east1";
ALTER DATABASE PRIMARY REGION
Time: 94ms total (execution 93ms / network 0ms)
root@localhost:26257/defaultdb> create table postal_codes ( id int primary key, code string) locality global;
CREATE TABLE
Time: 23ms total (execution 23ms / network 0ms)Maintenant, si nous regardons la sortie de la table de création, nous voyons ce à quoi vous vous attendriez après avoir lu la documentation CRDB sur le sujet.
root@localhost:26257/defaultdb> show create table postal_codes;
table_name | create_statement
---------------+-------------------------------------------------
postal_codes | CREATE TABLE public.postal_codes (
| id INT8 NOT NULL,
| code STRING NULL,
| CONSTRAINT "primary" PRIMARY KEY (id ASC),
| FAMILY "primary" (id, code)
| ) LOCALITY GLOBAL
(1 row)
Time: 46ms total (execution 46ms / network 0ms)Les LOCALITY GLOBAL est l’élément clé là-dedans.
Mais que se passe-t-il si nous regardons la configuration de la zone ?
root@localhost:26257/defaultdb> show zone configuration for table postal_codes;
target | raw_config_sql
---------------------+-------------------------------------------------
TABLE postal_codes | ALTER TABLE postal_codes CONFIGURE ZONE USING
| range_min_bytes = 134217728,
| range_max_bytes = 536870912,
| gc.ttlseconds = 90000,
| global_reads = true,
| num_replicas = 3,
| num_voters = 3,
| constraints="{+region=us-east1: 1}",
| voter_constraints="[+region=us-east1]",
| lease_preferences="[[+region=us-east1]]"
(1 row)
Time: 17ms total (execution 17ms / network 0ms)Par rapport à 20.2 et aux versions précédentes, il y a quelques nouvelles variables ici. Plus précisément, les nouveaux éléments sont global_reads, num_voters, et le voter_constraints. Tous les autres éléments semblent familiers.
Donc, si ce nouveau concept de table globale est un ensemble de variables de configuration de zone… pourquoi ne les utilisons-nous pas dans nos configurations de zone traditionnelles ? Nous pouvons alors disposer de la nouvelle fonctionnalité et utiliser l’ancienne syntaxe pour les raisons évoquées précédemment. La mise en garde pour l’utilisation global_reads = true est qu’il faut aussi préciser une préférence de bail, et des contraintes (tant régulières que pour les votants). Et une fois que nous aurons utilisé l’ancienne syntaxe de configuration de zone, nous ne voudrons plus utiliser la nouvelle syntaxe déclarative pour la survie, les régions et les tables globales.
Dans l’exemple ci-dessus, où nous avons trois régions dans notre cluster à neuf nœuds, nous créons trois réplicas au total et les épinglons à us-east1 avec le titulaire du bail. Si nous prenons num_replicas et soustraire num_voters il nous reste le nombre de répliques non votantes dans le cluster (0 dans ce cas) dont les lectures de table globales tireront parti. Nous pouvons augmenter le nombre de réplicas à neuf, de sorte que nous aurons six réplicas sans droit de vote, et un réplica sera sur chaque nœud du cluster avec chacun des réplicas votants (ceux qui participent aux écritures basées sur le quorum) en nous -est1. Maintenant, avec neuf répliques, il y aura une copie de ces données à proximité de n’importe quel endroit où nous pourrions émettre une requête.
Si au lieu de cela nous devions définir num_replicas = 5 nous aurions alors les 3 répliques votantes dans us-east1 et une réplique non votante dans chacune des deux autres régions. Encore une fois, nous obtenons maintenant des recherches très rapides dans us-east1 (1 ms pour les recherches de points avec une indexation appropriée) et des recherches relativement rapides dans les deux autres régions (~ 14 ms pour les recherches de points avec une indexation appropriée si nous ne sommes pas connectés au nœud avec la réplique pour cette région et 1 ms si nous sommes connectés au nœud avec la réplique pour cette région).
Et avec cela, nous n’avons plus besoin d’utiliser notre ancienne technique consistant à créer des index de couverture en double et à spécifier dans quelle région chacun de ces index doit résider. Au lieu de cela, nous pouvons définir global_reads = true dans notre configuration de zone pour la table et utilisez la nouvelle fonctionnalité.