Le migrazioni dello schema del database sono un problema negli ambienti di produzione?

Solo perché il tuo database NoSql non ha uno schema in senso tradizionale non significa che non ci sia uno schema logico che devi affrontare man mano che cambia. Nel caso di un'applicazione tipica che utilizza MongoDb, molto probabilmente il tuo codice si aspetta che determinati campi dell'oggetto json si comportino in determinati modi. Se si modifica il comportamento, è possibile che si desideri aggiornare i dati già esistenti nel database. Ora, con l'RDBMS tradizionale, questo era un problema largamente risolto: bastava ALTERARE le tabelle sottostanti. Ma con questi nuovi database NoSQL, hai una decisione: scrivi uno script per munge e aggiorna tutti i tuoi oggetti? O aggiungi il codice per convertire tra le versioni al volo? In tal caso, per quanto tempo supporti gli oggetti v1? Per sempre? Fino alla v3?

Aggiungerò che l'esempio usato nel post del blog MongoDb è un po 'semplicistico e un caso molto facile da gestire se hai un processo di aggiornamento decente, non importa quale sia l'RDBMS; aggiungere un campo raramente fa male. È quando decidi di dividere il tuo campo Name in FirstName e LastName che le cose si eccitano.

But is that really a big problem when doing upgrades?

Può essere.

Alcune organizzazioni sono - ben disorganizzate, e fanno un pessimo lavoro di migrazione dello schema.

1. "Fine settimana migrazione". Arresta i server. Esegui il backup ed esporta tutti i dati. Costruisci il nuovo schema (spesso modificando lo schema esistente). Ricarica i dati o tenta di ristrutturare sul posto.

2. "Modifica continua". Modificare le tabelle nella misura consentita da SQL. Senza tracciare la sequenza di ALTER eseguita. Non c'è modo di tornare a una versione precedente dello schema. Ove necessario, crea nuove tabelle da tabelle esistenti, si spera che aggiusti tutte le applicazioni per utilizzare le nuove tabelle. Ma - manca un buon QA - lasciando i vecchi tavoli in funzione "nel caso in cui".

3. "Panico completo". Semplicemente prevenire le modifiche dello schema. Fai una grande puzza. Richiedi il rischio è troppo alto. Blocca tutti gli sforzi in questa direzione. Prendi lo schema in ostaggio fino a quando non sarà costretto ad adottare un approccio più ragionevole.

Are relational databases bad for such operations?

Qualsiasi schema è un problema da migrare.

Il problema più grande non è tecnico.

È semantico.

Un motivo principale per una modifica dello schema è che lo schema precedente non corrisponde molto bene al dominio del problema. Poiché la semantica è cambiata, il database (e le applicazioni) devono essere modificati. Talvolta si tratta di modifiche profonde che richiedono un ripensamento del modo in cui le applicazioni funzionano con i dati.

La revisione della semantica del database può essere molto difficile.

Quello che le persone fanno invece delle modifiche dello schema è solo un uso improprio dello schema fisico. Iniziano a caricare dati errati nei campi esistenti perché possono. Un campo di "commenti" inizia improvvisamente ad avere un importante pezzo di informazioni sulla gestione del cliente seguito da "//" seguito dal commento reale. Che cresce per avere pezzi di dati "campo 1 - campo 2 // commento". Gli utenti hanno un foglio di calcolo che estrae questi dati aggiuntivi dal campo dei commenti perché il software applicativo "reale" ha uno schema difficile da modificare che l'IT ha rifiutato di modificarlo.

Aggiorniamo i database di produzione aggiungendo tabelle e colonne (nullable) senza problemi. Le versioni precedenti dell'applicazione funzionano correttamente con il database aggiornato, semplicemente non fanno riferimento alle novità. Evitiamo di rimuovere tabelle o colonne o di modificare il modo in cui i dati esistenti vengono archiviati, sebbene quando ciò sia necessario produciamo script di conversione appropriati. Indipendentemente dal fatto che il database abbia o meno uno schema di tipo sicuro dichiarato, le modifiche nella struttura dei dati richiedono la conversione dei dati e gli aggiornamenti delle applicazioni per interagire con la nuova struttura.

Dipende.

In primo luogo, se si dispone di un database molto grande che si estende su più macchine, allora tutto (non solo l'aggiornamento del database) sarà doloroso. (non importa quanto hai pianificato in anticipo).

In secondo luogo, l'aggiornamento di un database NON è solo una questione di database, ma dipende anche dal sistema più grande di cui fa parte il DB. Ciò include anche l'implementazione del database (molti server di database, più data center, setup master-slave, ecc.)

Il dolore può essere alleggerito architetturando i componenti del sistema in modo tale che tutti abbiano una sorta di "cognizione" dell'evento di cambiamento dello schema DB. Ciò significa che l'intero sistema deve essere tollerante alle modifiche dello schema e può rispondere ad esso in modo "sano".

Puoi consultare una utility sviluppata da Facebook per affrontare gli aggiornamenti dello schema MySQL.

Inoltre, esistono best practice standard come trasformare il master in sola lettura, apportare modifiche agli slave o alla copia di sviluppo, ecc.

In ogni caso, avere un backup completo e un'ampia suite di test è un MUST. Solo allora, puoi apportare modifiche in modo sicuro e sicuro.