Una guida completa sulle strategie di migrazione tecnologica: (Parte 3 – Migrazione del database)

Immagina uno scenario in cui acquisti un nuovo appartamento, sei pronto per trasferirti e hai pianificato attentamente il processo. Sei pronto per trasferirti nella tua nuova casa, poi improvvisamente ti rendi conto che c'è un problema. I mobili e i manufatti non si adattano bene al tuo nuovo appartamento.

Come ti sentiresti se dovessi buttare via tutti i tuoi mobili e ricominciare da capo? Portando ulteriormente questa analogia, considera il nuovo appartamento come il tuo nuovo database e i mobili come i dati. Siamo sicuri che i dati sarebbero molto più importanti dei mobili per la tua attività e quindi vorresti conservarne ogni singolo pezzo mentre prevedi di migrare.

Come continuazione della nostra serie sulla migrazione della tecnologia, in questo blog cercheremo di scoprire le basi della migrazione del database (DBM), ciò che si dovrebbe capire, considerare e di cui occuparsi durante l'esecuzione della migrazione del database.

Perché e quando è necessaria la migrazione del database?

Come seguito del nostro precedente blog sulla migrazione delle applicazioni, il pezzo di oggi è incentrato sulla migrazione del database (nota anche come migrazione dello schema) perché è una delle migrazioni più importanti che riguarda principalmente la selezione, l'estrazione, il trasferimento/l'aggiornamento dei dati da un framework di database a altro.

In sostanza, la necessità di migrazione del database può essere specifica per un'esigenza aziendale o anche per soddisfare le più recenti politiche normative multiple istituite da vari regolatori. Sebbene non ci siano situazioni definite in cui è necessario il DBM, abbiamo elencato alcune situazioni in cui ciò è inevitabile:

• Un motivo comune è spostare il tuo sistema obsoleto in un sistema che soddisfi i tuoi requisiti aziendali e le moderne esigenze di dati. Nuove e moderne tecniche di archiviazione sono diventate una necessità ai tempi dei Big Data.
• Alcune autorità di regolamentazione hanno reso obbligatorio che i dati rimangano solo in una particolare area geografica. Pertanto, è necessario che i dati distribuiti vengano migrati in un'unica posizione.
• Alcune aziende preferiscono spostare un database locale in un database cloud. Questo in genere consente di risparmiare sull'infrastruttura e sulle risorse di competenza necessarie per supportare i dati e anche rendere i sistemi più veloci.
• La migrazione a una nuova piattaforma garantisce l'integrità completa dei dati. Riduce i costi di archiviazione e dei media, il che si traduce in un miglioramento significativo del ROI.
• Molte aziende moderne desiderano conservare tutti i propri dati in un unico posto. In questo modo i dati sono accessibili a tutti i reparti dell'azienda.

La migrazione del sistema di database su una nuova piattaforma riduce le interruzioni che si verificano nelle operazioni aziendali quotidiane. Questo può essere fatto con il minimo sforzo manuale se la selezione di una nuova piattaforma di database viene eseguita con saggezza.

Tipi di database

Prima di procedere con la migrazione del database, diamo prima un'occhiata ai diversi tipi di database:

• Database relazionale: i database relazionali sono conosciuti come i cavalli di battaglia del settore dei database. Questi database sono classificati in base a un insieme di tabelle. Le tabelle sono costituite da righe e colonne in cui la riga contiene l'istanza di dati e la colonna contiene l'immissione di dati per una categoria specifica. SQL – Structured Query Language è un'interfaccia di programmazione standard per Database relazionali.
• Database distribuito : come suggerisce il nome, i dati vengono distribuiti in vari siti di qualsiasi organizzazione. I collegamenti di comunicazione vengono utilizzati per collegare i siti tra loro. Questo aiuta ad accedere facilmente al database distribuito.
• Database orientato agli oggetti : questo tipo di database unisce gli attributi del database relazionale e della programmazione orientata agli oggetti. Vari elementi creati in C++ e Java possono essere archiviati in database relazionali, tuttavia un database orientato agli oggetti è più adatto a loro.
• Database NoSQL: il database NoSQL può analizzare in modo efficiente grandi dati non strutturati archiviati su più server virtuali. Al contrario, un database relazionale non è in grado di gestire in modo efficiente alcune prestazioni di big data. I database NoSQL possono gestire facilmente tali casi e vengono utilizzati per un ampio set di dati distribuiti.
• Database cloud : il database cloud è un ambiente virtuale che offre la flessibilità di pagare in base all'utilizzo. L'utente deve solo pagare per la larghezza di banda e la capacità di archiviazione adatta alle proprie esigenze.
• Database dei grafici: in parole povere, un grafico è una raccolta di nodi e bordi. Il database del grafico contiene nodi che rappresentano entità e edge descrive le relazioni tra tali entità. È un tipo di database NoSQL e utilizza la teoria dei grafi per mappare, archiviare e interrogare le relazioni.
• Database centralizzato : con questo tipo di database, i dati vengono archiviati in un'unica posizione centralizzata. Il database contiene essenzialmente procedure applicative che consentono agli utenti di accedere al DB anche da postazioni remote.

