Ce document décrit des stratégies permettant de migrer des clés primaires de vos tables de base de données vers Spanner afin d'éviter les probl��mes de hotspotting. Un hotspot est une concentration d'opérations sur un seul n��ud, qui réduit le débit en écriture à la capacité du nœud au lieu de bénéficier de l'équilibrage de charge de toutes les écritures sur les nœuds Spanner. L'utilisation de colonnes qui augmentent ou diminuent de manière monotone en tant que première partie de votre clé primaire (par exemple, des séquences ou des horodatages réguliers) est la cause la plus courante de hotspots.
Stratégies générales
Dans Spanner, chaque table devant stocker plusieurs lignes doit posséder une clé primaire composée d'une ou de plusieurs colonnes de la table. La clé primaire de votre table identifie de manière unique chaque ligne d'une table, et Spanner utilise la clé primaire pour trier les lignes de la table. Spanner étant hautement distribué, vous pouvez utiliser les techniques suivantes pour générer des valeurs de clé primaire uniques et réduire le risque de hotspots:
- Utilisez une fonctionnalité de clé générée automatiquement compatible avec Spanner et compatible avec Spanner (pour en savoir plus, consultez la section Migrer des cl��s générées automatiquement) :
- Utilisez la fonction
GENERATE_UUID()
(GoogleSQL, PostgreSQL) pour générer des valeurs d'identifiant unique universel (UUID version 4) avec le type de donnéesSTRING(36)
. La RFC 4122 définit le format de l'UUID version 4. - Utilisez une séquence positive inversée sur les bits (GoogleSQL, PostgreSQL). Une telle séquence génère des valeurs positives avec des bits de poids fort déjà inversés, de sorte qu'ils sont répartis uniformément sur l'espace numérique positif de 64 bits.
- Utilisez la fonction
- Permutez l'ordre des clés pour que la colonne contenant la valeur qui augmente ou diminue de manière monotone ne constitue pas la première partie de clé.
- Hachez la clé unique et répartissez les écritures sur des segments logiques en créant une colonne contenant le hachage de la clé unique, puis en utilisant la colonne de hachage (ou la colonne de hachage et les colonnes de clé unique ensemble) comme clé primaire. Cette approche permet d’éviter les hotspots, car les nouvelles lignes sont réparties de manière plus uniforme dans l’espace de clés.
Une fois que vous avez désigné la clé primaire de votre table, vous ne pouvez plus la modifier sans supprimer et recréer la table. Pour en savoir plus sur la manière de désigner votre clé primaire, consultez la section Schéma et modèle de données – clés primaires.
Voici un exemple d'instruction LDD qui crée une table pour une base de données de pistes musicales:
GoogleSQL
CREATE TABLE Singers ( SingerId INT64 NOT NULL, FirstName STRING(1024), LastName STRING(1024), SingerInfo BYTES(MAX), BirthDate DATE, ) PRIMARY KEY(SingerId);
PostgreSQL
CREATE TABLE Singers ( SingerId bigint NOT NULL, FirstName varchar(1024), LastName varchar(1024), SingerInfo bytea, BirthDate date, PRIMARY KEY(SingerId) );
Migrer des clés générées automatiquement
Cette section décrit les stratégies et les exemples pour les scénarios suivants dans lesquels la table source utilise déjà une fonctionnalité clé générée automatiquement:
- Migration depuis une table source qui utilise une clé primaire UUID.
- Migration depuis une table source qui utilise une clé d'entier séquentielle générée automatiquement. Les exemples incluent, sans s'y limiter, les séquences (prises en charge par diverses bases de données), les colonnes
IDENTITY
(compatibles avec différentes bases de données), les types de donnéesSERIAL
PostgreSQL et l'attribut de colonneAUTO_INCREMENT
MySQL. - Migration à partir d'une table source qui utilise une clé inversée sur les bits. Peut-être que la base de données source est Spanner, dans laquelle vous créez des valeurs de clé à l'aide du guide Inverser les bits des valeurs séquentielles.
Il est important de noter que dans toutes les stratégies, Spanner ne modifie pas les données qu'il migre à partir d'une base de données source. Vous ne changez que la méthode pour générer de nouvelles données.
Migrer les colonnes de clé UUID
Si votre table source utilise une colonne UUID, vous pouvez la convertir du type STRING, mettre les valeurs en minuscules conformément à la spécification RFC 4122 et utiliser la fonction GENERATE_UUID()
(GoogleSQL, PostgreSQL) comme valeur par défaut de la colonne. Exemple :
GoogleSQL
CREATE TABLE UserAccessLog ( UserId STRING(36) DEFAULT (GENERATE_UUID()), ... ) PRIMARY KEY (UserId);
PostgreSQL
CREATE TABLE UserAccessLog ( UserId varchar(36) DEFAULT SPANNER.GENERATE_UUID(), ... PRIMARY KEY (UserId) );
Migrer des colonnes de clés séquentielles
Si votre système de base de données source génère des valeurs séquentielles pour une colonne de clé, vous pouvez utiliser une séquence positive inversée (GoogleSQL, PostgreSQL) dans votre schéma Spanner pour générer des valeurs réparties équitablement entre les nombres entiers positifs de 64 bits. Pour empêcher la séquence Spanner de générer une valeur qui chevauche une valeur migrée, vous pouvez définir une plage ignorée. Par exemple, vous pouvez ignorer la plage de 1 à 4 294 967 296 (2^32) pour les deux séquences suivantes, si vous savez que la base de données source ne génère que des entiers 32 bits:
GoogleSQL
CREATE SEQUENCE MyFirstSequence OPTIONS ( sequence_kind = "bit_reversed_positive", skip_range_min = 1, skip_range_max = 4294967296 ); ALTER SEQUENCE MySecondSequence SET OPTIONS ( skip_range_min = 1, skip_range_max = 4294967296 );
PostgreSQL
CREATE SEQUENCE MyFirstSequence BIT_REVERSED_POSITIVE SKIP RANGE 1 4294967296; ALTER SEQUENCE MySecondSequence SKIP RANGE 1 4294967296;
Migrer des colonnes de clé avec inversion des bits
Si vous avez déjà inversé les bits de vos valeurs de clé pour éviter les problèmes de hotspots dans votre base de données source, vous pouvez également utiliser une séquence positive avec inversion bit de bit dans Spanner (GoogleSQL, PostgreSQL) pour continuer à générer ces valeurs. Pour éviter de générer des valeurs en double, vous pouvez configurer la séquence de sorte que son compteur démarre à partir d'un nombre personnalisé.
Par exemple, si vous avez inversé des nombres de 1 à 1 000 pour générer des valeurs de clé primaire, la séquence Spanner peut lancer son compteur à partir de n'importe quel nombre supérieur à 10 000. Vous pouvez éventuellement choisir un nombre élevé afin de laisser un tampon pour les nouvelles écritures qui se produisent dans la base de données source après la migration de données. Dans l'exemple suivant, les compteurs commencent à 11 000:
GoogleSQL
CREATE SEQUENCE MyFirstSequence OPTIONS ( sequence_kind = "bit_reversed_positive", start_with_counter = 11000 ); ALTER SEQUENCE MySecondSequence SET OPTIONS ( start_with_counter = 11000 );
PostgreSQL
CREATE SEQUENCE MyFirstSequence BIT_REVERSED_POSITIVE START COUNTER 11000; ALTER SEQUENCE MySecondSequence RESTART COUNTER 11000;