Migrer des stratégies de clé primaire

Ce document décrit les 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 d'un équilibrage de charge pour 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 régulières ou des horodatages) est la cause la plus courante de hotspots.

Stratégies globales

Dans Spanner, chaque table devant stocker plusieurs lignes doit avoir 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 et protégée par un point d'accès compatible avec Spanner (pour en savoir plus, consultez la section Migrer les 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). Le document RFC 4122 définit le format de l'UUID version 4.
    • Utilisez une séquence positive inversée (GoogleSQL, PostgreSQL). Une telle séquence génère des valeurs positives avec les bits de poids élevé déjà inversés, de sorte qu'elles sont réparties uniformément sur l'espace de nombres positifs de 64 bits.
  • Échangez 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é votre clé primaire pour 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é de clé générée automatiquement:

  • Migration à partir d'une table source utilisant une clé primaire UUID
  • Migration à partir d'une table source utilisant une clé entière séquentielle générée automatiquement Voici quelques exemples (liste non exhaustive) : séquences (compatibles avec différentes bases de données), colonnes IDENTITY (compatibles avec différentes bases de données), types de données PostgreSQL SERIAL et attribut de colonne MySQL AUTO_INCREMENT.
  • Migration à partir d'une table source utilisant une clé inversée. La base de données source peut être Spanner, dans laquelle vous créez des clés-valeurs à l'aide du guide sur les valeurs séquentielles de bits inversés.

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 changez uniquement 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 convertir la colonne au 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 les colonnes de clé séquentielle

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 qui se répartissent uniformément sur l'espace de 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 de 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 les colonnes de clé inversée

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 d'inversion de bits 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 façon à démarrer son compteur à 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 démarrer son compteur à partir de tout nombre supérieur à 10 000. Vous pouvez éventuellement choisir un nombre élevé pour laisser un tampon pour les nouvelles écritures effectuées dans la base de données source après la migration des 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;