Le document traite de Google Spanner, une base de données géodistribuée, et de son architecture ainsi que de ses fonctionnalités, en soulignant son rôle dans la gestion des données à l'échelle mondiale. Il décrit les défis auxquels font face les bases de données traditionnelles et comment Google Spanner répond à ces besoins en offrant une architecture résiliente, consistante et scalable garantissant les propriétés ACID. En outre, il aborde les transactions, la conception des bases de données et les bonnes pratiques pour optimiser les requêtes dans Spanner.

1. Google Spanner
Une base géodistribuée
1 03/2020: Google Spanner: une base géodistribuée

2. A la conquête du monde
2 03/2020: Google Spanner: à la conquête du monde

3.  Du début des années 1970 à l’an 2000, c’est le règne des bases relationnelles
avec deux grands leaders dans le temps, DB2 d’IBM, puis Oracle Database.
 Pour répondre aux nouveaux besoins, on étend le SQL ( SQL étendu à l’OLAP,
support du XML ) et on ajoute de nouvelles briques ( ajout d’une JVM pour le
développement en Java )
 Pour profiter de la puissance exponentielle des machines, on crée des clusters de
plus en plus grands ( qqes dizaines de nœuds ), des clusters répartis sur
plusieurs sites en utilisant de la fibre noire ou des appliances du style Exadata si
on recherche plus une archi verticale.
 Mais subsiste un défi, comment répartir les clusters à travers les continents et
aller au-delà du transfert de fichiers ou d’un système de réplication souvent posé
en maître-esclave pour éviter les conflits de réplication ? Comment réaliser des
applications mondiales résilientes, consistantes et scalables ?
Historique & Enjeux
3 03/2020: Google Spanner: historique & enjeux

4.  Des projets débutent au cours des années 2000 pour atteindre cet objectif. Les
deux plus représentatifs bénéficiant de la puissance financière du cloud sont
Cosmos de Microsoft et Spanner de Google.
 J’ai choisi d’étudier Spanner car je connais l’environnement GCP. Mais Cosmos
est aussi très intéressant, je pense par exemple à la possibilité d’instancier
plusieurs modèles de données ( clé-valeur, colonne, document, graphe),
Spanner étant très SQL dans son approche.
 On peut citer aussi Cockroach DB et YugaByte DB dans la famille des bases
géodistribuées
 A mon avis, il s’agit de la vraie avancée technologique en terme de bases de
données des 20 dernières années, les bases NoSql ayant plutôt pour objectif de
mieux répondre à certains usages ( bases document, bases graphe, … ) ou de
délaisser l’ACID pour être plus performant en terme de concurrence d’accès
Historique & Enjeux
4 03/2020: Google Spanner: historique & enjeux

5. Architecture
5 03/2020: Google Spanner: architecture

6.  Deux types d’architecture: une architecture régionale et une architecture multi-
régionale
 Un système de réplication au cœur du moteur, un système de fichiers distribués
composé d’instances dupliquées
 Un système de réplication synchrone basé sur Paxos
 Une instance dupliquée est constituée d’un ensemble de partitions, un ensemble
de lignes d’une table.
 Trois types d’instance dupliquée: instance en lecture/écriture, instance en
lecture et instance témoin
 Il existe une instance dupliquée principale, le pivot pour l’écriture des données.
Un point de contention possible à grande échelle ?
Les majeurs
6 03/2020: Google Spanner: les majeurs

7. Région
Architecture régionale
7 03/2020: Google Spanner: architecture régionale
Zone 1
1 instance dupliquée principale en
lecture/écriture
Stockage
1 à n nœuds de type compute
CPU + RAM
Zone 2
1 instance dupliquée en
lecture/écriture
Stockage
1 à n nœuds de type compute
CPU + RAM
Zone 3
1 instance dupliquée en
lecture/écriture
Stockage
1 à n nœuds de type compute
CPU + RAM

8. Architecture régionale
8 03/2020: Google Spanner: architecture régionale

9. Architecture multi-régionale
9 03/2020: Google Spanner: architecture multi-régionale
Zone 1
Région 1
Région 3
Zone 2
1 instance dupliquée principale en
lecture/écriture
1 à n nœuds de type compute
Zone 1
Région 2
Zone 2
1 instance dupliquée en
lecture/écriture
1 à n nœuds de type compute
Zone 1
1 instance dupliquée témoin
1 noeud de type compute
Région 4Zone 1
1 instance dupliquée en lecture
1 à n nœuds de type compute
1 instance dupliquée principale en
lecture/écriture
1 à n nœuds de type compute
1 instance dupliquée en
lecture/écriture
1 à n nœuds de type compute