Approcci di migrazione di database

La migrazione dei dati da una piattaforma di database a un'altra può essere un compito cruciale. Se la migrazione è pianificata in un ambiente LIVE, la migrazione deve essere eseguita con la massima cautela. È necessario scegliere un tempo di migrazione conveniente prima di procedere con la migrazione dei dati. I sistemi live spesso subiscono tempi di inattività quando i dati vengono trasferiti a un nuovo database.
Esistono principalmente due approcci alla migrazione del database:

Migrazione dei dati del Big Bang:

Questo approccio è il punto in cui si sceglie di migrare il database completo in una volta in un intervallo di tempo limitato. Sebbene la migrazione dei dati big bang sembri meno complessa, richiede tempi di inattività sufficienti per il sito Web live. Inoltre, con questo approccio, un rollback completo del processo di migrazione potrebbe non essere facile da ottenere nel caso in cui la migrazione fallisca in qualsiasi momento.

Migrazione dei dati di mantenimento

Con questo approccio, è necessario suddividere il processo di migrazione in blocchi o fasi più piccoli. Quasi come un approccio agile alla migrazione, se una singola fase non riesce, è necessario ripristinare solo quella fase e ripetere il processo. Tuttavia, la migrazione dei dati Trickle richiede molto tempo e quindi potrebbe aumentare il costo del progetto.

Diversi tipi di migrazione

DB relazionale a DB relazionale

Questo approccio è la migrazione più semplice. Ci sono tonnellate di strumenti disponibili che eseguono questo tipo di migrazione in modo abbastanza efficiente, con un'efficacia quasi del 100%.

DB relazionale a DB non relazionale e viceversa

Questa migrazione è più difficile rispetto a quella di cui sopra. Poiché il DB relazionale e il DB non relazionale sono fondamentalmente diversi, la loro migrazione potrebbe non essere efficiente al 100%. In sostanza, migrare a DB non relazionali significa sacrificare le proprietà ACID (atomiche, consistenti, isolate e durevoli) che garantiscono la scalabilità di un database.
Tuttavia, sono disponibili più strumenti gratuiti che supportano la migrazione del database da DB relazionale a DB non relazionale. Sebbene il loro utilizzo non sia ampiamente raccomandato in quanto questi strumenti non supportano la struttura dello schema del sistema e la maggior parte sembra troppo rigida per adattare i requisiti di sistema.

Sebbene ci siano alcuni suggerimenti di conversione di base che possiamo eseguire per questo tipo di migrazione che possiamo considerare (per semplicità, consideriamo MySQL come il nostro database relazionale e MongoDB come il nostro database non relazionale)

• Converti il ​​tipo di dati MySQL String in String in MongoDB. Questo può includere char, varchar, blob, testo, ecc.
• Converti il ​​tipo di dati MySQL Numeric in Number in MongoDB. Questo può includere int, float, decimal, double, ecc.
• Converti il ​​tipo di dati MySQL Date in Date in MongoDB. Questo può includere la data, l'anno, il timestamp, ecc.
• Converti il ​​tipo di dati MySQL Bool e Boolean in Boolean in MongoDB.
• Puoi valutare altri casi allo stesso modo.

Migrazione con un modello ibrido

Il design del modello ibrido integra i due popolari modelli di database in un unico framework mitigando gli svantaggi di ciascun sistema. Ad esempio, possiamo sempre adottare un approccio ibrido in cui possiamo sfruttare un DB relazionale per operazioni meno impegnative, in combinazione con un DB non relazionale per iniziative ad alta intensità di dati.

