Ho finito con la codifica del nostro migratore utilizzando NodeJS. Mi sono un po 'irritato con le risposte che spiegano cos'è redshift e MongoDB, quindi ho deciso che mi prenderò il tempo per condividere ciò che dovevo fare alla fine.
dati con registrazione cronologica
Fondamentalmente abbiamo garantire che tutte le nostre collezioni MongoDB che vogliamo essere migrati a tavoli in spostamento verso il rosso sono timestamped, e indicizzati in base a tale data e ora.
Plugin ritorno cursori
Abbiamo poi codificare un plug-in per ogni migrazione che vogliamo fare da una raccolta Mongo a una tabella spostamento verso il rosso.Ogni plug-in restituisce un cursore, che prende in considerazione l'ultima data migrata (passata dal motore di migrazione) e restituisce solo i dati che sono stati modificati dall'ultima migrazione riuscita per quel plug-in.
Come i cursori sono utilizzati
Il motore migratore quindi utilizza questo cursore, e loop attraverso ogni record. Richiama il plug-in per ciascun record, per trasformare il documento in un array, che viene quindi utilizzato dal migratore per creare una linea delimitata che esegue lo streaming su un file su disco. Utilizziamo le schede per delimitare questo file, poiché i nostri dati contenevano molte virgole e pipe.
esportazioni delimitati da S3 in una tabella sul redshift
Il migratore quindi carica il file delimitato su S3, ed esegue il comando di spostamento verso il rosso copia per caricare il file da S3 in una tabella temporanea, utilizzando la configurazione del plugin per ottenere il nome e una convenzione per denotarlo come un tavolo temporaneo.
Così, ad esempio, se avessi un plug-in configurato con un nome di tabella di employees, creerebbe una tabella temporanea con il nome di temp_employees.
Ora abbiamo dati in questa tabella temporanea. E i record in questa tabella temporanea ottengono i loro id dalla raccolta MongoDB di origine. Questo ci consente di eseguire un'eliminazione sulla tabella di destinazione, nel nostro esempio, la tabella dei dipendenti, in cui l'ID è presente nella tabella temporanea. Se nessuna tabella non esiste, viene creata al volo, in base a uno schema fornito dal plug-in. E così arriviamo a inserire tutti i record dalla tabella temporanea nella tabella di destinazione. Questo approvvigiona sia per i nuovi record sia per i record aggiornati. Facciamo solo soft delete sui nostri dati, quindi verrà aggiornato con un flag is_deleted in redshift.
Una volta completato l'intero processo, il motore di migrazione memorizza un timestamp per il plug-in in una tabella redshift, al fine di tenere traccia di quando l'ultima migrazione è stata eseguita correttamente. Questo valore viene quindi passato al plug-in la prossima volta che il motore decide di migrare i dati, consentendo al plug-in di utilizzare il timestamp nel cursore che deve fornire al motore.
Quindi, in sintesi, ogni plugin/migrazione fornisce la seguente al motore:
- un cursore, che utilizza opzionalmente l'ultima data migrato passata ad esso dal motore, al fine di garantire che solo i delta vengono spostati across.
- Una funzione di trasformazione, utilizzata dal motore per trasformare ciascun documento del cursore in una stringa delimitata, che viene aggiunta a un file di esportazione
- Un file di schema, questo è un file SQL che contiene lo schema per la tabella su redshift