Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Migrazione ad Amazon Keyspaces (per Apache Cassandra)
La migrazione ad Amazon Keyspaces (per Apache Cassandra) offre una serie di vantaggi interessanti per aziende e organizzazioni. Ecco alcuni vantaggi chiave che rendono Amazon Keyspaces una scelta interessante per la migrazione.
+ **Scalabilità**: Amazon Keyspaces è progettato per gestire carichi di lavoro enormi e scalare senza problemi per soddisfare volumi e traffico di dati in crescita. Con Cassandra tradizionale, la scalabilità non viene eseguita su richiesta e richiede la pianificazione per i picchi futuri. Con Amazon Keyspaces, puoi scalare facilmente le tabelle verso l'alto o verso il basso in base alla domanda, assicurando che le tue applicazioni siano in grado di gestire picchi improvvisi di traffico senza compromettere le prestazioni.
+ **Prestazioni**: Amazon Keyspaces offre un accesso ai dati a bassa latenza, consentendo alle applicazioni di recuperare ed elaborare i dati con una velocità eccezionale. La sua architettura distribuita garantisce che le operazioni di lettura e scrittura siano distribuite su più nodi, offrendo tempi di risposta coerenti a una cifra di millisecondi anche a frequenze di richieste elevate.
+ **Completamente gestito**: Amazon Keyspaces è un servizio completamente gestito fornito da. AWS Ciò significa che AWS gestisce gli aspetti operativi della gestione del database, tra cui il provisioning, la configurazione, l'applicazione di patch, i backup e la scalabilità. Ciò consente di concentrarsi maggiormente sullo sviluppo delle applicazioni e meno sulle attività di amministrazione del database.
+ **Architettura serverless**: Amazon Keyspaces è serverless. Paghi solo per la capacità consumata e non è richiesto alcun provisioning anticipato della capacità. Non hai server da gestire o istanze tra cui scegliere. Questo pay-per-request modello offre efficienza in termini di costi e spese operative minime, in quanto si paga solo per le risorse consumate senza la necessità di fornire e monitorare la capacità.
+ Flessibilità **NoSQL con schema: Amazon Keyspaces segue un modello di dati NoSQL, offrendo flessibilità** nella progettazione dello schema. Con Amazon Keyspaces, puoi archiviare dati strutturati, semistrutturati e non strutturati, rendendoli ideali per la gestione di tipi di dati diversi e in evoluzione. Inoltre, Amazon Keyspaces esegue la convalida dello schema in scrittura, consentendo un'evoluzione centralizzata del modello di dati. Questa flessibilità consente cicli di sviluppo più rapidi e un adattamento più semplice alle mutevoli esigenze aziendali.
+ **Disponibilità e durabilità elevate**: Amazon Keyspaces replica i dati su più [zone di disponibilità](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) all'interno di un'unica area Regione AWS, garantendo elevata disponibilità e durabilità dei dati. Gestisce automaticamente la replica, il failover e il ripristino, riducendo al minimo il rischio di perdita dei dati o interruzioni del servizio. Amazon Keyspaces offre uno SLA di disponibilità fino al 99,999%. [Per una resilienza ancora maggiore e letture locali a bassa latenza, Amazon Keyspaces offre la replica in più regioni.](multiRegion-replication.md)
+ **Sicurezza e conformità**: Amazon Keyspaces si integra AWS Identity and Access Management per un controllo granulare degli accessi. Fornisce la crittografia a riposo e in transito, contribuendo a migliorare la sicurezza dei dati. Amazon Keyspaces è stato valutato da revisori di terze parti per quanto riguarda la sicurezza e la conformità con programmi specifici, tra cui HIPAA, PCI DSS e SOC, che consentono di soddisfare i requisiti normativi. Per ulteriori informazioni, consulta [Convalida della conformità per Amazon Keyspaces (per Apache Cassandra)](Keyspaces-compliance.md).
+ **Integrazione con l' AWS ecosistema**: come parte dell' AWS ecosistema, Amazon Keyspaces si integra perfettamente con altri Servizi AWS, ad esempio AWS CloudFormation Amazon e. CloudWatch AWS CloudTrail Questa integrazione consente di creare architetture serverless, sfruttare l'infrastruttura come codice e creare applicazioni basate sui dati in tempo reale. Per ulteriori informazioni, consulta [Monitoraggio di Amazon Keyspaces (per Apache Cassandra)](monitoring-overview.md).
**Topics**
+ [Crea un piano di migrazione per la migrazione da Apache Cassandra ad Amazon Keyspaces](migrating-cassandra.md)
+ [Come scegliere lo strumento giusto per il caricamento in blocco o la migrazione di dati su Amazon Keyspaces](migrating-tools.md)
# Crea un piano di migrazione per la migrazione da Apache Cassandra ad Amazon Keyspaces
Per una migrazione di successo da Apache Cassandra ad Amazon Keyspaces, consigliamo una revisione dei concetti e delle best practice di migrazione applicabili, nonché un confronto tra le opzioni disponibili.
Questo argomento descrive come funziona il processo di migrazione introducendo diversi concetti chiave e gli strumenti e le tecniche a tua disposizione. È possibile valutare le diverse strategie di migrazione per selezionare quella che meglio soddisfa i propri requisiti.
**Topics**
+ [Compatibilità funzionale](#migrating-cassandra-compatibility)
+ [Stima dei prezzi di Amazon Keyspaces](#migrating-cassandra-sizing)
+ [Scegli una strategia di migrazione](#migrating-cassandra-strategy)
+ [Migrazione online verso Amazon Keyspaces: strategie e best practice](migrating-online.md)
+ [Processo di migrazione offline: da Apache Cassandra ad Amazon Keyspaces](migrating-offline.md)
+ [Utilizzo di una soluzione di migrazione ibrida: da Apache Cassandra ad Amazon Keyspaces](migrating-hybrid.md)
## Compatibilità funzionale
Valuta attentamente le differenze funzionali tra Apache Cassandra e Amazon Keyspaces prima della migrazione. Amazon Keyspaces supporta tutte le operazioni sul piano dati Cassandra di uso comune, come la creazione di keyspace e tabelle, la lettura e la scrittura di dati.
Tuttavia ci sono alcuni Cassandra APIs che Amazon Keyspaces non supporta. Per ulteriori informazioni sui supporti APIs, consulta. [Cassandra APIs, operazioni, funzioni e tipi di dati supportati](cassandra-apis.md) Per una panoramica di tutte le differenze funzionali tra Amazon Keyspaces e Apache Cassandra, consulta. [Differenze funzionali: Amazon Keyspaces e Apache Cassandra](functional-differences.md)
Per confrontare Cassandra APIs e lo schema che stai utilizzando con le funzionalità supportate in Amazon Keyspaces, puoi eseguire uno script di compatibilità disponibile nel toolkit Amazon Keyspaces su. [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)
**Come usare lo script di compatibilità**
1. Scarica lo script Python di compatibilità da [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)e spostalo in una posizione che abbia accesso al tuo cluster Apache Cassandra esistente.
1. Lo script di compatibilità utilizza parametri simili a. `CQLSH` Cerca `--host` e `--port` inserisci l'indirizzo IP e la porta che usi per connetterti ed eseguire query su uno dei nodi Cassandra del tuo cluster.
Se il tuo cluster Cassandra utilizza l'autenticazione, devi anche fornire e. `-username` `-password` Per eseguire lo script di compatibilità, puoi usare il seguente comando.
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## Stima dei prezzi di Amazon Keyspaces
Questa sezione fornisce una panoramica delle informazioni che devi raccogliere dalle tabelle Apache Cassandra per calcolare il costo stimato per Amazon Keyspaces. Ciascuna tabella richiede tipi di dati diversi, deve supportare diverse query CQL e mantiene un traffico distinto. read/write
Pensare ai tuoi requisiti in base alle tabelle è in linea con le modalità di isolamento delle risorse a livello di tabella di Amazon Keyspaces [e](ReadWriteCapacityMode.md) capacità di velocità effettiva di lettura/scrittura. Con Amazon Keyspaces, puoi definire la capacità di lettura/scrittura e le politiche di [scalabilità automatica per le tabelle in modo indipendente.](autoscaling.md)
La comprensione dei requisiti delle tabelle ti aiuta a dare priorità alle tabelle per la migrazione in base a funzionalità, costi e sforzi di migrazione.
Raccogli le seguenti metriche della tabella Cassandra prima di una migrazione. Queste informazioni aiutano a stimare il costo del carico di lavoro su Amazon Keyspaces.
+ **Nome della tabella**: il nome del keyspace completo e del nome della tabella.
+ **Descrizione**: una descrizione della tabella, ad esempio come viene utilizzata o che tipo di dati vi sono memorizzati.
+ **Letture medie al secondo**: il numero medio di letture a livello di coordinate sulla tabella in un ampio intervallo di tempo.
+ **Scritture medie al secondo**: il numero medio di scritture a livello di coordinate sulla tabella in un ampio intervallo di tempo.
+ Dimensione **media delle righe in byte: la dimensione** media delle righe in byte.
+ **Dimensione di archiviazione in GBs**: la dimensione di archiviazione non elaborata per una tabella.
+ **Ripartizione della coerenza di lettura**: la percentuale di letture che utilizzano una coerenza finale (`LOCAL_ONE`o`ONE`) rispetto a una consistenza forte (). `LOCAL_QUORUM`
Questa tabella mostra un esempio delle informazioni sulle tabelle che è necessario raccogliere durante la pianificazione di una migrazione.
****
| Nome tabella | Description | Letture medie al secondo | Scritture medie al secondo | Dimensione media delle righe in byte | Dimensioni di archiviazione in GBs | Leggi la ripartizione della coerenza |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | Utilizzato per memorizzare la cronologia del carrello | 10.000 | 5.000 | 2.200 | 2.000 | 100% `LOCAL_ONE` |
| mykeyspace.mytable2 | Utilizzato per memorizzare le informazioni più recenti sul profilo | 20.000 | 1.000 | 850 | 1.000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` |
### Come raccogliere le metriche delle tabelle
Questa sezione fornisce istruzioni dettagliate su come raccogliere le metriche di tabella necessarie dal cluster Cassandra esistente. Queste metriche includono la dimensione delle righe, la dimensione della tabella e read/write le richieste al secondo (RPS). Ti consentono di valutare i requisiti di capacità di throughput per una tabella Amazon Keyspaces e stimare i prezzi.
**Come raccogliere i parametri della tabella nella tabella dei sorgenti di Cassandra**
1. Determina la dimensione delle righe
La dimensione delle righe è importante per determinare la capacità di lettura e l'utilizzo della capacità di scrittura in Amazon Keyspaces. Il diagramma seguente mostra la distribuzione tipica dei dati su un intervallo di token Cassandra.
![\[Un diagramma che mostra la distribuzione tipica dei dati su un intervallo di token Cassandra utilizzando il partizionatore. murmur3\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
È possibile utilizzare uno script di campionamento delle dimensioni delle righe disponibile su [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)per raccogliere le metriche delle dimensioni delle righe per ogni tabella del cluster Cassandra.
Lo script esporta i dati della tabella da Apache Cassandra utilizzando `cqlsh` e `awk` calcolando la deviazione minima, massima, media e standard della dimensione delle righe su un set di dati di tabella di esempio configurabile. Il campionatore della dimensione delle righe passa gli argomenti a`cqlsh`, quindi è possibile utilizzare gli stessi parametri per connettersi e leggere dal cluster Cassandra.
La seguente dichiarazione ne è un esempio.
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
Per ulteriori informazioni su come viene calcolata la dimensione delle righe in Amazon Keyspaces, consulta. [Stima della dimensione delle righe in Amazon Keyspaces](calculating-row-size.md)
1. Determina le dimensioni della tabella
Con Amazon Keyspaces, non è necessario effettuare il provisioning dello storage in anticipo. Amazon Keyspaces monitora continuamente le dimensioni fatturabili delle tabelle per determinare i costi di archiviazione. Lo storage viene fatturato per GB al mese. La dimensione della tabella Amazon Keyspaces si basa sulla dimensione raw (non compressa) di una singola replica.
Per monitorare la dimensione della tabella in Amazon Keyspaces, puoi utilizzare la metrica`BillableTableSizeInBytes`, che viene visualizzata per ogni tabella in. Console di gestione AWS
Per stimare la dimensione fatturabile della tabella Amazon Keyspaces, puoi utilizzare uno di questi due metodi:
+ Usa la dimensione media delle righe e moltiplica per il numero o le righe.
Puoi stimare la dimensione della tabella Amazon Keyspaces moltiplicando la dimensione media delle righe per il numero di righe della tabella sorgente di Cassandra. Utilizza lo script di esempio relativo alla dimensione delle righe della sezione precedente per acquisire la dimensione media delle righe. Per acquisire il conteggio delle righe, puoi utilizzare strumenti come `dsbulk count` determinare il numero totale di righe nella tabella di origine.
+ Usa `nodetool` per raccogliere i metadati della tabella.
`Nodetool`è uno strumento amministrativo fornito nella distribuzione Apache Cassandra che fornisce informazioni sullo stato del processo Cassandra e restituisce i metadati della tabella. Puoi utilizzarli `nodetool` per campionare i metadati sulla dimensione della tabella e quindi estrapolare la dimensione della tabella in Amazon Keyspaces.
Il comando da usare è. `nodetool tablestats` Tablestats restituisce le dimensioni e il rapporto di compressione della tabella. La dimensione della tabella viene memorizzata come riferimento `tablelivespace` per la tabella ed è possibile dividerla per. `compression ratio` Quindi moltiplica questo valore di dimensione per il numero di nodi. Infine dividi per il fattore di replica (in genere tre).
Questa è la formula completa per il calcolo che puoi usare per valutare le dimensioni della tabella.
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
Supponiamo che il cluster Cassandra abbia 12 nodi. L'esecuzione del `nodetool tablestats` comando restituisce un valore `tablelivespace` di 200 GB e uno `compression ratio` di 0,5. Il keyspace ha un fattore di replica pari a tre.
Ecco come appare il calcolo per questo esempio.
```
(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. Registra il numero di letture e scritture
Per determinare i requisiti di capacità e scalabilità per le tabelle Amazon Keyspaces, acquisisci la frequenza di richiesta di lettura e scrittura delle tabelle Cassandra prima della migrazione.
Amazon Keyspaces è serverless e paghi solo per ciò che usi. In generale, il prezzo del read/write throughput in Amazon Keyspaces si basa sul numero e sulla dimensione delle richieste.
Esistono due modalità di capacità in Amazon Keyspaces:
+ [On-demand](ReadWriteCapacityMode.OnDemand.md): si tratta di un'opzione di fatturazione flessibile in grado di soddisfare migliaia di richieste al secondo senza la necessità di pianificare la capacità. Offre pay-per-request prezzi per le richieste di lettura e scrittura in modo da pagare solo per ciò che si utilizza.
+ [Provisioned](ReadWriteCapacityMode.Provisioned.md): se si sceglie la modalità Provisioned Throughput Capacity, si specifica il numero di letture e scritture al secondo necessarie per l'applicazione. Questo ti aiuta a gestire l'utilizzo di Amazon Keyspaces in modo che rimanga pari o inferiore a una frequenza di richieste definita per mantenere la prevedibilità.
La modalità Provisioned offre [la scalabilità automatica](autoscaling.md) per regolare automaticamente la tariffa assegnata per aumentare o diminuire per migliorare l'efficienza operativa. Per ulteriori informazioni sulla gestione delle risorse senza server, vedere. [Gestione delle risorse serverless in Amazon Keyspaces (per Apache Cassandra)](serverless_resource_management.md)
Poiché la capacità di throughput di lettura e scrittura viene fornita separatamente in Amazon Keyspaces, è necessario misurare la frequenza di richieste di lettura e scrittura nelle tabelle esistenti in modo indipendente.
Per raccogliere i parametri di utilizzo più accurati dal cluster Cassandra esistente, acquisisci la media delle richieste al secondo (RPS) per le operazioni di lettura e scrittura a livello di coordinatore per un periodo di tempo prolungato per una tabella aggregata su tutti i nodi di un singolo data center.
L'acquisizione dell'RPS medio in un periodo di almeno diverse settimane consente di rilevare picchi e avvallamenti nei modelli di traffico, come illustrato nel diagramma seguente.
![\[Un diagramma che mostra la frequenza media di richieste al secondo al giorno per un periodo di due settimane.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/migration-rps.png)
Sono disponibili due opzioni per determinare la frequenza delle richieste di lettura e scrittura della tabella Cassandra.
+ Usa il monitoraggio Cassandra esistente
Puoi utilizzare le metriche mostrate nella tabella seguente per osservare le richieste di lettura e scrittura. Tieni presente che i nomi delle metriche possono cambiare in base allo strumento di monitoraggio che stai utilizzando.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/migrating-cassandra.html)
+ Utilizzo della `nodetool`
Usa `nodetool tablestats` e `nodetool info` per acquisire le operazioni medie di lettura e scrittura dalla tabella. `tablestats`restituisce il conteggio totale di letture e scritture dal momento in cui il nodo è stato avviato. `nodetool info`fornisce il tempo di attività di un nodo in secondi.
Per ottenere la media delle letture e delle scritture al secondo, dividi il conteggio delle letture e delle scritture per il tempo di attività del nodo, espresso in secondi. Quindi, per le letture si divide per il livello di coerenza e per le scritture si divide per il fattore di replica. Questi calcoli sono espressi nelle seguenti formule.
Formula per la media delle letture al secondo:
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
Formula per la media delle scritture al secondo:
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
Supponiamo di avere un cluster a 12 nodi attivo da 4 settimane. `nodetool info`restituisce 2.419.200 secondi di uptime e `nodetool tablestats` restituisce 1 miliardo di scritture e 2 miliardi di letture. Questo esempio comporterebbe il seguente calcolo.
```
((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. Determinare l'utilizzo della capacità della tabella
Per stimare l'utilizzo medio della capacità, inizia con i tassi di richiesta medi e la dimensione media delle righe della tabella dei sorgenti di Cassandra.
Amazon Keyspaces utilizza unità di *capacità di lettura (RCUs) e unità* di *capacità di scrittura* (WCUs) per misurare la capacità di throughput assegnata per le letture e le scritture per le tabelle. Per questa stima utilizziamo queste unità per calcolare le esigenze di capacità di lettura e scrittura della nuova tabella Amazon Keyspaces dopo la migrazione.
Più avanti in questo argomento vedremo in che modo la scelta tra la modalità di capacità fornita e quella con capacità su richiesta influisce sulla fatturazione. Tuttavia, per la stima dell'utilizzo della capacità in questo esempio, supponiamo che la tabella sia in modalità provisioning.
+ **Letture**: una RCU rappresenta una `LOCAL_QUORUM` o due richieste di `LOCAL_ONE` lettura per una riga di dimensioni fino a 4 KB. Se è necessario leggere una riga di dimensioni superiori a 4 KB, l'operazione di lettura utilizza elementi aggiuntivi. RCUs Il numero totale di elementi RCUs richiesti dipende dalla dimensione della riga e dal fatto che si desideri utilizzare `LOCAL_QUORUM` o `LOCAL_ONE` leggere la coerenza.
Ad esempio, per leggere una riga da 8 KB sono necessarie 2 unità che RCUs utilizzano la coerenza di `LOCAL_QUORUM` lettura e 1 RCU se si sceglie la coerenza di `LOCAL_ONE` lettura.
+ **Scritture**: una WCU rappresenta una scrittura per una riga di dimensioni fino a 1 KB. Tutte le scritture utilizzano `LOCAL_QUORUM` la coerenza e non sono previsti costi aggiuntivi per l'utilizzo di transazioni leggere ()LWTs.
Il numero totale di WCUs richieste dipende dalla dimensione della riga. Se è necessario scrivere una riga più grande di 1 KB, l'operazione di scrittura utilizza elementi aggiuntivi WCUs. Ad esempio, se la dimensione della riga è di 2 KB, ne occorrono 2 WCUs per eseguire una richiesta di scrittura.
La formula seguente può essere utilizzata per stimare la quantità RCUs e WCUs.
+ **La capacità di lettura in RCUs** entrata può essere determinata moltiplicando le letture al secondo per il numero di righe lette per lettura moltiplicato per la dimensione media delle righe divisa per 4 KB e arrotondata al numero intero più vicino.
+ **La capacità di scrittura WCUs** può essere determinata moltiplicando il numero di richieste per la dimensione media delle righe divisa per 1 KB e arrotondata al numero intero più vicino.
Ciò è espresso nelle seguenti formule.
```
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
```
Ad esempio, se stai eseguendo 4.960 richieste di lettura con una dimensione di riga di 2,5 KB sulla tua tabella Cassandra, ne occorrono 4.960 in Amazon Keyspaces. RCUs Se attualmente stai eseguendo 1.653 richieste di scrittura al secondo con una dimensione di riga di 2,5 KB sulla tua tabella Cassandra, ne occorrono 4.959 al WCUs secondo in Amazon Keyspaces.
Questo esempio è espresso nelle seguenti formule.
```
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'utilizzo `eventual consistency` consente di risparmiare fino alla metà della capacità di throughput per ogni richiesta di lettura. Ogni lettura coerente alla fine può consumare fino a 8 KB. È possibile calcolare eventuali letture coerenti moltiplicando il calcolo precedente per 0,5, come illustrato nella formula seguente.
```
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. Calcola la stima mensile dei prezzi per Amazon Keyspaces
Per stimare la fatturazione mensile della tabella in base alla read/write capacità effettiva, puoi calcolare i prezzi per la modalità on-demand e quella per la modalità provisioning utilizzando formule diverse e confrontare le opzioni disponibili per la tabella.
**Modalità di provisioning**: il consumo di capacità di lettura e scrittura viene fatturato in base a una tariffa oraria basata sulle unità di capacità al secondo. Innanzitutto, dividi tale percentuale per 0,7 per rappresentare l'obiettivo di utilizzo predefinito del 70% per la scalabilità automatica. Quindi moltiplica per 30 giorni di calendario, 24 ore al giorno e tariffazione regionale.
Questo calcolo è riepilogato nelle seguenti formule.
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**Modalità su richiesta: la** capacità di lettura e scrittura viene fatturata in base a una tariffa per richiesta. Innanzitutto, moltiplica la frequenza delle richieste per 30 giorni di calendario e 24 ore al giorno. Quindi dividi per un milione di unità di richiesta. Infine, moltiplicare per la tariffa regionale.
Questo calcolo è riassunto nelle seguenti formule.
```
((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
```
## Scegli una strategia di migrazione
Puoi scegliere tra le seguenti strategie di migrazione durante la migrazione da Apache Cassandra ad Amazon Keyspaces:
+ **Online**: si tratta di una migrazione in tempo reale che utilizza la doppia scrittura per iniziare a scrivere nuovi dati contemporaneamente su Amazon Keyspaces e sul cluster Cassandra. Questo tipo di migrazione è consigliato per le applicazioni che non richiedono tempi di inattività durante la migrazione e la coerenza tra lettura e scrittura.
Per ulteriori informazioni su come pianificare e implementare una strategia di migrazione online, consulta[Migrazione online verso Amazon Keyspaces: strategie e best practice](migrating-online.md).
+ **Offline**: questa tecnica di migrazione prevede la copia di un set di dati da Cassandra ad Amazon Keyspaces durante una finestra di inattività. La migrazione offline può semplificare il processo di migrazione, poiché non richiede modifiche all'applicazione o la risoluzione dei conflitti tra dati storici e nuove scritture.
Per ulteriori informazioni su come pianificare una migrazione offline, consulta[Processo di migrazione offline: da Apache Cassandra ad Amazon Keyspaces](migrating-offline.md).
+ **Ibrido**: questa tecnica di migrazione consente di replicare le modifiche su Amazon Keyspaces quasi in tempo reale, ma senza coerenza tra lettura e scrittura.
Per ulteriori informazioni su come pianificare una migrazione ibrida, consulta. [Utilizzo di una soluzione di migrazione ibrida: da Apache Cassandra ad Amazon Keyspaces](migrating-hybrid.md)
Dopo aver esaminato le tecniche di migrazione e le best practice illustrate in questo argomento, è possibile inserire le opzioni disponibili in un albero decisionale per progettare una strategia di migrazione basata sui requisiti e sulle risorse disponibili.
# Migrazione online verso Amazon Keyspaces: strategie e best practice
Se devi mantenere la disponibilità delle applicazioni durante una migrazione da Apache Cassandra ad Amazon Keyspaces, puoi preparare una strategia di migrazione online personalizzata implementando i componenti chiave discussi in questo argomento. Seguendo queste best practice per le migrazioni online, puoi garantire che la disponibilità e la read-after-write coerenza delle applicazioni siano mantenute durante l'intero processo di migrazione, riducendo al minimo l'impatto sugli utenti.
Quando si progetta una strategia di migrazione online da Apache Cassandra ad Amazon Keyspaces, è necessario considerare i seguenti passaggi chiave.
1. **Scrittura di nuovi dati**
+ **Proxy ZDM Dual Write per la migrazione di Amazon Keyspaces**: utilizza lo ZDM Dual Write Proxy disponibile su [Github per eseguire la migrazione senza downtime da Apache Cassandra](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) ad Amazon Keyspaces. Il proxy ZDM esegue due scritture senza la necessità di rifattorizzare le applicazioni esistenti ed esegue due letture per la convalida delle query.
+ Scritture doppie delle applicazioni: è possibile implementare la doppia scrittura nell'applicazione utilizzando le librerie e i driver client Cassandra esistenti. Designate un database come leader e l'altro come seguace. Gli errori di scrittura nel database dei follower vengono registrati in una [coda di lettere morte (](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)DLQ) per l'analisi.
+ Doppia scrittura a livello di messaggistica: in alternativa, puoi configurare la tua piattaforma di messaggistica esistente per inviare scritture sia a Cassandra che ad Amazon Keyspaces utilizzando un consumatore aggiuntivo. Ciò crea alla fine viste coerenti su entrambi i database.
1. **Migrazione dei dati storici**
+ Copiare dati storici: puoi migrare i dati storici da Cassandra ad Amazon Keyspaces utilizzando AWS Glue i nostri script di estrazione, trasformazione e caricamento (ETL) personalizzati. Gestisci la risoluzione dei conflitti tra due scritture e carichi di massa utilizzando tecniche come transazioni leggere o timestamp.
+ Utilizzo Time-To-Live (TTL): per periodi di conservazione dei dati più brevi, puoi utilizzare TTL sia in Cassandra che in Amazon Keyspaces per evitare di caricare dati storici non necessari. Man mano che i vecchi dati scadono in Cassandra e i nuovi dati vengono scritti tramite doppia scrittura, Amazon Keyspaces alla fine recupera il ritardo.
1. **Convalida dei dati**
+ Doppie letture: implementa letture doppie da entrambi i database Cassandra (primario) e Amazon Keyspaces (secondario), confrontando i risultati in modo asincrono. Le differenze vengono registrate o inviate a un DLQ.
+ Letture di esempio: utilizzate le funzioni λ per campionare e confrontare periodicamente i dati su entrambi i sistemi, registrando eventuali discrepanze su un DLQ.
1. **Migrazione dell'applicazione**
+ Strategia blue-green: cambia la tua applicazione per trattare Amazon Keyspaces come principale e Cassandra come archivio dati secondario in un unico passaggio. Monitora le prestazioni ed esegui il rollback in caso di problemi.
+ Implementazione Canary: distribuisci gradualmente la migrazione prima a un sottoinsieme di utenti, aumentando in modo incrementale il traffico verso Amazon Keyspaces come principale fino alla completa migrazione.
1. **Smantellamento di Cassandra**
Una volta completata la migrazione dell'applicazione ad Amazon Keyspaces e convalidata la coerenza dei dati, puoi pianificare la disattivazione del cluster Cassandra in base alle politiche di conservazione dei dati.
Pianificando una strategia di migrazione online con questi componenti, puoi passare senza problemi al servizio Amazon Keyspaces completamente gestito con tempi di inattività o interruzioni minimi. Le seguenti sezioni approfondiscono ogni componente in modo più dettagliato.
**Topics**
+ [Scrittura di nuovi dati durante una migrazione online](migration-online-dw.md)
+ [Caricamento di dati storici durante una migrazione online](migration-online-historical.md)
+ [Convalida della coerenza dei dati durante una migrazione online](migration-online-validation.md)
+ [Migrazione dell'applicazione durante una migrazione online](migration-online-app-migration.md)
+ [Disattivazione di Cassandra dopo una migrazione online](migration-online-decommission.md)
# Scrittura di nuovi dati durante una migrazione online
Il primo passo di un piano di migrazione online consiste nell'assicurare che tutti i nuovi dati scritti dall'applicazione siano archiviati in entrambi i database, nel cluster Cassandra esistente e in Amazon Keyspaces. L'obiettivo è fornire una visione coerente tra i due archivi di dati. È possibile farlo applicando tutte le nuove scritture a entrambi i database. Per implementare la doppia scrittura, considera una delle tre opzioni seguenti.
+ **Proxy ZDM Dual Write per la migrazione di Amazon Keyspaces**: utilizzando il proxy ZDM per Amazon Keyspaces disponibile [su Github, puoi migrare i carichi di lavoro di Apache Cassandra su](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) Amazon Keyspaces senza tempi di inattività delle applicazioni. Questa soluzione avanzata implementa le migliori pratiche ed estende le funzionalità ufficiali di ZDM Proxy. AWS
+ Esegui migrazioni online tra Apache Cassandra e Amazon Keyspaces.
+ Scrivi dati su entrambe le tabelle di origine e di destinazione contemporaneamente senza rifattorizzare le applicazioni.
+ Convalida le query tramite operazioni di doppia lettura.
La soluzione offre i seguenti miglioramenti con cui lavorare e AWS Amazon Keyspaces.
+ **Distribuzione di container**: utilizza un'immagine Docker preconfigurata da Amazon Elastic Container Registry (Amazon ECR) per distribuzioni accessibili tramite VPC.
+ **Infrastruttura come codice**: esegui la distribuzione utilizzando modelli per la configurazione automatica su. AWS CloudFormation AWS Fargate
+ **Compatibilità con Amazon Keyspaces:** accedi alle tabelle di sistema con adattamenti personalizzati per Amazon Keyspaces.
La soluzione viene eseguita su Amazon ECS con Fargate, fornendo scalabilità serverless in base alle richieste del carico di lavoro. Un sistema di bilanciamento del carico di rete distribuisce il traffico delle applicazioni in entrata tra più attività Amazon ECS per un'elevata disponibilità.
![\[Implementazione del proxy dual write ZDM per la migrazione dei dati da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **Scritture doppie delle applicazioni**: è possibile implementare la doppia scrittura con modifiche minime al codice dell'applicazione sfruttando le librerie e i driver client Cassandra esistenti. È possibile implementare la doppia scrittura nell'applicazione esistente o creare un nuovo livello nell'architettura per gestire le doppie scritture. Per ulteriori informazioni e per un case study di un cliente che mostra come sono state implementate le doppie scritture in un'applicazione esistente, consulta il [case study sulla migrazione di Cassandra](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/).
Quando si implementano le doppie scritture, è possibile designare un database come leader e l'altro database come seguace. Ciò consente di continuare a scrivere sul database di origine o leader originale senza che errori di scrittura del database follower o di destinazione interrompano il percorso critico dell'applicazione.
Invece di riprovare le scritture non riuscite al follower, puoi utilizzare Amazon Simple Queue Service per registrare le scritture non riuscite in una [coda di lettere morte](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) (DLQ). Il DLQ consente di analizzare le scritture non riuscite al follower e determinare il motivo per cui l'elaborazione non è riuscita nel database di destinazione.
Per un'implementazione in doppia scrittura più sofisticata, puoi seguire le AWS migliori pratiche per progettare una sequenza di transazioni locali utilizzando il modello [saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html). Un modello a catena garantisce che, se una transazione fallisce, la saga esegua transazioni di compensazione per ripristinare le modifiche al database apportate dalle transazioni precedenti.
Quando si utilizzano le doppie scritture per una migrazione online, è possibile configurare le doppie scritture seguendo lo schema saga in modo che ogni scrittura sia una transazione locale per garantire operazioni atomiche su database eterogenei. [Per ulteriori informazioni sulla progettazione di applicazioni distribuite utilizzando i modelli di progettazione consigliati per ilCloud AWS, consulta Modelli di progettazione, architetture e implementazioni del cloud.](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction)
![\[Implementazione della doppia scrittura a livello di applicazione durante la migrazione da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **Doppia scrittura a livello di messaggistica**: invece di implementare la doppia scrittura a livello di applicazione, puoi utilizzare il livello di messaggistica esistente per eseguire due scritture su Cassandra e Amazon Keyspaces.
A tale scopo, puoi configurare un utente aggiuntivo sulla tua piattaforma di messaggistica per inviare scritture a entrambi gli archivi di dati. Questo approccio offre una semplice strategia low-code che utilizza il livello di messaggistica per creare due visualizzazioni su entrambi i database che alla fine sono coerenti.
# Caricamento di dati storici durante una migrazione online
Dopo aver implementato la doppia scrittura per garantire che i nuovi dati vengano scritti in entrambi gli archivi di dati in tempo reale, il passaggio successivo del piano di migrazione consiste nel valutare la quantità di dati storici da copiare o caricare in blocco da Cassandra ad Amazon Keyspaces. Ciò garantisce che sia i nuovi dati che i dati storici siano disponibili nel nuovo database Amazon Keyspaces prima della migrazione dell'applicazione.
A seconda dei requisiti di conservazione dei dati, ad esempio della quantità di dati storici da conservare in base alle politiche dell'organizzazione, puoi prendere in considerazione una delle due opzioni seguenti.
+ **Caricamento in blocco di dati storici**: la migrazione dei dati storici dalla distribuzione esistente di Cassandra ad Amazon Keyspaces può essere ottenuta attraverso varie tecniche, ad esempio utilizzando AWS Glue o script personalizzati per estrarre, trasformare e caricare (ETL) i dati. Per ulteriori informazioni sull'utilizzo per caricare dati storici, AWS Glue consulta. [Processo di migrazione offline: da Apache Cassandra ad Amazon Keyspaces](migrating-offline.md)
Quando si pianifica il caricamento in blocco di dati storici, è necessario considerare come risolvere i conflitti che possono verificarsi quando nuove scritture tentano di aggiornare gli stessi dati in fase di caricamento. Si prevede che il caricamento in blocco alla fine sia coerente, il che significa che alla fine i dati raggiungeranno tutti i nodi.
Se si verifica un aggiornamento degli stessi dati contemporaneamente a causa di una nuova scrittura, devi assicurarti che non vengano sovrascritti dal caricamento dei dati storici. Per garantire la conservazione degli aggiornamenti più recenti dei dati anche durante l'importazione in blocco, è necessario aggiungere la risoluzione dei conflitti negli script di caricamento in blocco o nella logica dell'applicazione per le scritture doppie.
Ad esempio, è possibile utilizzare [Transazioni leggere](functional-differences.md#functional-differences.light-transactions) (LWT) per confrontare e impostare le operazioni. A tale scopo, è possibile aggiungere un campo aggiuntivo al modello di dati che rappresenti l'ora o lo stato della modifica.
Inoltre, Amazon Keyspaces supporta la funzione timestamp di Cassandra`WRITETIME`. Puoi utilizzare i timestamp lato client di Amazon Keyspaces per conservare i timestamp del database di origine e implementare la risoluzione dei conflitti. last-writer-wins Per ulteriori informazioni, consulta [Timestamp lato client in Amazon Keyspaces](client-side-timestamps.md).
+ **Utilizzo di Time-to-Live (TTL)**: per periodi di conservazione dei dati inferiori a 30, 60 o 90 giorni, puoi utilizzare TTL in Cassandra e Amazon Keyspaces durante la migrazione per evitare di caricare dati storici non necessari su Amazon Keyspaces. TTL consente di impostare un periodo di tempo dopo il quale i dati vengono rimossi automaticamente dal database.
Durante la fase di migrazione, invece di copiare i dati storici su Amazon Keyspaces, puoi configurare le impostazioni TTL per far scadere automaticamente i dati storici nel vecchio sistema (Cassandra) applicando solo le nuove scritture ad Amazon Keyspaces utilizzando il metodo dual-write. Nel tempo e con i vecchi dati che scadono continuamente nel cluster Cassandra e i nuovi dati scritti utilizzando il metodo dual-write, Amazon Keyspaces recupera automaticamente il ritardo e contiene gli stessi dati di Cassandra.
Questo approccio può ridurre in modo significativo la quantità di dati da migrare, con conseguente processo di migrazione più efficiente e semplificato. È possibile prendere in considerazione questo approccio quando si ha a che fare con set di dati di grandi dimensioni con requisiti di conservazione dei dati diversi. Per ulteriori informazioni su TTL, consulta [Fai scadere i dati con Time to Live (TTL) per Amazon Keyspaces (per Apache Cassandra)](TTL.md).
Considera il seguente esempio di migrazione da Cassandra ad Amazon Keyspaces utilizzando la scadenza dei dati TTL. In questo esempio impostiamo il TTL per entrambi i database su 60 giorni e mostriamo come procede il processo di migrazione in un periodo di 90 giorni. Entrambi i database ricevono gli stessi dati appena scritti durante questo periodo utilizzando il metodo di doppia scrittura. Esamineremo tre diverse fasi della migrazione, ogni fase dura 30 giorni.
Il funzionamento del processo di migrazione per ciascuna fase è illustrato nelle immagini seguenti.
![\[Utilizzo di TTL per far scadere i dati storici durante la migrazione da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. Dopo i primi 30 giorni, il cluster Cassandra e Amazon Keyspaces hanno ricevuto nuove scritture. Il cluster Cassandra contiene anche dati storici che non hanno ancora raggiunto i 60 giorni di conservazione, che rappresentano il 50% dei dati del cluster.
I dati più vecchi di 60 giorni vengono eliminati automaticamente nel cluster Cassandra tramite TTL. A questo punto Amazon Keyspaces contiene il 50% dei dati archiviati nel cluster Cassandra, che è composto dalle nuove scritture meno i dati storici.
1. Dopo 60 giorni, sia il cluster Cassandra che Amazon Keyspaces contengono gli stessi dati scritti negli ultimi 60 giorni.
1. Entro 90 giorni, sia Cassandra che Amazon Keyspaces contengono gli stessi dati e i dati in scadenza hanno la stessa frequenza.
Questo esempio illustra come evitare la fase di caricamento dei dati storici utilizzando TTL con una data di scadenza impostata su 60 giorni.
# Convalida della coerenza dei dati durante una migrazione online
La fase successiva del processo di migrazione online è la convalida dei dati. Le doppie scritture aggiungono nuovi dati al tuo database Amazon Keyspaces e hai completato la migrazione dei dati storici utilizzando il caricamento in blocco o la scadenza dei dati con TTL.
Ora puoi utilizzare la fase di convalida per confermare che entrambi gli archivi dati contengano effettivamente gli stessi dati e restituiscano gli stessi risultati di lettura. Puoi scegliere una delle due opzioni seguenti per verificare che entrambi i database contengano dati identici.
+ **Doppie letture**: per verificare che sia il database di origine che quello di destinazione contengano lo stesso set di dati appena scritti e storici, puoi implementare letture doppie. A tale scopo, leggi sia il database principale Cassandra che quello secondario di Amazon Keyspaces in modo analogo al metodo dual write e confronta i risultati in modo asincrono.
I risultati del database primario vengono restituiti al client e i risultati del database secondario vengono utilizzati per la convalida rispetto al set di risultati primario. Le differenze rilevate possono essere registrate o inviate a una [coda di lettere morte (DLQ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) per una successiva riconciliazione.
Nel diagramma seguente, l'applicazione esegue una lettura sincrona da Cassandra, che è l'archivio dati primario) e una lettura asincrona da Amazon Keyspaces, che è l'archivio dati secondario.
![\[Utilizzo di due letture per convalidare la coerenza dei dati durante una migrazione online da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **Letture di esempio**: una soluzione alternativa che non richiede modifiche al codice dell'applicazione consiste nell'utilizzare AWS Lambda le funzioni per campionare periodicamente e in modo casuale i dati sia dal cluster Cassandra di origine che dal database Amazon Keyspaces di destinazione.
Queste funzioni Lambda possono essere configurate per essere eseguite a intervalli regolari. La funzione Lambda recupera un sottoinsieme casuale di dati sia dal sistema di origine che da quello di destinazione, quindi esegue un confronto tra i dati campionati. Eventuali discrepanze o discrepanze tra i due set di dati possono essere registrate e inviate a una coda di [lettere morte (DLQ) dedicata per una successiva riconciliazione](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html).
Questo processo è illustrato nello schema seguente.
![\[Utilizzo di letture di esempio per convalidare la coerenza dei dati durante la migrazione online da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# Migrazione dell'applicazione durante una migrazione online
Nella quarta fase di una migrazione online, stai migrando la tua applicazione e passando ad Amazon Keyspaces come archivio dati principale. Ciò significa che passi l'applicazione alla lettura e alla scrittura direttamente da e verso Amazon Keyspaces. Per garantire interruzioni minime agli utenti, questo deve essere un processo ben pianificato e coordinato.
Sono disponibili due diverse soluzioni consigliate per la migrazione delle applicazioni, la strategia blue green cut over e la canary cut over strategy. Le sezioni seguenti descrivono queste strategie in modo più dettagliato.
+ **Strategia blue green**: utilizzando questo approccio, puoi cambiare la tua applicazione per trattare Amazon Keyspaces come data store primario e Cassandra come data store secondario in un unico passaggio. Puoi farlo utilizzando un flag di AWS AppConfig funzionalità per controllare la selezione degli archivi dati primari e secondari nell'istanza dell'applicazione. Per ulteriori informazioni sui feature flag, consultate [Creazione di un profilo di configurazione dei feature flag in AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html).
Dopo aver reso Amazon Keyspaces l'archivio dati principale, monitora il comportamento e le prestazioni dell'applicazione, assicurandoti che Amazon Keyspaces soddisfi i tuoi requisiti e che la migrazione abbia esito positivo.
Ad esempio, se hai implementato la doppia lettura per la tua applicazione, durante la fase di migrazione dell'applicazione trasferisci le letture primarie da Cassandra ad Amazon Keyspaces e le letture secondarie da Amazon Keyspaces a Cassandra. Dopo la transizione, continuerai a monitorare e confrontare i risultati come descritto nella sezione sulla [convalida dei dati per garantire la coerenza tra entrambi i database prima della disattivazione di Cassandra](migration-online-validation.md).
Se rilevi problemi, puoi tornare rapidamente allo stato precedente tornando a Cassandra come archivio dati principale. Puoi procedere alla fase di smantellamento della migrazione solo se Amazon Keyspaces soddisfa tutte le tue esigenze come data store primario.
![\[Utilizzo della strategia blu-verde per la migrazione di un'applicazione da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Strategia Canary**: con questo approccio, estendi gradualmente la migrazione a un sottoinsieme dei tuoi utenti o del tuo traffico. Inizialmente, una piccola percentuale del traffico dell'applicazione, ad esempio il 5% di tutto il traffico, viene indirizzato alla versione che utilizza Amazon Keyspaces come data store principale, mentre il resto del traffico continua a utilizzare Cassandra come data store principale.
In questo modo puoi testare a fondo la versione migrata con traffico reale, monitorarne le prestazioni e la stabilità e indagare su potenziali problemi. Se non rilevi alcun problema, puoi aumentare in modo incrementale la percentuale di traffico indirizzato ad Amazon Keyspaces fino a farlo diventare l'archivio dati principale per tutti gli utenti e il traffico.
Questa implementazione graduale riduce al minimo il rischio di interruzioni diffuse del servizio e consente un processo di migrazione più controllato. In caso di problemi critici durante l'implementazione di Canary, puoi tornare rapidamente alla versione precedente utilizzando Cassandra come archivio dati principale per il segmento di traffico interessato. Puoi procedere alla fase di smantellamento della migrazione solo dopo aver verificato che Amazon Keyspaces elabori il 100% degli utenti e del traffico come previsto.
Il diagramma seguente illustra le singole fasi della strategia delle Canarie.
![\[Utilizzo della strategia canary per la migrazione di un'applicazione da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# Disattivazione di Cassandra dopo una migrazione online
Una volta completata la migrazione dell'applicazione, con l'applicazione completamente in esecuzione su Amazon Keyspaces e aver convalidato la coerenza dei dati per un periodo di tempo, puoi pianificare la disattivazione del cluster Cassandra. Durante questa fase, puoi valutare se i dati rimanenti nel cluster Cassandra devono essere archiviati o possono essere eliminati. Ciò dipende dalle politiche dell'organizzazione per la gestione e la conservazione dei dati.
Seguendo questa strategia e considerando le best practice consigliate descritte in questo argomento durante la pianificazione della migrazione online da Cassandra ad Amazon Keyspaces, puoi garantire una transizione senza interruzioni ad Amazon Keyspaces read-after-write mantenendo al contempo la coerenza e la disponibilità dell'applicazione.
La migrazione da Apache Cassandra ad Amazon Keyspaces può offrire numerosi vantaggi, tra cui riduzione del sovraccarico operativo, scalabilità automatica, maggiore sicurezza e un framework che ti aiuta a raggiungere i tuoi obiettivi di conformità. Pianificando una strategia di migrazione online con doppia scrittura, caricamento storico dei dati, convalida dei dati e implementazione graduale, puoi garantire una transizione fluida con interruzioni minime per l'applicazione e i suoi utenti.
L'implementazione della strategia di migrazione online illustrata in questo argomento consente di convalidare i risultati della migrazione, identificare e risolvere eventuali problemi e, infine, disattivare la distribuzione Cassandra esistente a favore del servizio Amazon Keyspaces completamente gestito.
# Processo di migrazione offline: da Apache Cassandra ad Amazon Keyspaces
Le migrazioni offline sono adatte quando ci si può permettere tempi di inattività necessari per eseguire la migrazione. È comune tra le aziende disporre di finestre di manutenzione per l'applicazione di patch, rilasci di grandi dimensioni o tempi di inattività per aggiornamenti hardware o aggiornamenti importanti. La migrazione offline può utilizzare questa finestra per copiare i dati e trasferire il traffico delle applicazioni da Apache Cassandra ad Amazon Keyspaces.
La migrazione offline riduce le modifiche all'applicazione perché non richiede la comunicazione simultanea con Cassandra e Amazon Keyspaces. Inoltre, con il flusso di dati in pausa, è possibile copiare lo stato esatto senza mantenere le mutazioni.
In questo esempio, utilizziamo Amazon Simple Storage Service (Amazon S3) come area di gestione temporanea per i dati durante la migrazione offline per ridurre al minimo i tempi di inattività. Puoi importare automaticamente i dati archiviati in formato Parquet in Amazon S3 in una tabella Amazon Keyspaces utilizzando il connettore Spark Cassandra e. AWS Glue La sezione seguente mostrerà una panoramica di alto livello del processo. Puoi trovare esempi di codice per questo processo su [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue).
Il processo di migrazione offline da Apache Cassandra ad Amazon Keyspaces utilizza Amazon S3 e richiede i seguenti processi. AWS Glue AWS Glue
1. Un processo ETL che estrae e trasforma i dati CQL e li archivia in un bucket Amazon S3.
1. Un secondo processo che importa i dati dal bucket in Amazon Keyspaces.
1. Un terzo lavoro per importare dati incrementali.
**Come eseguire una migrazione offline verso Amazon Keyspaces da Cassandra in esecuzione su Amazon EC2 in un Amazon Virtual Private Cloud**
1. Innanzitutto devi AWS Glue esportare i dati della tabella da Cassandra in formato Parquet e salvarli in un bucket Amazon S3. È necessario eseguire un AWS Glue processo utilizzando un AWS Glue connettore a un VPC in cui risiede l' EC2 istanza Amazon che esegue Cassandra. Quindi, utilizzando l'endpoint privato Amazon S3, puoi salvare i dati nel bucket Amazon S3.
Il diagramma seguente illustra questi passaggi.
![\[Migrazione dei dati di Apache Cassandra da Amazon EC2 in esecuzione in un VPC a un bucket Amazon S3 utilizzando. AWS Glue\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Mescola i dati nel bucket Amazon S3 per migliorare la randomizzazione dei dati. I dati importati in modo uniforme consentono una maggiore distribuzione del traffico nella tabella di destinazione.
Questo passaggio è necessario quando si esportano dati da Cassandra con partizioni di grandi dimensioni (partizioni con più di 1000 righe) per evitare schemi di tasti di scelta rapida durante l'inserimento dei dati in Amazon Keyspaces. I problemi relativi ai tasti di scelta rapida si verificano `WriteThrottleEvents` in Amazon Keyspaces e comportano un aumento del tempo di caricamento.
![\[Un AWS Glue job mescola i dati da un bucket Amazon S3 e li restituisce in un altro bucket Amazon S3.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. Usa un altro AWS Glue processo per importare dati dal bucket Amazon S3 in Amazon Keyspaces. I dati mischiati nel bucket Amazon S3 vengono archiviati in formato Parquet.
![\[Il processo di AWS Glue importazione prende i dati mescolati dal bucket Amazon S3 e li sposta in una tabella Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/migration-import.png)
Per ulteriori informazioni sul processo di migrazione offline, consulta il workshop [Amazon Keyspaces](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue) con AWS Glue
# Utilizzo di una soluzione di migrazione ibrida: da Apache Cassandra ad Amazon Keyspaces
La seguente soluzione di migrazione può essere considerata un ibrido tra migrazione online e offline. Con questo approccio ibrido, i dati vengono scritti nel database di destinazione quasi in tempo reale senza fornire coerenza tra lettura e scrittura. Ciò significa che i dati appena scritti non saranno immediatamente disponibili e sono prevedibili ritardi. Se hai bisogno di coerenza tra lettura e scrittura, vedi[Migrazione online verso Amazon Keyspaces: strategie e best practice](migrating-online.md).
Per una migrazione quasi in tempo reale da Apache Cassandra ad Amazon Keyspaces, puoi scegliere tra due metodi disponibili.
+ **CQLReplicator**— (Consigliata) CQLReplicator è un'utilità open source disponibile su [Github](https://github.com/aws-samples/cql-replicator) che consente di migrare i dati da Apache Cassandra ad Amazon Keyspaces quasi in tempo reale.
Per determinare le scritture e gli aggiornamenti da propagare al database di destinazione, CQLReplicator analizza l'intervallo di token Apache Cassandra e utilizza un AWS Glue processo per rimuovere gli eventi duplicati e applicare scritture e aggiornamenti direttamente ad Amazon Keyspaces.
+ **Change Data Capture (CDC)**: se conosci Cassandra CDC, la funzionalità CDC integrata di Apache Cassandra che consente di acquisire le modifiche copiando il log di commit in una directory CDC separata è un'altra opzione per implementare una migrazione ibrida.
Puoi farlo replicando le modifiche ai dati in Amazon Keyspaces, rendendo CDC un'opzione alternativa per gli scenari di migrazione dei dati.
Se non hai bisogno di coerenza tra lettura e scrittura, puoi utilizzare la pipeline CQLReplicator o una CDC per migrare i dati da Apache Cassandra ad Amazon Keyspaces in base alle tue preferenze e alla tua familiarità con gli strumenti utilizzati in ciascuna soluzione. Servizi AWS L'utilizzo di questi metodi per migrare i dati quasi in tempo reale può essere considerato un approccio ibrido alla migrazione che offre un'alternativa alla migrazione online.
Questa strategia è considerata un approccio ibrido, poiché oltre alle opzioni descritte in questo argomento, è necessario implementare alcune fasi del progresso della migrazione online, ad esempio la copia storica dei dati e le strategie di migrazione delle applicazioni discusse nell'argomento sulla [migrazione online](migrating-online.md).
Le sezioni seguenti esaminano le opzioni di migrazione ibrida in modo più dettagliato.
**Topics**
+ [Migra i dati utilizzando CQLReplicator](migration-hybrid-cql-rep.md)
+ [Migra i dati utilizzando Change Data Capture (CDC)](migration-hybrid-cdc.md)
# Migra i dati utilizzando CQLReplicator
Con [CQLReplicator](https://github.com/aws-samples/cql-replicator), puoi leggere i dati da Apache Cassandra quasi in tempo reale scansionando in modo intelligente il token ring di Cassandra utilizzando le query CQL. CQLReplicator non utilizza Cassandra CDC e implementa invece una strategia di caching per ridurre le penalità prestazionali delle scansioni complete.
Per ridurre il numero di scritture sulla destinazione, rimuove automaticamente gli eventi di replica duplicati CQLReplicator . Con CQLReplicator, puoi ottimizzare la replica delle modifiche dal database di origine al database di destinazione, consentendo una migrazione quasi in tempo reale dei dati da Apache Cassandra ad Amazon Keyspaces.
Il diagramma seguente mostra l'architettura tipica di un job che utilizza. CQLReplicator AWS Glue
1. **Per consentire l'accesso ad Apache Cassandra in esecuzione in un VPC privato, configura una AWS Glue connessione con il tipo di connessione Rete.**
1. Per rimuovere i duplicati e abilitare la memorizzazione nella cache delle chiavi con il CQLReplicator job, configura Amazon Simple Storage Service (Amazon S3).
1. Il database di origine verificato di CQLReplicator Job Streams viene modificato direttamente in Amazon Keyspaces.
![\[Utilizzo CQLReplicator per migrare i dati da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
Per ulteriori informazioni sull'utilizzo del processo di migrazione CQLReplicator, consulta il seguente post sul blog AWS Database [Migrate Cassandra to Amazon Keyspaces using CQLReplicator e la guida AWS prescrittiva Migrate Apache [Cassandra](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) workload](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) to Amazon Keyspaces using. AWS Glue
# Migra i dati utilizzando Change Data Capture (CDC)
Se hai già familiarità con la configurazione di una pipeline di change data capture (CDC) con [Debezium](https://debezium.io/), puoi utilizzare questa opzione per migrare i dati su Amazon Keyspaces come alternativa all'utilizzo. CQLReplicator Debezium è una piattaforma open source e distribuita per CDC, progettata per monitorare un database e acquisire le modifiche a livello di riga in modo affidabile.
Il [connettore Debezium per Apache Cassandra carica le](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) modifiche su Amazon Managed Streaming for Apache Kafka (Amazon MSK) in modo che possano essere utilizzate ed elaborate dai consumatori downstream che a loro volta scrivono i dati su Amazon Keyspaces. Per ulteriori informazioni, consulta [Guida per la migrazione continua dei dati da Apache Cassandra ad Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/).
Per risolvere eventuali problemi di coerenza dei dati, puoi implementare un processo con Amazon MSK in cui un consumatore confronta le chiavi o le partizioni di Cassandra con quelle di Amazon Keyspaces.
Per implementare correttamente questa soluzione, consigliamo di prendere in considerazione quanto segue.
+ Come analizzare il registro di commit del CDC, ad esempio come rimuovere gli eventi duplicati.
+ Come mantenere la directory CDC, ad esempio come eliminare i vecchi log.
+ Come gestire gli errori parziali in Apache Cassandra, ad esempio se una scrittura riesce solo in una replica su tre.
+ Come gestire l'allocazione delle risorse, ad esempio aumentando le dimensioni dell'istanza per tenere conto dei requisiti aggiuntivi di CPU, memoria, DISCO e IO per il processo CDC che si verifica su un nodo.
Questo modello considera le modifiche apportate a Cassandra come un «indizio» del fatto che una chiave potrebbe essere cambiata rispetto al suo stato precedente. Per determinare se ci sono modifiche da propagare al database di destinazione, devi prima leggere dal cluster Cassandra di origine utilizzando un'`LOCAL_QUORUM`operazione per ricevere i record più recenti e poi scriverli su Amazon Keyspaces.
In caso di eliminazioni o aggiornamenti di intervalli, potrebbe essere necessario eseguire un confronto con l'intera partizione per determinare quali eventi di scrittura o aggiornamento devono essere scritti nel database di destinazione.
Nei casi in cui le scritture non sono idempotenti, devi anche confrontare le tue scritture con quelle già presenti nel database di destinazione prima di scrivere su Amazon Keyspaces.
Il diagramma seguente mostra l'architettura tipica di una pipeline CDC che utilizza Debezium e Amazon MSK.
![\[Utilizzo di una pipeline di acquisizione dei dati di modifica per migrare i dati da Apache Cassandra ad Amazon Keyspaces.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)
# Come scegliere lo strumento giusto per il caricamento in blocco o la migrazione di dati su Amazon Keyspaces
In questa sezione puoi esaminare i diversi strumenti che puoi utilizzare per caricare in blocco o migrare dati su Amazon Keyspaces e scoprire come selezionare lo strumento corretto in base alle tue esigenze. Inoltre, questa sezione fornisce una panoramica e casi d'uso per step-by-step i tutorial disponibili che dimostrano come importare dati in Amazon Keyspaces.
Per esaminare le strategie disponibili per migrare i carichi di lavoro da Apache Cassandra ad Amazon Keyspaces, consulta. [Crea un piano di migrazione per la migrazione da Apache Cassandra ad Amazon Keyspaces](migrating-cassandra.md)
+ **Strumenti di migrazione**
+ Con il [calcolatore dei prezzi per Amazon Keyspaces (per Apache Cassandra](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra)) disponibile su Github, puoi stimare i costi mensili per Amazon Keyspaces in base al tuo carico di lavoro Apache Cassandra esistente. Inserisci i parametri dello stato dello strumento Cassandra e della configurazione serverless prevista per Amazon Keyspaces per confrontare i costi diretti tra le due soluzioni. Tieni presente che questo calcolatore si concentra solo sui costi operativi di Amazon Keyspaces rispetto alla distribuzione Cassandra esistente. Non include fattori del costo totale di proprietà (TCO) come la manutenzione dell'infrastruttura, le spese generali operative o i costi di supporto per Cassandra.
+ **Proxy ZDM Dual Write per Amazon Keyspaces Migration — ZDM Dual Write Proxy disponibile su [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) supporta la migrazione** senza downtime da Apache Cassandra ad Amazon Keyspaces.
+ **CQLReplicator**— CQLReplicator è un'utilità open source disponibile su [Github](https://github.com/aws-samples/cql-replicator) che consente di migrare i dati da Apache Cassandra ad Amazon Keyspaces quasi in tempo reale.
Per ulteriori informazioni, consulta [Migra i dati utilizzando CQLReplicator](migration-hybrid-cql-rep.md).
+ Per ulteriori informazioni su come utilizzare Amazon Managed Streaming for Apache Kafka per [implementare un](migrating-online.md) processo di migrazione online con doppia scrittura[, consulta la Guida per la migrazione continua dei dati da](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/) Apache Cassandra ad Amazon Keyspaces.
+ Per migrazioni di grandi dimensioni, prendi in considerazione l'utilizzo di uno strumento di estrazione, trasformazione e caricamento (ETL). È possibile utilizzarlo AWS Glue per eseguire migrazioni di trasformazione dei dati in modo rapido ed efficace. Per ulteriori informazioni, consulta [Processo di migrazione offline: da Apache Cassandra ad Amazon Keyspaces](migrating-offline.md).
+ Per informazioni su come utilizzare il connettore Apache Cassandra Spark per scrivere dati su Amazon Keyspaces, consulta. [Tutorial: Integrazione con Apache Spark per importare o esportare dati](spark-integrating.md)
+ Inizia rapidamente a caricare dati in Amazon Keyspaces utilizzando il `COPY FROM` comando cqlsh. cqlsh è incluso in Apache Cassandra ed è ideale per caricare piccoli set di dati o dati di test. step-by-stepPer istruzioni, consulta. [Tutorial: Caricamento di dati in Amazon Keyspaces utilizzando cqlsh](bulk-upload.md)
+ Puoi anche utilizzare DataStax Bulk Loader per Apache Cassandra per caricare dati in Amazon Keyspaces utilizzando il comando. `dsbulk` DSBulk[offre funzionalità di importazione più solide rispetto a cqlsh ed è disponibile nel repository. GitHub ](https://github.com/datastax/dsbulk) Per step-by-step istruzioni, vedere. [Tutorial: caricamento di dati in Amazon Keyspaces utilizzando DSBulk](dsbulk-upload.md)
Considerazioni generali per il caricamento di dati su Amazon Keyspaces
+ **Suddividi il caricamento dei dati in componenti più piccoli.**
Considerate le seguenti unità di migrazione e il loro potenziale impatto in termini di dimensioni dei dati grezzi. Il caricamento di piccole quantità di dati in una o più fasi può contribuire a semplificare la migrazione.
+ **Per cluster**: migra tutti i dati di Cassandra contemporaneamente. Questo approccio può essere utile per i cluster più piccoli.
+ **Per spazio di chiavi o tabella**: suddividi la migrazione in gruppi di spazi chiave o tabelle. Questo approccio può aiutarti a migrare i dati in fasi in base ai requisiti per ogni carico di lavoro.
+ **In base ai dati**: valuta la possibilità di migrare i dati per un gruppo specifico di utenti o prodotti, per ridurre ulteriormente le dimensioni dei dati.
+ **Dai la priorità ai dati da caricare per primi in base alla semplicità.**
Valuta se disponi di dati che potrebbero essere migrati per primi più facilmente, ad esempio dati che non cambiano in orari specifici, dati provenienti da processi in batch notturni, dati non utilizzati durante le ore offline o dati provenienti da app interne.
**Topics**
+ [Tutorial: Caricamento di dati in Amazon Keyspaces utilizzando cqlsh](bulk-upload.md)
+ [Tutorial: caricamento di dati in Amazon Keyspaces utilizzando DSBulk](dsbulk-upload.md)
# Tutorial: Caricamento di dati in Amazon Keyspaces utilizzando cqlsh
Questo tutorial ti guida attraverso il processo di migrazione dei dati da Apache Cassandra ad Amazon Keyspaces utilizzando il comando. `cqlsh COPY FROM` Il `cqlsh COPY FROM` comando è utile per caricare rapidamente e facilmente piccoli set di dati su Amazon Keyspaces per scopi accademici o di test. Per ulteriori informazioni su come migrare i carichi di lavoro di produzione, consulta. [Processo di migrazione offline: da Apache Cassandra ad Amazon Keyspaces](migrating-offline.md) In questo tutorial, completerai i seguenti passaggi:
Prerequisiti: configura un AWS account con credenziali, crea un file di trust store JKS per il certificato e configura la connessione `cqlsh` ad Amazon Keyspaces.
1. **Crea CSV di origine e tabella di destinazione**: prepara un file CSV come dati di origine e crea lo spazio chiave e la tabella di destinazione in Amazon Keyspaces.
1. **Preparazione dei dati**: randomizza i dati nel file CSV e analizzali per determinare le dimensioni medie e massime delle righe.
1. **Imposta la capacità di trasmissione**: calcola le unità di capacità di scrittura richieste (WCUs) in base alla dimensione dei dati e al tempo di caricamento desiderato e configura la capacità assegnata alla tabella.
1. **Configura i parametri cqlsh**: determina i valori ottimali per `cqlsh COPY FROM` parametri come`INGESTRATE`, `NUMPROCESSES``MAXBATCHSIZE`, e distribuisci il carico di lavoro `CHUNKSIZE` in modo uniforme.
1. **Esegui il `cqlsh COPY FROM` comando**: esegui il `cqlsh COPY FROM` comando per caricare i dati dal file CSV nella tabella Amazon Keyspaces e monitorare l'avanzamento.
Risoluzione dei problemi: risolvi problemi comuni come richieste non valide, errori del parser, errori di capacità ed errori cqlsh durante il processo di caricamento dei dati.
**Topics**
+ [Prerequisiti: passaggi da completare prima di poter caricare i dati utilizzando `cqlsh COPY FROM`](bulk-upload-prequs.md)
+ [Passaggio 1: crea il file CSV di origine e una tabella di destinazione per il caricamento dei dati](bulk-upload-source.md)
+ [Passaggio 2: prepara i dati di origine per un corretto caricamento dei dati](bulk-upload-prepare-data.md)
+ [Fase 3: Impostare la capacità di throughput per la tabella](bulk-upload-capacity.md)
+ [Fase 4: Configurare `cqlsh COPY FROM` le impostazioni](bulk-upload-config.md)
+ [Passaggio 5: Esegui il `cqlsh COPY FROM` comando per caricare i dati dal file CSV nella tabella di destinazione](bulk-upload-run.md)
+ [Risoluzione dei problemi](bulk-upload-troubleshooting.md)
# Prerequisiti: passaggi da completare prima di poter caricare i dati utilizzando `cqlsh COPY FROM`
Devi completare le seguenti attività prima di iniziare questo tutorial.
1. Se non l'hai già fatto, iscriviti a un account Account AWS seguendo i passaggi riportati in[Configurazione AWS Identity and Access Management](accessing.md#SettingUp.IAM).
1. Crea credenziali specifiche per il servizio seguendo i passaggi riportati in. [Crea credenziali specifiche del servizio per l'accesso programmatico ad Amazon Keyspaces](programmatic.credentials.ssc.md)
1. Configura la connessione shell Cassandra Query Language (cqlsh) e conferma di poterti connettere ad Amazon Keyspaces seguendo i passaggi indicati. [Utilizzo `cqlsh` per connettersi ad Amazon Keyspaces](programmatic.cqlsh.md)
# Passaggio 1: crea il file CSV di origine e una tabella di destinazione per il caricamento dei dati
Per questo tutorial, utilizziamo un file con valori separati da virgole (CSV) con il nome `keyspaces_sample_table.csv` come file di origine per la migrazione dei dati. Il file di esempio fornito contiene alcune righe di dati per una tabella con il nome. `book_awards`
1. Crea il file sorgente. Puoi scegliere una delle seguenti opzioni:
+ Scaricate il file CSV di esempio (`keyspaces_sample_table.csv`) contenuto nel seguente file di archivio [samplemigration.zip](samples/samplemigration.zip). Decomprimi l'archivio e prendi nota del percorso verso. `keyspaces_sample_table.csv`
+ Per compilare un file CSV con i propri dati memorizzati in un database Apache Cassandra, è possibile compilare il file CSV di origine utilizzando l'`cqlsh``COPY TO`istruzione, come illustrato nell'esempio seguente.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true";
```
Assicurati che il file CSV che crei soddisfi i seguenti requisiti:
+ La prima riga contiene i nomi delle colonne.
+ I nomi delle colonne nel file CSV di origine corrispondono ai nomi delle colonne nella tabella di destinazione.
+ I dati sono delimitati da una virgola.
+ Tutti i valori dei dati sono tipi di dati Amazon Keyspaces validi. Per informazioni, consulta [Tipi di dati](cql.elements.md#cql.data-types).
1. Crea lo spazio chiave e la tabella di destinazione in Amazon Keyspaces.
1. Connettiti ad Amazon Keyspaces utilizzando `cqlsh` e sostituendo l'endpoint del servizio, il nome utente e la password nell'esempio seguente con i tuoi valori.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Crea un nuovo keyspace con il nome mostrato nell'`catalog`esempio seguente.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Quando il nuovo keyspace è disponibile, utilizzate il codice seguente per creare la tabella di destinazione. `book_awards`
```
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)
);
```
Se Apache Cassandra è la tua fonte di dati originale, un modo semplice per creare la tabella di destinazione di Amazon Keyspaces con intestazioni corrispondenti consiste nel generare l'`CREATE TABLE`istruzione dalla tabella di origine, come illustrato nell'istruzione seguente.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Quindi crea la tabella di destinazione in Amazon Keyspaces con i nomi delle colonne e i tipi di dati che corrispondono alla descrizione della tabella di origine di Cassandra.
# Passaggio 2: prepara i dati di origine per un corretto caricamento dei dati
La preparazione dei dati di origine per un trasferimento efficiente è un processo in due fasi. Innanzitutto, i dati vengono randomizzati. Nella seconda fase, si analizzano i dati per determinare i valori dei `cqlsh` parametri appropriati e le impostazioni della tabella richieste per garantire che il caricamento dei dati abbia esito positivo.
**Randomizza i dati**
Il `cqlsh COPY FROM` comando legge e scrive i dati nello stesso ordine in cui appaiono nel file CSV. Se si utilizza il `cqlsh COPY TO` comando per creare il file sorgente, i dati vengono scritti in ordine di chiave nel file CSV. Internamente, Amazon Keyspaces partiziona i dati utilizzando chiavi di partizione. Sebbene Amazon Keyspaces disponga di una logica integrata per aiutare a bilanciare il carico delle richieste per la stessa chiave di partizione, il caricamento dei dati è più rapido ed efficiente se si rende casuale l'ordine. Questo perché puoi sfruttare il bilanciamento del carico integrato che si verifica quando Amazon Keyspaces scrive su partizioni diverse.
Per distribuire le scritture tra le partizioni in modo uniforme, devi randomizzare i dati nel file sorgente. [È possibile scrivere un'applicazione per eseguire questa operazione o utilizzare uno strumento open source, come Shuf.](https://en.wikipedia.org/wiki/Shuf) Shuf è disponibile gratuitamente sulle distribuzioni Linux, su macOS (installando coreutils in [homebrew](https://brew.sh)) e su Windows (utilizzando Windows Subsystem for Linux (WSL)). È necessario un passaggio aggiuntivo per evitare che la riga di intestazione con i nomi delle colonne venga mescolata in questo passaggio.
Per rendere casuale il file sorgente preservando l'intestazione, inserisci il codice seguente.
```
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 riscrive i dati in un nuovo file CSV chiamato. `keyspace.table.csv` Ora puoi eliminare il `keyspaces_sample_table.csv` file, non è più necessario.
**Analizza i dati**
Determina la dimensione media e massima delle righe analizzando i dati.
Lo fai per i seguenti motivi:
+ La dimensione media delle righe aiuta a stimare la quantità totale di dati da trasferire.
+ È necessaria la dimensione media delle righe per fornire la capacità di scrittura necessaria per il caricamento dei dati.
+ Puoi assicurarti che ogni riga abbia una dimensione inferiore a 1 MB, che è la dimensione massima delle righe in Amazon Keyspaces.
**Nota**
Questa quota si riferisce alla dimensione della riga, non alla dimensione della partizione. A differenza delle partizioni Apache Cassandra, le partizioni Amazon Keyspaces possono avere dimensioni praticamente illimitate. Le chiavi di partizione e le colonne di clustering richiedono spazio di archiviazione aggiuntivo per i metadati, che è necessario aggiungere alla dimensione grezza delle righe. Per ulteriori informazioni, consulta [Stima della dimensione delle righe in Amazon Keyspaces](calculating-row-size.md).
Il codice seguente utilizza [AWK](https://en.wikipedia.org/wiki/AWK) per analizzare un file CSV e stampare la dimensione media e massima delle righe.
```
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'esecuzione di questo codice produce il seguente risultato.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Utilizzerai la dimensione media delle righe nel passaggio successivo di questo tutorial per fornire la capacità di scrittura per la tabella.
# Fase 3: Impostare la capacità di throughput per la tabella
Questo tutorial mostra come ottimizzare cqlsh per caricare i dati entro un intervallo di tempo prestabilito. Poiché sapete quante letture e scritture eseguite in anticipo, utilizzate la modalità di capacità fornita. Al termine del trasferimento dei dati, è necessario impostare la modalità di capacità della tabella in modo che corrisponda ai modelli di traffico dell'applicazione. Per ulteriori informazioni sulla gestione della capacità, consulta[Gestione delle risorse serverless in Amazon Keyspaces (per Apache Cassandra)](serverless_resource_management.md).
Con la modalità di capacità fornita, è possibile specificare in anticipo la quantità di capacità di lettura e scrittura che si desidera fornire alla tabella. La capacità di scrittura viene fatturata ogni ora e misurata in unità di capacità di scrittura (). WCUs Ogni WCU ha una capacità di scrittura sufficiente per supportare la scrittura di 1 KB di dati al secondo. Quando si caricano i dati, la velocità di scrittura deve essere inferiore al valore massimo WCUs (parametro:`write_capacity_units`) impostato nella tabella di destinazione.
Per impostazione predefinita, puoi eseguire il provisioning fino a 40.000 WCUs per tabella e 80.000 per WCUs tutte le tabelle del tuo account. Se hai bisogno di capacità aggiuntiva, puoi richiedere un aumento della quota nella console [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas). Per ulteriori informazioni sulle quote, consulta [Quote per Amazon Keyspaces (per Apache Cassandra)](quotas.md).
**Calcola il numero medio di componenti WCUs necessari per un inserto**
L'inserimento di 1 KB di dati al secondo richiede 1 WCU. Se il tuo file CSV ha 360.000 righe e desideri caricare tutti i dati in un'ora, devi scrivere 100 righe al secondo (360.000 righe/60 minuti/60 secondi = 100 righe al secondo). Se ogni riga contiene fino a 1 KB di dati, per inserire 100 righe al secondo, devi assegnarne 100 WCUs alla tabella. Se ogni riga contiene 1,5 KB di dati, ne occorrono due WCUs per inserire una riga al secondo. Pertanto, per inserire 100 righe al secondo, è necessario predisporre 200 WCUs.
Per determinare quante WCUs righe sono necessarie per inserire una riga al secondo, dividi la dimensione media delle righe in byte per 1024 e arrotonda al numero intero più vicino.
Ad esempio, se la dimensione media delle righe è 3000 byte, ne occorrono tre WCUs per inserire una riga al secondo.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Calcola il tempo e la capacità di caricamento dei dati**
Ora che conosci la dimensione e il numero medi di righe del tuo file CSV, puoi calcolare quante sono WCUs necessarie per caricare i dati in un determinato periodo di tempo e il tempo approssimativo necessario per caricare tutti i dati nel file CSV utilizzando diverse impostazioni WCU.
Ad esempio, se ogni riga del file è di 1 KB e il file CSV contiene 1.000.000 di righe, per caricare i dati in un'ora, è necessario fornire almeno 278 righe WCUs alla tabella per quell'ora.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Configura le impostazioni della capacità assegnata**
È possibile impostare le impostazioni della capacità di scrittura di una tabella al momento della creazione della tabella o utilizzando il comando `ALTER TABLE` CQL. Di seguito è riportata la sintassi per modificare le impostazioni della capacità assegnata a una tabella con l'istruzione CQL. `ALTER TABLE`
```
ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Per il riferimento completo alla lingua, vedere. [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)
# Fase 4: Configurare `cqlsh COPY FROM` le impostazioni
Questa sezione descrive come determinare i valori dei parametri per`cqlsh COPY FROM`. Il `cqlsh COPY FROM` comando legge il file CSV preparato in precedenza e inserisce i dati in Amazon Keyspaces utilizzando CQL. Il comando divide le righe e distribuisce le operazioni tra un insieme di lavoratori. `INSERT` Ogni lavoratore stabilisce una connessione con Amazon Keyspaces e `INSERT` invia richieste attraverso questo canale.
Il `cqlsh COPY` comando non ha una logica interna per distribuire il lavoro in modo uniforme tra i suoi lavoratori. Tuttavia, puoi configurarlo manualmente per assicurarti che il lavoro sia distribuito in modo uniforme. Inizia esaminando questi parametri chiave di cqlsh:
+ **DELIMITATORE**: se hai utilizzato un delimitatore diverso da una virgola, puoi impostare questo parametro, che per impostazione predefinita è la virgola.
+ **INGESTRATE**: il numero target di righe che tenta di elaborare al secondo. `cqlsh COPY FROM` Se non è impostato, il valore predefinito è 100.000.
+ **NUMPROCESSES: il numero di processi** di lavoro minorile che cqlsh crea per le attività. `COPY FROM` Il massimo per questa impostazione è 16, l'impostazione predefinita è`num_cores - 1`, `num_cores` dov'è il numero di core di elaborazione sull'host che esegue cqlsh.
+ **MAXBATCHSIZE** — La dimensione del batch determina il numero massimo di righe inserite nella tabella di destinazione in un singolo batch. Se non è impostato, cqlsh utilizza batch di 20 righe inserite.
+ **CHUNKSIZE — La dimensione** dell'unità di lavoro che passa al lavoratore minorile. Per impostazione predefinita, è impostata su 5.000.
+ **MAXTENTEMENTS** — Il numero massimo di volte in cui riprovare un blocco di lavoro non riuscito. Una volta raggiunto il tentativo massimo, i record non riusciti vengono scritti in un nuovo file CSV che è possibile eseguire nuovamente in un secondo momento dopo aver esaminato l'errore.
`INGESTRATE`Impostato in base al numero di file WCUs che hai assegnato alla tabella di destinazione. Il `INGESTRATE` valore del `cqlsh COPY FROM` comando non è un limite, ma una media target. Ciò significa che può (e spesso succede) superare il numero impostato. Per consentire l'insorgenza di interruzioni e assicurarvi che sia disponibile una capacità sufficiente per gestire le richieste di caricamento dei dati, impostate `INGESTRATE` il 90% della capacità di scrittura della tabella.
```
INGESTRATE = WCUs * .90
```
Quindi, impostate il `NUMPROCESSES` parametro in modo che sia uguale a uno in meno rispetto al numero di core del sistema. Per scoprire qual è il numero di core del sistema, è possibile eseguire il codice seguente.
```
python -c "import multiprocessing; print(multiprocessing.cpu_count())"
```
Per questo tutorial, utilizziamo il seguente valore.
```
NUMPROCESSES = 4
```
Ogni processo crea un lavoratore e ogni lavoratore stabilisce una connessione ad Amazon Keyspaces. Amazon Keyspaces può supportare fino a 3.000 richieste CQL al secondo su ogni connessione. Ciò significa che devi assicurarti che ogni lavoratore elabori meno di 3.000 richieste al secondo.
Inoltre`INGESTRATE`, i lavoratori spesso superano il numero impostato e non sono limitati dai secondi. Pertanto, per tenere conto delle interruzioni, impostate i parametri cqlsh in modo che ciascun lavoratore elabori 2.500 richieste al secondo. Per calcolare la quantità di lavoro distribuita a un lavoratore, utilizzate le seguenti linee guida.
+ Dividi `INGESTRATE` per`NUMPROCESSES`.
+ Se`INGESTRATE`/`NUMPROCESSES`> 2.500, abbassa il valore `INGESTRATE` per rendere vera questa formula.
```
INGESTRATE / NUMPROCESSES <= 2,500
```
Prima di configurare le impostazioni per ottimizzare il caricamento dei nostri dati di esempio, esaminiamo le impostazioni `cqlsh` predefinite e vediamo come il loro utilizzo influisce sul processo di caricamento dei dati. Poiché `cqlsh COPY FROM` utilizza il `CHUNKSIZE` per creare blocchi di lavoro (`INSERT`rendiconti) da distribuire ai lavoratori, il lavoro non viene distribuito automaticamente in modo uniforme. Alcuni lavoratori potrebbero rimanere inattivi, a seconda dell'impostazione. `INGESTRATE`
Per distribuire il lavoro in modo uniforme tra i lavoratori e mantenere per ogni lavoratore la frequenza ottimale di 2.500 richieste al secondo, è necessario impostare `CHUNKSIZE` e modificare i `INGESTRATE` parametri di input. `MAXBATCHSIZE` Per ottimizzare l'utilizzo del traffico di rete durante il caricamento dei dati, scegliete un valore vicino al valore massimo di 30. `MAXBATCHSIZE` Passando `CHUNKSIZE` a 100 e `MAXBATCHSIZE` a 25, le 10.000 righe vengono distribuite uniformemente tra i quattro lavoratori (10.000/2500 = 4).
Il seguente esempio di codice lo illustra.
```
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
```
Per riassumere, utilizzate le seguenti formule per impostare i parametri: `cqlsh COPY FROM`
+ **INGESTRATE** = write\$1capacity\$1units \$1 .90
+ **NUMPROCESSES** = num\$1cores -1 (impostazione predefinita)
+ **INGESTRATE/NUMPROCESSES** = 2.500 (deve essere una dichiarazione vera).
+ **MAXBATCHSIZE** = 30 (il valore predefinito è 20. Amazon Keyspaces accetta batch fino a 30.)
+ **CHUNKSIZE** = (INGESTRATE/NUMPROCESSES)/MAXBATCHSIZE
Ora che hai calcolato e `CHUNKSIZE` sei pronto per `NUMPROCESSES` caricare `INGESTRATE` i tuoi dati.
# Passaggio 5: Esegui il `cqlsh COPY FROM` comando per caricare i dati dal file CSV nella tabella di destinazione
Per eseguire il `cqlsh COPY FROM` comando, completare i passaggi seguenti.
1. Connect ad Amazon Keyspaces utilizzando cqlsh.
1. Scegli il tuo keyspace con il codice seguente.
```
USE catalog;
```
1. Imposta la coerenza di scrittura su`LOCAL_QUORUM`. Per garantire la durabilità dei dati, Amazon Keyspaces non consente altre impostazioni di coerenza di scrittura. Vedi il codice seguente.
```
CONSISTENCY LOCAL_QUORUM;
```
1. Preparate la `cqlsh COPY FROM` sintassi utilizzando il seguente esempio di codice.
```
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. Esegui l'istruzione preparata nel passaggio precedente. cqlsh riporta tutte le impostazioni che hai configurato.
1. Assicurati che le impostazioni corrispondano ai dati immessi. Guarda l'esempio seguente.
```
Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'}
Using 15 child processes
```
1. Controlla il numero di righe trasferite e il tasso medio corrente, come mostrato nell'esempio seguente.
```
Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s
```
1. Quando cqlsh ha finito di caricare i dati, esamina il riepilogo delle statistiche di caricamento dei dati (il numero di file letti, di runtime e le righe ignorate) come mostrato nell'esempio seguente.
```
15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped).
```
In questo passaggio finale del tutorial, hai caricato i dati su Amazon Keyspaces.
**Importante**
Ora che hai trasferito i dati, regola le impostazioni della modalità di capacità della tabella di destinazione in modo che corrispondano ai normali modelli di traffico dell'applicazione. Fino a quando non la modifichi, ti verranno addebitati i costi in base alla tariffa oraria per la capacità assegnata.
# Risoluzione dei problemi
Una volta completato il caricamento dei dati, controlla se le righe sono state saltate. Per farlo, accedi alla directory dei sorgenti del file CSV di origine e cerca un file con il nome seguente.
```
import_yourcsvfilename.err.timestamp.csv
```
cqlsh scrive tutte le righe di dati saltate in un file con quel nome. Se il file esiste nella tua directory di origine e contiene dati, queste righe non sono state caricate su Amazon Keyspaces. Per riprovare queste righe, verifica innanzitutto la presenza di eventuali errori riscontrati durante il caricamento e modifica i dati di conseguenza. Per riprovare queste righe, puoi eseguire nuovamente il processo.
**Errori comuni**
I motivi più comuni per cui le righe non vengono caricate sono gli errori di capacità e gli errori di analisi.
**Errori di richiesta non validi durante il caricamento di dati su Amazon Keyspaces**
Nell'esempio seguente, la tabella di origine contiene una colonna counter, che genera chiamate batch registrate dal comando cqlsh. `COPY` Le chiamate batch registrate non sono supportate da 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
```
Per risolvere questo errore, usa DSBulk per migrare i dati. Per ulteriori informazioni, consulta [Tutorial: caricamento di dati in Amazon Keyspaces utilizzando DSBulk](dsbulk-upload.md).
**Errori del parser durante il caricamento di dati su Amazon Keyspaces**
L'esempio seguente mostra una riga saltata a causa di un. `ParseError`
```
Failed to import 1 rows: ParseError - Invalid ... –
```
Per risolvere questo errore, devi assicurarti che i dati da importare corrispondano allo schema della tabella in Amazon Keyspaces. Controlla il file di importazione per verificare eventuali errori di analisi. Puoi provare a utilizzare una singola riga di dati utilizzando un'`INSERT`istruzione per isolare l'errore.
**Errori di capacità durante il caricamento dei dati su 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 utilizza le `WriteTimeout` eccezioni `ReadTimeout` e per indicare quando una richiesta di scrittura non riesce a causa di una capacità di throughput insufficiente. Per aiutare a diagnosticare eccezioni di capacità insufficienti, Amazon Keyspaces pubblica parametri e `WriteThrottleEvents` parametri in Amazon. `ReadThrottledEvents` CloudWatch Per ulteriori informazioni, consulta [Monitoraggio di Amazon Keyspaces con Amazon CloudWatch](monitoring-cloudwatch.md).
**errori cqlsh durante il caricamento di dati su Amazon Keyspaces**
Per facilitare la risoluzione degli errori cqlsh, esegui nuovamente il comando che ha avuto esito negativo con il flag. `--debug`
Quando si utilizza una versione incompatibile di cqlsh, viene visualizzato il seguente errore.
```
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
```
Verificare che sia installata la versione corretta di cqlsh eseguendo il comando seguente.
```
cqlsh --version
```
Dovreste vedere qualcosa di simile a quanto segue per l'output.
```
cqlsh 5.0.1
```
Se usi Windows, sostituisci tutte le istanze di `cqlsh` with`cqlsh.bat`. Ad esempio, per verificare la versione di cqlsh in Windows, esegui il comando seguente.
```
cqlsh.bat --version
```
La connessione ad Amazon Keyspaces fallisce dopo che il client cqlsh riceve tre errori consecutivi di qualsiasi tipo dal server. Il client cqlsh fallisce e viene visualizzato il seguente messaggio.
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
Per risolvere questo errore, devi assicurarti che i dati da importare corrispondano allo schema della tabella in Amazon Keyspaces. Controlla il file di importazione per verificare eventuali errori di analisi. Puoi provare a utilizzare una singola riga di dati utilizzando un'istruzione INSERT per isolare l'errore.
Il client tenta automaticamente di ristabilire la connessione.
# Tutorial: caricamento di dati in Amazon Keyspaces utilizzando DSBulk
Questo step-by-step tutorial ti guida nella migrazione dei dati da Apache Cassandra ad Amazon Keyspaces utilizzando DataStax Bulk Loader () disponibile su. DSBulk [GitHub](https://github.com/datastax/dsbulk.git) L'utilizzo DSBulk è utile per caricare set di dati su Amazon Keyspaces per scopi accademici o di test. Per ulteriori informazioni su come migrare i carichi di lavoro di produzione, consulta. [Processo di migrazione offline: da Apache Cassandra ad Amazon Keyspaces](migrating-offline.md) In questo tutorial, completerai i seguenti passaggi.
Prerequisiti: configura un AWS account con credenziali, crea un file di trust store JKS per il certificato, configura, scarica `cqlsh` DSBulk, installa e configura un file. `application.conf`
1. **Crea CSV di origine e tabella di destinazione**: prepara un file CSV come dati di origine e crea lo spazio chiave e la tabella di destinazione in Amazon Keyspaces.
1. **Preparazione dei dati**: randomizza i dati nel file CSV e analizzali per determinare le dimensioni medie e massime delle righe.
1. **Imposta la capacità di trasmissione**: calcola le unità di capacità di scrittura richieste (WCUs) in base alla dimensione dei dati e al tempo di caricamento desiderato e configura la capacità assegnata alla tabella.
1. **Configura DSBulk le impostazioni**: crea un file di DSBulk configurazione con impostazioni come autenticazione, SSL/TLS, livello di coerenza e dimensione del pool di connessioni.
1. **Esegui il comando DSBulk load**: esegui il comando DSBulk load per caricare i dati dal file CSV nella tabella Amazon Keyspaces e monitorare l'avanzamento.
**Topics**
+ [Prerequisiti: passaggi da completare prima di poter caricare i dati con DSBulk](dsbulk-upload-prequs.md)
+ [Passaggio 1: creare il file CSV di origine e una tabella di destinazione per il caricamento dei dati utilizzando DSBulk](dsbulk-upload-source.md)
+ [Passaggio 2: prepara i dati da caricare utilizzando DSBulk](dsbulk-upload-prepare-data.md)
+ [Fase 3: Impostare la capacità di throughput per la tabella di destinazione](dsbulk-upload-capacity.md)
+ [Passaggio 4: Configurare `DSBulk` le impostazioni per caricare i dati dal file CSV alla tabella di destinazione](dsbulk-upload-config.md)
+ [Passaggio 5: Esegui il DSBulk `load` comando per caricare i dati dal file CSV nella tabella di destinazione](dsbulk-upload-run.md)
# Prerequisiti: passaggi da completare prima di poter caricare i dati con DSBulk
È necessario completare le seguenti attività prima di iniziare questo tutorial.
1. Se non l'hai ancora fatto, crea un AWS account seguendo i passaggi riportati in[Configurazione AWS Identity and Access Management](accessing.md#SettingUp.IAM).
1. Crea le credenziali seguendo i passaggi riportati in[Crea e configura AWS credenziali per Amazon Keyspaces](access.credentials.md).
1. Crea un file di trust store JKS.
1. Scarica i seguenti certificati digitali e salva i file localmente o nella tua home directory.
1. AmazonRootCA1
1. AmazonRootCA2
1. AmazonRootCA3
1. AmazonRootCA4
1. Starfield Class 2 Root (opzionale, per compatibilità con le versioni precedenti)
Per scaricare i certificati, puoi usare i seguenti comandi.
```
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
```
**Nota**
Amazon Keyspaces utilizzava in precedenza certificati TLS ancorati alla CA Starfield Class 2. AWS sta migrando tutto Regioni AWS verso certificati emessi nell'ambito di Amazon Trust Services (Amazon Root CAs 1—4). Durante questa transizione, configura i client in modo che si fidino sia di Amazon Root CAs 1-4 che di Starfield root per garantire la compatibilità in tutte le regioni.
1. Converti i certificati digitali in file TrustStore e aggiungili al 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
```
Nell'ultimo passaggio, è necessario creare una password per il keystore e considerare attendibile ogni certificato. Il comando interattivo ha questo aspetto.
```
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. Configura la connessione shell Cassandra Query Language (cqlsh) e conferma di poterti connettere ad Amazon Keyspaces seguendo i passaggi indicati. [Utilizzo `cqlsh` per connettersi ad Amazon Keyspaces](programmatic.cqlsh.md)
1. Scarica e installa. DSBulk
**Nota**
La versione mostrata in questo tutorial potrebbe non essere l'ultima disponibile. Prima di eseguire il download DSBulk, controlla la [pagina di download di DataStax Bulk Loader](https://downloads.datastax.com/#bulk-loader) per la versione più recente e aggiorna di conseguenza il numero di versione nei seguenti comandi.
1. Per effettuare il download DSBulk, è possibile utilizzare il codice seguente.
```
curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz
```
1. Quindi decomprimi il file tar e aggiungilo DSBulk al tuo `PATH` come mostrato nell'esempio seguente.
```
tar -zxvf dsbulk-1.8.0.tar.gz
# add the DSBulk directory to the path
export PATH=$PATH:./dsbulk-1.8.0/bin
```
1. Crea un `application.conf` file per memorizzare le impostazioni da utilizzare. DSBulk È possibile salvare il seguente esempio come`./dsbulk_keyspaces.conf`. Sostituiscilo `localhost` con il punto di contatto del cluster Cassandra locale se non ti trovi sul nodo locale, ad esempio il nome DNS o l'indirizzo IP. Prendi nota del nome e del percorso del file, poiché dovrai specificarlo più avanti nel `dsbulk load` comando.
```
datastax-java-driver {
basic.contact-points = [ "localhost"]
advanced.auth-provider {
class = software.aws.mcs.auth.SigV4AuthProvider
aws-region = us-east-1
}
}
```
1. Per abilitare il supporto SigV4, scaricate il `jar` file ombreggiato da [GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/)e inseritelo nella DSBulk `lib` cartella come mostrato nell'esempio seguente.
```
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
```
# Passaggio 1: creare il file CSV di origine e una tabella di destinazione per il caricamento dei dati utilizzando DSBulk
Per questo tutorial, utilizziamo un file con valori separati da virgole (CSV) con il nome `keyspaces_sample_table.csv` come file di origine per la migrazione dei dati. Il file di esempio fornito contiene alcune righe di dati per una tabella con il nome. `book_awards`
1. Crea il file sorgente. Puoi scegliere una delle seguenti opzioni:
+ Scaricate il file CSV di esempio (`keyspaces_sample_table.csv`) contenuto nel seguente file di archivio [samplemigration.zip](samples/samplemigration.zip). Decomprimi l'archivio e prendi nota del percorso verso. `keyspaces_sample_table.csv`
+ Per compilare un file CSV con i propri dati memorizzati in un database Apache Cassandra, è possibile compilare il file CSV di origine utilizzando `dsbulk unload` quanto illustrato nell'esempio seguente.
```
dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv
```
Assicurati che il file CSV che crei soddisfi i seguenti requisiti:
+ La prima riga contiene i nomi delle colonne.
+ I nomi delle colonne nel file CSV di origine corrispondono ai nomi delle colonne nella tabella di destinazione.
+ I dati sono delimitati da una virgola.
+ Tutti i valori dei dati sono tipi di dati Amazon Keyspaces validi. Per informazioni, consulta [Tipi di dati](cql.elements.md#cql.data-types).
1. Crea lo spazio chiave e la tabella di destinazione in Amazon Keyspaces.
1. Connettiti ad Amazon Keyspaces utilizzando `cqlsh` e sostituendo l'endpoint del servizio, il nome utente e la password nell'esempio seguente con i tuoi valori.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. Crea un nuovo keyspace con il nome mostrato nell'`catalog`esempio seguente.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. Dopo che il nuovo keyspace ha lo stato di disponibile, utilizzate il codice seguente per creare la tabella di destinazione. `book_awards` Per ulteriori informazioni sulla creazione asincrona di risorse e su come verificare se una risorsa è disponibile, consulta. [Verifica lo stato di creazione del keyspace in 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)
);
```
Se Apache Cassandra è la tua fonte di dati originale, un modo semplice per creare la tabella di destinazione di Amazon Keyspaces con intestazioni corrispondenti consiste nel generare l'`CREATE TABLE`istruzione dalla tabella di origine, come mostrato nell'istruzione seguente.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
Quindi crea la tabella di destinazione in Amazon Keyspaces con i nomi delle colonne e i tipi di dati che corrispondono alla descrizione della tabella di origine di Cassandra.
# Passaggio 2: prepara i dati da caricare utilizzando DSBulk
La preparazione dei dati di origine per un trasferimento efficiente è un processo in due fasi. Innanzitutto, i dati vengono randomizzati. Nella seconda fase, si analizzano i dati per determinare i valori dei `dsbulk` parametri appropriati e le impostazioni della tabella richieste.
**Randomizza i dati**
Il `dsbulk` comando legge e scrive i dati nello stesso ordine in cui appaiono nel file CSV. Se si utilizza il `dsbulk` comando per creare il file sorgente, i dati vengono scritti in ordine di chiave nel file CSV. Internamente, Amazon Keyspaces partiziona i dati utilizzando chiavi di partizione. Sebbene Amazon Keyspaces disponga di una logica integrata per aiutare a bilanciare il carico delle richieste per la stessa chiave di partizione, il caricamento dei dati è più rapido ed efficiente se si rende casuale l'ordine. Questo perché puoi sfruttare il bilanciamento del carico integrato che si verifica quando Amazon Keyspaces scrive su partizioni diverse.
Per distribuire le scritture tra le partizioni in modo uniforme, devi randomizzare i dati nel file sorgente. [È possibile scrivere un'applicazione per eseguire questa operazione o utilizzare uno strumento open source, come Shuf.](https://en.wikipedia.org/wiki/Shuf) Shuf è disponibile gratuitamente sulle distribuzioni Linux, su macOS (installando coreutils in [homebrew](https://brew.sh)) e su Windows (utilizzando Windows Subsystem for Linux (WSL)). È necessario un passaggio aggiuntivo per evitare che la riga di intestazione con i nomi delle colonne venga mescolata in questo passaggio.
Per rendere casuale il file sorgente preservando l'intestazione, inserisci il codice seguente.
```
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 riscrive i dati in un nuovo file CSV chiamato. `keyspace.table.csv` Ora puoi eliminare il `keyspaces_sample_table.csv` file, non è più necessario.
**Analizza i dati**
Determina la dimensione media e massima delle righe analizzando i dati.
Lo fai per i seguenti motivi:
+ La dimensione media delle righe aiuta a stimare la quantità totale di dati da trasferire.
+ È necessaria la dimensione media delle righe per fornire la capacità di scrittura necessaria per il caricamento dei dati.
+ Puoi assicurarti che ogni riga abbia una dimensione inferiore a 1 MB, che è la dimensione massima delle righe in Amazon Keyspaces.
**Nota**
Questa quota si riferisce alla dimensione della riga, non alla dimensione della partizione. A differenza delle partizioni Apache Cassandra, le partizioni Amazon Keyspaces possono avere dimensioni praticamente illimitate. Le chiavi di partizione e le colonne di clustering richiedono spazio di archiviazione aggiuntivo per i metadati, che è necessario aggiungere alla dimensione grezza delle righe. Per ulteriori informazioni, consulta [Stima della dimensione delle righe in Amazon Keyspaces](calculating-row-size.md).
Il codice seguente utilizza [AWK](https://en.wikipedia.org/wiki/AWK) per analizzare un file CSV e stampare la dimensione media e massima delle righe.
```
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'esecuzione di questo codice produce il seguente risultato.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
Assicurati che la dimensione massima delle righe non superi 1 MB. In caso affermativo, devi suddividere la riga o comprimere i dati per portare la dimensione della riga al di sotto di 1 MB. Nel passaggio successivo di questo tutorial, utilizzerai la dimensione media delle righe per fornire la capacità di scrittura per la tabella.
# Fase 3: Impostare la capacità di throughput per la tabella di destinazione
Questo tutorial mostra come eseguire la regolazione per DSBulk caricare i dati entro un intervallo di tempo prestabilito. Poiché sapete quante letture e scritture eseguite in anticipo, utilizzate la modalità di capacità fornita. Al termine del trasferimento dei dati, è necessario impostare la modalità di capacità della tabella in modo che corrisponda ai modelli di traffico dell'applicazione. Per ulteriori informazioni sulla gestione della capacità, consulta[Gestione delle risorse serverless in Amazon Keyspaces (per Apache Cassandra)](serverless_resource_management.md).
Con la modalità di capacità fornita, è possibile specificare in anticipo la quantità di capacità di lettura e scrittura che si desidera fornire alla tabella. La capacità di scrittura viene fatturata ogni ora e misurata in unità di capacità di scrittura (). WCUs Ogni WCU ha una capacità di scrittura sufficiente per supportare la scrittura di 1 KB di dati al secondo. Quando si caricano i dati, la velocità di scrittura deve essere inferiore al valore massimo WCUs (parametro:`write_capacity_units`) impostato nella tabella di destinazione.
Per impostazione predefinita, puoi assegnare fino a 40.000 unità WCUs a una tabella e 80.000 unità WCUs in tutte le tabelle del tuo account. Se hai bisogno di capacità aggiuntiva, puoi richiedere un aumento della quota nella console [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas). Per ulteriori informazioni sulle quote, consulta [Quote per Amazon Keyspaces (per Apache Cassandra)](quotas.md).
**Calcola il numero medio di componenti WCUs necessari per un inserto**
L'inserimento di 1 KB di dati al secondo richiede 1 WCU. Se il tuo file CSV ha 360.000 righe e desideri caricare tutti i dati in un'ora, devi scrivere 100 righe al secondo (360.000 righe/60 minuti/60 secondi = 100 righe al secondo). Se ogni riga contiene fino a 1 KB di dati, per inserire 100 righe al secondo, devi assegnarne 100 WCUs alla tabella. Se ogni riga contiene 1,5 KB di dati, ne occorrono due WCUs per inserire una riga al secondo. Pertanto, per inserire 100 righe al secondo, è necessario predisporre 200 WCUs.
Per determinare quante WCUs righe sono necessarie per inserire una riga al secondo, dividi la dimensione media delle righe in byte per 1024 e arrotonda al numero intero più vicino.
Ad esempio, se la dimensione media delle righe è 3000 byte, ne occorrono tre WCUs per inserire una riga al secondo.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**Calcola il tempo e la capacità di caricamento dei dati**
Ora che conosci la dimensione e il numero medi di righe del tuo file CSV, puoi calcolare quante sono WCUs necessarie per caricare i dati in un determinato periodo di tempo e il tempo approssimativo necessario per caricare tutti i dati nel file CSV utilizzando diverse impostazioni WCU.
Ad esempio, se ogni riga del file è di 1 KB e il file CSV contiene 1.000.000 di righe, per caricare i dati in un'ora, è necessario fornire almeno 278 righe WCUs alla tabella per quell'ora.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**Configura le impostazioni della capacità assegnata**
È possibile impostare le impostazioni della capacità di scrittura di una tabella al momento della creazione della tabella o utilizzando il `ALTER TABLE` comando. Di seguito è riportata la sintassi per modificare le impostazioni della capacità assegnata a una tabella con il comando. `ALTER TABLE`
```
ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
Per il riferimento completo alla lingua, vedere e. [CREATE TABLE](cql.ddl.table.md#cql.ddl.table.create) [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)
# Passaggio 4: Configurare `DSBulk` le impostazioni per caricare i dati dal file CSV alla tabella di destinazione
Questa sezione descrive i passaggi necessari DSBulk per configurare il caricamento dei dati su Amazon Keyspaces. La configurazione DSBulk viene effettuata utilizzando un file di configurazione. Il file di configurazione viene specificato direttamente dalla riga di comando.
1. Crea un file di DSBulk configurazione per la migrazione ad Amazon Keyspaces, in questo esempio utilizziamo il nome del file. `dsbulk_keyspaces.conf` Specificate le seguenti impostazioni nel file DSBulk di configurazione.
1. *`PlainTextAuthProvider`*— Crea il provider di autenticazione con la `PlainTextAuthProvider` classe. `ServiceUserName`e `ServicePassword` deve corrispondere al nome utente e alla password ottenuti al momento della generazione delle credenziali specifiche del servizio seguendo la procedura riportata in. [Crea credenziali per l'accesso programmatico ad Amazon Keyspaces](programmatic.credentials.md)
1. *`local-datacenter`*— Imposta il valore `local-datacenter` per il quale Regione AWS ti stai connettendo. Ad esempio, se l'applicazione si connette a`cassandra.us-east-1.amazonaws.com`, imposta il data center locale su`us-east-1`. Per tutte le opzioni disponibili Regioni AWS, vedi[Endpoint di servizio per Amazon Keyspaces](programmatic.endpoints.md). Per evitare repliche, imposta su`slow-replica-avoidance`. `false`
1. *`SSLEngineFactory`*— Per configurare SSL/TLS, inizializza `SSLEngineFactory` aggiungendo una sezione nel file di configurazione con una sola riga che specifica la classe con. `class = DefaultSslEngineFactory` Fornisci il percorso `cassandra_truststore.jks` e la password che hai creato in precedenza.
1. *`consistency`*— Imposta il livello di coerenza su`LOCAL QUORUM`. Altri livelli di coerenza di scrittura non sono supportati, per ulteriori informazioni, vedere[Livelli di coerenza di lettura e scrittura supportati da Apache Cassandra e costi associati](consistency.md).
1. Il numero di connessioni per pool è configurabile nel driver Java. Per questo esempio, imposta su `advanced.connection.pool.local.size` 3.
Di seguito è riportato il file di configurazione di esempio completo.
```
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. Esaminate i parametri del DSBulk `load` comando.
1. *`executor.maxPerSecond`*— Il numero massimo di righe che il comando load tenta di elaborare contemporaneamente al secondo. Se non è impostata, questa impostazione viene disabilitata con -1.
Imposta in `executor.maxPerSecond` base al numero di WCUs elementi che hai assegnato alla tabella di destinazione. Il valore `executor.maxPerSecond` del `load` comando non è un limite, ma una media obiettivo. Ciò significa che può (e spesso succede) superare il numero impostato. Per consentire l'insorgenza di interruzioni e assicurarvi che sia disponibile una capacità sufficiente per gestire le richieste di caricamento dei dati, impostate `executor.maxPerSecond` il 90% della capacità di scrittura della tabella.
```
executor.maxPerSecond = WCUs * .90
```
In questo tutorial, abbiamo impostato su `executor.maxPerSecond` 5.
**Nota**
Se stai usando DSBulk 1.6.0 o versioni successive, puoi usare `dsbulk.engine.maxConcurrentQueries` invece.
1. Configura questi parametri aggiuntivi per il DSBulk `load` comando.
+ *`batch-mode`*— Questo parametro indica al sistema di raggruppare le operazioni per chiave di partizione. Si consiglia di disabilitare la modalità batch, poiché può causare scenari e cause `WriteThrottleEvents` con tasti di scelta rapida.
+ *`driver.advanced.retry-policy-max-retries`*— Ciò determina quante volte riprovare un'interrogazione non riuscita. Se non è impostata, l'impostazione predefinita è 10. È possibile modificare questo valore in base alle esigenze.
+ *`driver.basic.request.timeout`*— Il tempo in minuti in cui il sistema attende la restituzione di una query. Se non è impostata, l'impostazione predefinita è «5 minuti». È possibile modificare questo valore in base alle esigenze.
# Passaggio 5: Esegui il DSBulk `load` comando per caricare i dati dal file CSV nella tabella di destinazione
Nella fase finale di questo tutorial, carichi i dati in Amazon Keyspaces.
Per eseguire il DSBulk `load` comando, completa i seguenti passaggi.
1. Esegui il codice seguente per caricare i dati dal tuo file csv nella tabella Amazon Keyspaces. Assicurati di aggiornare il percorso del file di configurazione dell'applicazione che hai creato in precedenza.
```
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. L'output include la posizione di un file di registro che riporta i dettagli delle operazioni riuscite e non riuscite. Il file è memorizzato nella seguente directory.
```
Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911
```
1. Le voci del file di registro includeranno le metriche, come nell'esempio seguente. Assicurati che il numero di righe sia coerente con il numero di righe del tuo file csv.
```
total | failed | rows/s | p50ms | p99ms | p999ms
200 | 0 | 200 | 21.63 | 21.89 | 21.89
```
**Importante**
Ora che hai trasferito i dati, regola le impostazioni della modalità di capacità della tabella di destinazione in modo che corrispondano ai normali modelli di traffico dell'applicazione. Fino a quando non la modifichi, ti verranno addebitati i costi in base alla tariffa oraria per la capacità assegnata. Per ulteriori informazioni, consulta [Configura le modalità di read/write capacità in Amazon Keyspaces](ReadWriteCapacityMode.md).