Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Téléchargement de données historiques lors d'une migration en ligne
Après avoir implémenté deux écritures pour garantir que les nouvelles données sont écrites dans les deux magasins de données en temps réel, l'étape suivante du plan de migration consiste à évaluer la quantité de données historiques que vous devez copier ou charger en masse depuis Cassandra vers Amazon Keyspaces. Cela garantit que les nouvelles données et les données historiques seront disponibles dans la nouvelle base de données Amazon Keyspaces avant la migration de l'application.
En fonction de vos exigences en matière de conservation des données, par exemple la quantité de données historiques que vous devez conserver en fonction des politiques de votre organisation, vous pouvez envisager l'une des deux options suivantes.
Téléchargement groupé de données historiques — La migration des données historiques de votre déploiement Cassandra existant vers Amazon Keyspaces peut être réalisée à l'aide de différentes techniques, par exemple à l'aide AWS Glue de scripts personnalisés pour extraire, transformer et charger (ETL) les données. Pour plus d'informations sur l'utilisation AWS Glue pour charger des données historiques, consultezProcessus de migration hors ligne : Apache Cassandra vers Amazon Keyspaces.
Lorsque vous planifiez le téléchargement groupé de données historiques, vous devez réfléchir à la manière de résoudre les conflits qui peuvent survenir lorsque de nouvelles écritures tentent de mettre à jour les mêmes données en cours de téléchargement. Le téléchargement en masse devrait être finalement cohérent, ce qui signifie que les données atteindront à terme tous les nœuds.
Si une mise à jour des mêmes données se produit en même temps en raison d'une nouvelle écriture, vous devez vous assurer qu'elles ne seront pas remplacées par le téléchargement des données historiques. Pour vous assurer de conserver les dernières mises à jour de vos données même pendant l'importation en masse, vous devez ajouter la résolution des conflits soit dans les scripts de téléchargement en bloc, soit dans la logique de l'application pour les écritures doubles.
Par exemple, vous pouvez utiliser Transactions légères (LWT) pour comparer et définir des opérations. Pour ce faire, vous pouvez ajouter un champ supplémentaire à votre modèle de données qui représente l'heure de la modification ou l'état.
Amazon Keyspaces prend également en charge la fonction d'
WRITETIMEhorodatage Cassandra. Vous pouvez utiliser les horodatages côté client d'Amazon Keyspaces pour préserver l'horodatage de la base de données source et implémenter la résolution des conflits du dernier auteur gagnant. Pour de plus amples informations, veuillez consulter Client-side horodatages dans Amazon Keyspaces.Utilisation Time-to-Live (TTL) : pour les périodes de conservation des données inférieures à 30, 60 ou 90 jours, vous pouvez utiliser le TTL dans Cassandra et Amazon Keyspaces pendant la migration afin d'éviter de télécharger des données historiques inutiles sur Amazon Keyspaces. TTL vous permet de définir une période au terme de laquelle les données sont automatiquement supprimées de la base de données.
Au cours de la phase de migration, au lieu de copier les données historiques vers Amazon Keyspaces, vous pouvez configurer les paramètres TTL pour laisser les données historiques expirer automatiquement dans l'ancien système (Cassandra) tout en appliquant uniquement les nouvelles écritures à Amazon Keyspaces à l'aide de la méthode de double écriture. Au fil du temps, les anciennes données expirant continuellement dans le cluster Cassandra et les nouvelles données étant écrites à l'aide de la méthode de double écriture, Amazon Keyspaces les rattrape automatiquement pour contenir les mêmes données que Cassandra.
Cette approche permet de réduire de manière significative la quantité de données à migrer, ce qui se traduit par un processus de migration plus efficace et rationalisé. Vous pouvez envisager cette approche lorsque vous traitez de grands ensembles de données dont les exigences de conservation des données varient. Pour plus d’informations sur TTL, consultez Expirer les données avec Time to Live (TTL) pour Amazon Keyspaces (pour Apache Cassandra).
Prenons l'exemple suivant d'une migration de Cassandra vers Amazon Keyspaces utilisant l'expiration des données TTL. Dans cet exemple, nous définissons le TTL pour les deux bases de données à 60 jours et montrons comment le processus de migration progresse sur une période de 90 jours. Les deux bases de données reçoivent les mêmes données nouvellement écrites au cours de cette période en utilisant la méthode des écritures doubles. Nous allons examiner trois phases différentes de la migration, chaque phase dure 30 jours.
Le fonctionnement du processus de migration pour chaque phase est illustré dans les images suivantes.
Après les 30 premiers jours, le cluster Cassandra et Amazon Keyspaces ont reçu de nouvelles écritures. Le cluster Cassandra contient également des données historiques dont la durée de conservation n'a pas encore atteint 60 jours, soit 50 % des données du cluster.
Les données datant de plus de 60 jours sont automatiquement supprimées dans le cluster Cassandra à l'aide du TTL. À ce stade, Amazon Keyspaces contient 50 % des données stockées dans le cluster Cassandra, qui comprend les nouvelles écritures moins les données historiques.
Après 60 jours, le cluster Cassandra et Amazon Keyspaces contiennent les mêmes données écrites au cours des 60 derniers jours.
Dans les 90 jours, Cassandra et Amazon Keyspaces contiennent les mêmes données et expirent les données au même rythme.
Cet exemple montre comment éviter de télécharger des données historiques en utilisant le TTL dont la date d'expiration est fixée à 60 jours.
