Présentation de la migration des clés primaires

Cette page décrit le fonctionnement de Spanner avec les clés primaires et les offres. stratégies de migration de clés primaires pour les cas d'utilisation suivants:

Une approche classique des clés primaires consiste à utiliser des clés de substitution telles que des nombres à incrémentation automatique. Ces clés primaires offrent la flexibilité nécessaire pour optimiser vos clés actuelles et futures, même si votre logique métier change. Dans une base de données à instance unique à faible volume, les clés séquentielles fonctionnent bien. Toutefois, dans un système distribué, les clés séquentielles ne s'adaptent pas bien.

Clés primaires séquentielles dans Spanner

Dans Spanner, chaque table possède une clé primaire composée d'un ou de plusieurs colonnes du tableau. La clé primaire de votre table identifie de manière unique chaque ligne d'une table. Spanner utilise la clé primaire pour distribuer des groupes de lignes, appelés "divisions", sur les nœuds de calcul d'une instance Spanner. C'est (segmentation de plages) et permet à Spanner d'exécuter des requêtes en parallèle à grande échelle.

Lorsque vous avez des lignes dont les valeurs des clés primaires sont proches (par exemple, des clés monotones incrémentées automatiquement), elles ont tendance à se retrouver dans la même division. Ce créer un hotspot, où la division peut utiliser toutes les ressources de calcul et de mémoire disponibles ressources. Un point chaud peut entraîner une augmentation de la latence, ce qui peut entraîner des délais avant expiration et des transactions interrompues.

Pour profiter de l'évolutivité de Spanner et éviter les hotspots, Spanner propose des solutions intégrées comme alternatives à l'incrémentation automatique des clés primaires.

Recommandations concernant les clés primaires

Dans Spanner, il est recommandé par défaut d'utiliser Valeurs de l'identifiant unique universel version 4 (UUIDv4). Les UUID sont des identifiants 128 bits qui utilisent 122 bits de données aléatoires. Les valeurs UUIDv4 couvrent une plage de valeurs très large et sont effectivement uniques, quel que soit l'endroit où elles sont générées. Cela les rend de bons candidats pour les clés primaires sans hotspot dans Spanner.

Vous pouvez utiliser des clés primaires entières, car elles prennent moins d'espace et réduisent la la complexité des changements d'application que vous devrez faire. Vous pouvez utiliser une valeur positive séquence inversée sur les bits pour générer des valeurs de clé primaire uniques qui uniformisent répartir dans l'espace entier positif de 64 bits.

Pour savoir comment choisir clé primaire pour éviter la création de hotspots, consultez les bonnes pratiques de conception de schémas.

Stratégies de migration

En fonction du cas d'utilisation et des besoins de votre application, vous pouvez déployer une stratégie de migration de clé primaire. Chacune de ces stratégies de migration :

  • Assurez-vous que les clés primaires migrées sont fidèles et correctes.
  • Réduisez les modifications apportées aux applications en aval, telles que les modifications de types ou de valeurs de clé primaire.
  • Appliquer les bonnes pratiques Spanner en matière de performances et d'évolutivité
  • Spanner ne modifie que la méthode de génération des nouvelles données. Il n'a aucune incidence sur les données existantes.

Migrer des bases de données de clés UUID

Imaginons que vous migriez une base de données qui utilise des clés primaires UUID vers Spanner. Configurez des clés UUID existantes en tant que chaînes dans votre base de données source et importez-les. dans Spanner en l'état. Les valeurs UUID, v4 en particulier, sont uniques, quel que soit l'endroit où elles sont générées.

Vous pouvez utiliser la fonction GENERATE_UUID() (GoogleSQL, PostgreSQL) sur Spanner pour migrer les bases de données de clés UUID.

Pour savoir comment migrer des bases de données de clés UUID, consultez Migrer des colonnes de clés UUID.

Migrer des bases de données à instance unique comportant des clés séquentielles

Supposons que vous effectuiez la migration à partir d'une base de données à instance unique qui utilise des clés monotones séquentielles, telles que AUTO_INCREMENT dans MySQL, SERIAL dans PostgreSQL ou le type IDENTITY standard dans SQL Server ou Oracle.

Configurez l'objet Spanner SEQUENCE pour ignorer les valeurs comprises dans la plage les clés existantes et générer de nouvelles clés inversées sur bits. Clés inversées sur bits générées par l'objet SEQUENCE de Spanner sont toujours supérieures à zéro, et sont uniformément réparties sur l'espace entier positif de 64 bits.

Pour obtenir des instructions sur la migration de bases de données avec des clés séquentielles, consultez Migrer des clés primaires séquentielles générées automatiquement.

Migrer des bases de données de clés séquentielles compatibles avec la transition en direct

Imaginons que vous migriez d'une base de données à instance unique qui utilise des clés monotones séquentielles vers Spanner et que vous acceptiez les scénarios de réplication. Par exemple, vous souhaitez effectuer une transition en direct entre les systèmes de base de données.

Configurer l'objet SEQUENCE Spanner pour ignorer la totalité de la plage de valeurs de clés existantes dans votre base de données source et générer de nouvelles clés inversées sur bits sur Spanner. Les clés inversées générées par l'objet SEQUENCE de Spanner sont toujours supérieures à zéro, mais pas ordonnées.

Pour savoir comment migrer des bases de données compatibles avec le basculement en direct, consultez Utiliser Spanner et votre base de données source.

Migrer des bases de données de clés séquentielles qui ont des dépendances de logique d'application

Imaginons que vous effectuiez la migration à partir d'une base de données qui utilise des clés monotones séquentielles et que la logique de votre application s'appuie sur l'ordre de la clé primaire pour déterminer la récence ou pour séquencer les données nouvellement créées.

Créez une clé composite qui combine une valeur distribuée uniformément, telle qu'un ID de fragment ou un hachage, comme premier composant et un numéro séquentiel comme deuxième composant. Les valeurs des clés ordonnées sont ainsi conservées, sans créer de hotspot à grande échelle.

Pour savoir comment migrer des bases de données de clés séquentielles avec des dépendances de logique d'application, consultez Migrer vos propres clés primaires.

Étape suivante