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