Backup dei dati

La pianificazione della strategia di migrazione prima dell'esecuzione può garantire un processo di migrazione senza intoppi. Detto questo, dobbiamo sempre avere un piano B. Supponendo uno scenario peggiore in cui si verifica una perdita di dati o i dati vengono danneggiati durante l'esecuzione della migrazione; devi essere pronto a ripristinare i dati allo stato originale prima di riprovare. Questo è il motivo per cui il Data Backup è un passaggio molto imperativo durante il DBM (Database Migration). Quindi, quali opzioni esistono per garantire un backup sicuro dei dati, approfondiamo.

Backup su cloud

Uno dei metodi più efficienti e sicuri per proteggere la tua iniziativa di migrazione consiste nell'eseguire un backup nell'archivio cloud. In sostanza, quando si esegue il backup dei dati nell'archivio cloud, i file vengono archiviati fuori sede. Ciò elimina le vulnerabilità hardware locali che potrebbero causare problemi. Allora, perché un backup su cloud?

• I backup su cloud sono convenienti perché devi pagare solo per utilizzo.
• Un backup su cloud è sicuro in quanto fornisce una crittografia end-to-end.
• Consente un facile ripristino di emergenza e ripristino dei dati
• Le robuste opzioni di backup su cloud includono l'intero backup dell'immagine del sistema. Pertanto, non è necessario reinstallare il sistema operativo. Computer e server vengono ripristinati all'ultima versione funzionante.

Software per la condivisione di file

Le suite software come Dropbox stanno crescendo per soddisfare le esigenze dei loro utenti. Dropbox conserva le versioni dei file che possono essere ripristinate quando necessario. Simile al backup su cloud, questa opzione è conveniente e i file vengono archiviati fuori sede. Quali sono i suoi vantaggi?