10. Configurations disponibles
10 03/2020: Google Spanner: configuration multi-régionale

11. ACID
11 03/2020: Google Spanner: ACID

12.  Les bases NoSqL (https://db-engines.com/en/ ) ont mis de côté l’ACID pour
gagner en performance, en particulier pour les mises à jour. Elles se reposent sur
CAP ( Consistency, Availability, Partition Tolerance ) en assurant deux de ses
propriétés suivant la nature de la base.
 Les bases géodistribuées ont pour objectif de revenir à l’ACID sans renier la
performance et cela à l’échelle mondiale.
 L’ACID recouvre quatres propriétés:
 A = Atomicity : une transaction, une séquence d’opérations ( lecture, mise à jour ) délimitée
par un début et une fin s’exécute totalement ou non.
 C = Consistency : une transaction part d’un point valide de la base de données ( commit à
l’instant t ) et l’amène à un autre point valide de la base de données ( commit à l’instant t’ ).
Pour ce faire, elle respecte les règles définies dans la base de données ( contraintes, triggers,
cascade, … )
 I = Isolation : une transaction ne peut pas être impactée par d’autres transactions
s’exécutant en même temps, les données qu’elle utilise ne peuvent pas être écrasées par une
autre transaction
 D = Durability : une transaction validée ne peut plus être perdue même si une ou plusieurs
instances s’arrêtent pour une raison matérielle ou logicielle
 Pour la consistance, il y a encore débat, vous pourrez trouver des variantes,
mais elle ne garantit pas que la transaction délivre le résultat souhaité
Présentation d’ACID
12 03/2020: Google Spanner: présentation ACID

13.  Une transaction est un ensemble de lectures et d'écritures qui s'exécutent de
manière atomique à un moment logique unique dans des colonnes, des lignes et
des tables d'une base de données.
 Deux modes de transaction ACID:
 Une transaction en lecture-écriture pour les mises à jour
 Une transaction en lecture pour conserver une vue cohérente des données
 Une lecture peut être effectuée sans utiliser le mode transactionnel. On distingue
deux types de lecture:
 Une lecture forte pour obtenir la dernière valeur d’une donnée
 Une lecture non actualisée pour obtenir une valeur du passé
 Deux principaux types de verrous:
 Verrou de type partagé pour les lectures
 Verrou de type exclusif ou de type auteur partagé pour les écritures
 Granularité: ligne et colonne
Les transactions dans Spanner
13 03/2020: Google Spanner: Transactions

14. Lecture forte
14 03/2020: Google Spanner: lecture forte

15. Lecture forte
15 003/2020: Google Spanner: lecture forte

16. Lecture dans le passé
16 03/2020: Google Spanner: lecture dans le passé

17. Transaction sans two-phase commit
17 03/2020: Google Spanner: transaction sans two-phase commit

18. Transaction avec two-phase commit
18 03/2020: Google Spanner: transaction avec two-phase commit

19. Transaction avec two-phase commit
19
03/2020: Google Spanner: transaction avec two-phase commit

20. Transaction avec two-phase commit
20
03/2020: Google Spanner: transaction avec two-phase commit

21.  Un deadlock est un état ou plusieurs transactions se bloquent mutuellement sur
plusieurs ressources.
 Dans Spanner, le blocage potentiel de plusieurs transactions est détecté et
provoque l'abandon de toutes les transactions sauf une. Par exemple,
considérons le scénario suivant : la transaction Txn1 maintient un verrou sur
l'enregistrement A et attend un verrou sur l'enregistrement B, tandis que Txn2
maintient un verrou sur l'enregistrement B et attend un verrou sur
l'enregistrement A. Le seul moyen d'avancer dans cette situation consiste à
annuler l'une des transactions pour qu'elle procède au déverrouillage,
permettant ainsi à l'autre transaction de progresser.
 La priorité est donnée aux transactions plus anciennes, on ainsi la garantie que
chaque transaction a la possibilité d'obtenir un verrou, une fois que leur
ancienneté est devenue suffisante pour leur donner une priorité plus élevée par
rapport aux autres transactions. Par exemple, une transaction qui obtient un
verrou partagé pour le lecteur peut être annulée par une transaction plus
ancienne nécessitant un verrou partagé pour l'auteur.
Le mécanisme de deadlock
21 03/2020: Google Spanner: deadlock

22.  Pour les mises à jour à grande échelle ( UPDATE et DELETE ), il existe des
transactions partitionnées dont le but est de dépasser les limites des
transactions classiques et de ne pas verrouiller une table entière
 La table est découpée en partitions et pour chaque partition, on dédie une transaction en lecture-
écriture
 Une seule instruction en LMD partitionné peut être exécutée en une seule fois
 Si une instruction en LMD partitionné échoue ou est annulée, les partitions déjà exécutées ne sont
pas restaurées, cela n’arrête que les partitions en cours d’exécution et les partitions en attente ne
sont pas démarrées
 Une instruction en LMD partitionné ne traite pas les INSERT
 Une transaction classique ne dépasse pas 20 000 mutations. L’unité d’une
mutation n’est pas facile à identifier, mais on peut approximativement la définir
comme une modification sur une colonne.
Les grandes transactions: LMD Partitionné
22 03/2020: Google Spanner: LMD partitionné

23. Conception des bdd
23 03/2020: Google Spanner: conception des bdd

24.  Les tables entrelaçées permettent de regrouper des données physiquement dans
une partition ou division commune. Cela permet d’optimiser la lecture des
données, on parle de clustering de données.
 Exemple:
Les tables entrelaçées
24 03/2020: Google spanner: les tables entrelaçées
CREATE TABLE Singers (
SingerId INT64 NOT NULL,
FirstName STRING(1024),
LastName STRING(1024),
SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);
CREATE TABLE Albums (
SingerId INT64 NOT NULL,
AlbumId INT64 NOT NULL,
AlbumTitle STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

25. Les tables entrelaçées
25 03/2020: Google Spanner: disposition physique
Pour répartir la charge de lecture sur plusieurs nœuds, la partition Singers(1) est placée sur un nœud 1 et
la partition Singers(2) sur un nœud 2.

26. Hotspot à l’insertion des données
26 03/2020: Google Spanner: hotspot insertion
Les lignes sont écrites dans cette table dans l'ordre d'horodatage de dernier accès, et comme les
horodatages de dernier accès ne cessent d'augmenter, ils sont toujours écrits à la fin de la table. La
création du hotspot est due au fait qu'un seul serveur Cloud Spanner va recevoir toutes les écritures, ce qui
le surchargera.
Quelques solutions:
- Permuter l’ordre des clés
- Créer une première colonne de hachage
- Utiliser un identifiant unique universel ( UUID )

27.  Un index est créé par défaut pour la clé primaire.
 Un index est une table.
 Un index secondaire est utile pour accélérer certaines recherches.
 Un index secondaire contient les éléments suivants:
 Les colonnes de la clé primaire
 Les colonnes décrites dans l’index
 Les colonnes spécifiées dans la clause facultative STORING
 Un index peut être entrelaçé.
 Dans une requête, il peut être utile de préciser l’index à utiliser dans le plan
d’exécution si ce dernier ne le choisit pas par défaut => FROM
MyTable@{FORCE_INDEX=MyTableIndex}
 Exemples
 CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName)
 CREATE INDEX SongsBySingerSongName ON Songs(SingerId, SongName),
INTERLEAVE IN Singers
Les index secondaires
27 03/2020: Google Spanner: les index secondaires

28. Optimisation des requêtes
28 03/2020: Google Spanner: optimisation des requêtes

29.  Utiliser des paramètres pour accélérer les requêtes fréquemment exécutées
 Réduit les coûts de compilation de la requête
 Evite une attaque par injection SQL
 Attention, dans certains cas, peut être contre-productif. A tester, mais une répartition des valeurs non
uniforme sur une ou plusieurs colonnes pourrait obliger à un retour à des constantes
 Utiliser des index secondaires pour accélérer les requêtes courantes
 Optimiser la recherche par plage de clés
 Utiliser UNNEST pour les listes de valeurs non adjacentes
 Utiliser BETWEEN pour les listes de valeurs adjacentes
 Choisir la bonne jointure et n’hésiter pas à utiliser des hints si pb de
performance, l’optimiseur étant jeune et le système ayant l’air d’être un système
full scan en mode parallèle
 La directive de jointure @{FORCE_JOIN_ORDER=TRUE} indique à Cloud Spanner d'utiliser l'ordre de
jointure spécifié dans la requête
 Utiliser le hint @{JOIN_TYPE=HASH_JOIN} si à gauche de la jointure, vous avez une table de petite
taille
 Éviter les opérations de lecture de grande taille dans les transactions en lecture-
écriture
 Un lock de type exclusif est posé sur les données lues
Bonnes pratiques SQL
29 03/2020: Google Spanner: bonnes pratiques SQL

30.  Utiliser ORDER BY pour garantir l’ordre du résultat de votre requête
 Utiliser STARTS_WITH au lieu de LIKE pour accélérer les requêtes SQL
paramétrées
 Cloud Spanner n'évalue pas les modèles LIKE paramétrés avant l'exécution, il doit lire toutes les
lignes et les évaluer par rapport à l'expression afin d'exclure celles qui ne correspondent pas
 Il peut être aussi utile d’ajouter un index sur la colonne de recherche
Bonnes pratiques SQL
30 03/2020: Google Spanner: bonnes pratiques SQL

31. Plan d’exécution: jointure non distribuée
31 03/2020: Google Spanner: jointure non distribuée
Requête: update all_sessions_index t1
set channelGrouping = ( select channelGrouping
from all_sessions
where fullVisitorId = t1.fullVisitorId )
where id = 1

32. Plan d’exécution: utilisation d’un index
32 03/2020: Google Spanner: index

33. Plan d’exécution: jointure distribuée
33 03/2020: Google Spanner: jointure distribuée

34. Demo
34 03/2020: Google Spanner: demo

35.  Une base Big Query: https://console.cloud.google.com/bigquery?p=data-to-
insights&page=ecommerce
 Création d’une instance Spanner à 1 ou n noeuds
 Import de tables dans une instance Spanner via Dataflow
 Un exemple de TP: https://codelabs.developers.google.com/codelabs/datasme-cloud-
spanner-01/index.html?index=..%2F..index#0
Environnement
35 03/2020: Goggle Spanner: environnement de la démo

36. Configuration import table
36 03/2020: configuration import table

37. Chargement Dataflow sans limite de nœuds à 1 CPU
37 03/2020: Google Spanner: chargement dataflow

38. Ressources du chargement au pic
38 03/2020: Google Spanner: ressources du chargement

39. CPU
Monitoring du nœud Spanner
Nb d’opérations
par seconde
Débit ( MB/s ) Latence ( ms )
39 03/2020: Google Spanner: monitoring du nœud Spanner

40. Chargement dataflow avec 4 nœuds à 16 CPU
40 03/2020: Google Spanner: charegemnt Dataflow

41. Ressources du chargement au pic
41 03/2020: Google Spanner: ressources du chargement

42. Monitoring des 3 nœuds Spanner
42 03/2020: Google Spanner: monitoring des 3 nœuds Spanner
CPU Nb d’opérations
par seconde

43. Monitoring des 3 nœuds Spanner
43 03/2020: Google Spanner: monitoring des 3 nœuds Spanner
Débit ( MB/s ) Latence ( ms )

44. Spanner: chargement à 6 et 9 noeuds
44 03/2020: Google Spanner: limites

45. Limite par transaction
45 03/2020: Google Spanner: Limite par transaction
 Une instruction LMD est limitée à 20 000 mutations. Une mutation est
approximativement une modification sur une colonne.
 Pour aller au-delà, on peut utiliser gcloud ou une bibliothèque cliente … mais
uniquement pour l’update et le delete => utilisation d’une LMD partitionnée
 Pour l’insertion, il faut ruser avec cette limite des 20 000 mutations.

46. Une mutation ~ une mise à jour de colonne
46 03/2020: Google Spanner: mutation
Remarque: pas d’index sur la table cible, all_sessions_index

47. LMD partitionnée
47 03/2020: Google Spanner: LMD partitionnée
 Une instruction LMD partitionnée ne s’applique qu’à des requêtes update et
delete
 Une requête update imbriquée n’est pas traitée par une instruction LMD
partitionnée

48. Bibliographie
48 03/2020: Google Spanner: Bibliographie

49.  Google concepts: https://cloud.google.com/spanner/docs/concepts
 Cloud Spanner on YouTube:
https://www.youtube.com/user/googlecloudplatform/search?query=spanner
 Optimizing Applications, Schemas, and Query Design on Cloud Spanner (Cloud
Next ‘18): https://www.youtube.com/watch?v=DxrdatA_ULk
 How Cloud Spanner operates and how it guarantees external consistency on
reads and writes: https://www.youtube.com/watch?v=QPpSzxs_8bc
 Cloud Spanner Ticketshop Demo:
https://github.com/GoogleCloudPlatform/cloudspanner-ticketshop-demo
 Exemple de migration: https://cloud.google.com/solutions/migrating-oracle-to-
cloud-spanner
Pour aller plus loin
49 03/2020: Google Spanner: bibliographie

50.  CAP: https://en.wikipedia.org/wiki/CAP_theorem
 PAXOS: https://en.wikipedia.org/wiki/Paxos_(computer_science)
 ACID: https://en.wikipedia.org/wiki/ACID
 Two phase-commit: https://en.wikipedia.org/wiki/Two-phase_commit_protocol
 Desiging Data-Intensive Applications, Martin Kleppmann
Pour aller plus loin
50 03/2020: Google Spanner: bibliographie