Migrer les stratégies de clés primaires

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ées STRING(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.
  • 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ées SERIAL PostgreSQL et l'attribut de colonne AUTO_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;