Présentation de la migration des clés primaires

Cette page décrit le fonctionnement de Spanner avec les clés primaires et propose des 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émentés automatiquement. Ces clés primaires offrent une flexibilité qui vous permet d'optimiser vos clés maintenant et à l'avenir, 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 sont pas adaptées à l'évolutivité.

Clés primaires séquentielles dans Spanner

Dans Spanner, chaque table possède 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. 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 ce que l'on appelle le fractionnement par plage. Il permet à Spanner de paralléliser les requêtes et de s'étendre.

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. Cela peut créer un point d'accès où la division peut utiliser toutes les ressources de calcul et de mémoire disponibles. Un point d'accès peut entraîner une augmentation de la latence, ce qui peut entraîner des délais avant expiration et des transactions abandonnées.

Pour profiter de l'évolutivité de Spanner et éviter les points chauds, Spanner propose des solutions intégrées comme alternative aux clés primaires incrémentées automatiquement.

Recommandations concernant les clés primaires

La recommandation par défaut pour les clés primaires dans Spanner consiste à utiliser des valeurs UUIDv4 (identifiant unique universel, version 4). 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. Ils sont donc de bons candidats pour les clés primaires non hotspottées dans Spanner.

Vous pouvez utiliser des clés primaires entières, car elles prennent moins d'espace et réduisent la complexité des modifications d'application que vous devrez effectuer. Vous pouvez utiliser une séquence positive inversée par bits pour générer des valeurs de clé primaire uniques qui se répartissent uniformément dans l'espace d'entiers 64 bits positifs.

Pour en savoir plus sur le choix d'une clé primaire pour éviter les 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.
  • Appliquez les bonnes pratiques Spanner pour les performances et l'évolutivité.
  • Spanner ne modifie que la méthode de génération des nouvelles données et n'affecte pas les données existantes.

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

Imaginons que vous migriez depuis une base de données qui utilise des clés primaires UUID vers Spanner. Configurez les clés UUID existantes en tant que chaînes dans votre base de données source et importez-les dans Spanner telles quelles. Les valeurs UUID, en particulier la version 4, sont effectivement 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 qui comportent des clés séquentielles

Supposons que vous migriez à 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 SEQUENCE Spanner pour ignorer les valeurs de la plage des clés existantes et générer de nouvelles clés inversées. Les clés inversées générées par l'objet SEQUENCE Spanner sont toujours supérieures à zéro et sont réparties uniformément dans l'espace d'entiers 64 bits positifs.

Pour savoir comment migrer des 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.

Configurez l'objet SEQUENCE Spanner pour ignorer toute la plage de valeurs des clés existantes dans votre base de données source et générer de nouvelles clés inversées 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 présentent 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. Cela permet de conserver les valeurs de clé ordonnées, sans créer de point chaud à 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