Présentation des schémas

Cette page traite des exigences concernant les schémas Spanner et de leur utilisation. pour créer des relations hiérarchiques et des caractéristiques de schéma. Elle présente également entrelacées, ce qui peut améliorer les performances des requêtes lors de l'interrogation de tables dans une relation parent-enfant.

Un schéma est un espace de noms qui contient des objets de base de données, tels que des tables, des vues, des index et des fonctions. Vous organisez les objets à l'aide de schémas et appliquez un contrôle des accès ultraprécis les privilèges et d'éviter les conflits au niveau des noms. Vous devez définir un schéma pour chaque dans Spanner.

Vous pouvez également segmenter et stocker davantage les lignes de votre tableau de base de données sur dans différentes zones géographiques. Pour en savoir plus, consultez les Présentation du partitionnement géographique

Données fortement typées

Dans Spanner, les données sont fortement typées. Les types de données incluent les données scalaires et complexes décrits dans la section Types de données dans GoogleSQL. et les types de données PostgreSQL.

Choisissez une clé primaire.

Les bases de données Spanner peuvent contenir une ou plusieurs tables. Les tableaux sont structurés sous forme de lignes et de colonnes. Le schéma de la table définit une ou plusieurs colonnes de table comme clé primaire de la table, qui identifie chaque ligne de manière unique. Les clés primaires sont toujours indexé pour une recherche rapide des lignes. Si vous souhaitez mettre à jour ou supprimer lignes d'une table, celle-ci doit avoir une clé primaire. Une table sans adresse principale les colonnes de clé ne peuvent comporter qu'une seule ligne. Seules les bases de données utilisant le dialecte GoogleSQL peuvent contenir sans clé primaire.

Bien souvent, votre application dispose déjà d'un champ qui convient naturellement à l'utilisation clé primaire. Par exemple, pour une table Customers, il peut y avoir CustomerId fourni par l'application qui sert de clé primaire. Dans d'autres vous devrez peut-être générer une clé primaire lors de l'insertion de la ligne. Ce correspond généralement à un nombre entier unique sans importance pour l'entreprise (une clé primaire de substitution).

Dans tous les cas, lors du choix de votre clé primaire, veillez à ne pas créer de hotspots. Par exemple, si vous insérez des données dont la clé est un nombre entier augmentant de manière monotone, les insertions se feront toujours à la fin de l'espace clé. Ce n'est pas souhaitable, car Spanner répartit les données entre serveurs par plages de clés, ce qui signifie que vos insertions seront dirigées vers une seule ce qui crée un point d'accès. Il existe des techniques pouvant répartir la charge sur plusieurs serveurs et éviter la création de hotspots. Les voici :

• Hacher la clé et la stocker dans une colonne. Utilisez la colonne de hachage (ou la colonne de hachage et les colonnes de clé unique). ensemble) comme clé primaire.
• Échanger l'ordre des colonnes dans la clé primaire.
• Utiliser un identifiant unique universel (UUID). Version 4 L'UUID est recommandé, car il utilise des valeurs aléatoires dans les bits de poids fort. N'utilisez pas d'algorithme d'UUID (tel que UUID version 1) qui stocke l'horodatage dans les bits de poids fort.
• Utiliser des valeurs séquentielles de bits inversés.

Relations de table parents-enfants

Il existe deux façons de définir des relations parent-enfant dans Spanner: l'entrelacement de tables et les clés étrangères.

L'entrelacement de tables de Spanner convient les relations parent-enfant. Avec l'entrelacement, Spanner permet physiquement coloc les lignes enfants avec les lignes parentes dans l'espace de stockage. La colocalisation peut considérablement améliorer les performances. Par exemple, si vous disposez d'une table Customers et d'une Invoices, et votre application récupère fréquemment toutes les factures d'une client, vous pouvez définir Invoices comme table enfant entrelacée de Customers Ce faisant, vous déclarez une relation de localité des données entre deux tables indépendantes. Vous indiquez à Spanner pour stocker une ou plusieurs lignes de Invoices avec une ligne Customers.

Pour associer une table enfant à une table parente, utilisez un LDD qui déclare le la table enfant comme entrelacée dans la table parente, et en incluant la table parente clé primaire comme première partie de la clé primaire composite de la table enfant. Pour plus des informations sur l'entrelacement, consultez la section Créer des tables entrelacées plus loin dans ce .

