Come implementare le modifiche dello schema in un sistema di storage NOSQL

Question

Come si gestisce una modifica dello schema principale quando si utilizza un negozio Nosql come SimpleDB?

So che sto ancora pensando in termini SQL, ma dopo aver lavorato con SimpleDB per alcune settimane ho bisogno di apportare una modifica a un database in esecuzione. Vorrei cambiare una delle classi oggetto per avere un ID univoco, come piuttosto che un nome di business, e dato che è referenziato da un altro oggetto, dovrò anche aggiornare il valore di riferimento in questi oggetti.

Con un database SQL eseguire una serie di istruzioni SQL come parte del processo di distribuzione del software client. Ovviamente questo non funzionerà con qualcosa come SimpleDB come

• non esiste un equivalente di un'istruzione di aggiornamento SQL.
• A causa della natura distribuita di SimpleDB, non è possibile sapere quando le modifiche apportate al database sono state "filtrate" su tutti i nodi che eseguono il software client.

Alcune soluzioni che ho pensato sono

• Ogni dominio ha un numero di versione. Il software client sa quale versione del dominio deve utilizzare. Scrivi del codice che copia i dati da una versione di dominio a un'altra, apportando tutte le modifiche necessarie man mano che procedi. È quindi possibile installare un nuovo software client che acceda alla nuova versione del dominio. Questo approccio non funzionerà se non è possibile "congelare" tutti gli accessi in scrittura durante il processo di aggiornamento.

• Ogni articolo ha un attributo di versione che indica il formato utilizzato quando è stato memorizzato. Il client utilizza questo attributo quando carica l'oggetto in memoria. L'oggetto può quindi essere convertito nel formato più recente quando viene riscritto in SimpleDB. Il problema con questo è che il nuovo software deve essere distribuito a tutti i server prima che si verifichino eventuali scritture nel nuovo formato, oi client che eseguono il vecchio software non sapranno leggere il nuovo formato.

È tutto piuttosto complesso e mi chiedo se mi manca qualcosa?

Grazie

Richard

Answer 1

Io uso qualcosa di simile alla seconda opzione, ma senza l'attributo di versione.

In primo luogo, cerca di mantenere le tue modifiche a cose che sono facili da rendere compatibili con le versioni precedenti: cambiare la chiave primaria è lo scenario peggiore per questo.

La rimozione di un campo è semplice: basta interrompere la scrittura su quel campo quando tutti i server eseguono una versione che non lo richiede.

L'aggiunta di un campo richiede che non si scriva mai quell'oggetto utilizzando il codice che non salverà quel campo. Se non è possibile distribuire la nuova versione ovunque in una volta, utilizzare una versione intermedia che supporti il ​​salvataggio del campo prima di distribuire una versione che lo richiede.

La modifica di un campo è solo una combinazione di queste due operazioni.

Con questo approccio le modifiche vengono applicate come necessario: scrivere utilizzando la nuova versione, ma consentire la lettura della versione precedente con valori predefiniti o derivati ​​per il nuovo campo.

È possibile utilizzare lo stesso codice per aggiornare tutti i record contemporaneamente, sebbene ciò potrebbe non essere appropriato su un set di dati di grandi dimensioni.

Cambiare la chiave primaria può essere gestita allo stesso modo, ma potrebbe diventare molto complessa a seconda del sistema nosql che si sta utilizzando. In questo caso, probabilmente sei bloccato con la progettazione di un codice di migrazione personalizzato.

Answer 2

RavenDB un altro database NoSQL utilizza migrazioni per raggiungere questo obiettivo

http://ayende.com/blog/66563/ravendb-migrations-rolling-updates

http://ayende.com/blog/66562/ravendb-migrations-when-to-execute

Normalmente questo tipo di cambiamenti sono gestiti dalla vostra applicazione che cambia il schema a uno più recente al caricamento della versione X e dei converti ng alla versione Y e persistente