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 a DynamoDB da un database relazionale
La migrazione di un database relazionale in DynamoDB richiede un'attenta pianificazione per garantire un esito positivo. Questa guida ti aiuterà a capire come funziona questo processo, quali strumenti hai a disposizione e quindi come valutare le potenziali strategie di migrazione e selezionarne una più adatta alle tue esigenze.
Argomenti
- Motivi per migrare a DynamoDB
- Considerazioni sulla migrazione di un database relazionale a DynamoDB
- Comprendere come funziona una migrazione a DynamoDB
- Strumenti per facilitare la migrazione a DynamoDB
- Scelta della strategia appropriata per la migrazione a DynamoDB
- Esecuzione di una migrazione offline a DynamoDB
- Esecuzione di una migrazione ibrida verso DynamoDB
- Esecuzione di una migrazione online a DynamoDB migrando ogni tabella 1:1
- Esegui una migrazione online a DynamoDB utilizzando una tabella intermedia personalizzata
Motivi per migrare a DynamoDB
La migrazione ad Amazon DynamoDB offre una serie di vantaggi interessanti per aziende e organizzazioni. Ecco alcuni vantaggi chiave che rendono DynamoDB una scelta interessante per la migrazione del database:
-
Scalabilità: DynamoDB è progettato per gestire carichi di lavoro enormi e scalare senza problemi per soddisfare volumi e traffico di dati in crescita. Con DynamoDB, puoi scalare facilmente il tuo database verso l'alto o verso il basso in base alla richiesta, assicurando che le tue applicazioni siano in grado di gestire picchi improvvisi di traffico senza compromettere le prestazioni.
-
Prestazioni: DynamoDB offre un accesso ai dati a bassa latenza, permettendo 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: DynamoDB è un servizio completamente gestito fornito da AWS. Questo 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: DynamoDB supporta un modello serverless, noto come DynamoDB on-demand, in cui si paga solo per le effettive richieste di lettura e scrittura effettuate dall'applicazione senza richiedere il provisioning anticipato della capacità. Questo pay-per-request modello offre efficienza in termini di costi e spese operative minime, in quanto si pagano solo le risorse consumate senza la necessità di fornire e monitorare la capacità.
-
Nessuna SQL flessibilità: a differenza dei database relazionali tradizionali, DynamoDB segue un modello SQL senza dati, che offre flessibilità nella progettazione dello schema. Con DynamoDB, puoi archiviare dati strutturati, semistrutturati e non strutturati, rendendoli ideali per la gestione di tipi di dati diversi e in evoluzione. Questa flessibilità consente cicli di sviluppo più rapidi e un adattamento più semplice alle mutevoli esigenze aziendali.
-
Disponibilità e durabilità elevate: DynamoDB replica i dati su più zone di disponibilità all'interno di una regione, 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. DynamoDB offre una SLA disponibilità fino al 99,999%.
-
Sicurezza e conformità: DynamoDB si integra con AWS Identity and Access Management per un controllo granulare degli accessi. Fornisce la crittografia a riposo e in transito, garantendo la sicurezza dei dati. DynamoDB aderisce inoltre a diversi standard di conformità, HIPAA tra cui PCIDSS, GDPR e consente di soddisfare i requisiti normativi.
-
Integrazione con AWS Ecosistema: come parte di AWS ecosistema, DynamoDB si integra perfettamente con altri AWS servizi, come AWS Lambda, AWS CloudFormation e AWS AppSync. Questa integrazione consente di creare architetture serverless, sfruttare l'infrastruttura come codice e creare applicazioni basate sui dati in tempo reale.
Considerazioni sulla migrazione di un database relazionale a DynamoDB
I sistemi di database relazionali e i SQL database No presentano punti di forza e di debolezza diversi. Queste differenze rendono la progettazione del database diversa tra i due sistemi.
| Tipo di attività | Database relazionale | Nessun SQL database |
|---|---|---|
| Interrogazione del database | Nei database relazionali, è possibile interrogare i dati in modo flessibile, ma le query sono relativamente costose e non si adattano bene in situazioni di traffico elevato (vedi). Fase iniziale per la modellazione dei dati relazionali in DynamoDB Un'applicazione di database relazionale può implementare la logica aziendale in stored procedure, SQL sottoquery, query di aggiornamento in blocco e query di aggregazione. | In un SQL database No come DynamoDB, i dati possono essere interrogati in modo efficiente in un numero limitato di modi, al di fuori dei quali le query possono essere costose e lente. Le scritture su DynamoDB sono singleton. La logica di business dell'applicazione che in precedenza veniva eseguita nelle stored procedure deve essere rifattorizzata per essere eseguita all'esterno di DynamoDB in codice personalizzato eseguito su un host come Amazon Amazon o EC2 AWS Lambda. |
| Progettazione del database | Progettate in modo flessibile senza preoccuparvi dei dettagli di implementazione o delle prestazioni. L'ottimizzazione delle query in genere non ha ripercussioni sulla progettazione dello schema, ma la normalizzazione è importante. | Lo schema viene progettato specificamente per rendere le query più comuni e importanti il più veloci ed economiche possibile. Le tue strutture di dati sono programmate per i requisiti specifici dei casi d'uso del tuo business. |
Progettazione per nessun SQL database richiede una mentalità diversa rispetto alla progettazione di un sistema di gestione di database relazionali (). RDBMS Per esempioRDBMS, è possibile creare un modello di dati normalizzato senza pensare ai modelli di accesso. Puoi estenderlo in seguito quando si presentano nuovi quesiti e requisiti di query. Puoi organizzare ogni tipo di dati nella sua tabella.
Con No SQL design, puoi progettare il tuo schema per DynamoDB quando conosci le domande a cui rispondere. Comprendere i problemi aziendali e i modelli di lettura e scrittura dell'applicazione è essenziale. È inoltre necessario cercare di mantenere il minor numero possibile di tabelle in un'applicazione DynamoDB. Un numero inferiore di tabelle rende le cose più scalabili, richiede una minore gestione delle autorizzazioni e riduce il sovraccarico dell'applicazione DynamoDB. Può anche aiutare a mantenere i costi di backup complessivi più bassi.
Il compito di modellare i dati relazionali per DynamoDB e creare una nuova versione dell'applicazione front-end è un argomento a parte. Questa guida presuppone che tu abbia una nuova versione dell'applicazione creata per utilizzare DynamoDB, ma devi comunque determinare il modo migliore per migrare e sincronizzare i dati storici durante il cutover.
Considerazioni sul dimensionamento
La dimensione massima di ogni elemento (riga) archiviato in una tabella DynamoDB è di 400 KB. Per ulteriori informazioni, consulta Quote di servizio, account e tabelle in Amazon DynamoDB. La dimensione dell'elemento è determinata dalla dimensione totale di tutti i nomi e i valori degli attributi in un elemento. Per ulteriori informazioni, consulta Dimensioni e formati degli elementi DynamoDB.
Se la tua applicazione deve archiviare in un elemento più dati di quelli consentiti dal limite di dimensione di DynamoDB, suddividi l'elemento in una raccolta di elementi, comprimi i dati dell'articolo o archivia l'elemento come oggetto in Amazon Simple Storage Service (Amazon S3) memorizzando l'identificatore dell'oggetto Amazon S3 nel tuo articolo DynamoDB. Per informazioni, consulta Le migliori pratiche per l'archiviazione di elementi e attributi di grandi dimensioni in DynamoDB. Il costo dell'aggiornamento di un articolo si basa sulla dimensione completa dell'articolo. Per i carichi di lavoro che richiedono aggiornamenti frequenti degli elementi esistenti, l'aggiornamento di elementi di piccole dimensioni di uno o due KB avrà un costo inferiore rispetto agli elementi più grandi. Raccolte di articoli: come modellare one-to-many le relazioni in DynamoDBPer ulteriori informazioni sulle raccolte di articoli, consulta.
Quando scegli gli attributi delle chiavi di partizione e ordinamento, le altre impostazioni della tabella, la dimensione e la struttura degli elementi e se creare indici secondari, assicurati di consultare la documentazione di DynamoDB Modeling e la guida per. Ottimizzazione dei costi sulle tabelle DynamoDB Assicurati di testare il tuo piano di migrazione in modo che la tua soluzione DynamoDB sia efficiente in termini di costi e si adatti alle funzionalità e ai limiti di DynamoDB.
Comprendere come funziona una migrazione a DynamoDB
Prima di esaminare gli strumenti di migrazione a nostra disposizione, considera come le scritture vengono elaborate da DynamoDB.
L'operazione di scrittura predefinita e più comune è una singola PutItemAPIoperazione. È possibile eseguire un'PutItemoperazione in un ciclo per elaborare set di dati. DynamoDB supporta connessioni simultanee praticamente illimitate, quindi supponendo che sia possibile configurare ed eseguire una routine di caricamento multithread di massa MapReduce come o Spark, la velocità di scrittura è limitata solo dalla capacità della tabella di destinazione (anch'essa generalmente illimitata).
Quando si caricano dati in DynamoDB, è importante comprendere la velocità di scrittura del loader. Se gli elementi (righe) che stai caricando hanno una dimensione pari o inferiore a 1 KB, questa velocità è semplicemente il numero di elementi al secondo. È quindi possibile dotare la tabella di destinazione di una quantità sufficiente WCU (unità di capacità di scrittura) per gestire questa velocità. Se il loader supera la capacità fornita in un dato secondo, le richieste aggiuntive possono essere limitate o rifiutate del tutto. Puoi verificare la presenza di accelerazioni nei CloudWatch grafici che si trovano nella scheda di monitoraggio della console DynamoDB.
La seconda operazione che può essere eseguita è con una chiamata correlata. API BatchWriteItem BatchWriteItemconsente di combinare fino a 25 richieste di scrittura in un'unica API chiamata. Queste vengono ricevute dal servizio ed elaborate come PutItem richieste separate alla tabella. Attualmente, quando si sceglieBatchWriteItem, non si otterrà il vantaggio dei nuovi tentativi automatici inclusi nel AWS SDKquando si effettuano chiamate singleton con. PutItem Quindi, se ci sono errori (come le eccezioni di limitazione), dovrai cercare l'elenco di tutte le scritture non riuscite nella chiamata di risposta a. BatchWriteItem Per ulteriori informazioni sulla gestione degli avvisi di limitazione nel caso in cui questi vengano rilevati nelle tabelle di limitazione, consulta. CloudWatch Problemi di limitazione per DynamoDB
Il terzo tipo di importazione dei dati è possibile con la funzionalità DynamoDB Import fromPutItem, richiede un processo upstream e scrive i dati nel formato scelto in un bucket Amazon S3.
Strumenti per facilitare la migrazione a DynamoDB
Esistono diversi ETL strumenti e strumenti di migrazione comuni che è possibile utilizzare per migrare i dati in DynamoDB.
Amazon fornisce una serie di strumenti di dati che possono essere utilizzati durante la migrazione, tra cui AWS Servizio di migrazione del Database (DMS), AWS GlueEMR, Amazon e Amazon Managed Streaming per Apache Kafka. Tutti questi strumenti possono essere utilizzati per eseguire una migrazione in caso di inattività e possono sfruttare le funzionalità di Change Data Capture (CDC) del database relazionale per supportare le migrazioni online. Nella scelta di uno strumento, è utile considerare il set di competenze e l'esperienza dell'organizzazione con ogni strumento, oltre alle caratteristiche, alle prestazioni e al costo di ciascuno di essi.
Molti clienti scelgono di scrivere i propri script e processi di migrazione per creare trasformazioni dei dati personalizzate per il processo di migrazione. Se prevedi di gestire una tabella DynamoDB ad alto volume con traffico di scrittura intenso o lavori regolari con carichi di massa di grandi dimensioni, potresti voler scrivere tu stesso il codice di migrazione per acquisire maggiore familiarità con il comportamento di DynamoDB in presenza di traffico di scrittura intenso. Scenari come la gestione dell'acceleratore e il provisioning efficiente delle tabelle possono essere sperimentati nelle prime fasi del progetto, quando si esegue una migrazione pratica.
Scelta della strategia appropriata per la migrazione a DynamoDB
Un'applicazione di database relazionale di grandi dimensioni può estendersi su un centinaio o più tabelle e supportare diverse funzioni applicative. Quando ci si avvicina a una migrazione su larga scala, prendete in considerazione la possibilità di suddividere l'applicazione in componenti o microservizi più piccoli e di migrare un piccolo set di tabelle alla volta. È quindi possibile migrare componenti aggiuntivi su DynamoDB a ondate.
Quando si seleziona una strategia di migrazione, diversi fattori possono indirizzare l'utente verso una soluzione o un'altra. Possiamo presentare queste opzioni in un albero decisionale per semplificare le opzioni a nostra disposizione in base ai requisiti e alle risorse disponibili. I concetti sono brevemente menzionati qui (ma verranno trattati più approfonditamente più avanti nella guida):
-
Migrazione offline: se l'applicazione può tollerare alcuni tempi di inattività durante la migrazione, semplificherà il processo di migrazione.
-
Migrazione ibrida: questo approccio consente un uptime parziale durante la migrazione, ad esempio consentendo le letture ma non le scritture, oppure consente letture e inserimenti ma non aggiornamenti ed eliminazioni.
-
Migrazione online: le applicazioni che non richiedono tempi di inattività durante la migrazione sono meno facili da migrare e possono richiedere una pianificazione significativa e uno sviluppo personalizzato. Una decisione chiave consiste nel stimare e ponderare i costi legati alla creazione di un processo di migrazione personalizzato rispetto al costo per l'azienda derivante dai tempi di inattività durante la fase di cutover.
| Se | And | Quindi |
|---|---|---|
| Puoi disattivare l'applicazione per qualche tempo durante una finestra di manutenzione per eseguire la migrazione dei dati. Si tratta di una migrazione offline. |
Utilizzo AWS DMS ed esegui una migrazione offline utilizzando un'attività a pieno carico. Preforma i dati di origine con un, SQL |
|
| Puoi eseguire l'applicazione in modalità di sola lettura durante la migrazione. Si tratta di una migrazione ibrida. | Disabilita le scritture all'interno dell'applicazione o del database di origine. Utilizzo AWS DMS ed esegui una migrazione offline utilizzando un'attività a pieno carico. | |
| Puoi eseguire l'applicazione con letture e inserimenti di nuovi record, ma senza aggiornamenti o eliminazioni, durante la migrazione. Si tratta di una migrazione ibrida. | Hai competenze nello sviluppo di applicazioni e puoi aggiornare l'app relazionale esistente per eseguire doppie scritture, anche su DynamoDB, per tutti i nuovi record | Utilizzo AWS DMS ed esegui una migrazione offline utilizzando un'attività a pieno carico. Contemporaneamente, distribuisci una versione dell'app esistente che consenta la lettura e l'esecuzione di due scritture. |
| È necessaria una migrazione con tempi di inattività minimi. Si tratta di una migrazione online. |
|
Utilizzo AWS DMS per eseguire una migrazione dei dati online. Esegui un'attività di caricamento in blocco seguita da un'attività di CDC sincronizzazione. |
| È necessaria una migrazione con tempi di inattività minimi. Si tratta di una migrazione online. |
|
Crea la tabella No SQL -ready all'interno del SQL database. Compilala e sincronizzala utilizzandoJOINs,,UNIONs, triggerVIEWs, stored procedure. |
| È necessaria una migrazione con tempi di inattività minimi. Si tratta di una migrazione online. |
|
Prendi in considerazione gli approcci di migrazione ibridi o offline. |
| È necessaria una migrazione con tempi di inattività minimi. Si tratta di una migrazione online. | Puoi saltare la migrazione dei dati storici delle transazioni oppure archiviarli in Amazon S3 anziché migrarli. Devi solo migrare alcune piccole tabelle statiche. | Scrivi uno script o usa qualsiasi ETL strumento per migrare le tabelle. Preforma i dati di origine con un, SQL VIEW se lo desideri. |
Esecuzione di una migrazione offline a DynamoDB
Le migrazioni offline sono adatte quando è possibile consentire una finestra di inattività per eseguire la migrazione. I database relazionali in genere richiedono almeno alcuni tempi di inattività ogni mese per la manutenzione e l'applicazione delle patch, oppure possono richiedere tempi di inattività più lunghi per gli aggiornamenti hardware o gli aggiornamenti delle release principali.
Amazon S3 può essere utilizzato come area di staging durante una migrazione. I dati archiviati in formato CSV (valori separati da virgole) o JSON DynamoDB possono essere importati automaticamente in una nuova tabella DynamoDB utilizzando la funzionalità di importazione di DynamoDB da S3.
Potresti voler combinare le tabelle per sfruttare modelli unici di No SQL access (ad esempio, trasformando quattro tabelle legacy in un'unica tabella DynamoDB). Una richiesta di documento con un singolo valore chiave o una query per una raccolta di elementi preraggruppati di solito restituisce con una latenza migliore rispetto a un database che esegue un join su più tabelle. SQL Tuttavia, ciò rende l'attività di migrazione più difficile. Una SQL vista potrebbe funzionare all'interno del database di origine per preparare un singolo set di dati che rappresenti tutte e quattro le tabelle in un unico set.
Questa visualizzazione consente di creare JOIN tabelle in una forma denormalizzata oppure può mantenere le entità normalizzate e impilare le tabelle utilizzando un. SQL UNION Le decisioni chiave relative alla ridefinizione dei dati relazionali sono trattate in questo video.
Pianifica
Esegui una migrazione offline utilizzando Amazon S3
Strumenti
-
Un ETL processo per estrarre e trasformare SQL i dati e archiviarli in un bucket S3, ad esempio:
-
AWS Database Migration Service, un servizio in grado di caricare in blocco i dati storici e di elaborare anche i record Change Data Capture (CDC) per sincronizzare le tabelle di origine e di destinazione.
-
AWS Aderenza
-
Amazon EMR
-
Il tuo codice personalizzato
-
-
La funzionalità di importazione di DynamoDB da S3
Fasi della migrazione offline:
-
Crea un ETL job in grado di interrogare il SQL database, trasformare i dati della tabella in JSON DynamoDB CSV o in formato e salvarli in un bucket S3.
-
La funzionalità di importazione da S3 di DynamoDB viene richiamata per creare una nuova tabella e caricare automaticamente i dati dal bucket S3.
La migrazione completamente offline è semplice e diretta, ma potrebbe non essere apprezzata dai proprietari e dagli utenti delle applicazioni. Gli utenti trarrebbero vantaggio se l'applicazione potesse fornire livelli di servizio ridotti durante la migrazione, anziché non fornire alcun servizio.
È possibile aggiungere funzionalità per disabilitare le scritture durante la migrazione offline, consentendo al contempo alle letture di continuare normalmente. Gli utenti delle applicazioni possono comunque sfogliare e interrogare in modo sicuro i dati esistenti durante la migrazione dei dati relazionali. Se questo è ciò che stai cercando, continua a leggere per saperne di più sulle migrazioni ibride.
Esecuzione di una migrazione ibrida verso DynamoDB
Sebbene tutte le applicazioni di database eseguano operazioni di lettura e scrittura, è necessario considerare i tipi di operazioni di scrittura eseguite quando si pianifica una migrazione ibrida o online. Le scritture del database possono essere classificate in tre bucket: inserimenti, aggiornamenti ed eliminazioni. Alcune applicazioni potrebbero non richiedere l'elaborazione immediata delle eliminazioni. Ad esempio, queste applicazioni possono rimandare le eliminazioni a un processo di pulizia in blocco alla fine del mese. La migrazione di questi tipi di applicazioni può essere più semplice e al contempo consentire tempi di attività parziali.
Piano
Esegui una migrazione ibrida online/offline con doppia scrittura delle applicazioni
Strumenti
-
Un ETL processo per estrarre e trasformare SQL i dati e archiviarli in un bucket S3 come:
-
AWS DMS
-
AWS Aderenza
-
Amazon EMR
-
Il tuo codice personalizzato
-
Fasi della migrazione ibrida:
-
Crea la tabella DynamoDB di destinazione. Questa tabella riceverà sia dati storici in blocco che nuovi dati in tempo reale
-
Crea una versione dell'applicazione legacy con le eliminazioni e gli aggiornamenti disabilitati mentre esegui tutti gli inserimenti come doppia scrittura sia sul SQL database che su DynamoDB
-
Inizia il lavoro o ETL AWS DMS attività per riempire i dati esistenti e distribuire contemporaneamente la nuova versione dell'applicazione
-
Una volta completato il processo di backfill, DynamoDB disporrà di tutti i record esistenti e nuovi e sarà pronto per il cutover dell'applicazione
Nota
Il processo di backfill scrive direttamente da SQL DynamoDB. Non siamo in grado di utilizzare la funzionalità di importazione S3 come nell'esempio di migrazione offline, poiché tale funzionalità crea una nuova tabella che sarà attiva solo dopo il caricamento dei dati da parte di DynamoDB.
Esecuzione di una migrazione online a DynamoDB migrando ogni tabella 1:1
Molti database relazionali dispongono di una funzionalità chiamata Change Data Capture (CDC), in cui il database consente agli utenti di richiedere un elenco delle modifiche a una tabella avvenute prima o dopo un determinato momento. CDCutilizza log interni per abilitare questa funzionalità e non richiede che la tabella abbia alcuna colonna di timestamp per funzionare.
Quando si migra uno schema di SQL tabelle in un SQL database No, è possibile combinare e rimodellare i dati in un numero inferiore di tabelle. In questo modo potrai raccogliere i dati in un unico posto ed evitare di dover unire manualmente i dati correlati in operazioni di lettura in più fasi. Tuttavia, il data shaping a tabella singola non è sempre necessario e a volte si migrano le tabelle 1 per 1 in DynamoDB. Queste migrazioni da 1 a 1 sono meno complicate in quanto è possibile sfruttare la CDC funzionalità del database di origine, utilizzando strumenti comuni che supportano questo tipo di migrazione. ETL I dati per ogni riga possono ancora essere trasformati in nuovi formati, ma l'ambito di ogni tabella rimane lo stesso.
Prendi in considerazione la migrazione delle SQL tabelle 1 a 1 in DynamoDB, con l'avvertenza che DynamoDB non supporta i join lato server. Dovrai aggiungere logica all'applicazione per combinare i dati di più tabelle.
Pianifica
Esegui una migrazione online di ogni tabella in DynamoDB utilizzando AWS DMS
Strumenti
Fasi della migrazione online:
-
Identifica le tabelle nello schema di origine che verranno migrate
-
Crea lo stesso numero di tabelle in DynamoDB con la stessa struttura chiave del codice sorgente
-
Crea un server di replica in AWS DMS e configura gli endpoint di origine e di destinazione
-
Definisci eventuali trasformazioni per riga richieste (ad esempio colonne concatenate o conversione delle date nel formato di stringa -8601) ISO
-
Crea un'attività di migrazione per ogni tabella per Full Load and Change Data Capture
-
Monitora queste attività fino all'inizio della fase di replica in corso
-
A questo punto, è possibile eseguire qualsiasi verifica di convalida e quindi far passare gli utenti all'applicazione che legge e scrive su DynamoDB.
Esegui una migrazione online a DynamoDB utilizzando una tabella intermedia personalizzata
Come nello scenario di migrazione offline riportato sopra, puoi scegliere di combinare le tabelle per sfruttare modelli di SQL accesso univoci (ad esempio, trasformando quattro tabelle legacy in un'unica tabella DynamoDB). A SQL VIEW potrebbe eseguire il lavoro all'interno del database di origine per preparare un singolo set di dati che rappresenti tutte e quattro le tabelle in un unico set.
Tuttavia, per le migrazioni online con dati in tempo reale e in evoluzione, non è possibile sfruttare le CDC funzionalità in quanto non sono supportate per s. VIEW Se le tabelle includono una colonna con data e ora dell'ultimo aggiornamento e queste sono incorporate in, puoi creare un ETL processo personalizzato che le VIEW utilizzi per eseguire un caricamento di massa con la sincronizzazione.
Un nuovo approccio a questa sfida consiste nell'utilizzare SQL funzionalità standard come viste, stored procedure e trigger per creare una nuova SQL tabella nel formato SQL DynamoDB No finale desiderato.
Se il server di database dispone di capacità inutilizzata, è possibile creare questa singola tabella intermedia prima dell'inizio della migrazione. A tale scopo, è necessario scrivere una stored procedure che legga le tabelle esistenti, trasformi i dati in base alle esigenze e scriva nella nuova tabella temporanea. È possibile aggiungere un set di trigger per replicare le modifiche nelle tabelle nella tabella intermedia in tempo reale. Se i trigger non sono consentiti in base alla politica aziendale, le modifiche alle stored procedure possono ottenere lo stesso risultato. È necessario aggiungere alcune righe di codice a qualsiasi procedura che scrive dati, per scrivere inoltre le stesse modifiche nella tabella intermedia.
La disponibilità di questa tabella intermedia completamente sincronizzata con le tabelle delle applicazioni precedenti vi offrirà un ottimo punto di partenza per una migrazione in tempo reale. Strumenti che utilizzano il database CDC per eseguire migrazioni in tempo reale, come AWS DMS, ora può essere utilizzato su questa tabella. Un vantaggio di questo approccio è che utilizza SQL competenze e funzionalità ben note disponibili nel motore di database relazionale.
Pianifica
Esegui una migrazione online con una tabella SQL di gestione temporanea utilizzando AWS DMS
Strumenti
-
Procedure o trigger SQL memorizzati personalizzati
Fasi della migrazione online:
-
All'interno del motore di database relazionale di origine, assicurati che ci sia spazio su disco e capacità di elaborazione aggiuntivi.
-
Crea una nuova tabella intermedia nel SQL database, con timestamp o funzionalità abilitate CDC
-
Scrivi ed esegui una procedura memorizzata per copiare i dati della tabella relazionale esistente nella tabella temporanea
-
Implementa i trigger o modifica le procedure esistenti per eseguire la doppia scrittura nella nuova tabella intermedia mentre esegui le normali scritture sulle tabelle esistenti
-
Esecuzione AWS DMS per migrare e sincronizzare questa tabella di origine in una tabella DynamoDB di destinazione
Questa guida ha presentato diverse considerazioni e approcci per la migrazione dei dati di database relazionali in DynamoDB, con particolare attenzione alla riduzione al minimo dei tempi di inattività e all'utilizzo di strumenti e tecniche di database comuni. Per ulteriori informazioni, consulta gli argomenti seguenti:
