Nelle discussioni sui database NoSQL vs SQL, a volte sento che le aziende preferiscono utilizzare i database NoSQL senza schemi perché è problematico migrare lo schema in una nuova versione. Ma è davvero un grosso problema quando si eseguono gli aggiornamenti? I database relazionali sono dannosi per tali operazioni?
Ho letto questo post sul blog MongoDB: Perché Schemaless?
Risposte:
Solo perché il tuo database NoSql non ha uno schema in senso tradizionale non significa che non c'è uno schema logico che devi affrontare quando cambia. Nel caso di un'app 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, ne consegue che potrebbe essere necessario aggiornare i dati già esistenti nel database. Ora, con RDBMS tradizionale questo era un problema ampiamente risolto: dovevi solo ALTER le tabelle sottostanti. Ma con questi nuovi database NoSQL, hai una decisione: scrivi uno script per scavalcare e aggiornare 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 utilizzato nel post sul blog MongoDb è un po 'semplicistico e un caso molto semplice da gestire se hai un processo di aggiornamento decente, qualunque sia l'RDBMS; l'aggiunta di un campo fa male raramente. È quando decidi di dividere il tuo Namecampo in FirstNamee LastNameche le cose diventano eccitanti.
Ma è davvero un grosso problema quando si eseguono gli aggiornamenti?
Può essere.
Alcune organizzazioni sono - ben - disorganizzate e svolgono un pessimo lavoro di migrazione dello schema.
"Weekend della migrazione". Ferma i server. Eseguire il backup ed esportare tutti i dati. Costruisci il nuovo schema (spesso modificando lo schema esistente). Ricarica i dati o prova a ristrutturare sul posto.
"Ritocco continuo". Modificare le tabelle nella misura consentita da SQL. Senza tenere traccia della sequenza di ALTER eseguita. Non c'è modo di tornare a una versione precedente dello schema. Se necessario, creare nuove tabelle da tabelle esistenti, sperando di adattare tutte le applicazioni per utilizzare le nuove tabelle. Ma - manca un buon QA - lasciando i vecchi tavoli in posizione "per ogni evenienza".
"Panico completo". Basta impedire le modifiche allo schema. Fai una grande puzza. Affermare che il rischio è troppo alto. Blocca tutti gli sforzi in questa direzione. Prendi l'ostaggio dello schema fino a quando non sei costretto ad adottare un approccio più sensato.
I database relazionali sono dannosi per tali operazioni?
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 cambiare. A volte si tratta di cambiamenti profondi che richiedono un ripensamento del modo in cui le applicazioni lavorano con i dati.
La revisione della semantica del database può essere molto difficile.
Quello che la gente fa invece delle modifiche allo schema è semplicemente abusare dello schema fisico. Iniziano a caricare dati errati nei campi esistenti perché possono. Un campo "commento" inizia improvvisamente con un'importante informazione di gestione dei clienti seguita 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" aveva uno schema difficile da modificare che l'IT ha rifiutato di cambiarlo.
Aggiorniamo i database di produzione aggiungendo tabelle e colonne (nullable) senza problemi. Le versioni precedenti dell'applicazione funzionano bene con il database aggiornato, ma non fanno riferimento alle nuove cose. Evitiamo di rimuovere tabelle o colonne o di modificare il modo in cui sono archiviati i dati esistenti, sebbene quando ciò sia necessario produciamo script di conversione adeguati. Indipendentemente dal fatto che il database disponga di uno schema sicuro di tipo dichiarato o meno, le modifiche nella struttura dei dati richiedono la conversione dei dati e gli aggiornamenti dell'applicazione per interagire con la nuova struttura.
Dipende.
Innanzitutto, se si dispone di un database davvero 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 la distribuzione del database (molti server di database, più data center, configurazioni master-slave, ecc.)
Il dolore può essere alleggerito architettando i componenti del sistema in modo tale che tutti abbiano una sorta di "conoscenza" dell'evento di modifica dello schema del DB. Ciò significa che l'intero sistema dovrebbe essere tollerante nei confronti delle modifiche allo schema e in grado di rispondere ad esso in modo "sano".
Puoi provare un'utilità 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 sulla copia di sviluppo, ecc.
In ogni caso, disporre di un backup completo e di un'ampia suite di test è DEVE. Solo allora puoi apportare qualsiasi modifica in modo sicuro e sicuro.