Les clés étrangères constituent une solution parent-enfant plus générale et répondent à des cas d'utilisation supplémentaires. Elles ne sont pas limitées aux colonnes de clé primaire, et les tables peuvent posséder plusieurs relations de clés étrangères en faisant office de tables parentes dans certaines relations et de tables enfants dans d'autres. Toutefois, une relation de clé étrangère n'implique pas la colocation des tables dans la couche de stockage.

Google vous recommande de représenter les relations parents-enfants soit comme des tables entrelacées, soit comme des clés étrangères, mais pas les deux. Pour en savoir plus sur étrangères et leur comparaison avec les tables entrelacées, consultez la section Clés étrangères présentation.

Clés primaires dans les tables entrelacées

Pour l'entrelacement, chaque table doit avoir une clé primaire. Si vous déclarez une table pour être un enfant entrelacé d'une autre table, la table doit avoir un élément composite qui inclut tous les composants de la clé primaire du parent, dans le même ordre et, généralement, une ou plusieurs colonnes de table enfants supplémentaires.

Spanner stocke les lignes dans l'ordre de tri par valeur de clé primaire, avec lignes enfants insérées entre les lignes parent. Voir une illustration de lignes entrelacées consultez la section Créer des tables entrelacées plus loin sur cette page.

En résumé, Spanner peut cohéberger physiquement des lignes de tables associées. La Des exemples de schéma montrent à quoi ressemble cette disposition physique.

Divisions de base de données

Vous pouvez définir des hiérarchies de relations parent-enfant entrelacées jusqu'à sept ce qui signifie que vous pouvez cohéberger les lignes de sept tables indépendantes. Si la taille des données dans vos tables est petite, un seul service Spanner peut probablement gérer votre base de données. Mais que se passe-t-il lorsque vos applications tables augmentent et commencent à atteindre les limites de ressources d'un serveur individuel ? Spanner est une base de données distribuée. En d'autres termes, de votre base de données, Spanner divise vos données en fragments appelés les fractionnements. Les divisions sont indépendantes les unes des autres et peuvent être affectées à différents serveurs pouvant être situés dans différents emplacements physiques. A "split" contient une plage de lignes contiguës. Les clés de début et de fin de cette plage sont appelées "limites de division". Spanner ajoute et supprime automatiquement les limites de division en fonction de la taille et de la charge, ce qui modifie le nombre de divisions dans la base de données.

Répartition basée sur la charge

Voici un exemple de la façon dont Spanner effectue une répartition basée sur la charge atténuer les problèmes de hotspots de lecture, supposons que votre base de données contient une table avec 10 lignes sont lues plus fréquemment que toutes les autres lignes de la table. Spanner peut ajouter des limites de division entre chacune de ces 10 lignes afin de qu'ils sont tous gérés par un serveur différent, au lieu de permettre les lectures de ces lignes pour consommer les ressources d'un seul serveur.

En règle générale, si vous suivez les bonnes pratiques pour la conception de schémas, Spanner peut limiter les hotspots de sorte que le débit en lecture doit s'améliorer toutes les deux ou trois minutes, jusqu'à ce que les ressources soient saturées ou qu'il n'est pas possible d'ajouter de nouvelles limites de division un fractionnement ne couvre qu'une seule ligne, sans enfants entrelacés).

Schémas nommés

Les schémas nommés vous aident à organiser des données similaires. Vous pouvez ainsi rapidement trouver des objets dans la console Google Cloud, appliquer des droits et éviter de nommer les collisions.

Les schémas nommés, comme les autres objets de base de données, sont gérés à l'aide du LDD.

Les schémas nommés Spanner vous permettent d'utiliser des noms complets pour rechercher des données. Les noms de domaine complets vous permettent de combiner le nom du schéma et le pour identifier les objets de base de données. Par exemple, vous pouvez créer un schéma appelé warehouse pour l'unité commerciale de l'entrepôt. Les tables qui utilisent cette schéma peut inclure: product, order et customer information. Ou vous pourrait créer un schéma appelé fulfillment pour l'unité commerciale de traitement. Ce schéma peut également comporter des tables appelées product, order et customer information. Dans le premier exemple, le nom de domaine complet est warehouse.product. Dans deuxième exemple, le nom de domaine complet est fulfillment.product. Cela évite toute confusion dans situations où plusieurs objets portent le même nom.

