L'architecture distribuée de Spanner vous permet de concevoir votre schéma de manière à éviter les hotspots, c'est-à-dire les situations où un trop grand nombre de requêtes sont envoyées au même serveur, ce qui sature ses ressources et peut entraîner des latences élevées.
La présente page décrit les bonnes pratiques relatives à la conception de vos schémas afin d'éviter de créer des hotspots. Pour éviter les hotspots, vous pouvez ajuster la conception du schéma afin de permettre à Spanner de diviser et de distribuer les données sur plusieurs serveurs. La distribution des données sur les serveurs permet à votre base de données Spanner de fonctionner efficacement, en particulier lors de l'insertion groupée de données.
Choisir une clé primaire en évitant de créer des hotspots
Comme indiqué dans la section Schéma et modèle de données, vous devez faire attention lorsque vous choisissez une clé primaire dans la conception du schéma afin de ne pas créer de hotspots par inadvertance dans votre base de données. Les hotspots peuvent être engendrés par une colonne dont la valeur change de manière monotone en tant que premier élément de clé, car dans ce cas, toutes les insertions se produisent à la fin de votre espace clé. Ce phénomène n'est pas souhaitable, car Spanner utilise des plages de clés pour diviser les données entre les serveurs, ce qui signifie que toutes vos insertions sont dirigées vers un seul serveur qui finit par faire tout le travail.
Par exemple, supposons que vous souhaitiez conserver une colonne d'horodatage du dernier accès sur des lignes de la table UserAccessLog. La définition de table suivante utilise une clé primaire basée sur un horodatage comme premier élément de clé. Nous vous déconseillons cette approche si le taux d'insertion de la table est élevé:
GoogleSQL
CREATE TABLE UserAccessLogs ( LastAccess TIMESTAMP NOT NULL, UserId STRING(1024), ... ) PRIMARY KEY (LastAccess, UserId);
PostgreSQL
CREATE TABLE useraccesslog ( lastaccess timestamptz NOT NULL, userid text, ... PRIMARY KEY (lastaccess, userid) );
Le problème est le suivant : 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 Spanner reçoit toutes les écritures, ce qui le surcharge.
Le schéma suivant illustre ce problème:
La table UserAccessLog précédente comprend cinq exemples de lignes de données, qui représentent cinq utilisateurs différents effectuant une action d'utilisateur quelconque à environ une milliseconde d'intervalle. Le schéma indique également l'ordre dans lequel Spanner insère les lignes (les flèches étiquetées indiquent l'ordre des écritures pour chaque ligne). Les insertions étant classées par horodatage et la valeur de l'horodatage ne cessant d'augmenter, Spanner ajoute toujours les insertions à la fin du tableau et les dirige vers la même division. (Comme indiqué dans la section Schéma et modèle de données, une division est un ensemble de lignes provenant d'une ou de plusieurs tables liées que Spanner stocke par ordre de clé de ligne.)
Cela pose problème, car Spanner attribue des tâches à différents serveurs sous forme d'unités de divisions. Le serveur affecté à cette division finit par gérer toutes les requêtes d'insertion. À mesure que la fréquence des événements d'accès utilisateur augmente, la fréquence des requêtes d'insertion adressées au serveur correspondant augmente aussi. Le serveur risque alors de se transformer en point d'accès, et ressemble à l'encadré rouge et à l'arrière-plan de l'image précédente. Dans cette illustration simplifiée, chaque serveur traite une division au maximum, mais Spanner peut attribuer à chaque serveur plusieurs divisions.
Lorsque Spanner ajoute des lignes à la table, la division augmente et lorsqu'elle atteint environ 8 Go, Spanner crée une autre division, comme décrit dans la section Répartition basée sur la charge. Spanner ajoute les nouvelles lignes suivantes à cette nouvelle division, et le serveur attribué à la division devient le nouveau point d'accès potentiel.
En présence de hotspots, vous remarquerez peut-être que les insertions prennent du temps et que d'autres tâches sur le même serveur ralentissent. La modification de l'ordre de la colonne LastAccess par ordre croissant ne résout pas ce problème, car toutes les écritures sont insérées en haut de la table, et toutes les insertions sont donc envoyées à un seul serveur.
Bonne pratique de conception de schéma n° 1 : Ne choisissez pas une colonne dont la valeur augmente ou diminue de façon linéaire en tant que premier élément clé d'une table à taux d'écriture élevé.
Utiliser un identifiant unique universel (UUID)
Vous pouvez utiliser en tant que clé primaire un identifiant unique universel (UUID) défini par la RFC 4122. Nous vous recommandons d'utiliser la version 4 de l'UUID, car elle utilise des valeurs aléatoires dans la séquence de bits. Nous ne recommandons pas les UUID de la version 1, car ils stockent l'horodatage dans les bits d'ordre supérieur.
Il existe plusieurs façons de stocker l'UUID en tant que clé primaire :
- Dans une colonne
STRING(36) - Dans une paire de colonnes
INT64 - Dans une colonne
BYTES(16)
Pour une colonne STRING(36), vous pouvez utiliser la fonction GENERATE_UUID() Spanner (GoogleSQL ou PostgreSQL) comme valeur par défaut de la colonne pour que Spanner génère automatiquement des valeurs UUID.
Par exemple, pour le tableau suivant:
GoogleSQL
CREATE TABLE UserAccessLogs (
LogEntryId STRING(36) NOT NULL,
LastAccess TIMESTAMP NOT NULL,
UserId STRING(1024),
...
) PRIMARY KEY (LogEntryId, LastAccess, UserId);
PostgreSQL
CREATE TABLE useraccesslog (
logentryid VARCHAR(36) NOT NULL,
lastaccess timestamptz NOT NULL,
userid text,
...
PRIMARY KEY (lastaccess, userid)
);
Vous pouvez insérer GENERATE_UUID() pour générer les valeurs LogEntryId.
GENERATE_UUID() génère une valeur STRING. Par conséquent, la colonne LogEntryId doit utiliser le type STRING pour GoogleSQL ou le type text pour PostgreSQL.
GoogleSQL
INSERT INTO
UserAccessLog (LogEntryId, LastAccess, UserId)
VALUES
(GENERATE_UUID(), '2016-01-25 10:10:10.555555-05:00', 'TomSmith');
PostgreSQL
INSERT INTO
useraccesslog (logentryid, lastaccess, userid)
VALUES
(spanner.generate_uuid(),'2016-01-25 10:10:10.555555-05:00', 'TomSmith');
L'utilisation d'UUID présente néanmoins quelques inconvénients :
- Ils sont plutôt volumineux et utilisent 16 octets, voire plus. Les autres options de clés primaires ne consomment pas autant d'espace de stockage.
- Ils n'indiquent aucune information sur l'enregistrement. Par exemple, contrairement à l'UUID, la clé primaire des identifiants
SingerIdetAlbumIdrevêt une signification inhérente. - Vous perdez les données de localité des enregistrements liés. C'est la raison pour laquelle l'utilisation d'un UUID élimine les hotspots.
Inverser les bits des valeurs séquentielles
Vous devez vous assurer que les clés primaires numériques (INT64 dans GoogleSQL ou bigint dans PostgreSQL) ne sont pas séquentiellement croissantes ou décroissantes. Les clés primaires séquentielles peuvent créer des hotspots à grande échelle. Pour éviter ce problème, vous pouvez inverser les bits des valeurs séquentielles, en veillant à répartir les valeurs de clé primaire de manière uniforme sur l'espace de clés.
Spanner prend en charge la séquence par bit inversé, qui génère des valeurs entières uniques par bit inversé. Vous pouvez utiliser une séquence dans le premier (ou seul) composant d'une clé primaire pour éviter les problèmes de point d'accès. Pour en savoir plus, consultez la section Séquence inversée.
Permuter l'ordre des clés
Une manière de répartir les écritures sur l'espace clé de manière plus uniforme consiste à permuter l'ordre des clés de sorte que la colonne contenant la valeur monotone ne constitue pas la première partie de clé:
GoogleSQL
CREATE TABLE UserAccessLog ( UserId INT64 NOT NULL, LastAccess TIMESTAMP NOT NULL, ... ) PRIMARY KEY (UserId, LastAccess);
PostgreSQL
CREATE TABLE useraccesslog ( userid bigint NOT NULL, lastaccess TIMESTAMPTZ NOT NULL, ... PRIMARY KEY (UserId, LastAccess) );
Dans ce schéma modifié, les insertions sont désormais triées en priorité par UserId, plutôt que par horodatage de dernier accès chronologique. Ce schéma répartit les écritures entre différentes divisions, car il est peu probable qu'un seul utilisateur produise des milliers d'événements par seconde.
L'image suivante montre les cinq lignes de la table UserAccessLog que Spanner trie avec UserId au lieu de l'horodatage d'accès:
Ici, Spanner divise les données UserAccessLog en trois partitions, chacune contenant environ un millier de lignes de valeurs UserId ordonnées. Il s'agit d'une estimation raisonnable de la façon dont les données utilisateur peuvent être divisées, en supposant que chaque ligne contienne environ 1 Mo de données utilisateur et une taille de division maximale d'environ 8 Go. Même si les événements utilisateur se sont produits à environ une milliseconde d'intervalle, chaque événement a été déclenché par un utilisateur différent. Par conséquent, l'ordre des insertions est beaucoup moins susceptible de créer un hotspot que l'ordre des horodatages.
Consultez également les bonnes pratiques associées au classement des clés par horodatage.
Hacher la clé unique et répartir les écritures sur des segments logiques
Une autre technique courante de répartition de la charge sur plusieurs serveurs consiste à créer une colonne contenant le hachage de la clé unique réelle, puis à utiliser la colonne de hachage (ou la colonne de hachage et les colonnes de clé unique) comme clé primaire. Ce procédé permet d'éviter la création de hotspots, car les nouvelles lignes sont réparties sur l'espace clé de manière plus uniforme.
La valeur de hachage peut vous permettre de créer des segments logiques, ou partitions, dans votre base de données. Dans une base de données physiquement segmentée, les lignes sont réparties sur plusieurs serveurs de base de données. Dans une base de données segmentée de manière logique, les données de la table définissent les segments. Par exemple, pour répartir les écritures dans la table UserAccessLog sur N segments logiques, vous pouvez ajouter une colonne de clé ShardId en début de table :
GoogleSQL
CREATE TABLE UserAccessLog ( ShardId INT64 NOT NULL, LastAccess TIMESTAMP NOT NULL, UserId INT64 NOT NULL, ... ) PRIMARY KEY (ShardId, LastAccess, UserId);
PostgreSQL
CREATE TABLE useraccesslog ( shardid bigint NOT NULL, lastaccess TIMESTAMPTZ NOT NULL, userid bigint NOT NULL, ... PRIMARY KEY (shardid, lastaccess, userid) );
Pour calculer la valeur ShardId, hachez une combinaison des colonnes de clé primaire, puis calculez le modulo N du hachage. Exemple :
GoogleSQL
ShardId = hash(LastAccess and UserId) % N
La fonction de hachage et la combinaison de colonnes que vous choisissez déterminent la répartition de vos lignes dans l'espace de clés. Spanner crée ensuite des divisions de lignes pour optimiser les performances.
Le schéma suivant montre comment l'utilisation d'un hachage pour créer trois segments logiques permet de répartir le débit d'écriture de manière plus uniforme entre les serveurs:
Ici, la table UserAccessLog est classée par ShardId, cette valeur étant calculée comme une fonction de hachage des colonnes de clé. Les cinq lignes UserAccessLog sont divisées en trois segments logiques, chacun d'entre eux appartenant à une division différente. Les insertions sont réparties uniformément entre les divisions, ce qui équilibre le débit d'écriture entre les trois serveurs qui gèrent les divisions.
Spanner vous permet également de créer une fonction de hachage dans une colonne générée.
Pour ce faire dans GoogleSQL, utilisez la fonction FARM_FINGERPRINT au moment de l'écriture, comme illustré dans l'exemple suivant:
GoogleSQL
CREATE TABLE UserAccessLog (
ShardId INT64 NOT NULL
AS (MOD(FARM_FINGERPRINT(CAST(LastAccess AS STRING)), 2048)) STORED,
LastAccess TIMESTAMP NOT NULL,
UserId INT64 NOT NULL,
) PRIMARY KEY (ShardId, LastAccess, UserId);
La fonction de hachage que vous choisissez détermine la qualité de la répartition de vos insertions sur la plage de clés. Bien qu'un hachage de chiffrement ne soit pas nécessaire, il peut s'avérer utile. Lorsque vous choisissez une fonction de hachage, vous devez prendre en compte les facteurs suivants:
- Évitement des points d'accès. Une fonction qui génère davantage de valeurs de hachage a tendance à réduire les hotspots.
- Efficacité de la lecture. Moins il y a de valeurs de hachage à analyser, plus les lectures de l'ensemble des valeurs de hachage sont rapides.
- Nombre de nœuds.
Utiliser l'ordre décroissant pour les clés basées sur l'horodatage
Si vous disposez d'une table pour l'historique qui utilise l'horodatage comme clé, envisagez de classer les colonnes de clé par ordre décroissant si l'un des scénarios suivants s'applique à votre situation:
- Si vous souhaitez lire l'historique le plus récent, vous utilisez une table entrelacée pour l'historique et vous lisez la ligne parente. Dans ce cas, avec une colonne d'horodatage
DESC, les dernières entrées d'historique sont stockées à côté de la ligne parente. Sinon, la lecture de la ligne parente et de son historique récent nécessitera une recherche intermédiaire afin d'ignorer l'historique plus ancien. - Vous lisez des entrées séquentielles dans l'ordre chronologique inverse et ne savez pas exactement combien d'entrées vous devez parcourir : vous pouvez par exemple exécuter une requête SQL avec une valeur
LIMITpour obtenir les N événements les plus récents, ou planifier l'annulation de la lecture une fois que vous avez lu un certain nombre de lignes. Dans les deux cas, vous souhaiterez commencer par les entrées les plus récentes et lire séquentiellement les plus anciennes jusqu'à ce que votre condition soit remplie. Spanner s'avère plus efficace pour cette tâche lorsqu'il exploite des clés d'horodatage stockées dans l'ordre décroissant.
Ajoutez le mot clé DESC pour classer les clés d'horodatage dans l'ordre décroissant. Exemple :
GoogleSQL
CREATE TABLE UserAccessLog ( UserId INT64 NOT NULL, LastAccess TIMESTAMP NOT NULL, ... ) PRIMARY KEY (UserId, LastAccess DESC);
Bonne pratique de conception de schéma n° 2: L'ordre décroissant ou croissant dépend des requêtes des utilisateurs (par exemple, les résultats les plus récents ou les plus anciens sont affichés en haut).
Utiliser un index entrelacé sur une colonne dont la valeur augmente ou diminue de façon linéaire
Comme pour l'exemple de clé primaire précédent que vous devez éviter, il est également déconseillé de créer des index non entrelacés sur des colonnes dont les valeurs augmentent ou diminuent de manière linéaire, même s'il ne s'agit pas de colonnes de clé primaire.
Par exemple, imaginons que vous définissiez la table suivante, dans laquelle LastAccess correspond à une colonne de clé non primaire :
GoogleSQL
CREATE TABLE Users ( UserId INT64 NOT NULL, LastAccess TIMESTAMP, ... ) PRIMARY KEY (UserId);
PostgreSQL
CREATE TABLE Users ( userid bigint NOT NULL, lastaccess TIMESTAMPTZ, ... PRIMARY KEY (userid) );
Cela peut paraître utile de définir un index sur la colonne LastAccess pour interroger rapidement la base de données sur les accès d'utilisateur "depuis la période X", comme ceci :
GoogleSQL
CREATE NULL_FILTERED INDEX UsersByLastAccess ON Users(LastAccess);
PostgreSQL
CREATE INDEX usersbylastaccess ON users(lastaccess) WHERE lastaccess IS NOT NULL;
Cette action aboutit néanmoins au même problème que celui décrit dans la bonne pratique précédente, car Spanner implémente les index sous forme de tables en arrière-plan, et la table d'index qui en résulte utilise une colonne dont la valeur augmente de façon linéaire en tant que premier élément de clé.
Vous pouvez toutefois créer un index entrelacé comme celui-ci, car les lignes d'index entrelacés sont entrelacées dans les lignes parent correspondantes, et il est peu probable qu'une ligne parent unique génère des milliers d'événements par seconde.
Bonne pratique de conception de schéma n° 3: Ne créez pas d'index non entrelacé sur une colonne à taux d'écriture élevé dont la valeur augmente ou diminue de façon linéaire. Au lieu d'utiliser des index entrelacés, utilisez des techniques comme celles que vous utiliseriez pour la conception de la clé primaire de la table de base lorsque vous concevez des colonnes d'index (par exemple, ajoutez "shardId").
Étape suivante
- Consultez des exemples de conception de schémas.
- Découvrez le chargement groupé de données.