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.
# Migration vers Amazon Keyspaces (pour Apache Cassandra)
La migration vers Amazon Keyspaces (pour Apache Cassandra) présente de nombreux avantages convaincants pour les entreprises et les organisations. Voici quelques avantages clés qui font d'Amazon Keyspaces un choix intéressant pour la migration.
+ **Évolutivité** — Amazon Keyspaces est conçu pour gérer des charges de travail massives et évoluer de manière fluide afin de s'adapter à l'augmentation des volumes de données et du trafic. Avec le Cassandra traditionnel, le dimensionnement n'est pas effectué à la demande et nécessite de planifier les pics futurs. Avec Amazon Keyspaces, vous pouvez facilement augmenter ou diminuer vos tableaux en fonction de la demande, afin que vos applications puissent gérer des pics de trafic soudains sans compromettre les performances.
+ **Performances** — Amazon Keyspaces offre un accès aux données à faible latence, ce qui permet aux applications de récupérer et de traiter les données à une vitesse exceptionnelle. Son architecture distribuée garantit que les opérations de lecture et d'écriture sont réparties sur plusieurs nœuds, offrant ainsi des temps de réponse constants à un chiffre en millisecondes, même à des taux de requêtes élevés.
+ **Entièrement géré** — Amazon Keyspaces est un service entièrement géré fourni par. AWS Cela signifie qu'il AWS gère les aspects opérationnels de la gestion des bases de données, notamment le provisionnement, la configuration, les correctifs, les sauvegardes et le dimensionnement. Cela vous permet de vous concentrer davantage sur le développement de vos applications et moins sur les tâches d'administration de base de données.
+ **Architecture sans serveur** — Amazon Keyspaces fonctionne sans serveur. Vous ne payez que pour la capacité consommée, sans qu'aucun provisionnement de capacité initial ne soit requis. Vous n'avez pas de serveurs à gérer ni d'instances à choisir. Ce pay-per-request modèle offre une rentabilité et une charge opérationnelle minimale, car vous ne payez que pour les ressources que vous consommez sans avoir à provisionner et à surveiller les capacités.
+ **Flexibilité NoSQL avec schéma —** Amazon Keyspaces suit un modèle de données NoSQL, offrant ainsi de la flexibilité dans la conception des schémas. Avec Amazon Keyspaces, vous pouvez stocker des données structurées, semi-structurées et non structurées, ce qui les rend parfaitement adaptées à la gestion de types de données divers et évolutifs. En outre, Amazon Keyspaces valide le schéma en écriture, ce qui permet une évolution centralisée du modèle de données. Cette flexibilité permet d'accélérer les cycles de développement et de s'adapter plus facilement à l'évolution des besoins de l'entreprise.
+ **Haute disponibilité et durabilité** : Amazon Keyspaces réplique les données dans plusieurs [zones de disponibilité](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) au sein d'un même Région AWS, garantissant ainsi une haute disponibilité et une durabilité des données. Il gère automatiquement la réplication, le basculement et la restauration, minimisant ainsi le risque de perte de données ou d'interruption de service. Amazon Keyspaces fournit un SLA de disponibilité allant jusqu'à 99,999 %. [Pour encore plus de résilience et des lectures locales à faible latence, Amazon Keyspaces propose une réplication multirégionale.](multiRegion-replication.md)
+ **Sécurité et conformité** : Amazon Keyspaces s'intègre Gestion des identités et des accès AWS pour un contrôle d'accès précis. Il fournit un chiffrement au repos et en transit, ce qui contribue à améliorer la sécurité de vos données. Amazon Keyspaces a été évalué par des auditeurs tiers en termes de sécurité et de conformité à des programmes spécifiques, notamment HIPAA, PCI DSS et SOC, vous permettant de répondre aux exigences réglementaires. Pour de plus amples informations, veuillez consulter [Validation de conformité pour Amazon Keyspaces (pour Apache Cassandra)](Keyspaces-compliance.md).
+ **Intégration à AWS l'écosystème** — Dans le cadre de l' AWS écosystème, Amazon Keyspaces s'intègre parfaitement à d'autres Services AWS, par exemple AWS CloudFormation Amazon CloudWatch et. AWS CloudTrail Cette intégration vous permet de créer des architectures sans serveur, de tirer parti de l'infrastructure sous forme de code et de créer des applications pilotées par les données en temps réel. Pour de plus amples informations, veuillez consulter [Surveillance d'Amazon Keyspaces (pour Apache Cassandra)](monitoring-overview.md).
**Topics**
+ [Créez un plan de migration pour migrer d'Apache Cassandra vers Amazon Keyspaces](migrating-cassandra.md)
+ [Comment sélectionner le bon outil pour le téléchargement groupé ou la migration de données vers Amazon Keyspaces](migrating-tools.md)
# Créez un plan de migration pour migrer d'Apache Cassandra vers Amazon Keyspaces
Pour une migration réussie d'Apache Cassandra vers Amazon Keyspaces, nous vous recommandons de passer en revue les concepts de migration applicables et les meilleures pratiques, ainsi que de comparer les options disponibles.
Cette rubrique décrit le fonctionnement du processus de migration en présentant plusieurs concepts clés ainsi que les outils et techniques mis à votre disposition. Vous pouvez évaluer les différentes stratégies de migration afin de sélectionner celle qui répond le mieux à vos besoins.
**Topics**
+ [Compatibilité fonctionnelle](#migrating-cassandra-compatibility)
+ [Estimer le prix d'Amazon Keyspaces](#migrating-cassandra-sizing)
+ [Choisissez une stratégie de migration](#migrating-cassandra-strategy)
+ [Migration en ligne vers Amazon Keyspaces : stratégies et meilleures pratiques](migrating-online.md)
+ [Processus de migration hors ligne : Apache Cassandra vers Amazon Keyspaces](migrating-offline.md)
+ [Utilisation d'une solution de migration hybride : Apache Cassandra vers Amazon Keyspaces](migrating-hybrid.md)
## Compatibilité fonctionnelle
Examinez attentivement les différences fonctionnelles entre Apache Cassandra et Amazon Keyspaces avant la migration. Amazon Keyspaces prend en charge toutes les opérations courantes du plan de données Cassandra, telles que la création d'espaces de touches et de tables, la lecture de données et l'écriture de données.
Cependant, Amazon Keyspaces ne prend pas en charge certaines Cassandra APIs . Pour plus d'informations sur la prise en charge APIs, consultez[Cassandra APIs, opérations, fonctions et types de données pris en charge](cassandra-apis.md). Pour un aperçu de toutes les différences fonctionnelles entre Amazon Keyspaces et Apache Cassandra, consultez. [Différences fonctionnelles : Amazon Keyspaces et Apache Cassandra](functional-differences.md)
Pour comparer le Cassandra APIs et le schéma que vous utilisez aux fonctionnalités prises en charge dans Amazon Keyspaces, vous pouvez exécuter un script de compatibilité disponible dans le kit d'outils Amazon Keyspaces sur. [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)
**Comment utiliser le script de compatibilité**
1. Téléchargez le script Python de compatibilité depuis [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)et déplacez-le vers un emplacement ayant accès à votre cluster Apache Cassandra existant.
1. Le script de compatibilité utilise des paramètres similaires à`CQLSH`. `--port`Entrez `--host` et saisissez l'adresse IP et le port que vous utilisez pour vous connecter et exécuter des requêtes sur l'un des nœuds Cassandra de votre cluster.
Si votre cluster Cassandra utilise l'authentification, vous devez également fournir `-username` et`-password`. Pour exécuter le script de compatibilité, vous pouvez utiliser la commande suivante.
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## Estimer le prix d'Amazon Keyspaces
Cette section fournit un aperçu des informations que vous devez collecter à partir de vos tables Apache Cassandra pour calculer le coût estimé d'Amazon Keyspaces. Chacune de vos tables nécessite des types de données différents, doit prendre en charge différentes requêtes CQL et gère un read/write trafic distinct.
La prise en compte de vos besoins sur la base de tableaux correspond aux modes d'isolation des ressources au niveau des tables d'Amazon Keyspaces [et](ReadWriteCapacityMode.md) de capacité de débit de lecture/écriture. Avec Amazon Keyspaces, vous pouvez définir la capacité de lecture/écriture et les [politiques de dimensionnement automatique](autoscaling.md) pour les tables de manière indépendante.
Comprendre les exigences relatives aux tables vous permet de hiérarchiser les tables à migrer en fonction des fonctionnalités, du coût et de l'effort de migration.
Collectez les métriques de la table Cassandra suivantes avant une migration. Ces informations permettent d'estimer le coût de votre charge de travail sur Amazon Keyspaces.
+ **Nom de la table** : nom du keyspace complet et du nom de la table.
+ **Description** : description de la table, par exemple de son utilisation ou du type de données qui y est stocké.
+ Nombre **moyen de lectures par seconde** : nombre moyen de lectures au niveau des coordonnées par rapport au tableau sur un long intervalle de temps.
+ Nombre **moyen d'écritures par seconde** : nombre moyen d'écritures au niveau des coordonnées par rapport à la table sur un long intervalle de temps.
+ **Taille de ligne moyenne en octets** : taille de ligne moyenne en octets.
+ **Taille de stockage en GBs** : taille de stockage brute d'une table.
+ **Répartition de la cohérence des lectures** : pourcentage de lectures utilisant une cohérence éventuelle (`LOCAL_ONE`ou`ONE`) par rapport à une cohérence forte (`LOCAL_QUORUM`).
Ce tableau présente un exemple des informations relatives à vos tables que vous devez rassembler lors de la planification d'une migration.
****
| Nom de la table | Description | Nombre moyen de lectures par seconde | Nombre moyen d'écritures par seconde | Taille moyenne des lignes en octets | Taille de stockage en GBs | Lire le tableau de cohérence |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | Utilisé pour enregistrer l'historique du panier | 10 000 | 5 000 | 2 200 | 2 000 | 100 % `LOCAL_ONE` |
| mykeyspace.mytable2 | Utilisé pour stocker les dernières informations de profil | 20 000 | 1 000 | 850 | 1 000 | 25 % `LOCAL_QUORUM` 75 % `LOCAL_ONE` |
### Comment collecter les métriques du tableau
Cette section fournit des instructions étape par étape sur la façon de collecter les métriques de table nécessaires à partir de votre cluster Cassandra existant. Ces mesures incluent la taille des lignes, la taille des tables et le nombre de read/write demandes par seconde (RPS). Ils vous permettent d'évaluer les besoins en capacité de débit pour une table Amazon Keyspaces et d'estimer les prix.
**Comment collecter des métriques de table sur la table source de Cassandra**
1. Déterminer la taille des lignes
La taille des lignes est importante pour déterminer la capacité de lecture et l'utilisation de la capacité d'écriture dans Amazon Keyspaces. Le schéma suivant montre la distribution typique des données sur une plage de jetons Cassandra.
![\[Schéma illustrant la distribution typique des données sur une plage de jetons Cassandra à l'aide du murmur3 partitionneur.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
Vous pouvez utiliser un script d'échantillonnage de taille de ligne disponible sur [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)pour collecter des métriques de taille de ligne pour chaque table de votre cluster Cassandra.
Le script exporte les données de table depuis Apache Cassandra en utilisant `cqlsh` et `awk` pour calculer le minimum, le maximum, la moyenne et l'écart type de la taille des lignes sur un ensemble d'échantillons configurable de données de table. L'échantillonneur de taille de ligne transmet les arguments à`cqlsh`, de sorte que les mêmes paramètres peuvent être utilisés pour se connecter et lire à partir de votre cluster Cassandra.
La déclaration suivante en est un exemple.
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
Pour plus d'informations sur le calcul de la taille des lignes dans Amazon Keyspaces, consultez. [Estimer la taille des lignes dans Amazon Keyspaces](calculating-row-size.md)
1. Déterminer la taille de la table
Avec Amazon Keyspaces, vous n'avez pas besoin de provisionner le stockage à l'avance. Amazon Keyspaces surveille en permanence la taille facturable de vos tables afin de déterminer vos frais de stockage. Le stockage est facturé par Go par mois. La taille du tableau Amazon Keyspaces est basée sur la taille brute (non compressée) d'une seule réplique.
Pour surveiller la taille du tableau dans Amazon Keyspaces, vous pouvez utiliser la métrique`BillableTableSizeInBytes`, qui est affichée pour chaque tableau dans le. AWS Management Console
Pour estimer la taille facturable de votre tableau Amazon Keyspaces, vous pouvez utiliser l'une des deux méthodes suivantes :
+ Utilisez la taille moyenne des lignes et multipliez-la par le nombre de lignes.
Vous pouvez estimer la taille de la table Amazon Keyspaces en multipliant la taille moyenne des lignes par le nombre de lignes de votre table source Cassandra. Utilisez l'exemple de script de taille de ligne de la section précédente pour capturer la taille de ligne moyenne. Pour capturer le nombre de lignes, vous pouvez utiliser des outils tels que `dsbulk count` la détermination du nombre total de lignes dans votre table source.
+ Utilisez le `nodetool` pour collecter les métadonnées des tables.
`Nodetool`est un outil administratif fourni dans la distribution Apache Cassandra qui fournit un aperçu de l'état du processus Cassandra et renvoie les métadonnées des tables. Vous pouvez les utiliser `nodetool` pour échantillonner les métadonnées relatives à la taille des tables et ainsi extrapoler la taille des tables dans Amazon Keyspaces.
La commande à utiliser est`nodetool tablestats`. Tablestats renvoie la taille et le taux de compression de la table. La taille du tableau est enregistrée comme celle `tablelivespace` du tableau et vous pouvez la diviser par le`compression ratio`. Multipliez ensuite cette valeur de taille par le nombre de nœuds. Enfin, divisez par le facteur de réplication (généralement trois).
Il s'agit de la formule complète de calcul que vous pouvez utiliser pour évaluer la taille de la table.
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
Supposons que votre cluster Cassandra comporte 12 nœuds. L'exécution de la `nodetool tablestats` commande renvoie une valeur `tablelivespace` de 200 Go et une valeur `compression ratio` de 0,5. Le keyspace possède un facteur de réplication de trois.
Voici à quoi ressemble le calcul de cet exemple.
```
(200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
= 4,800 GB / 3
= 1,600 GB is the table size estimate for Amazon Keyspaces
```
1. Capturez le nombre de lectures et d'écritures
Pour déterminer les exigences de capacité et de mise à l'échelle de vos tables Amazon Keyspaces, capturez le taux de demandes de lecture et d'écriture de vos tables Cassandra avant la migration.
Amazon Keyspaces fonctionne sans serveur et vous ne payez que pour ce que vous utilisez. En général, le prix du read/write débit dans Amazon Keyspaces est basé sur le nombre et la taille des demandes.
Amazon Keyspaces propose deux modes de capacité :
+ [À la demande](ReadWriteCapacityMode.OnDemand.md) : il s'agit d'une option de facturation flexible capable de traiter des milliers de demandes par seconde sans qu'il soit nécessaire de planifier les capacités. Il propose des pay-per-request tarifs pour les demandes de lecture et d'écriture afin que vous ne payiez que pour ce que vous utilisez.
+ [Provisionné](ReadWriteCapacityMode.Provisioned.md) : si vous choisissez le mode de capacité de débit provisionnée, vous spécifiez le nombre de lectures et d'écritures par seconde requis pour votre application. Cela vous permet de gérer votre utilisation d'Amazon Keyspaces afin de rester au niveau ou en dessous d'un taux de demandes défini afin de garantir la prévisibilité.
Le mode provisionné offre une [mise à l'échelle automatique](autoscaling.md) pour ajuster automatiquement votre taux provisionné à la hausse ou à la baisse afin d'améliorer l'efficacité opérationnelle. Pour plus d'informations sur la gestion des ressources sans serveur, consultez[Gestion des ressources sans serveur dans Amazon Keyspaces (pour Apache Cassandra)](serverless_resource_management.md).
Étant donné que vous allouez séparément la capacité de débit de lecture et d'écriture dans Amazon Keyspaces, vous devez mesurer le taux de demandes de lecture et d'écriture dans vos tables existantes de manière indépendante.
Pour recueillir les indicateurs d'utilisation les plus précis de votre cluster Cassandra existant, capturez le nombre moyen de demandes par seconde (RPS) pour les opérations de lecture et d'écriture au niveau du coordinateur sur une période prolongée pour une table agrégée sur tous les nœuds d'un seul centre de données.
La capture du RPS moyen sur une période d'au moins plusieurs semaines permet de saisir les pics et les creux de vos modèles de trafic, comme le montre le schéma suivant.
![\[Un diagramme montrant le taux moyen de demandes par seconde et par jour sur une période de deux semaines.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/migration-rps.png)
Deux options s'offrent à vous pour déterminer le taux de requêtes en lecture et en écriture de votre table Cassandra.
+ Utiliser la surveillance Cassandra existante
Vous pouvez utiliser les métriques présentées dans le tableau suivant pour observer les demandes de lecture et d'écriture. Notez que les noms des métriques peuvent changer en fonction de l'outil de surveillance que vous utilisez.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/migrating-cassandra.html)
+ Utilisation de la `nodetool`
Utilisez `nodetool tablestats` et `nodetool info` pour capturer les opérations de lecture et d'écriture moyennes à partir de la table. `tablestats`renvoie le nombre total de lectures et d'écritures depuis le moment où le nœud a été initié. `nodetool info`fournit le temps de disponibilité d'un nœud en secondes.
Pour obtenir la moyenne des lectures et des écritures par seconde, divisez le nombre de lectures et d'écritures par le temps de disponibilité du nœud en secondes. Ensuite, pour les lectures, vous divisez par le niveau de cohérence et pour les écritures, vous divisez par le facteur de réplication. Ces calculs sont exprimés dans les formules suivantes.
Formule pour le nombre moyen de lectures par seconde :
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
Formule pour le nombre moyen d'écritures par seconde :
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
Supposons que nous ayons un cluster de 12 nœuds actif depuis 4 semaines. `nodetool info`renvoie 2 419 200 secondes de disponibilité et `nodetool tablestats` renvoie 1 milliard d'écritures et 2 milliards de lectures. Cet exemple entraînerait le calcul suivant.
```
((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
= 12 billion reads / 2,419,200 seconds
= 4,960 read request per second
((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
= 4 billion writes / 2,419,200 seconds
= 1,653 write request per second
```
1. Déterminer l'utilisation de la capacité de la table
Pour estimer l'utilisation moyenne de la capacité, commencez par les taux de demandes moyens et la taille moyenne des lignes de votre table source Cassandra.
Amazon Keyspaces utilise des unités de *capacité de lecture (RCUs) et des unités* de *capacité d'écriture* (WCUs) pour mesurer la capacité de débit allouée pour les lectures et les écritures pour les tables. Pour cette estimation, nous utilisons ces unités pour calculer les besoins en capacité de lecture et d'écriture de la nouvelle table Amazon Keyspaces après la migration.
Plus loin dans cette rubrique, nous verrons comment le choix entre le mode de capacité provisionnée et le mode de capacité à la demande affecte la facturation. Mais pour l'estimation de l'utilisation de la capacité dans cet exemple, nous supposons que la table est en mode provisionné.
+ **`LOCAL_QUORUM`Lectures** — Une RCU représente une ou deux demandes de `LOCAL_ONE` lecture pour une ligne d'une taille maximale de 4 Ko. Si vous devez lire une ligne de plus de 4 Ko, l'opération de lecture utilise des éléments supplémentaires RCUs. Le nombre total de lignes RCUs requises dépend de la taille de la ligne et de la cohérence que vous souhaitez utiliser `LOCAL_QUORUM` ou `LOCAL_ONE` lire.
Par exemple, la lecture d'une ligne de 8 Ko nécessite 2 lignes RCUs utilisant la cohérence de `LOCAL_QUORUM` lecture et 1 RCU si vous choisissez la cohérence de `LOCAL_ONE` lecture.
+ **Écritures** — Une WCU représente une écriture pour une ligne d'une taille maximale de 1 Ko. Toutes les écritures utilisent `LOCAL_QUORUM` la cohérence, et l'utilisation de transactions légères (LWTs) est gratuite.
Le nombre total de lignes WCUs requises dépend de la taille de la ligne. Si vous devez écrire une ligne supérieure à 1 Ko, l'opération d'écriture utilise des éléments supplémentaires WCUs. Par exemple, si la taille de votre ligne est de 2 Ko, vous en avez besoin WCUs de 2 pour exécuter une demande d'écriture.
La formule suivante peut être utilisée pour estimer les valeurs requises RCUs et WCUs.
+ **La capacité de lecture RCUs peut être déterminée en** multipliant les lectures par seconde par le nombre de lignes lues par lecture multiplié par la taille moyenne des lignes divisée par 4 Ko et arrondie au nombre entier le plus proche.
+ La **capacité d'écriture WCUs peut être déterminée en** multipliant le nombre de demandes par la taille moyenne des lignes divisée par 1 Ko et arrondie au nombre entier le plus proche.
Cela s'exprime dans les formules suivantes.
```
Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second
```
Par exemple, si vous effectuez 4 960 demandes de lecture avec une taille de ligne de 2,5 Ko sur votre table Cassandra, vous en avez besoin de 4 960 dans RCUs Amazon Keyspaces. Si vous effectuez actuellement 1 653 demandes d'écriture par seconde avec une taille de ligne de 2,5 Ko sur votre table Cassandra, vous en avez besoin de 4 959 par seconde WCUs dans Amazon Keyspaces.
Cet exemple est exprimé dans les formules suivantes.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit)
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs
```
L'utilisation vous `eventual consistency` permet d'économiser jusqu'à la moitié de la capacité de débit à chaque demande de lecture. Chaque lecture finalement cohérente peut consommer jusqu'à 8 Ko. Vous pouvez calculer les lectures cohérentes éventuelles en multipliant le calcul précédent par 0,5, comme indiqué dans la formule suivante.
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5
= 2,480 read request per second * 1 RCU
= 2,480 RCUs
```
1. Calculez l'estimation du prix mensuel pour Amazon Keyspaces
Pour estimer la facturation mensuelle de la table en fonction de la read/write capacité de débit, vous pouvez calculer le prix pour le mode à la demande et pour le mode provisionné à l'aide de différentes formules et comparer les options de votre tableau.
**Mode provisionné** — La consommation de capacité de lecture et d'écriture est facturée selon un taux horaire basé sur les unités de capacité par seconde. Divisez d'abord ce taux par 0,7 pour représenter l'utilisation cible de 70 % par défaut de l'autoscaling. Multipliez ensuite par 30 jours calendaires, 24 heures par jour, et par le tarif régional.
Ce calcul est résumé dans les formules suivantes.
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**Mode à la demande** — La capacité de lecture et d'écriture est facturée au tarif par demande. Tout d'abord, multipliez le taux de demandes par 30 jours civils et 24 heures par jour. Divisez ensuite par un million d'unités de demande. Enfin, multipliez par le taux régional.
Ce calcul est résumé dans les formules suivantes.
```
((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate
```
## Choisissez une stratégie de migration
Vous pouvez choisir entre les stratégies de migration suivantes lors de la migration d'Apache Cassandra vers Amazon Keyspaces :
+ **En ligne** — Il s'agit d'une migration en direct utilisant deux écritures pour commencer à écrire simultanément de nouvelles données sur Amazon Keyspaces et le cluster Cassandra. Ce type de migration est recommandé pour les applications qui ne nécessitent aucun temps d'arrêt pendant la migration et qui nécessitent une cohérence entre les opérations de lecture après écriture.
Pour plus d'informations sur la planification et la mise en œuvre d'une stratégie de migration en ligne, consultez[Migration en ligne vers Amazon Keyspaces : stratégies et meilleures pratiques](migrating-online.md).
+ **Hors ligne** : cette technique de migration consiste à copier un ensemble de données de Cassandra vers Amazon Keyspaces pendant une période d'indisponibilité. La migration hors ligne peut simplifier le processus de migration, car elle ne nécessite pas de modifications de votre application ni de résolution de conflit entre les données historiques et les nouvelles écritures.
Pour plus d'informations sur la planification d'une migration hors ligne, consultez[Processus de migration hors ligne : Apache Cassandra vers Amazon Keyspaces](migrating-offline.md).
+ **Hybride** : cette technique de migration permet de répliquer les modifications sur Amazon Keyspaces quasiment en temps réel, mais sans cohérence entre lecture après écriture.
Pour plus d'informations sur la planification d'une migration hybride, consultez[Utilisation d'une solution de migration hybride : Apache Cassandra vers Amazon Keyspaces](migrating-hybrid.md).
Après avoir examiné les techniques de migration et les meilleures pratiques abordées dans cette rubrique, vous pouvez placer les options disponibles dans un arbre de décision afin de concevoir une stratégie de migration basée sur vos besoins et les ressources disponibles.
# Migration en ligne vers Amazon Keyspaces : stratégies et meilleures pratiques
Si vous devez maintenir la disponibilité des applications lors d'une migration d'Apache Cassandra vers Amazon Keyspaces, vous pouvez préparer une stratégie de migration en ligne personnalisée en implémentant les composants clés décrits dans cette rubrique. En suivant ces bonnes pratiques pour les migrations en ligne, vous pouvez garantir la disponibilité et la read-after-write cohérence des applications tout au long du processus de migration, minimisant ainsi l'impact sur vos utilisateurs.
Lorsque vous concevez une stratégie de migration en ligne d'Apache Cassandra vers Amazon Keyspaces, vous devez prendre en compte les étapes clés suivantes.
1. **Écrire de nouvelles données**
+ Proxy **ZDM Dual Write pour la migration d'Amazon Keyspaces — Utilisez le proxy** ZDM Dual Write disponible [sur](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github pour effectuer une migration sans interruption d'Apache Cassandra vers Amazon Keyspaces. Le proxy ZDM effectue deux écritures sans qu'il soit nécessaire de refactoriser les applications existantes et effectue des lectures doubles pour la validation des requêtes.
+ Deux écritures d'application : vous pouvez implémenter des écritures doubles dans votre application à l'aide des bibliothèques clientes et des pilotes Cassandra existants. Désignez une base de données comme leader et l'autre comme suiveuse. Les échecs d'écriture dans la base de données des abonnés sont enregistrés dans une [file d'attente de lettres mortes (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) à des fins d'analyse.
+ Deux écritures au niveau de messagerie : vous pouvez également configurer votre plateforme de messagerie existante pour envoyer des écritures à Cassandra et à Amazon Keyspaces en utilisant un consommateur supplémentaire. Cela crée finalement des vues cohérentes entre les deux bases de données.
1. **Migration des données historiques**
+ Copier les données historiques : vous pouvez migrer les données historiques de Cassandra vers Amazon Keyspaces à AWS Glue l'aide ou de scripts d'extraction, de transformation et de chargement (ETL) personnalisés. Gérez la résolution des conflits entre les écritures doubles et les chargements groupés à l'aide de techniques telles que les transactions légères ou les horodatages.
+ Utilisation Time-To-Live (TTL) : pour des périodes de conservation des données plus courtes, vous pouvez utiliser le TTL dans Cassandra et Amazon Keyspaces afin d'éviter de télécharger des données historiques inutiles. Lorsque les anciennes données expirent dans Cassandra et que les nouvelles données sont écrites par double écriture, Amazon Keyspaces finit par rattraper son retard.
1. **Validation des données**
+ Lectures doubles : implémentez des lectures doubles à partir des bases de données Cassandra (principale) et Amazon Keyspaces (secondaire), en comparant les résultats de manière asynchrone. Les différences sont enregistrées ou envoyées à un DLQ.
+ Exemples de lectures : utilisez les fonctions λ pour échantillonner et comparer périodiquement les données des deux systèmes, en enregistrant toute anomalie dans un DLQ.
1. **Migration de l'application**
+ Stratégie bleu-vert : changez d'application pour traiter Amazon Keyspaces comme le magasin de données principal et Cassandra comme le magasin de données secondaire en une seule étape. Surveillez les performances et revenez en arrière en cas de problème.
+ Déploiement de Canary : déployez d'abord progressivement la migration vers un sous-ensemble d'utilisateurs, en augmentant progressivement le trafic vers Amazon Keyspaces en tant que principal utilisateur jusqu'à la migration complète.
1. **Démantèlement de Cassandra**
Une fois que votre application est entièrement migrée vers Amazon Keyspaces et que la cohérence des données est validée, vous pouvez planifier la mise hors service de votre cluster Cassandra en fonction des politiques de conservation des données.
En planifiant une stratégie de migration en ligne à l'aide de ces composants, vous pouvez passer en douceur au service Amazon Keyspaces entièrement géré avec un minimum de temps d'arrêt ou d'interruption. Les sections suivantes abordent chaque composant de manière plus détaillée.
**Topics**
+ [Écrire de nouvelles données lors d'une migration en ligne](migration-online-dw.md)
+ [Téléchargement de données historiques lors d'une migration en ligne](migration-online-historical.md)
+ [Validation de la cohérence des données lors d'une migration en ligne](migration-online-validation.md)
+ [Migration de l'application lors d'une migration en ligne](migration-online-app-migration.md)
+ [Mise hors service de Cassandra après une migration en ligne](migration-online-decommission.md)
# Écrire de nouvelles données lors d'une migration en ligne
La première étape d'un plan de migration en ligne consiste à s'assurer que toutes les nouvelles données écrites par l'application sont stockées dans les deux bases de données, dans votre cluster Cassandra existant et dans Amazon Keyspaces. L'objectif est de fournir une vue cohérente des deux magasins de données. Vous pouvez le faire en appliquant toutes les nouvelles écritures aux deux bases de données. Pour implémenter les écritures doubles, considérez l'une des trois options suivantes.
+ **Proxy ZDM à double écriture pour la migration vers Amazon Keyspaces** — À l'aide du proxy ZDM pour Amazon Keyspaces disponible [sur](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github, vous pouvez migrer vos charges de travail Apache Cassandra vers Amazon Keyspaces sans interruption des applications. Cette solution améliorée met en œuvre les AWS meilleures pratiques et étend les fonctionnalités officielles du proxy ZDM.
+ Effectuez des migrations en ligne entre Apache Cassandra et Amazon Keyspaces.
+ Écrivez des données simultanément dans les tables source et cible sans refactoriser les applications.
+ Validez les requêtes par le biais d'opérations de double lecture.
La solution propose les améliorations suivantes pour fonctionner avec Amazon Keyspaces AWS et Amazon Keyspaces.
+ **Déploiement de conteneurs** : utilisez une image Docker préconfigurée provenant d'Amazon Elastic Container Registry (Amazon ECR) pour les déploiements accessibles par VPC.
+ **Infrastructure sous forme de code** — Déployez à l'aide de AWS CloudFormation modèles pour une configuration automatisée surAWS Fargate.
+ **Compatibilité avec Amazon Keyspaces :** accédez aux tables du système avec des adaptations personnalisées pour Amazon Keyspaces.
La solution s'exécute sur Amazon ECS avec Fargate, offrant une évolutivité sans serveur en fonction des exigences de votre charge de travail. Un équilibreur de charge réseau répartit le trafic applicatif entrant entre plusieurs tâches Amazon ECS pour garantir une haute disponibilité.
![\[Implémentation du proxy à double écriture ZDM pour la migration des données d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Deux écritures d'application** : vous pouvez implémenter des écritures doubles en modifiant le moins possible le code de votre application en exploitant les bibliothèques et les pilotes clients Cassandra existants. Vous pouvez soit implémenter les écritures doubles dans votre application existante, soit créer une nouvelle couche dans l'architecture pour gérer les écritures doubles. Pour plus d'informations et une étude de cas client qui montre comment les écritures doubles ont été mises en œuvre dans une application existante, consultez l'[étude de cas sur la migration de Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Lorsque vous implémentez les écritures doubles, vous pouvez désigner une base de données comme leader et l'autre comme suiveuse. Cela vous permet de continuer à écrire dans votre base de données source d'origine, ou base de données principale, sans que les échecs d'écriture dans la base de données suiveuse ou dans la base de données de destination perturbent le chemin critique de votre application.
Au lieu de réessayer les écritures échouées sur l'abonné, vous pouvez utiliser Amazon Simple Queue Service pour enregistrer les échecs d'écriture dans une file d'[attente de lettres mortes (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). Le DLQ vous permet d'analyser les écritures échouées sur le suiveur et de déterminer pourquoi le traitement a échoué dans la base de données de destination.
Pour une implémentation à double écriture plus sophistiquée, vous pouvez suivre les AWS meilleures pratiques pour concevoir une séquence de transactions locales à l'aide du [modèle saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html). Un modèle de saga garantit qu'en cas d'échec d'une transaction, la saga exécute des transactions de compensation pour annuler les modifications de base de données apportées par les transactions précédentes.
Lorsque vous utilisez des écritures doubles pour une migration en ligne, vous pouvez configurer les écritures doubles selon le modèle Saga afin que chaque écriture soit une transaction locale afin de garantir les opérations atomiques sur des bases de données hétérogènes. Pour plus d'informations sur la conception d'applications distribuées à l'aide de modèles de conception recommandés pour leAWS Cloud, voir [Modèles de conception, architectures et implémentations dans le cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction).
![\[Implémentation de deux écritures au niveau de la couche application lors de la migration d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Deux écritures au niveau de la messagerie** : au lieu d'implémenter des écritures doubles au niveau de la couche application, vous pouvez utiliser votre niveau de messagerie existant pour effectuer des écritures doubles sur Cassandra et Amazon Keyspaces.
Pour ce faire, vous pouvez configurer un consommateur supplémentaire sur votre plateforme de messagerie pour envoyer des écritures aux deux magasins de données. Cette approche fournit une stratégie simple à faible code utilisant le niveau de messagerie pour créer deux vues cohérentes entre les deux bases de données.
# Téléchargement de données historiques lors d'une migration en ligne
Après avoir implémenté les écritures doubles 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 télé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 entreprise, 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 diverses techniques, par exemple AWS Glue en utilisant des scripts personnalisés pour extraire, transformer et charger (ETL) les données. Pour plus d'informations sur l'utilisation AWS Glue du téléchargement de données historiques, consultez[Processus de migration hors ligne : Apache Cassandra vers Amazon Keyspaces](migrating-offline.md).
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 que celles en cours de téléchargement. Le téléchargement groupé devrait finalement être cohérent, ce qui signifie que les données finiront par atteindre tous les nœuds.
Si les mêmes données sont mises à jour 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 garantir que vous conservez les dernières mises à jour de vos données, même pendant l'importation en bloc, 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](functional-differences.md#functional-differences.light-transactions) (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 modification ou l'état.
En outre, Amazon Keyspaces prend en charge la fonction d'horodatage Cassandra`WRITETIME`. Vous pouvez utiliser les horodatages côté client d'Amazon Keyspaces pour préserver les horodatages de la base de données source et implémenter la résolution des conflits. last-writer-wins Pour de plus amples informations, veuillez consulter [Horodatages côté client dans Amazon Keyspaces](client-side-timestamps.md).
+ **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. Le TTL vous permet de définir une période après laquelle les données sont automatiquement supprimées de la base de données.
Pendant 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 les nouvelles écritures à Amazon Keyspaces uniquement à l'aide de la méthode d'écriture double. Au fil du temps, alors que les anciennes données expirent continuellement dans le cluster Cassandra et que les nouvelles données sont écrites à l'aide de la méthode à double écriture, Amazon Keyspaces les rattrapent automatiquement pour contenir les mêmes données que Cassandra.
Cette approche permet de réduire considérablement 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 soumis à des exigences différentes en matière de conservation des données. Pour plus d’informations sur TTL, consultez [Expirer les données avec Time to Live (TTL) pour Amazon Keyspaces (pour Apache Cassandra)](TTL.md).
Prenons l'exemple suivant de migration de Cassandra vers Amazon Keyspaces à l'aide de l'expiration des données TTL. Dans cet exemple, nous avons défini le TTL pour les deux bases de données sur 60 jours et nous 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, chacune d'entre elles étant d'une durée de 30 jours.
Le fonctionnement du processus de migration pour chaque phase est illustré dans les images suivantes.
![\[Utilisation du TTL pour faire expirer les données historiques lors de la migration d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. 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 qui n'ont pas encore atteint 60 jours de rétention, 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 protocole TTL. À ce stade, Amazon Keyspaces contient 50 % des données stockées dans le cluster Cassandra, qui est composé des nouvelles écritures moins les données historiques.
1. Après 60 jours, le cluster Cassandra et Amazon Keyspaces contiennent les mêmes données écrites au cours des 60 derniers jours.
1. Dans les 90 jours, Cassandra et Amazon Keyspaces contiennent les mêmes données et expirent au même rythme.
Cet exemple montre comment éviter de télécharger des données historiques en utilisant le protocole TTL avec une date d'expiration fixée à 60 jours.
# Validation de la cohérence des données lors d'une migration en ligne
La prochaine étape du processus de migration en ligne est la validation des données. Les écritures doubles ajoutent de nouvelles données à votre base de données Amazon Keyspaces et vous avez terminé la migration des données historiques par téléchargement groupé ou par expiration des données avec TTL.
Vous pouvez maintenant utiliser la phase de validation pour confirmer que les deux magasins de données contiennent en fait les mêmes données et renvoient les mêmes résultats de lecture. Vous pouvez choisir l'une des deux options suivantes pour vérifier que vos deux bases de données contiennent des données identiques.
+ **Lectures doubles** : pour vérifier que la base de données source et la base de données de destination contiennent le même ensemble de données nouvellement écrites et historiques, vous pouvez implémenter des lectures doubles. Pour ce faire, vous pouvez lire à la fois dans votre base de données Cassandra principale et dans votre base de données Amazon Keyspaces secondaire de la même manière que la méthode à double écriture et vous comparez les résultats de manière asynchrone.
Les résultats de la base de données principale sont renvoyés au client, et les résultats de la base de données secondaire sont utilisés pour être validés par rapport au jeu de résultats principal. Les différences détectées peuvent être enregistrées ou envoyées dans une [file d'attente de lettres mortes (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) pour un rapprochement ultérieur.
Dans le schéma suivant, l'application effectue une lecture synchrone depuis Cassandra (qui est le magasin de données principal) et une lecture asynchrone depuis Amazon Keyspaces, qui est le magasin de données secondaire.
![\[Utilisation de deux lectures pour valider la cohérence des données lors d'une migration en ligne d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Exemples de lectures** — Une solution alternative qui ne nécessite pas de modification du code de l'application consiste à utiliser des AWS Lambda fonctions pour échantillonner périodiquement et aléatoirement les données du cluster Cassandra source et de la base de données Amazon Keyspaces de destination.
Ces fonctions Lambda peuvent être configurées pour s'exécuter à intervalles réguliers. La fonction Lambda extrait un sous-ensemble aléatoire de données des systèmes source et de destination, puis effectue une comparaison des données échantillonnées. Toute divergence ou inadéquation entre les deux ensembles de données peut être enregistrée et envoyée à une [file d'attente dédiée (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) pour un rapprochement ultérieur.
Ce processus est illustré dans le diagramme suivant.
![\[Utilisation d'exemples de lecture pour valider la cohérence des données lors de la migration en ligne d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migration de l'application lors d'une migration en ligne
Au cours de la quatrième phase d'une migration en ligne, vous migrez votre application et passez à Amazon Keyspaces en tant que banque de données principale. Cela signifie que vous basculez votre application pour lire et écrire directement depuis et vers Amazon Keyspaces. Pour garantir un minimum de perturbations à vos utilisateurs, ce processus doit être bien planifié et coordonné.
Deux solutions différentes recommandées pour la migration des applications sont disponibles : la stratégie blue green cut over et la stratégie canari cut over. Les sections suivantes décrivent ces stratégies de manière plus détaillée.
+ **Stratégie bleu-vert** — En utilisant cette approche, vous changez d'application pour traiter Amazon Keyspaces comme le magasin de données principal et Cassandra comme le magasin de données secondaire en une seule étape. Vous pouvez le faire à l'aide d'un indicateur de AWS AppConfig fonctionnalité pour contrôler le choix des magasins de données principaux et secondaires dans l'instance de l'application. Pour plus d'informations sur les indicateurs de fonctionnalité, consultez la section [Création d'un profil de configuration d'indicateurs de fonctionnalité dans AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Après avoir fait d'Amazon Keyspaces le principal magasin de données, vous surveillez le comportement et les performances de l'application pour vous assurer qu'Amazon Keyspaces répond à vos exigences et que la migration est réussie.
Par exemple, si vous avez implémenté la double lecture pour votre application, pendant la phase de migration de l'application, vous transférez les lectures principales de Cassandra vers Amazon Keyspaces et les lectures secondaires d'Amazon Keyspaces vers Cassandra. Après la transition, vous continuez à surveiller et à comparer les résultats comme décrit dans la section de [validation des données](migration-online-validation.md) afin de garantir la cohérence entre les deux bases de données avant de mettre Cassandra hors service.
Si vous détectez des problèmes, vous pouvez rapidement revenir à l'état précédent en reprenant Cassandra comme banque de données principale. Vous ne passez à la phase de mise hors service de la migration que si Amazon Keyspaces répond à tous vos besoins en tant que magasin de données principal.
![\[Utilisation de la stratégie bleu-vert pour migrer une application d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Stratégie Canary** — Dans cette approche, vous déployez progressivement la migration vers un sous-ensemble de vos utilisateurs ou de votre trafic. Au départ, un faible pourcentage du trafic de votre application, par exemple 5 % de l'ensemble du trafic, est acheminé vers la version utilisant Amazon Keyspaces comme magasin de données principal, tandis que le reste du trafic continue d'utiliser Cassandra comme magasin de données principal.
Cela vous permet de tester de manière approfondie la version migrée avec le trafic réel, de surveiller ses performances, sa stabilité et d'étudier les problèmes potentiels. Si vous ne détectez aucun problème, vous pouvez augmenter progressivement le pourcentage de trafic acheminé vers Amazon Keyspaces jusqu'à ce qu'il devienne le principal magasin de données pour tous les utilisateurs et le trafic.
Ce déploiement par étapes minimise le risque d'interruptions de service généralisées et permet un processus de migration plus contrôlé. Si des problèmes critiques surviennent lors du déploiement de Canary, vous pouvez rapidement revenir à la version précédente en utilisant Cassandra comme base de données principale pour le segment de trafic concerné. Vous ne passez à la phase de mise hors service de la migration qu'après avoir vérifié qu'Amazon Keyspaces traite 100 % de vos utilisateurs et de votre trafic comme prévu.
Le schéma suivant illustre les différentes étapes de la stratégie Canary.
![\[Utilisation de la stratégie Canary pour migrer une application d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Mise hors service de Cassandra après une migration en ligne
Une fois que la migration de l'application est terminée, que votre application est entièrement exécutée sur Amazon Keyspaces et que vous avez validé la cohérence des données sur une certaine période, vous pouvez planifier de mettre hors service votre cluster Cassandra. Au cours de cette phase, vous pouvez évaluer si les données restantes dans votre cluster Cassandra doivent être archivées ou peuvent être supprimées. Cela dépend des politiques de votre organisation en matière de traitement et de conservation des données.
En suivant cette stratégie et en tenant compte des meilleures pratiques recommandées décrites dans cette rubrique lors de la planification de votre migration en ligne de Cassandra vers Amazon Keyspaces, vous pouvez garantir une transition fluide vers Amazon Keyspaces tout en read-after-write préservant la cohérence et la disponibilité de votre application.
La migration d'Apache Cassandra vers Amazon Keyspaces peut apporter de nombreux avantages, notamment une réduction des coûts opérationnels, une mise à l'échelle automatique, une sécurité améliorée et un cadre qui vous aide à atteindre vos objectifs de conformité. En planifiant une stratégie de migration en ligne comprenant deux écritures, le téléchargement des données historiques, la validation des données et un déploiement progressif, vous pouvez garantir une transition fluide avec un minimum de perturbations pour votre application et ses utilisateurs.
La mise en œuvre de la stratégie de migration en ligne décrite dans cette rubrique vous permet de valider les résultats de la migration, d'identifier et de résoudre les problèmes éventuels, puis de mettre hors service votre déploiement Cassandra existant au profit du service Amazon Keyspaces entièrement géré.
# Processus de migration hors ligne : Apache Cassandra vers Amazon Keyspaces
Les migrations hors ligne conviennent lorsque vous pouvez vous permettre une interruption de service pour effectuer la migration. Il est courant dans les entreprises d'avoir des fenêtres de maintenance pour les correctifs, les versions volumineuses ou des temps d'arrêt pour les mises à niveau matérielles ou les mises à niveau majeures. La migration hors ligne peut utiliser cette fenêtre pour copier des données et transférer le trafic de l'application d'Apache Cassandra vers Amazon Keyspaces.
La migration hors ligne réduit les modifications apportées à l'application car elle ne nécessite pas de communication simultanée avec Cassandra et Amazon Keyspaces. De plus, lorsque le flux de données est suspendu, l'état exact peut être copié sans conserver les mutations.
Dans cet exemple, nous utilisons Amazon Simple Storage Service (Amazon S3) comme zone intermédiaire pour les données lors de la migration hors ligne afin de minimiser les temps d'arrêt. Vous pouvez importer automatiquement les données que vous avez stockées au format Parquet dans Amazon S3 dans une table Amazon Keyspaces à l'aide du connecteur Spark Cassandra et. AWS Glue La section suivante va présenter un aperçu général du processus. Vous pouvez trouver des exemples de code pour ce processus sur [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue).
Le processus de migration hors ligne d'Apache Cassandra vers Amazon Keyspaces à l'aide d'Amazon S3 nécessite AWS Glue les AWS Glue tâches suivantes.
1. Une tâche ETL qui extrait et transforme les données CQL et les stocke dans un compartiment Amazon S3.
1. Une deuxième tâche qui importe les données du bucket vers Amazon Keyspaces.
1. Une troisième tâche pour importer des données incrémentielles.
**Comment effectuer une migration hors ligne vers Amazon Keyspaces depuis Cassandra exécutée sur Amazon EC2 dans un Amazon Virtual Private Cloud**
1. Vous devez d'abord AWS Glue exporter les données de table de Cassandra au format Parquet et les enregistrer dans un compartiment Amazon S3. Vous devez exécuter une AWS Glue tâche à l'aide d'un AWS Glue connecteur vers un VPC où réside l' EC2 instance Amazon exécutant Cassandra. Ensuite, à l'aide du point de terminaison privé Amazon S3, vous pouvez enregistrer des données dans le compartiment Amazon S3.
Le schéma suivant illustre ces étapes.
![\[Migration des données Apache Cassandra d'Amazon EC2 exécuté dans un VPC vers un compartiment Amazon S3 à l'aide de. AWS Glue\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Répartissez les données dans le compartiment Amazon S3 pour améliorer la randomisation des données. Les données importées de manière uniforme permettent de répartir davantage le trafic dans la table cible.
Cette étape est requise lors de l'exportation de données depuis Cassandra avec de grandes partitions (partitions de plus de 1 000 lignes) afin d'éviter les raccourcis clavier lors de l'insertion des données dans Amazon Keyspaces. Les principaux problèmes affectent `WriteThrottleEvents` Amazon Keyspaces et augmentent le temps de chargement.
![\[Une AWS Glue tâche mélange les données d'un compartiment Amazon S3 et les renvoie dans un autre compartiment Amazon S3.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. Utilisez une autre AWS Glue tâche pour importer des données depuis le compartiment Amazon S3 vers Amazon Keyspaces. Les données mélangées dans le compartiment Amazon S3 sont stockées au format Parquet.
![\[La tâche AWS Glue d'importation prend les données mélangées du compartiment Amazon S3 et les déplace dans une table Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/migration-import.png)
Pour plus d'informations sur le processus de migration hors ligne, consultez l'atelier [Amazon Keyspaces](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue) avec AWS Glue
# Utilisation d'une solution de migration hybride : Apache Cassandra vers Amazon Keyspaces
La solution de migration suivante peut être considérée comme un hybride entre la migration en ligne et hors ligne. Grâce à cette approche hybride, les données sont écrites dans la base de données de destination quasiment en temps réel sans garantir la cohérence entre les lectures et les écritures. Cela signifie que les données nouvellement écrites ne seront pas immédiatement disponibles et que des retards sont à prévoir. Si vous avez besoin de cohérence entre lecture après écriture, consultez[Migration en ligne vers Amazon Keyspaces : stratégies et meilleures pratiques](migrating-online.md).
Pour une migration en temps quasi réel d'Apache Cassandra vers Amazon Keyspaces, vous pouvez choisir entre deux méthodes disponibles.
+ **CQLReplicator**— (Recommandé) CQLReplicator est un utilitaire open source disponible sur [Github](https://github.com/aws-samples/cql-replicator) qui vous aide à migrer des données d'Apache Cassandra vers Amazon Keyspaces en temps quasi réel.
Pour déterminer les écritures et les mises à jour à propager vers la base de données de destination, CQLReplicator scanne la plage de jetons Apache Cassandra et utilise une AWS Glue tâche pour supprimer les événements dupliqués et appliquer les écritures et les mises à jour directement à Amazon Keyspaces.
+ **Capture des données de modification (CDC)** — Si vous connaissez Cassandra CDC, la fonctionnalité CDC intégrée d'Apache Cassandra qui permet de capturer les modifications en copiant le journal de validation dans un répertoire CDC distinct est une autre option pour implémenter une migration hybride.
Vous pouvez le faire en répliquant les modifications apportées aux données sur Amazon Keyspaces, faisant ainsi du CDC une option alternative pour les scénarios de migration de données.
Si vous n'avez pas besoin de cohérence en lecture après écriture, vous pouvez utiliser le pipeline CDC CQLReplicator ou un pipeline CDC pour migrer les données d'Apache Cassandra vers Amazon Keyspaces en fonction de vos préférences et de votre connaissance des outils utilisés dans chaque Services AWS solution. L'utilisation de ces méthodes pour migrer des données en temps quasi réel peut être considérée comme une approche hybride de la migration qui offre une alternative à la migration en ligne.
Cette stratégie est considérée comme une approche hybride, car outre les options décrites dans cette rubrique, vous devez mettre en œuvre certaines étapes de la progression de la migration en ligne, par exemple la copie des données historiques et les stratégies de migration des applications abordées dans la rubrique sur la [migration en ligne](migrating-online.md).
Les sections suivantes présentent plus en détail les options de migration hybride.
**Topics**
+ [Migrez les données en utilisant CQLReplicator](migration-hybrid-cql-rep.md)
+ [Migrer les données à l'aide de la capture des données de modification (CDC)](migration-hybrid-cdc.md)
# Migrez les données en utilisant CQLReplicator
Avec [CQLReplicator](https://github.com/aws-samples/cql-replicator), vous pouvez lire les données d'Apache Cassandra en temps quasi réel en scannant intelligemment l'anneau de jetons Cassandra à l'aide de requêtes CQL. CQLReplicator n'utilise pas le CDC Cassandra et met en œuvre une stratégie de mise en cache pour réduire les pertes de performances liées aux scans complets.
Pour réduire le nombre d'écritures vers la destination, supprime CQLReplicator automatiquement les événements de réplication dupliqués. Vous pouvez ainsi ajuster la réplication des modifications de la base de données source vers la base de données de destination, ce qui permet une migration en temps quasi réel des données d'Apache Cassandra vers Amazon Keyspaces. CQLReplicator
Le schéma suivant montre l'architecture typique d'une CQLReplicator tâche utilisantAWS Glue.
1. **Pour autoriser l'accès à Apache Cassandra exécuté dans un VPC privé, configurez AWS Glue une connexion avec le type de connexion Network.**
1. Pour supprimer les doublons et activer la mise en cache des clés avec la CQLReplicator tâche, configurez Amazon Simple Storage Service (Amazon S3).
1. Le CQLReplicator job diffuse les modifications de la base de données source vérifiée directement sur Amazon Keyspaces.
![\[Utilisation CQLReplicator pour migrer les données d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
Pour plus d'informations sur le processus de migration utilisé CQLReplicator, consultez le billet suivant sur le blog de AWS base de données [Migrer les charges de travail Cassandra vers Amazon Keyspaces en utilisant CQLReplicator](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) et les instructions AWS prescriptives Migrer les [charges de travail Apache Cassandra](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) vers Amazon Keyspaces en utilisant. AWS Glue
# Migrer les données à l'aide de la capture des données de modification (CDC)
Si vous êtes déjà familiarisé avec la configuration d'un pipeline de capture des données de modification (CDC) avec [Debezium](https://debezium.io/), vous pouvez utiliser cette option pour migrer les données vers Amazon Keyspaces au lieu de les utiliser. CQLReplicator Debezium est une plate-forme distribuée open source pour le CDC, conçue pour surveiller une base de données et capturer de manière fiable les modifications au niveau des lignes.
Le [connecteur Debezium pour Apache Cassandra](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) télécharge les modifications apportées à Amazon Managed Streaming for Apache Kafka (Amazon MSK) afin qu'elles puissent être consommées et traitées par les consommateurs en aval qui, à leur tour, écrivent les données sur Amazon Keyspaces. Pour plus d'informations, consultez les [conseils pour la migration continue des données d'Apache Cassandra vers Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
Pour résoudre tout problème potentiel de cohérence des données, vous pouvez mettre en œuvre un processus avec Amazon MSK dans le cadre duquel un consommateur compare les clés ou les partitions de Cassandra à celles d'Amazon Keyspaces.
Pour mettre en œuvre cette solution avec succès, nous vous recommandons de prendre en compte les points suivants.
+ Comment analyser le journal de validation du CDC, par exemple comment supprimer les événements dupliqués.
+ Comment gérer le répertoire CDC, par exemple comment supprimer les anciens journaux.
+ Comment gérer les échecs partiels dans Apache Cassandra, par exemple si une écriture ne réussit que dans une réplique sur trois.
+ Comment gérer l'allocation des ressources, par exemple en augmentant la taille de l'instance pour tenir compte des exigences supplémentaires en termes de processeur, de mémoire, de DISQUE et d'E/S pour le processus CDC qui a lieu sur un nœud.
Ce modèle traite les modifications apportées par Cassandra comme un « indice » indiquant qu'une clé a peut-être changé par rapport à son état précédent. Pour déterminer si des modifications doivent être appliquées à la base de données de destination, vous devez d'abord lire à partir du cluster Cassandra source à l'aide d'une `LOCAL_QUORUM` opération permettant de recevoir les derniers enregistrements, puis les écrire sur Amazon Keyspaces.
Dans le cas de suppressions ou de mises à jour de plages, vous devrez peut-être effectuer une comparaison avec l'ensemble de la partition afin de déterminer quels événements d'écriture ou de mise à jour doivent être écrits dans votre base de données de destination.
Dans les cas où les écritures ne sont pas idempotentes, vous devez également comparer vos écritures avec ce qui se trouve déjà dans la base de données de destination avant d'écrire sur Amazon Keyspaces.
Le schéma suivant montre l'architecture typique d'un pipeline CDC utilisant Debezium et Amazon MSK.
![\[Utilisation d'un pipeline de capture des données de modification pour migrer les données d'Apache Cassandra vers Amazon Keyspaces.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)
# Comment sélectionner le bon outil pour le téléchargement groupé ou la migration de données vers Amazon Keyspaces
Dans cette section, vous pouvez passer en revue les différents outils que vous pouvez utiliser pour télécharger ou migrer des données en masse vers Amazon Keyspaces, et apprendre à sélectionner l'outil approprié en fonction de vos besoins. En outre, cette section fournit une vue d'ensemble et des cas d'utilisation des step-by-step didacticiels disponibles qui montrent comment importer des données dans Amazon Keyspaces.
Pour passer en revue les stratégies disponibles pour migrer les charges de travail d'Apache Cassandra vers Amazon Keyspaces, consultez. [Créez un plan de migration pour migrer d'Apache Cassandra vers Amazon Keyspaces](migrating-cassandra.md)
+ **Outils de migration**
+ Grâce au [calculateur de prix pour Amazon Keyspaces (pour Apache Cassandra)](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra) disponible sur Github, vous pouvez estimer vos coûts mensuels pour Amazon Keyspaces en fonction de votre charge de travail Apache Cassandra existante. Entrez les statistiques issues de la sortie de statut de votre outil de nœud Cassandra et de la configuration sans serveur prévue pour Amazon Keyspaces afin de comparer les coûts directs entre les deux solutions. Notez que ce calculateur se concentre uniquement sur les coûts opérationnels d'Amazon Keyspaces par rapport à votre déploiement Cassandra existant. Il n'inclut pas les facteurs liés au coût total de possession (TCO) tels que la maintenance de l'infrastructure, les frais d'exploitation ou les coûts de support pour Cassandra.
+ Proxy **ZDM Dual Write pour la migration vers Amazon Keyspaces — Le proxy** ZDM Dual Write disponible [sur](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Github prend en charge la migration sans interruption d'Apache Cassandra vers Amazon Keyspaces.
+ **CQLReplicator**— CQLReplicator est un utilitaire open source disponible sur [Github](https://github.com/aws-samples/cql-replicator) qui vous aide à migrer des données d'Apache Cassandra vers Amazon Keyspaces en temps quasi réel.
Pour de plus amples informations, veuillez consulter [Migrez les données en utilisant CQLReplicator](migration-hybrid-cql-rep.md).
+ Pour en savoir plus sur l'utilisation d'Amazon Managed Streaming pour Apache Kafka afin de mettre en œuvre un processus de [migration en ligne](migrating-online.md) avec des écritures doubles, consultez les [instructions relatives à la migration continue des données d'Apache Cassandra vers Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
+ Pour les migrations de grande envergure, pensez à utiliser un outil d'extraction, de transformation et de chargement (ETL). Vous pouvez l'utiliser AWS Glue pour effectuer rapidement et efficacement des migrations de transformation de données. Pour de plus amples informations, veuillez consulter [Processus de migration hors ligne : Apache Cassandra vers Amazon Keyspaces](migrating-offline.md).
+ Pour savoir comment utiliser le connecteur Apache Cassandra Spark pour écrire des données sur Amazon Keyspaces, consultez. [Tutoriel : Intégrer à Apache Spark pour importer ou exporter des données](spark-integrating.md)
+ Commencez rapidement à charger des données dans Amazon Keyspaces à l'aide de la `COPY FROM` commande cqlsh. cqlsh est inclus dans Apache Cassandra et convient parfaitement au chargement de petits ensembles de données ou de données de test. Pour step-by-step obtenir des instructions, voir[Tutoriel : Chargement de données dans Amazon Keyspaces à l'aide de cqlsh](bulk-upload.md).
+ Vous pouvez également utiliser le DataStax Bulk Loader pour Apache Cassandra pour charger des données dans Amazon Keyspaces à l'aide `dsbulk` de la commande. DSBulk[fournit des fonctionnalités d'importation plus robustes que cqlsh et est disponible depuis le GitHub référentiel.](https://github.com/datastax/dsbulk) Pour step-by-step obtenir des instructions, voir[Tutoriel : Chargement de données dans Amazon Keyspaces à l'aide de DSBulk](dsbulk-upload.md).
Considérations générales relatives aux téléchargements de données vers Amazon Keyspaces
+ **Divisez le téléchargement des données en composants plus petits.**
Tenez compte des unités de migration suivantes et de leur empreinte potentielle en termes de taille des données brutes. Le téléchargement de petites quantités de données en une ou plusieurs phases peut contribuer à simplifier votre migration.
+ **Par cluster** : migrez toutes vos données Cassandra en une seule fois. Cette approche peut convenir aux petits clusters.
+ **Par espace de touches ou par table** : divisez votre migration en groupes d'espaces de touches ou de tables. Cette approche peut vous aider à migrer les données par étapes en fonction de vos besoins pour chaque charge de travail.
+ **Par données** — Envisagez de migrer les données pour un groupe spécifique d'utilisateurs ou de produits, afin de réduire encore davantage la taille des données.
+ **Priorisez les données à télécharger en premier en fonction de la simplicité.**
Déterminez si vous avez des données qui pourraient d'abord être migrées plus facilement, par exemple des données qui ne changent pas à des moments précis, des données provenant de traitements par lots effectués la nuit, des données non utilisées pendant les heures hors ligne ou des données provenant d'applications internes.
**Topics**
+ [Tutoriel : Chargement de données dans Amazon Keyspaces à l'aide de cqlsh](bulk-upload.md)
+ [Tutoriel : Chargement de données dans Amazon Keyspaces à l'aide de DSBulk](dsbulk-upload.md)
# Tutoriel : Chargement de données dans Amazon Keyspaces à l'aide de cqlsh
Ce didacticiel vous guide tout au long du processus de migration des données d'Apache Cassandra vers Amazon Keyspaces à l'aide de la commande. `cqlsh COPY FROM` La `cqlsh COPY FROM` commande est utile pour télécharger rapidement et facilement de petits ensembles de données sur Amazon Keyspaces à des fins académiques ou de test. Pour plus d'informations sur la façon de migrer les charges de travail de production, consultez[Processus de migration hors ligne : Apache Cassandra vers Amazon Keyspaces](migrating-offline.md). Dans ce didacticiel, vous allez effectuer les étapes suivantes :
Conditions préalables : configurez un AWS compte avec des informations d'identification, créez un fichier JKS Trust Store pour le certificat et configurez-le pour vous connecter `cqlsh` à Amazon Keyspaces.
1. **Créer un fichier CSV source et une table cible** : préparez un fichier CSV en tant que données source et créez le keyspace et le tableau cibles dans Amazon Keyspaces.
1. **Préparation des données** : répartissez les données du fichier CSV de manière aléatoire et analysez-les pour déterminer les tailles de ligne moyennes et maximales.
1. **Définissez la capacité de débit** : calculez les unités de capacité d'écriture requises (WCUs) en fonction de la taille des données et du temps de chargement souhaité, puis configurez la capacité allouée à la table.
1. **Configurer les paramètres cqlsh** : déterminez les valeurs optimales pour des `cqlsh COPY FROM` paramètres tels que`INGESTRATE`, `NUMPROCESSES``MAXBATCHSIZE`, et pour répartir la charge `CHUNKSIZE` de travail de manière uniforme.
1. **Exécuter la `cqlsh COPY FROM` commande** : exécutez la `cqlsh COPY FROM` commande pour télécharger les données du fichier CSV vers le tableau Amazon Keyspaces et suivre la progression.
Dépannage — Résolvez les problèmes courants tels que les demandes non valides, les erreurs d'analyseur, les erreurs de capacité et les erreurs cqlsh lors du processus de téléchargement des données.
**Topics**
+ [Conditions préalables : étapes à suivre avant de pouvoir télécharger des données à l'aide de `cqlsh COPY FROM`](bulk-upload-prequs.md)
+ [Étape 1 : Création du fichier CSV source et d'une table cible pour le téléchargement des données](bulk-upload-source.md)
+ [Étape 2 : Préparation des données sources pour un téléchargement de données réussi](bulk-upload-prepare-data.md)
+ [Étape 3 : définir la capacité de débit de la table](bulk-upload-capacity.md)
+ [Étape 4 : Configuration des `cqlsh COPY FROM` paramètres](bulk-upload-config.md)
+ [Étape 5 : Exécuter la `cqlsh COPY FROM` commande pour télécharger les données du fichier CSV vers la table cible](bulk-upload-run.md)
+ [Résolution des problèmes](bulk-upload-troubleshooting.md)
# Conditions préalables : étapes à suivre avant de pouvoir télécharger des données à l'aide de `cqlsh COPY FROM`
Vous devez effectuer les tâches suivantes avant de pouvoir commencer ce didacticiel.
1. Si ce n'est pas déjà fait, inscrivez-vous Compte AWS en suivant les étapes indiquées sur[Con Gestion des identités et des accès AWS figuration](accessing.md#SettingUp.IAM).
1. Créez des informations d'identification spécifiques au service en suivant les étapes décrites dans. [Créez des informations d'identification spécifiques au service pour un accès programmatique à Amazon Keyspaces](programmatic.credentials.ssc.md)
1. Configurez la connexion au shell Cassandra Query Language (cqlsh) et confirmez que vous pouvez vous connecter à Amazon Keyspaces en suivant les étapes indiquées sur. [Utilisation `cqlsh` pour se connecter à Amazon Keyspaces](programmatic.cqlsh.md)
# Étape 1 : Création du fichier CSV source et d'une table cible pour le téléchargement des données
Pour ce didacticiel, nous utilisons un fichier de valeurs séparées par des virgules (CSV) dont le `keyspaces_sample_table.csv` nom est le fichier source pour la migration des données. Le fichier d'exemple fourni contient quelques lignes de données pour une table portant le nom`book_awards`.
1. Créez le fichier source. Vous pouvez choisir l’une des options suivantes :
+ Téléchargez l'exemple de fichier CSV (`keyspaces_sample_table.csv`) contenu dans le fichier d'archive [samplemigration.zip](samples/samplemigration.zip) suivant. Décompressez l'archive et notez le chemin vers`keyspaces_sample_table.csv`.
+ Pour remplir un fichier CSV avec vos propres données stockées dans une base de données Apache Cassandra, vous pouvez remplir le fichier CSV source à l'aide de l'`cqlsh``COPY TO`instruction illustrée dans l'exemple suivant.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true";
```
Assurez-vous que le fichier CSV que vous créez répond aux exigences suivantes :
+ La première ligne contient les noms des colonnes.
+ Les noms des colonnes du fichier CSV source correspondent aux noms des colonnes de la table cible.
+ Les données sont délimitées par une virgule.
+ Toutes les valeurs de données sont des types de données Amazon Keyspaces valides. Consultez [Types de données](cql.elements.md#cql.data-types).
1. Créez le keyspace et le tableau cibles dans Amazon Keyspaces.
1. Connectez-vous à Amazon Keyspaces en utilisant`cqlsh`, en remplaçant le point de terminaison du service, le nom d'utilisateur et le mot de passe dans l'exemple suivant par vos propres valeurs.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Créez un nouvel espace de touches avec le `catalog` nom indiqué dans l'exemple suivant.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Lorsque le nouvel espace de touches est disponible, utilisez le code suivant pour créer la table `book_awards` cible.
```
CREATE TABLE "catalog.book_awards" (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Si Apache Cassandra est votre source de données d'origine, un moyen simple de créer la table cible Amazon Keyspaces avec les en-têtes correspondants consiste à générer `CREATE TABLE` l'instruction à partir de la table source, comme indiqué dans l'instruction suivante.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Créez ensuite la table cible dans Amazon Keyspaces avec les noms des colonnes et les types de données correspondant à la description de la table source de Cassandra.
# Étape 2 : Préparation des données sources pour un téléchargement de données réussi
La préparation des données sources pour un transfert efficace est un processus en deux étapes. Tout d'abord, vous répartissez les données de manière aléatoire. Au cours de la deuxième étape, vous analysez les données pour déterminer les valeurs de `cqlsh` paramètres appropriées et les paramètres de table requis afin de garantir le succès du téléchargement des données.
**Randomiser les données**
La `cqlsh COPY FROM` commande lit et écrit les données dans l'ordre dans lequel elles apparaissent dans le fichier CSV. Si vous utilisez la `cqlsh COPY TO` commande pour créer le fichier source, les données sont écrites dans un ordre trié par clé dans le fichier CSV. En interne, Amazon Keyspaces partitionne les données à l'aide de clés de partition. Bien qu'Amazon Keyspaces intègre une logique permettant d'équilibrer la charge des demandes pour la même clé de partition, le chargement des données est plus rapide et plus efficace si vous répartissez la commande de manière aléatoire. En effet, vous pouvez tirer parti de l'équilibrage de charge intégré qui se produit lorsque Amazon Keyspaces écrit sur différentes partitions.
Pour répartir uniformément les écritures sur les partitions, vous devez répartir les données de manière aléatoire dans le fichier source. Vous pouvez écrire une application pour cela ou utiliser un outil open source, tel que [Shuf](https://en.wikipedia.org/wiki/Shuf). Shuf est disponible gratuitement sur les distributions Linux, sur macOS (en installant coreutils dans [homebrew](https://brew.sh)) et sur Windows (en utilisant le sous-système Windows pour Linux (WSL)). Une étape supplémentaire est nécessaire pour éviter que la ligne d'en-tête contenant les noms des colonnes ne soit modifiée au cours de cette étape.
Pour randomiser le fichier source tout en préservant l'en-tête, entrez le code suivant.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf réécrit les données dans un nouveau fichier CSV appelé. `keyspace.table.csv` Vous pouvez désormais supprimer le `keyspaces_sample_table.csv` fichier, vous n'en avez plus besoin.
**Analyser les données**
Déterminez la taille moyenne et maximale des lignes en analysant les données.
Vous le faites pour les raisons suivantes :
+ La taille moyenne des lignes permet d'estimer la quantité totale de données à transférer.
+ Vous avez besoin de la taille de ligne moyenne pour fournir la capacité d'écriture nécessaire au téléchargement des données.
+ Vous pouvez vous assurer que la taille de chaque ligne est inférieure à 1 Mo, ce qui correspond à la taille de ligne maximale dans Amazon Keyspaces.
**Note**
Ce quota fait référence à la taille des lignes et non à la taille de la partition. Contrairement aux partitions Apache Cassandra, les partitions Amazon Keyspaces peuvent être de taille pratiquement indépendante. Les clés de partition et les colonnes de clustering nécessitent un espace de stockage supplémentaire pour les métadonnées, que vous devez ajouter à la taille brute des lignes. Pour de plus amples informations, veuillez consulter [Estimer la taille des lignes dans Amazon Keyspaces](calculating-row-size.md).
Le code suivant utilise [AWK](https://en.wikipedia.org/wiki/AWK) pour analyser un fichier CSV et imprimer la taille de ligne moyenne et maximale.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
L'exécution de ce code génère le résultat suivant.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Vous utiliserez la taille de ligne moyenne à l'étape suivante de ce didacticiel pour configurer la capacité d'écriture de la table.
# Étape 3 : définir la capacité de débit de la table
Ce didacticiel explique comment régler cqlsh pour charger des données dans un intervalle de temps défini. Comme vous savez à l'avance combien de lectures et d'écritures vous devez effectuer, utilisez le mode capacité provisionnée. Une fois le transfert de données terminé, vous devez définir le mode de capacité de la table en fonction des modèles de trafic de votre application. Pour en savoir plus sur la gestion des capacités, voir[Gestion des ressources sans serveur dans Amazon Keyspaces (pour Apache Cassandra)](serverless_resource_management.md).
Avec le mode capacité provisionnée, vous spécifiez à l'avance la capacité de lecture et d'écriture que vous souhaitez allouer à votre table. La capacité d'écriture est facturée à l'heure et mesurée en unités de capacité d'écriture ()WCUs. Chaque WCU possède une capacité d'écriture suffisante pour prendre en charge l'écriture de 1 Ko de données par seconde. Lorsque vous chargez les données, le taux d'écriture doit être inférieur au maximum WCUs (paramètre :`write_capacity_units`) défini sur la table cible.
Par défaut, vous pouvez provisionner jusqu'à 40 000 tables WCUs pour une table et 80 000 pour WCUs toutes les tables de votre compte. Si vous avez besoin de capacités supplémentaires, vous pouvez demander une augmentation de quota dans la console [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas). Pour plus d’informations sur les quotas, consultez [Quotas pour Amazon Keyspaces (pour Apache Cassandra)](quotas.md).
**Calculez le nombre moyen de WCUs caractères requis pour un encart**
L'insertion de 1 Ko de données par seconde nécessite 1 WCU. Si votre fichier CSV comporte 360 000 lignes et que vous souhaitez charger toutes les données en 1 heure, vous devez écrire 100 lignes par seconde (360 000 lignes/60 minutes/60 secondes = 100 lignes par seconde). Si chaque ligne contient jusqu'à 1 Ko de données, pour insérer 100 lignes par seconde, vous devez fournir 100 lignes WCUs à votre table. Si chaque ligne contient 1,5 Ko de données, il vous en faut deux WCUs pour insérer une ligne par seconde. Par conséquent, pour insérer 100 lignes par seconde, vous devez en prévoir 200 WCUs.
Pour déterminer le nombre de WCUs lignes à insérer par seconde, divisez la taille moyenne des lignes en octets par 1024 et arrondissez au nombre entier le plus proche.
Par exemple, si la taille moyenne des lignes est de 3 000 octets, il vous en faut trois WCUs pour insérer une ligne par seconde.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Calculer le temps et la capacité de chargement des données**
Maintenant que vous connaissez la taille moyenne et le nombre de lignes de votre fichier CSV, vous pouvez calculer le nombre WCUs de lignes nécessaires pour charger les données dans un laps de temps donné, ainsi que le temps approximatif nécessaire pour charger toutes les données de votre fichier CSV en utilisant différents paramètres WCU.
Par exemple, si chaque ligne de votre fichier fait 1 Ko et que votre fichier CSV contient 1 000 000 de lignes, pour charger les données en 1 heure, vous devez affecter au moins 278 lignes WCUs à votre table pour cette heure.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Configuration des paramètres de capacité provisionnée**
Vous pouvez définir les paramètres de capacité d'écriture d'une table lorsque vous créez la table ou à l'aide de la commande `ALTER TABLE` CQL. Voici la syntaxe permettant de modifier les paramètres de capacité provisionnée d'une table à l'aide de l'instruction `ALTER TABLE` CQL.
```
ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Pour la référence linguistique complète, voir[ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter).
# Étape 4 : Configuration des `cqlsh COPY FROM` paramètres
Cette section explique comment déterminer les valeurs des paramètres pour`cqlsh COPY FROM`. La `cqlsh COPY FROM` commande lit le fichier CSV que vous avez préparé précédemment et insère les données dans Amazon Keyspaces à l'aide de CQL. La commande divise les lignes et répartit les `INSERT` opérations entre un ensemble de travailleurs. Chaque collaborateur établit une connexion avec Amazon Keyspaces et envoie des `INSERT` demandes via ce canal.
La `cqlsh COPY` commande n'a pas de logique interne permettant de répartir le travail de manière égale entre ses employés. Cependant, vous pouvez le configurer manuellement pour vous assurer que le travail est réparti de manière uniforme. Commencez par passer en revue les principaux paramètres cqlsh suivants :
+ **DÉLIMITEUR** — Si vous avez utilisé un délimiteur autre qu'une virgule, vous pouvez définir ce paramètre, dont la valeur par défaut est une virgule.
+ **INGESTRATE** — Nombre cible de lignes à `cqlsh COPY FROM` traiter par seconde. S'il n'est pas défini, la valeur par défaut est de 100 000.
+ **NUMPROCESSES** — Le nombre de processus enfants créés par cqlsh pour les tâches. `COPY FROM` Le maximum pour ce paramètre est de 16, la valeur par défaut `num_cores - 1` `num_cores` étant le nombre de cœurs de traitement sur l'hôte exécutant cqlsh.
+ **MAXBATCHSIZE — La taille** du lot détermine le nombre maximal de lignes insérées dans la table de destination en un seul lot. S'il n'est pas défini, cqlsh utilise des lots de 20 lignes insérées.
+ **CHUNKSIZE** — Taille de l'unité de travail transmise à l'enfant travailleur. Par défaut, il est défini sur 5 000.
+ **MAXATTEMPTS** — Le nombre maximum de fois où il est possible de réessayer un worker chunk ayant échoué. Une fois le nombre maximal de tentatives atteint, les enregistrements ayant échoué sont écrits dans un nouveau fichier CSV que vous pourrez réexécuter ultérieurement après avoir examiné l'échec.
`INGESTRATE`Défini en fonction du nombre de ceux WCUs que vous avez provisionnés dans la table de destination cible. La `INGESTRATE` `cqlsh COPY FROM` commande n'est pas une limite, c'est une moyenne cible. Cela signifie qu'il peut (et c'est souvent le cas) dépasser le nombre que vous avez défini. Pour tenir compte des rafales et vous assurer que la capacité est suffisante pour traiter les demandes de chargement de données, définissez 90 % `INGESTRATE` de la capacité d'écriture de la table.
```
INGESTRATE = WCUs * .90
```
Définissez ensuite le `NUMPROCESSES` paramètre sur une valeur inférieure d'un au nombre de cœurs de votre système. Pour connaître le nombre de cœurs de votre système, vous pouvez exécuter le code suivant.
```
python -c "import multiprocessing; print(multiprocessing.cpu_count())"
```
Pour ce didacticiel, nous utilisons la valeur suivante.
```
NUMPROCESSES = 4
```
Chaque processus crée un travailleur, et chaque travailleur établit une connexion à Amazon Keyspaces. Amazon Keyspaces peut prendre en charge jusqu'à 3 000 demandes CQL par seconde à chaque connexion. Cela signifie que vous devez vous assurer que chaque travailleur traite moins de 3 000 demandes par seconde.
Comme c'est le cas`INGESTRATE`, les travailleurs dépassent souvent le nombre que vous avez défini et ne sont pas limités par les secondes d'horloge. Par conséquent, pour tenir compte des rafales, définissez vos paramètres cqlsh de manière à ce que chaque travailleur traite 2 500 demandes par seconde. Pour calculer la quantité de travail distribuée à un travailleur, suivez les directives suivantes.
+ Divisez `INGESTRATE` par`NUMPROCESSES`.
+ Si`INGESTRATE`/`NUMPROCESSES`> 2 500, abaissez le `INGESTRATE` pour que cette formule soit vraie.
```
INGESTRATE / NUMPROCESSES <= 2,500
```
Avant de configurer les paramètres pour optimiser le téléchargement de nos exemples de données, examinons les paramètres `cqlsh` par défaut et voyons comment leur utilisation influe sur le processus de téléchargement des données. Dans la `cqlsh COPY FROM` mesure où il est utilisé `CHUNKSIZE` pour créer des parties du travail (`INSERT`déclarations) à distribuer aux travailleurs, le travail n'est pas automatiquement distribué de manière uniforme. Certains travailleurs peuvent rester inactifs, selon le `INGESTRATE` réglage.
Pour répartir le travail de manière égale entre les travailleurs et maintenir chaque travailleur au taux optimal de 2 500 demandes par seconde, vous devez définir `CHUNKSIZE``MAXBATCHSIZE`, et `INGESTRATE` en modifiant les paramètres d'entrée. Pour optimiser l'utilisation du trafic réseau pendant le chargement des données, choisissez une valeur proche de la valeur maximale de 30. `MAXBATCHSIZE` En passant `CHUNKSIZE` à 100 et `MAXBATCHSIZE` à 25, les 10 000 rangées sont réparties uniformément entre les quatre travailleurs (10 000/ 2500 = 4).
L'exemple de code suivant illustre cela.
```
INGESTRATE = 10,000
NUMPROCESSES = 4
CHUNKSIZE = 100
MAXBATCHSIZE. = 25
Work Distribution:
Connection 1 / Worker 1 : 2,500 Requests per second
Connection 2 / Worker 2 : 2,500 Requests per second
Connection 3 / Worker 3 : 2,500 Requests per second
Connection 4 / Worker 4 : 2,500 Requests per second
```
En résumé, utilisez les formules suivantes lors de la définition `cqlsh COPY FROM` des paramètres :
+ **INGESTRATE** = write\$1capacity\$1units \$1 .90
+ **NUMPROCESSES** = num\$1cores -1 (par défaut)
+ **INGESTRATE/NUMPROCESSES** = 2 500 (Cette déclaration doit être vraie.)
+ **MAXBATCHSIZE** = 30 (20 par défaut). Amazon Keyspaces accepte des lots allant jusqu'à 30.)
+ **CHUNKSIZE** = (INGESTRATE/ NUMPROCESSES)/MAXBATCHSIZE
Maintenant que vous avez calculé `NUMPROCESSES``INGESTRATE`, et`CHUNKSIZE`, vous êtes prêt à charger vos données.
# Étape 5 : Exécuter la `cqlsh COPY FROM` commande pour télécharger les données du fichier CSV vers la table cible
Pour exécuter la `cqlsh COPY FROM` commande, procédez comme suit.
1. Connectez-vous à Amazon Keyspaces à l'aide de cqlsh.
1. Choisissez votre keyspace à l'aide du code suivant.
```
USE catalog;
```
1. Définissez la cohérence d'écriture sur`LOCAL_QUORUM`. Pour garantir la durabilité des données, Amazon Keyspaces n'autorise aucun autre paramètre de cohérence d'écriture. Consultez le code suivant.
```
CONSISTENCY LOCAL_QUORUM;
```
1. Préparez votre `cqlsh COPY FROM` syntaxe à l'aide de l'exemple de code suivant.
```
COPY book_awards FROM './keyspace.table.csv' WITH HEADER=true
AND INGESTRATE=calculated ingestrate
AND NUMPROCESSES=calculated numprocess
AND MAXBATCHSIZE=20
AND CHUNKSIZE=calculated chunksize;
```
1. Exécutez l'instruction préparée à l'étape précédente. cqlsh renvoie tous les paramètres que vous avez configurés.
1. Assurez-vous que les paramètres correspondent à ce que vous avez saisi. Consultez l'exemple suivant.
```
Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'}
Using 15 child processes
```
1. Vérifiez le nombre de lignes transférées et le taux moyen actuel, comme indiqué dans l'exemple suivant.
```
Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s
```
1. Lorsque cqlsh a fini de télécharger les données, consultez le résumé des statistiques de chargement des données (nombre de fichiers lus, temps d'exécution et lignes ignorées) comme indiqué dans l'exemple suivant.
```
15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped).
```
Dans cette dernière étape du didacticiel, vous avez chargé les données sur Amazon Keyspaces.
**Important**
Maintenant que vous avez transféré vos données, ajustez les paramètres du mode capacité de votre table cible pour qu'ils correspondent aux modèles de trafic habituels de votre application. Vous êtes facturé au taux horaire pour votre capacité provisionnée jusqu'à ce que vous la modifiiez.
# Résolution des problèmes
Une fois le téléchargement des données terminé, vérifiez si des lignes ont été ignorées. Pour ce faire, accédez au répertoire source du fichier CSV source et recherchez un fichier portant le nom suivant.
```
import_yourcsvfilename.err.timestamp.csv
```
cqlsh écrit toutes les lignes de données ignorées dans un fichier portant ce nom. Si le fichier existe dans votre répertoire source et contient des données, ces lignes n'ont pas été chargées sur Amazon Keyspaces. Pour réessayer ces lignes, vérifiez d'abord si des erreurs se sont produites lors du téléchargement et ajustez les données en conséquence. Pour réessayer ces lignes, vous pouvez relancer le processus.
**Erreurs courantes**
Les raisons les plus courantes pour lesquelles les lignes ne sont pas chargées sont les erreurs de capacité et les erreurs d'analyse.
**Erreurs de demande non valides lors du chargement de données sur Amazon Keyspaces**
Dans l'exemple suivant, la table source contient une colonne de compteur, qui génère des appels par lots enregistrés à partir de la commande cqlsh`COPY`. Les appels groupés enregistrés ne sont pas pris en charge par Amazon Keyspaces.
```
Failed to import 10 rows: InvalidRequest - Error from server: code=2200 [Invalid query] message=“Only UNLOGGED Batches are supported at this time.“, will retry later, attempt 22 of 25
```
Pour résoudre cette erreur, utilisez DSBulk pour migrer les données. Pour de plus amples informations, veuillez consulter [Tutoriel : Chargement de données dans Amazon Keyspaces à l'aide de DSBulk](dsbulk-upload.md).
**Erreurs de l'analyseur lors du chargement de données sur Amazon Keyspaces**
L'exemple suivant montre une ligne ignorée en raison d'un`ParseError`.
```
Failed to import 1 rows: ParseError - Invalid ... –
```
Pour résoudre cette erreur, vous devez vous assurer que les données à importer correspondent au schéma de table dans Amazon Keyspaces. Vérifiez le fichier d'importation pour détecter les erreurs d'analyse. Vous pouvez essayer d'utiliser une seule ligne de données à l'aide d'une `INSERT` instruction pour isoler l'erreur.
**Erreurs de capacité lors du chargement de données sur Amazon Keyspaces**
```
Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency':
'LOCAL_QUORUM'}, will retry later, attempt 1 of 100
```
Amazon Keyspaces utilise les `WriteTimeout` exceptions `ReadTimeout` et pour indiquer lorsqu'une demande d'écriture échoue en raison d'une capacité de débit insuffisante. Pour aider à diagnostiquer les exceptions liées à une capacité insuffisante, Amazon Keyspaces publie `WriteThrottleEvents` des `ReadThrottledEvents` statistiques sur Amazon. CloudWatch Pour de plus amples informations, veuillez consulter [Surveillance d'Amazon Keyspaces avec Amazon CloudWatch](monitoring-cloudwatch.md).
**erreurs cqlsh lors du chargement de données sur Amazon Keyspaces**
Pour résoudre les erreurs cqlsh, réexécutez la commande défaillante avec l'indicateur. `--debug`
Lorsque vous utilisez une version incompatible de cqlsh, le message d'erreur suivant s'affiche.
```
AttributeError: 'NoneType' object has no attribute 'is_up'
Failed to import 3 rows: AttributeError - 'NoneType' object has no attribute 'is_up', given up after 1 attempts
```
Vérifiez que la version correcte de cqlsh est installée en exécutant la commande suivante.
```
cqlsh --version
```
Vous devriez voir quelque chose comme la sortie suivante.
```
cqlsh 5.0.1
```
Si vous utilisez Windows, remplacez toutes les instances de `cqlsh` par`cqlsh.bat`. Par exemple, pour vérifier la version de cqlsh sous Windows, exécutez la commande suivante.
```
cqlsh.bat --version
```
La connexion à Amazon Keyspaces échoue lorsque le client cqlsh a reçu trois erreurs consécutives de tout type de la part du serveur. Le client cqlsh échoue avec le message suivant.
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
Pour résoudre cette erreur, vous devez vous assurer que les données à importer correspondent au schéma de table dans Amazon Keyspaces. Vérifiez le fichier d'importation pour détecter les erreurs d'analyse. Vous pouvez essayer d'utiliser une seule ligne de données en utilisant une instruction INSERT pour isoler l'erreur.
Le client tente automatiquement de rétablir la connexion.
# Tutoriel : Chargement de données dans Amazon Keyspaces à l'aide de DSBulk
Ce step-by-step didacticiel vous explique comment migrer des données d'Apache Cassandra vers Amazon Keyspaces à l'aide du DataStax Bulk Loader () DSBulk disponible sur. [GitHub](https://github.com/datastax/dsbulk.git) L'utilisation DSBulk est utile pour télécharger des ensembles de données sur Amazon Keyspaces à des fins académiques ou de test. Pour plus d'informations sur la migration des charges de travail de production, consultez[Processus de migration hors ligne : Apache Cassandra vers Amazon Keyspaces](migrating-offline.md). Dans ce didacticiel, vous devez suivre les étapes suivantes.
Conditions préalables — Configurez un AWS compte avec des informations d'identification, créez un fichier JKS Trust Store pour le certificat, configurez`cqlsh`, téléchargez et installez DSBulk, et configurez un `application.conf` fichier.
1. **Créer un fichier CSV source et une table cible** : préparez un fichier CSV en tant que données source et créez le keyspace et le tableau cibles dans Amazon Keyspaces.
1. **Préparation des données** : répartissez les données du fichier CSV de manière aléatoire et analysez-les pour déterminer les tailles de ligne moyennes et maximales.
1. **Définissez la capacité de débit** : calculez les unités de capacité d'écriture requises (WCUs) en fonction de la taille des données et du temps de chargement souhaité, puis configurez la capacité allouée à la table.
1. **Configurer DSBulk les paramètres** : créez un fichier de DSBulk configuration avec des paramètres tels que l'authentification, le protocole SSL/TLS, le niveau de cohérence et la taille du pool de connexions.
1. **Exécuter la DSBulk commande** de DSBulk chargement : exécutez la commande de chargement pour télécharger les données du fichier CSV vers le tableau Amazon Keyspaces et suivre la progression.
**Topics**
+ [Conditions préalables : étapes à suivre avant de pouvoir télécharger des données avec DSBulk](dsbulk-upload-prequs.md)
+ [Étape 1 : Créez le fichier CSV source et une table cible pour le téléchargement des données à l'aide de DSBulk](dsbulk-upload-source.md)
+ [Étape 2 : Préparez les données à télécharger à l'aide de DSBulk](dsbulk-upload-prepare-data.md)
+ [Étape 3 : définir la capacité de débit pour la table cible](dsbulk-upload-capacity.md)
+ [Étape 4 : configurer `DSBulk` les paramètres pour télécharger les données du fichier CSV vers la table cible](dsbulk-upload-config.md)
+ [Étape 5 : Exécuter la DSBulk `load` commande pour télécharger les données du fichier CSV vers la table cible](dsbulk-upload-run.md)
# Conditions préalables : étapes à suivre avant de pouvoir télécharger des données avec DSBulk
Vous devez effectuer les tâches suivantes avant de pouvoir commencer ce didacticiel.
1. Si ce n'est pas déjà fait, créez un AWS compte en suivant les étapes indiquées sur[Con Gestion des identités et des accès AWS figuration](accessing.md#SettingUp.IAM).
1. Créez des informations d'identification en suivant les étapes décrites dans[Création et configuration des AWS informations d'identification pour Amazon Keyspaces](access.credentials.md).
1. Créez un fichier JKS Trust Store.
1. Téléchargez les certificats numériques suivants et enregistrez les fichiers localement ou dans votre répertoire personnel.
1. AmazonRootCA1
1. AmazonRootCA2
1. AmazonRootCA3
1. AmazonRootCA4
1. Starfield Class 2 Root (en option, pour une rétrocompatibilité)
Pour télécharger les certificats, vous pouvez utiliser les commandes suivantes.
```
curl -O https://www.amazontrust.com/repository/AmazonRootCA1.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA2.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA3.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA4.pem
curl -O https://certs.secureserver.net/repository/sf-class2-root.crt
```
**Note**
Amazon Keyspaces utilisait auparavant des certificats TLS ancrés à l'autorité de certification Starfield Class 2. AWS migre le tout Régions AWS vers des certificats émis dans le cadre d'Amazon Trust Services (Amazon Root CAs 1—4). Au cours de cette transition, configurez les clients pour qu'ils fassent confiance à la fois à Amazon Root CAs 1-4 et à la racine Starfield afin de garantir la compatibilité entre toutes les régions.
1. Convertissez les certificats numériques en fichiers TrustStore et ajoutez-les au keystore.
```
openssl x509 -outform der -in AmazonRootCA1.pem -out temp_file.der
keytool -import -alias amazon-root-ca-1 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA2.pem -out temp_file.der
keytool -import -alias amazon-root-ca-2 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA3.pem -out temp_file.der
keytool -import -alias amazon-root-ca-3 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA4.pem -out temp_file.der
keytool -import -alias amazon-root-ca-4 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in sf-class2-root.crt -out temp_file.der
keytool -import -alias cassandra -keystore cassandra_truststore.jks -file temp_file.der
```
Dans la dernière étape, vous devez créer un mot de passe pour le keystore et faire confiance à chaque certificat. La commande interactive ressemble à ceci.
```
Enter keystore password:
Re-enter new password:
Owner: CN=Amazon Root CA 1, O=Amazon, C=US
Issuer: CN=Amazon Root CA 1, O=Amazon, C=US
Serial number: 66c9fcf99bf8c0a39e2f0788a43e696365bca
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sun Jan 17 00:00:00 UTC 2038
Certificate fingerprints:
SHA1: 8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16
SHA256: 8E:CD:E6:88:4F:3D:87:B1:12:5B:A3:1A:C3:FC:B1:3D:70:16:DE:7F:57:CC:90:4F:E1:CB:97:C6:AE:98:19:6E
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 84 18 CC 85 34 EC BC 0C 94 94 2E 08 59 9C C7 B2 ....4.......Y...
0010: 10 4E 0A 08 .N..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 2, O=Amazon, C=US
Issuer: CN=Amazon Root CA 2, O=Amazon, C=US
Serial number: 66c9fd29635869f0a0fe58678f85b26bb8a37
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 5A:8C:EF:45:D7:A6:98:59:76:7A:8C:8B:44:96:B5:78:CF:47:4B:1A
SHA256: 1B:A5:B2:AA:8C:65:40:1A:82:96:01:18:F8:0B:EC:4F:62:30:4D:83:CE:C4:71:3A:19:C3:9C:01:1E:A4:6D:B4
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: B0 0C F0 4C 30 F4 05 58 02 48 FD 33 E5 52 AF 4B ...L0..X.H.3.R.K
0010: 84 E3 66 52 ..fR
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 3, O=Amazon, C=US
Issuer: CN=Amazon Root CA 3, O=Amazon, C=US
Serial number: 66c9fd5749736663f3b0b9ad9e89e7603f24a
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 0D:44:DD:8C:3C:8C:1A:1A:58:75:64:81:E9:0F:2E:2A:FF:B3:D2:6E
SHA256: 18:CE:6C:FE:7B:F1:4E:60:B2:E3:47:B8:DF:E8:68:CB:31:D0:2E:BB:3A:DA:27:15:69:F5:03:43:B4:6D:B3:A4
Signature algorithm name: SHA256withECDSA
Subject Public Key Algorithm: 256-bit EC (secp256r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AB B6 DB D7 06 9E 37 AC 30 86 07 91 70 C7 9C C4 ......7.0...p...
0010: 19 B1 78 C0 ..x.
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 4, O=Amazon, C=US
Issuer: CN=Amazon Root CA 4, O=Amazon, C=US
Serial number: 66c9fd7c1bb104c2943e5717b7b2cc81ac10e
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: F6:10:84:07:D6:F8:BB:67:98:0C:C2:E2:44:C2:EB:AE:1C:EF:63:BE
SHA256: E3:5D:28:41:9E:D0:20:25:CF:A6:90:38:CD:62:39:62:45:8D:A5:C6:95:FB:DE:A3:C2:2B:0B:FB:25:89:70:92
Signature algorithm name: SHA384withECDSA
Subject Public Key Algorithm: 384-bit EC (secp384r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D3 EC C7 3A 65 6E CC E1 DA 76 9A 56 FB 9C F3 86 ...:en...v.V....
0010: 6D 57 E5 81 mW..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Serial number: 0
Valid from: Tue Jun 29 17:39:16 UTC 2004 until: Thu Jun 29 17:39:16 UTC 2034
Certificate fingerprints:
SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
SHA256: 14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58
Signature algorithm name: SHA1withRSA (weak)
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
[OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US]
SerialNumber: [ 00]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
]
Warning:
The input uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
Trust this certificate? [no]: yes
Certificate was added to keystore
```
1. Configurez la connexion au shell Cassandra Query Language (cqlsh) et confirmez que vous pouvez vous connecter à Amazon Keyspaces en suivant les étapes indiquées sur. [Utilisation `cqlsh` pour se connecter à Amazon Keyspaces](programmatic.cqlsh.md)
1. Téléchargez et installez DSBulk.
**Note**
La version présentée dans ce didacticiel n'est peut-être pas la dernière version disponible. Avant de procéder au téléchargement DSBulk, consultez la [page de téléchargement de DataStax Bulk Loader](https://downloads.datastax.com/#bulk-loader) pour obtenir la dernière version et mettez à jour le numéro de version dans les commandes suivantes en conséquence.
1. Pour le télécharger DSBulk, vous pouvez utiliser le code suivant.
```
curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz
```
1. Décompressez ensuite le fichier tar et ajoutez-le DSBulk à votre fichier `PATH` comme indiqué dans l'exemple suivant.
```
tar -zxvf dsbulk-1.8.0.tar.gz
# add the DSBulk directory to the path
export PATH=$PATH:./dsbulk-1.8.0/bin
```
1. Créez un `application.conf` fichier pour stocker les paramètres à utiliser par DSBulk. Vous pouvez enregistrer l'exemple suivant sous le nom`./dsbulk_keyspaces.conf`. `localhost`Remplacez-le par le point de contact de votre cluster Cassandra local si vous n'êtes pas sur le nœud local, par exemple le nom DNS ou l'adresse IP. Prenez note du nom et du chemin du fichier, car vous devrez le spécifier ultérieurement dans la `dsbulk load` commande.
```
datastax-java-driver {
basic.contact-points = [ "localhost"]
advanced.auth-provider {
class = software.aws.mcs.auth.SigV4AuthProvider
aws-region = us-east-1
}
}
```
1. Pour activer le support SigV4, téléchargez le `jar` fichier ombré depuis [GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/)et placez-le dans le DSBulk `lib` dossier comme indiqué dans l'exemple suivant.
```
curl -O -L https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/download/4.0.6-shaded-v2/aws-sigv4-auth-cassandra-java-driver-plugin-4.0.6-shaded.jar
```
# Étape 1 : Créez le fichier CSV source et une table cible pour le téléchargement des données à l'aide de DSBulk
Pour ce didacticiel, nous utilisons un fichier de valeurs séparées par des virgules (CSV) dont le `keyspaces_sample_table.csv` nom est le fichier source pour la migration des données. Le fichier d'exemple fourni contient quelques lignes de données pour une table portant le nom`book_awards`.
1. Créez le fichier source. Vous pouvez choisir l’une des options suivantes :
+ Téléchargez l'exemple de fichier CSV (`keyspaces_sample_table.csv`) contenu dans le fichier d'archive [samplemigration.zip](samples/samplemigration.zip) suivant. Décompressez l'archive et notez le chemin vers`keyspaces_sample_table.csv`.
+ Pour remplir un fichier CSV avec vos propres données stockées dans une base de données Apache Cassandra, vous pouvez remplir le fichier CSV source en utilisant `dsbulk unload` comme indiqué dans l'exemple suivant.
```
dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv
```
Assurez-vous que le fichier CSV que vous créez répond aux exigences suivantes :
+ La première ligne contient les noms des colonnes.
+ Les noms des colonnes du fichier CSV source correspondent aux noms des colonnes de la table cible.
+ Les données sont délimitées par une virgule.
+ Toutes les valeurs de données sont des types de données Amazon Keyspaces valides. Consultez [Types de données](cql.elements.md#cql.data-types).
1. Créez le keyspace et le tableau cibles dans Amazon Keyspaces.
1. Connectez-vous à Amazon Keyspaces en utilisant`cqlsh`, en remplaçant le point de terminaison du service, le nom d'utilisateur et le mot de passe dans l'exemple suivant par vos propres valeurs.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Créez un nouvel espace de touches avec le `catalog` nom indiqué dans l'exemple suivant.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Une fois que le nouveau keyspace est devenu disponible, utilisez le code suivant pour créer la table `book_awards` cible. Pour en savoir plus sur la création de ressources asynchrones et sur la façon de vérifier si une ressource est disponible, consultez. [Vérifiez le statut de création des espaces de touches dans Amazon Keyspaces](keyspaces-create.md)
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Si Apache Cassandra est votre source de données d'origine, un moyen simple de créer la table cible Amazon Keyspaces avec les en-têtes correspondants consiste à générer `CREATE TABLE` l'instruction à partir de la table source, comme indiqué dans l'instruction suivante.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Créez ensuite la table cible dans Amazon Keyspaces avec les noms des colonnes et les types de données correspondant à la description de la table source de Cassandra.
# Étape 2 : Préparez les données à télécharger à l'aide de DSBulk
La préparation des données sources pour un transfert efficace est un processus en deux étapes. Tout d'abord, vous répartissez les données de manière aléatoire. Dans la deuxième étape, vous analysez les données pour déterminer les valeurs de `dsbulk` paramètres appropriées et les paramètres de table requis.
**Randomiser les données**
La `dsbulk` commande lit et écrit les données dans l'ordre dans lequel elles apparaissent dans le fichier CSV. Si vous utilisez la `dsbulk` commande pour créer le fichier source, les données sont écrites dans un ordre trié par clé dans le fichier CSV. En interne, Amazon Keyspaces partitionne les données à l'aide de clés de partition. Bien qu'Amazon Keyspaces intègre une logique permettant d'équilibrer la charge des demandes pour la même clé de partition, le chargement des données est plus rapide et plus efficace si vous répartissez la commande de manière aléatoire. En effet, vous pouvez tirer parti de l'équilibrage de charge intégré qui se produit lorsque Amazon Keyspaces écrit sur différentes partitions.
Pour répartir uniformément les écritures sur les partitions, vous devez répartir les données de manière aléatoire dans le fichier source. Vous pouvez écrire une application pour cela ou utiliser un outil open source, tel que [Shuf](https://en.wikipedia.org/wiki/Shuf). Shuf est disponible gratuitement sur les distributions Linux, sur macOS (en installant coreutils dans [homebrew](https://brew.sh)) et sur Windows (en utilisant le sous-système Windows pour Linux (WSL)). Une étape supplémentaire est nécessaire pour éviter que la ligne d'en-tête contenant les noms des colonnes ne soit modifiée au cours de cette étape.
Pour randomiser le fichier source tout en préservant l'en-tête, entrez le code suivant.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf réécrit les données dans un nouveau fichier CSV appelé. `keyspace.table.csv` Vous pouvez désormais supprimer le `keyspaces_sample_table.csv` fichier, vous n'en avez plus besoin.
**Analyser les données**
Déterminez la taille moyenne et maximale des lignes en analysant les données.
Vous le faites pour les raisons suivantes :
+ La taille moyenne des lignes permet d'estimer la quantité totale de données à transférer.
+ Vous avez besoin de la taille de ligne moyenne pour fournir la capacité d'écriture nécessaire au téléchargement des données.
+ Vous pouvez vous assurer que la taille de chaque ligne est inférieure à 1 Mo, ce qui correspond à la taille de ligne maximale dans Amazon Keyspaces.
**Note**
Ce quota fait référence à la taille des lignes et non à la taille de la partition. Contrairement aux partitions Apache Cassandra, les partitions Amazon Keyspaces peuvent être de taille pratiquement indépendante. Les clés de partition et les colonnes de clustering nécessitent un espace de stockage supplémentaire pour les métadonnées, que vous devez ajouter à la taille brute des lignes. Pour de plus amples informations, veuillez consulter [Estimer la taille des lignes dans Amazon Keyspaces](calculating-row-size.md).
Le code suivant utilise [AWK](https://en.wikipedia.org/wiki/AWK) pour analyser un fichier CSV et imprimer la taille de ligne moyenne et maximale.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
L'exécution de ce code génère le résultat suivant.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Assurez-vous que la taille maximale de votre ligne ne dépasse pas 1 Mo. Si c'est le cas, vous devez diviser la ligne ou compresser les données pour ramener la taille de la ligne en dessous de 1 Mo. Dans l'étape suivante de ce didacticiel, vous allez utiliser la taille de ligne moyenne pour allouer la capacité d'écriture de la table.
# Étape 3 : définir la capacité de débit pour la table cible
Ce didacticiel explique comment régler le chargement DSBulk des données dans un intervalle de temps défini. Comme vous savez à l'avance combien de lectures et d'écritures vous devez effectuer, utilisez le mode capacité provisionnée. Une fois le transfert de données terminé, vous devez définir le mode de capacité de la table en fonction des modèles de trafic de votre application. Pour en savoir plus sur la gestion des capacités, voir[Gestion des ressources sans serveur dans Amazon Keyspaces (pour Apache Cassandra)](serverless_resource_management.md).
Avec le mode capacité provisionnée, vous spécifiez à l'avance la capacité de lecture et d'écriture que vous souhaitez allouer à votre table. La capacité d'écriture est facturée à l'heure et mesurée en unités de capacité d'écriture ()WCUs. Chaque WCU possède une capacité d'écriture suffisante pour prendre en charge l'écriture de 1 Ko de données par seconde. Lorsque vous chargez les données, le taux d'écriture doit être inférieur au maximum WCUs (paramètre :`write_capacity_units`) défini sur la table cible.
Par défaut, vous pouvez provisionner jusqu'à 40 000 tables WCUs pour une table et 80 000 pour WCUs toutes les tables de votre compte. Si vous avez besoin de capacités supplémentaires, vous pouvez demander une augmentation de quota dans la console [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas). Pour plus d’informations sur les quotas, consultez [Quotas pour Amazon Keyspaces (pour Apache Cassandra)](quotas.md).
**Calculez le nombre moyen de WCUs caractères requis pour un encart**
L'insertion de 1 Ko de données par seconde nécessite 1 WCU. Si votre fichier CSV comporte 360 000 lignes et que vous souhaitez charger toutes les données en 1 heure, vous devez écrire 100 lignes par seconde (360 000 lignes/60 minutes/60 secondes = 100 lignes par seconde). Si chaque ligne contient jusqu'à 1 Ko de données, pour insérer 100 lignes par seconde, vous devez fournir 100 lignes WCUs à votre table. Si chaque ligne contient 1,5 Ko de données, il vous en faut deux WCUs pour insérer une ligne par seconde. Par conséquent, pour insérer 100 lignes par seconde, vous devez en prévoir 200 WCUs.
Pour déterminer le nombre de WCUs lignes à insérer par seconde, divisez la taille moyenne des lignes en octets par 1024 et arrondissez au nombre entier le plus proche.
Par exemple, si la taille moyenne des lignes est de 3 000 octets, il vous en faut trois WCUs pour insérer une ligne par seconde.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Calculer le temps et la capacité de chargement des données**
Maintenant que vous connaissez la taille moyenne et le nombre de lignes de votre fichier CSV, vous pouvez calculer le nombre WCUs de lignes nécessaires pour charger les données dans un laps de temps donné, ainsi que le temps approximatif nécessaire pour charger toutes les données de votre fichier CSV en utilisant différents paramètres WCU.
Par exemple, si chaque ligne de votre fichier fait 1 Ko et que votre fichier CSV contient 1 000 000 de lignes, pour charger les données en 1 heure, vous devez affecter au moins 278 lignes WCUs à votre table pour cette heure.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Configuration des paramètres de capacité provisionnée**
Vous pouvez définir les paramètres de capacité d'écriture d'une table lorsque vous créez la table ou à l'aide de la `ALTER TABLE` commande. Voici la syntaxe permettant de modifier les paramètres de capacité provisionnée d'une table à l'aide de la `ALTER TABLE` commande.
```
ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Pour la référence linguistique complète, voir [CREATE TABLE](cql.ddl.table.md#cql.ddl.table.create) et[ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter).
# Étape 4 : configurer `DSBulk` les paramètres pour télécharger les données du fichier CSV vers la table cible
Cette section décrit les étapes nécessaires à la configuration du DSBulk téléchargement des données vers Amazon Keyspaces. Vous configurez à DSBulk l'aide d'un fichier de configuration. Vous spécifiez le fichier de configuration directement depuis la ligne de commande.
1. Créez un fichier DSBulk de configuration pour la migration vers Amazon Keyspaces. Dans cet exemple, nous utilisons le nom du fichier. `dsbulk_keyspaces.conf` Spécifiez les paramètres suivants dans le fichier DSBulk de configuration.
1. *`PlainTextAuthProvider`*— Créez le fournisseur d'authentification avec la `PlainTextAuthProvider` classe. `ServiceUserName`et `ServicePassword` doivent correspondre au nom d'utilisateur et au mot de passe que vous avez obtenus lorsque vous avez généré les informations d'identification spécifiques au service en suivant les étapes décrites dans. [Créez des informations d'identification pour un accès programmatique à Amazon Keyspaces](programmatic.credentials.md)
1. *`local-datacenter`*— Définissez la valeur de Région AWS celle `local-datacenter` à laquelle vous vous connectez. Par exemple, si l'application se connecte à`cassandra.us-east-1.amazonaws.com`, définissez le centre de données local sur`us-east-1`. Pour toutes les options disponibles Régions AWS, voir[Points de terminaison de service pour Amazon Keyspaces](programmatic.endpoints.md). Pour éviter les répliques, définissez sur`slow-replica-avoidance`. `false`
1. *`SSLEngineFactory`*— Pour configurer SSL/TLS, initialisez-le `SSLEngineFactory` en ajoutant une section dans le fichier de configuration avec une seule ligne qui spécifie la classe avec. `class = DefaultSslEngineFactory` Indiquez le chemin d'accès `cassandra_truststore.jks` et le mot de passe que vous avez créés précédemment.
1. *`consistency`*— Réglez le niveau de cohérence sur`LOCAL QUORUM`. Les autres niveaux de cohérence d'écriture ne sont pas pris en charge. Pour plus d'informations, consultez[Niveaux de cohérence en lecture et écriture pris en charge par Apache Cassandra et coûts associés](consistency.md).
1. Le nombre de connexions par pool est configurable dans le pilote Java. Pour cet exemple, définissez `advanced.connection.pool.local.size` sur 3.
L'exemple de fichier de configuration complet est le suivant.
```
datastax-java-driver {
basic.contact-points = [ "cassandra.us-east-1.amazonaws.com:9142"]
advanced.auth-provider {
class = PlainTextAuthProvider
username = "ServiceUserName"
password = "ServicePassword"
}
basic.load-balancing-policy {
local-datacenter = "us-east-1"
slow-replica-avoidance = false
}
basic.request {
consistency = LOCAL_QUORUM
default-idempotence = true
}
advanced.ssl-engine-factory {
class = DefaultSslEngineFactory
truststore-path = "./cassandra_truststore.jks"
truststore-password = "my_password"
hostname-validation = false
}
advanced.connection.pool.local.size = 3
}
```
1. Vérifiez les paramètres de la DSBulk `load` commande.
1. *`executor.maxPerSecond`*— Le nombre maximum de lignes que la commande de chargement tente de traiter simultanément par seconde. S'il n'est pas défini, ce paramètre est désactivé avec -1.
`executor.maxPerSecond`Défini en fonction du nombre de ceux WCUs que vous avez provisionnés dans la table de destination cible. La `executor.maxPerSecond` `load` commande n'est pas une limite, c'est une moyenne cible. Cela signifie qu'il peut (et c'est souvent le cas) dépasser le nombre que vous avez défini. Pour tenir compte des rafales et vous assurer que la capacité est suffisante pour traiter les demandes de chargement de données, définissez 90 % `executor.maxPerSecond` de la capacité d'écriture de la table.
```
executor.maxPerSecond = WCUs * .90
```
Dans ce didacticiel, nous avons défini `executor.maxPerSecond` la valeur 5.
**Note**
Si vous utilisez la DSBulk version 1.6.0 ou supérieure, vous pouvez utiliser à la `dsbulk.engine.maxConcurrentQueries` place.
1. Configurez ces paramètres supplémentaires pour la DSBulk `load` commande.
+ *`batch-mode`*— Ce paramètre indique au système de regrouper les opérations par clé de partition. Nous vous recommandons de désactiver le mode batch, car cela peut entraîner des scénarios de raccourcis clavier et des causes`WriteThrottleEvents`.
+ *`driver.advanced.retry-policy-max-retries`*— Cela détermine le nombre de tentatives à nouveau pour une requête qui a échoué. S'il n'est pas défini, la valeur par défaut est 10. Vous pouvez ajuster cette valeur selon vos besoins.
+ *`driver.basic.request.timeout`*— Durée en minutes pendant laquelle le système attend le retour d'une requête. S'il n'est pas défini, la valeur par défaut est « 5 minutes ». Vous pouvez ajuster cette valeur selon vos besoins.
# Étape 5 : Exécuter la DSBulk `load` commande pour télécharger les données du fichier CSV vers la table cible
Dans la dernière étape de ce didacticiel, vous téléchargerez les données dans Amazon Keyspaces.
Pour exécuter la DSBulk `load` commande, procédez comme suit.
1. Exécutez le code suivant pour télécharger les données de votre fichier csv dans votre tableau Amazon Keyspaces. Assurez-vous de mettre à jour le chemin du fichier de configuration de l'application que vous avez créé précédemment.
```
dsbulk load -f ./dsbulk_keyspaces.conf --connector.csv.url keyspace.table.csv -header true --batch.mode DISABLED --executor.maxPerSecond 5 --driver.basic.request.timeout "5 minutes" --driver.advanced.retry-policy.max-retries 10 -k catalog -t book_awards
```
1. La sortie inclut l'emplacement d'un fichier journal détaillant les opérations réussies et infructueuses. Le fichier est stocké dans le répertoire suivant.
```
Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911
```
1. Les entrées du fichier journal incluront des métriques, comme dans l'exemple suivant. Vérifiez que le nombre de lignes correspond au nombre de lignes de votre fichier csv.
```
total | failed | rows/s | p50ms | p99ms | p999ms
200 | 0 | 200 | 21.63 | 21.89 | 21.89
```
**Important**
Maintenant que vous avez transféré vos données, ajustez les paramètres du mode capacité de votre table cible pour qu'ils correspondent aux modèles de trafic habituels de votre application. Vous êtes facturé au taux horaire pour votre capacité provisionnée jusqu'à ce que vous la modifiiez. Pour de plus amples informations, veuillez consulter [Configurer les modes de read/write capacité dans Amazon Keyspaces](ReadWriteCapacityMode.md).