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à.
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 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 di migrare l'applicazione.
A seconda dei requisiti di conservazione dei dati, ad esempio la quantità di dati storici da conservare in base alle politiche della tua organizzazione, puoi prendere in considerazione una delle due opzioni seguenti.
Caricamento in blocco di dati storici: la migrazione dei dati storici dalla distribuzione Cassandra esistente 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
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. Il caricamento in blocco dovrebbe alla fine essere coerente, il che significa che alla fine i dati raggiungeranno tutti i nodi.
Se un aggiornamento degli stessi dati avviene contemporaneamente a causa di una nuova scrittura, assicurati che non vengano sovrascritti dal caricamento cronologico dei dati. Per assicurarti di conservare gli ultimi aggiornamenti dei dati anche durante l'importazione in blocco, devi aggiungere la risoluzione dei conflitti negli script di caricamento in blocco o nella logica dell'applicazione per le doppie scritture.
Ad esempio, è possibile utilizzare Transazioni leggere (LWT) per confrontare e impostare le operazioni. Per fare ciò, puoi aggiungere un campo aggiuntivo al tuo modello di dati che rappresenta l'ora della modifica o lo stato.
Inoltre, Amazon Keyspaces supporta la funzione di 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 basata sull'ultimo autore. Per ulteriori informazioni, consulta Client-side timestamp in Amazon Keyspaces.Utilizzo Time-to-Live (TTL): per periodi di conservazione dei dati inferiori a 30, 60 o 90 giorni, puoi utilizzare il TTL in Cassandra e Amazon Keyspaces durante la migrazione per evitare di caricare dati storici non necessari su Amazon Keyspaces. Il 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 in modo che i dati storici scadano automaticamente nel vecchio sistema (Cassandra) applicando solo le nuove scritture su Amazon Keyspaces utilizzando il metodo a doppia scrittura. 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 significativamente la quantità di dati da migrare, garantendo un processo di migrazione più efficiente e semplificato. È possibile prendere in considerazione questo approccio quando si tratta di 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).
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 dual writes. Esamineremo tre diverse fasi della migrazione, ognuna delle quali dura 30 giorni.
Il funzionamento del processo di migrazione per ciascuna fase è illustrato nelle immagini seguenti.
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 costituiscono il 50% dei dati nel 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, costituito dalle nuove scritture meno dai dati storici.
Dopo 60 giorni, sia il cluster Cassandra che Amazon Keyspaces contengono gli stessi dati scritti negli ultimi 60 giorni.
Entro 90 giorni, Cassandra e Amazon Keyspaces contengono gli stessi dati e i dati scadono alla stessa velocità.
Questo esempio illustra come evitare la fase di caricamento dei dati storici utilizzando il TTL con una data di scadenza impostata su 60 giorni.