• I file possono essere ripristinati su qualsiasi sistema in qualsiasi posizione.
• È gratuito e supporta la collaborazione.
• Altamente sicuro (l'archiviazione su cloud crittografa i file in transito)
• Capacità di lavoro offline

Uno svantaggio, tuttavia, è che il ripristino non è automatizzato. È necessario copiare e incollare i dati nella struttura della directory di condivisione file per salvare i dati. I file devono risiedere in una struttura definita, altrimenti non verrà eseguito il backup. Se i file si trovano in una cartella o directory condivisa, probabilmente sarà necessaria una maggiore larghezza di banda per eseguire il backup di tali file.

In generale, ci sono altri mezzi disponibili per il backup come un backup su un'unità flash o un disco rigido esterno. Ma queste opzioni non sono consigliate in quanto non sono del tutto sicure rispetto al backup su cloud o al software di condivisione file. Ad esempio, qualsiasi danno fisico a un disco rigido può causare la perdita di dati. Inoltre, sono più vulnerabili e suscettibili agli attacchi ransomware e ai criptovirus.

Come garantire che i dati siano al sicuro?

Quando si esegue la migrazione dei dati, è necessario assicurarsi che i dati sensibili non vengano violati o manomessi. Se la migrazione va storta, può portare a conseguenze maggiori e causare fughe di dati o perdite di dati come negli esempi qui citati nel 2020.

Sfortunatamente, le fughe di dati possono causare danni alla reputazione del cliente, portare alla perdita di affari e clienti; o in alcuni casi, può provocare azioni legali. Per evitare tutte queste conseguenze, è necessario elaborare preventivamente un piano di sicurezza tenendo presente la strategia di migrazione.

• Per cominciare, l'accesso al server affidabile e sicuro e l'accesso ai dati dovrebbero essere nella tua lista di priorità.
• Aumenta il numero di autorizzazioni necessarie per il trasferimento dei dati. Nelle organizzazioni più grandi, i dipartimenti di sicurezza limitano l'accesso ai server e definiscono la migrazione dei dati tra i server coinvolti.
• I dati sono ad alto rischio quando sono coinvolte più parti. Quindi, evita di trasferire tra le parti tramite dispositivi di archiviazione portatili o e-mail. In tali casi, i dati possono essere facilmente compromessi.
• Per garantire l'accesso, l'archiviazione e il recupero sicuri dei dati, è necessario praticare costantemente la crittografia e la decrittografia. È possibile utilizzare algoritmi di crittografia ibrida per garantire la massima sicurezza dei dati. Ma questo non è consigliato a tutti. Se la migrazione non riesce, i dati verrebbero ingombrati e potrebbero causare il danneggiamento o la perdita di dati.

Per garantire una migrazione sicura, evita di utilizzare strumenti primitivi. L'uso di strumenti primitivi potrebbe indebolire il tuo sistema e lasciare scappatoie a cui gli hacker possono accedere. È necessario utilizzare strumenti robusti per la migrazione dei dati che siano funzionalmente specifici.

Processo di migrazione dei dati

La migrazione dei dati è principalmente un processo multifase ed è necessario seguire i passaggi seguenti per evitare la perdita di dati e garantire una migrazione sicura del database.

1. Valutazione :

• Raccogli l'analisi dei requisiti aziendali e definisci l'obiettivo chiave da raggiungere con DBM.
• Definisci l'ambito
• Condurre un'ampia profilazione dei dati:
  • Esaminare i dati di origine, il formato dei dati, rivedere la struttura dello schema, il contenuto e le relazioni tra le istanze di dati
• Comprendere il sistema di destinazione
• Identificare gli stakeholder
• Budget l'intera attività

2. Backup dei dati

• Assicurati di eseguire il backup dei dati di cui stai migrando in modo sicuro. Si consiglia di utilizzare un backup su cloud.
• Assicurati che la destinazione sia pulita e protetta da qualsiasi attacco di dati.

3. Disponibilità delle risorse :

• La disponibilità di tempo per la migrazione e il tempo di inattività per il sistema di destinazione.
• Assicurati che la risorsa umana assunta abbia lo skillset corretto.
• Identifica lo strumento e gli script giusti.

4. Esecuzione della migrazione dei dati :

• Il processo di migrazione può includere script, strumenti ETL o altri strumenti comparabili per spostare i dati.
• Al momento della migrazione, trasformerai i dati, normalizzerai i tipi di dati e, infine, controllerai possibili errori.

5. Test e messa a punto :

• Il team e il team del cliente devono essere assolutamente sicuri che tutti i dati siano migrati correttamente
• Quindi, controlla se i dati sono stati spostati correttamente, se i dati sono completi e assicurati che non ci siano valori mancanti.
• Inoltre, assicurati che i dati siano validi e non contengano valori null.
• In caso di mancata corrispondenza dei dati, dovrebbe esserci un rollback dei dati e l'intero processo dovrebbe essere riavviato.

6. Audit

Una volta che il nuovo database è attivo, è possibile configurare un sistema per controllare i dati. Ciò garantirà l'accuratezza della migrazione del database e attirerà l'attenzione sui dati incompleti e imprecisi.

Potenziali rischi con la migrazione del database

La migrazione del database è una procedura molto complessa e comporta rischi e incertezze. Puoi sempre superarli con una corretta pianificazione ed esecuzione. I rischi che si possono incontrare sono:

• Sistemi di origine obsoleti: qui, l'origine dati può essere obsoleta, ridondante, obsoleta o banale
• Architettura di database eterogenea: in questo scenario, i database di origine potrebbero trovarsi in più posizioni e potrebbero avere architetture completamente diverse l'una dall'altra, tuttavia il database di destinazione ha bisogno che tutto sia sincronizzato.
• Tempo di inattività esteso: ci sono casi in cui la migrazione pianificata richiede più tempo del previsto e, a causa di ciò, si verifica un tempo di inattività prolungato per il sistema. Ciò potrebbe causare perdite commerciali per il cliente finale e potrebbe non essere accettabile.
• Potenziale perdita di dati: non tutte le perdite di dati possono essere identificate durante la fase di test. Alcune istanze di perdita di dati potrebbero essere identificate alla fine quando il sistema riceve abbastanza traffico.

Migrazione da un database in tempo reale: per qualsiasi sito Web con transazioni elevate, la migrazione del database è sempre difficile poiché sono in corso aggiornamenti costanti dei dati; e la migrazione dei dati in tempo reale e in tempo reale non è possibile. Ci deve essere un tempo di inattività per qualsiasi migrazione avvenga.

Osservazioni finali

Puoi sempre chiedere consiglio a esperti di terze parti sulla migrazione del database. Siamo Creole Studios, siamo specializzati nelle migrazioni di database e saremmo felici di aiutare o consultare in qualsiasi impresa del genere. Rimani legato al quarto e ultimo blog della serie sulla migrazione tecnologica.