Dans le LDD CREATE SCHEMA, les objets de table reçoivent à la fois un nom de domaine complet (par exemple, sales.customers et un nom court, par exemple sales.

Les objets de base de données suivants sont compatibles avec les schémas nommés:

• TABLE
  • CREATE
  • INTERLEAVE IN [PARENT]
  • FOREIGN KEY
  • SYNONYM
• VIEW
• INDEX
• FOREIGN KEY
• SEQUENCE

Pour en savoir plus sur l'utilisation des schémas nommés, consultez la section Gérer les noms de données.

Utiliser un contrôle des accès ultraprécis avec des schémas nommés

Les schémas nommés vous permettent d'accorder un accès au niveau du schéma à chaque objet du schéma. Cela s'applique aux objets de schéma qui existent au moment où vous accordez l'accès. Vous devez accorder l'accès aux objets qui seront ajoutés ultérieurement.

Un contrôle des accès ultraprécis limite l'accès à des groupes entiers d'objets de base de données, tableaux, colonnes et lignes du tableau.

Pour en savoir plus, consultez la section Accorder des droits de contrôle des accès précis aux de données.

Exemples de schéma

Les exemples de schéma de cette section montrent comment créer des tables parentes et enfants avec et sans entrelacement et illustrer les dispositions physiques correspondantes des données.

Créer une table parente

Supposons que vous créiez une application musicale et que vous ayez besoin d'une table qui stocke lignes de données sur les chanteurs:

Notez que la table contient une colonne de clé primaire, SingerId, qui apparaît à gauche de la ligne en gras, et que les tableaux sont organisés par lignes et colonnes.

Vous pouvez définir la table avec le LDD suivant:

GoogleSQL

CREATE TABLE Singers (
SingerId   INT64 NOT NULL,
FirstName  STRING(1024),
LastName   STRING(1024),
SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);

PostgreSQL

CREATE TABLE singers (
singer_id   BIGINT PRIMARY KEY,
first_name  VARCHAR(1024),
last_name   VARCHAR(1024),
singer_info BYTEA
);

Veuillez noter ce qui suit à propos de l'exemple de schéma :

• Singers est une table située à la racine de la hiérarchie de la base de données (car elle n'est pas défini comme un enfant entrelacé d'une autre table).
• Pour les bases de données utilisant le dialecte GoogleSQL, les colonnes de clé primaire sont généralement annotées avec NOT NULL. (bien que vous puissiez omettre cette annotation si vous souhaitez autoriser les valeurs NULL dans des colonnes de clé. Pour en savoir plus, consultez la section Clé colonnes).
• Les colonnes qui ne sont pas incluses dans la clé primaire sont appelées colonnes "non clés" et peuvent comporter l'annotation facultative NOT NULL.
• Les colonnes qui utilisent le type STRING ou BYTES dans GoogleSQL doivent être défini avec une longueur, qui représente le nombre maximal d'unités Unicode ; qui peuvent être stockés dans le champ. La spécification de longueur est facultatif pour les champs PostgreSQL varchar et character varying de données. Pour en savoir plus, consultez la page Types de données scalaires. pour les bases de données de dialecte GoogleSQL et les données PostgreSQL pour les bases de données de dialecte PostgreSQL.

À quoi ressemble la disposition physique des lignes dans la table Singers ? La Le schéma suivant montre les lignes de la table Singers stockées par clé primaire ("Singers(1)", puis "Singers(2)", où le nombre entre parenthèses est la valeur de la clé primaire.

Le schéma précédent montre un exemple de limite de division entre les lignes constituées par Singers(3) et Singers(4), avec les données des divisions obtenues sont attribuées à différents serveurs. À mesure que cette table s'agrandit, il est possible que des lignes de Singers à stocker dans des emplacements différents.

Créer des tables parents et enfants

Supposons que vous souhaitiez maintenant ajouter des données de base sur les albums de chaque chanteur à l'application musicale.

Notez que la clé primaire de la table Albums est composée de deux colonnes : SingerId et AlbumId, pour associer chaque album à son chanteur. L'exemple de schéma suivant Définit les tables Albums et Singers à la racine de la base de données ce qui en fait des tables sœurs.

-- Schema hierarchy:
-- + Singers (sibling table of Albums)
-- + Albums (sibling table of Singers)

GoogleSQL

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);

PostgreSQL

CREATE TABLE singers (
singer_id   BIGINT PRIMARY KEY,
first_name  VARCHAR(1024),
last_name   VARCHAR(1024),
singer_info BYTEA
);

CREATE TABLE albums (
singer_id     BIGINT,
album_id      BIGINT,
album_title   VARCHAR,
PRIMARY KEY (singer_id, album_id)
);

La disposition physique des lignes de Singers et Albums se présente comme suit : dans le schéma suivant, les lignes de la table Albums étant stockées par des instances principales contiguës puis les lignes de Singers stockées par clé primaire contiguë:

Remarque importante concernant le schéma : Spanner ne suppose les relations de localité des données entre les tables Singers et Albums, car ce sont des tables racines. À mesure que la base de données s'agrandit, Spanner peut ajouter des limites de division entre les lignes. Cela signifie que les lignes du Albums peut se retrouver dans une division différente des lignes de la table Singers, et les deux divisions pourraient évoluer indépendamment l'une de l'autre.

En fonction des besoins de votre application, il peut s'avérer judicieux de permettre aux données de la table Albums d'être placées dans des divisions différentes de celles où se trouvent les données de la table Singers. Toutefois, cela peut entraîner une perte de performances, en raison de la nécessité de coordonner les lectures et les mises à jour différentes ressources. Si votre application doit fréquemment récupérer des informations concernant tous les albums d'un chanteur en particulier, vous devez créer Albums en tant que une table enfant entrelacée de Singers, qui rapproche les lignes des deux les tableaux avec la dimension de clé primaire. L'exemple suivant explique ce point plus en détail dans les moindres détails.

Créer des tables entrelacées

Une table entrelacée est une table que vous déclarez comme étant un enfant entrelacé de une autre table, car vous souhaitez que les lignes de la table enfant soient physiquement stockée avec la ligne parent associée. Comme indiqué précédemment, la table parente La clé primaire doit être la première partie de la clé primaire composite de la table enfant.

Lors de la conception de votre application musicale, supposons que vous réalisiez que l'application doit accéder fréquemment aux lignes de la table Albums lorsqu'elle accède à une Singers ligne. Par exemple, lorsque vous accédez à la ligne Singers(1), vous avez également besoin pour accéder aux lignes Albums(1, 1) et Albums(1, 2). Dans ce cas, Singers et Albums doivent avoir une forte relation en termes de localité des données. Vous pouvez déclarer cette relation de localité des données en créant Albums en tant qu'enfant entrelacé tableau de Singers.

-- Schema hierarchy:
-- + Singers
--   + Albums (interleaved table, child table of Singers)

La ligne en gras dans le schéma suivant montre comment créer Albums en tant que table entrelacée de Singers.

GoogleSQL

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;

PostgreSQL

CREATE TABLE singers (
 singer_id   BIGINT PRIMARY KEY,
 first_name  VARCHAR(1024),
 last_name   VARCHAR(1024),
 singer_info BYTEA
 );

CREATE TABLE albums (
 singer_id     BIGINT,
 album_id      BIGINT,
 album_title   VARCHAR,
 PRIMARY KEY (singer_id, album_id)
 )
 INTERLEAVE IN PARENT singers ON DELETE CASCADE;

Remarques sur ce schéma :

• SingerId, qui est la première partie de la clé primaire de la table enfant Albums est également la clé primaire de sa table parente Singers.
• ON DELETE CASCADE indique que lorsqu'une ligne de la table parente est supprimée, son et les lignes enfants sont automatiquement supprimées. Si une table enfant ne contient pas ou si l'annotation est ON DELETE NO ACTION, vous devez supprimer les lignes enfants avant de pouvoir supprimer la ligne parent.
• Les lignes entrelacées sont d'abord triées par ligne de la table parente, puis par les lignes contiguës de la table enfant qui partagent la clé primaire du parent. Pour Exemple : "Singers(1)", "Albums(1, 1)", puis "Albums(1, 2)".
• La relation de localité des données de chaque chanteur et les données de leur album conservées en cas de division de la base de données, à condition que la taille d'une ligne Singers et ses Albums lignes restent en dessous de la limite de taille de fractionnement et qu'il existe aucune zone cliquable sur ces lignes Albums.
• La ligne parent doit exister pour que vous puissiez insérer des lignes enfants. Ligne parent peut déjà exister dans la base de données ou être insérée avant la des lignes enfants dans la même transaction.

Créer une hiérarchie de tables entrelacées

La relation parent-enfant entre les tables Singers et Albums peut être étendue à davantage de tables descendantes. Par exemple, vous pouvez créer une table entrelacée appelée Songs en tant qu'enfant de la table Albums pour stocker la liste des pistes de chaque album.

Songs doit avoir une clé primaire qui inclut toutes les clés primaires des tables qui se trouvent à un niveau supérieur dans la hiérarchie, c'est-à-dire SingerId et AlbumId.

-- Schema hierarchy:
-- + Singers
--   + Albums (interleaved table, child table of Singers)
--     + Songs (interleaved table, child table of Albums)

GoogleSQL

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;

CREATE TABLE Songs (
 SingerId     INT64 NOT NULL,
 AlbumId      INT64 NOT NULL,
 TrackId      INT64 NOT NULL,
 SongName     STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId, TrackId),
 INTERLEAVE IN PARENT Albums ON DELETE CASCADE;

PostgreSQL

CREATE TABLE singers (
 singer_id   BIGINT PRIMARY KEY,
 first_name  VARCHAR(1024),
 last_name   VARCHAR(1024),
 singer_info BYTEA
 );

CREATE TABLE albums (
 singer_id     BIGINT,
 album_id      BIGINT,
 album_title   VARCHAR,
 PRIMARY KEY (singer_id, album_id)
 )
 INTERLEAVE IN PARENT singers ON DELETE CASCADE;

CREATE TABLE songs (
 singer_id     BIGINT,
 album_id      BIGINT,
 track_id      BIGINT,
 song_name     VARCHAR,
 PRIMARY KEY (singer_id, album_id, track_id)
 )
 INTERLEAVE IN PARENT albums ON DELETE CASCADE;

Le schéma suivant représente une vue physique des lignes entrelacées.

Dans cet exemple, à mesure que le nombre de chanteurs augmente, Spanner ajoute les limites entre les chanteurs afin de préserver la localité des données entre un chanteur et ses des albums et des chansons. Toutefois, si la taille d'une ligne "Singer" et de ses lignes enfants dépasse la limite de taille de fractionnement, ou une zone cliquable est détectée dans les lignes enfants, Spanner tente d'ajouter des limites de division pour isoler ce hotspot. ligne ainsi que toutes les lignes enfants situées en dessous.

En résumé, une table parent, et toutes ses tables enfants et descendantes, forment une hiérarchie de tables dans le schéma. Bien que chaque table de la hiérarchie sont logiquement indépendantes et les entrelacent physiquement de cette façon pour améliorer les performances, en préjoignant efficacement les tables et en vous permettant d'accéder les lignes associées tout en réduisant au maximum les accès à l'espace de stockage.

Jointures avec des tables entrelacées

Si possible, joignez des données dans des tables entrelacées par clé primaire. Étant donné que chaque une ligne entrelacée est généralement stockée physiquement dans la même division que sa ligne parente Spanner peut effectuer des jointures par clé primaire localement, ce qui réduit l'accès au stockage et le trafic réseau. Dans l'exemple suivant, Singers et Les Albums sont jointes sur la clé primaire SingerId.

GoogleSQL

SELECT s.FirstName, a.AlbumTitle
FROM Singers AS s JOIN Albums AS a ON s.SingerId = a.SingerId;

PostgreSQL

SELECT s.first_name, a.album_title
FROM singers AS s JOIN albums AS a ON s.singer_id = a.singer_id;

Colonnes de clé

Cette section inclut quelques remarques sur les colonnes clés.

Modifier les clés d'une table

Les clés d'une table ne peuvent pas changer ; vous ne pouvez ni ajouter, ni supprimer une colonne de clé dans une table existante.

Stocker les valeurs NULL dans une clé primaire

Dans GoogleSQL, si vous souhaitez stocker NULL dans une colonne de clé primaire, omettez la clause NOT NULL pour cette colonne dans le schéma. (Les bases de données de dialecte PostgreSQL ne accepter les valeurs NULL dans une colonne de clé primaire.)

Voici un exemple d'omission de la clause NOT NULL dans la colonne de clé primaire SingerId. Comme SingerId est la clé primaire, il ne peut y avoir que une ligne qui stocke NULL dans cette colonne.

CREATE TABLE Singers (
  SingerId   INT64,
  FirstName  STRING(1024),
  LastName   STRING(1024),
) PRIMARY KEY (SingerId);

La propriété pouvant accepter la valeur Null de la colonne de clé primaire doit correspondre aux déclarations des tables parents et enfants. Dans cet exemple, NOT NULL pour la colonne Albums.SingerId n'est pas autorisé, car Singers.SingerId l'omet.

CREATE TABLE Singers (
  SingerId   INT64,
  FirstName  STRING(1024),
  LastName   STRING(1024),
) 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;

Types non autorisés

Les colonnes suivantes ne peuvent pas être de type ARRAY:

• Les colonnes de clé d'une table
• Les colonnes de clé d'un index

Concevoir pour l'architecture mutualisée

Vous voudrez peut-être mettre en œuvre l'architecture mutualisée si vous stockez des données appartenant à différents clients. Par exemple, un service de musique peut vouloir stocker chaque le contenu d'une maison de disques individuelle.

Architecture mutualisée classique

La méthode classique pour concevoir une architecture mutualisée consiste à créer une base de données distincte pour chaque client. Dans cet exemple, chaque base de données possède sa propre table Singers :

Base de données 1 : Ackworth Records

SingerId	FirstName	LastName
1	Marc	Richards
2	Catalina	Smith

Base de données 2 : Cama Records

SingerId	FirstName	LastName
1	Alice	Trentor
2	Gabriel	Wright

Base de données 3 : Eagan Records

SingerId	FirstName	LastName
1	Benjamin	Martinez
2	Hannah	Harris

Architecture mutualisée gérée par schéma

Une autre façon de concevoir une architecture mutualisée dans Spanner consiste à avoir tous clients dans une seule table d'une base de données unique, et d'utiliser un autre nom pour chaque client. Par exemple, vous pouvez inclure une clé CustomerId. dans vos tableaux. Si vous définissez CustomerId comme première colonne de clé, les données de chaque client ont une bonne localité. Spanner peuvent alors utiliser efficacement les divisions de base de données pour maximiser en fonction de la taille des données et des modèles de charge. Dans l'exemple suivant, il existe une seule table Singers pour tous les clients:

Base de données d'architecture mutualisée Spanner

CustomerId	SingerId	FirstName	LastName
1	1	Marc	Richards
1	2	Catalina	Smith
2	1	Alice	Trentor
2	2	Gabriel	Wright
3	1	Benjamin	Martinez
3	2	Hannah	Harris

Si vous devez avoir des bases de données distinctes pour chaque locataire, vous devez au sujet de:

• Le nombre de bases de données par instance est limité. et le nombre de tables et d'index par base de données. En fonction du nombre de clients, il n'est pas toujours possible d'avoir des bases de données ou des tables séparées.
• L'ajout de nouvelles tables et d'index non entrelacés peut prendre du temps heure. Vous n'êtes peut-être pas atteindre les performances souhaitées si la conception de votre schéma dépend en ajoutant des tables et des index.

Si vous souhaitez créer des bases de données séparées, il sera peut-être plus efficace de répartir vos tables sur plusieurs bases de données de sorte que chaque base de données subisse peu de modifications de schéma par semaine.

Si vous créez des tables et des index distincts pour chaque client de votre application, ne placez pas toutes les tables et tous les index dans la même base de données. Divisez plutôt sur plusieurs bases de données, afin d'atténuer les performances les problèmes de création d'un grand nombre d'index.

Pour en savoir plus sur les autres modèles de gestion des données et la conception d'applications pour pour l'architecture mutualisée, consultez la section Implémentation de l'architecture mutualisée Spanner