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à.
# 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)