Aggiornamento dell'applicazione in un ambiente ad alta disponibilità

Question

Sto scrivendo un motore di database NoSQL e desidero fornire funzionalità che aiutino gli sviluppatori ad aggiornare la loro applicazione a una nuova versione senza interrompere il funzionamento del sito Web, ovvero il tempo di inattività 0% durante l'aggiornamento. Quindi la mia domanda è: quali sono i metodi o la progettazione generale di un'applicazione web quando viene eseguita 24 ore su 24 e sta cambiando la sua struttura di database molto spesso? Eventuali esempi o storie di successo sarebbero molto apprezzate.

Answer 1

La struttura del database è strettamente correlata alle regole di business, quindi l'unico scenario che posso immaginare in cui il database sta cambiando spesso è nella fase di sviluppo di un progetto.

In un ambiente di produzione, si presume che l'applicazione sia già stabile in termini di regole aziendali, pertanto si presume che le modifiche alla struttura del database siano rare. Pertanto penso che sarà molto difficile trovare soluzioni elaborate per questo caso.

Vi sono naturalmente approcci ingenui come la creazione di una copia esatta del database prima dell'aggiornamento, il passaggio dell'applicazione per l'esecuzione sulla copia, l'aggiornamento e il successivo ripristino.

Oltre a questo, non posso pensare ad altro.

Answer 2

Con NoSQL - e in particolare un database orientato ai documenti - è possibile farlo con il controllo delle versioni.

Considerare MongoDB, che archivia tutto come documenti.

MongoDB consente di disporre di una raccolta (un gruppo di documenti) in cui lo schema per ogni documento può essere diverso.

Diciamo che avere questo documento per un utente:

{ "_id" : 100, "firstName" : "John", "lastName" : "Smith" }

si potrebbe anche avere questo come un documento nella stessa collezione:

{ "_id" : 123, "firstName" : "John", "lastName" : "Smith", "hasFoo" : false }

schemi diversi, ma entrambi nella stessa collezione. Ovviamente questo è molto diverso da un database relazionale tradizionale.

La soluzione è quindi aggiungere un campo a ogni documento che ha la versione dello schema. Quindi la tua applicazione cerca quella versione con ogni query.

interrogazione Un MongoDB potrebbe assomigliare a questo:

users.find({ "version" : 3 }).limit(10);

Che proprio restituisce tutti gli utenti che utilizzano la versione dello schema "3". È possibile inserire schemi più recenti senza influire sul sito esistente ed eliminare lentamente vecchie versioni dello schema che non sono più utili.

Answer 3

Stai per costruire un sistema distribuito. Non c'è modo di aggirare questo, in quanto avrete bisogno di più macchine coinvolte per affrontare cose come i reboot.

Costruire un sistema distribuito significa che stai facendo delle scelte.Scelta 2 di:

1. Resistenza
2. disponibilità
3. forte consistenza

Sistemi come S3, hanno scelto 1 & 2 e pagato il prezzo, sacrificando # 3 a favore di "Consistancy eventuali" . C'è un great paper on S3 che puoi leggere. Altre soluzioni di database, come DynamoDB, hanno scelto compromessi diversi.

Avrete bisogno di bilanciamento del carico. Altrimenti sei bloccato con i clienti che si connettono direttamente al tuo servizio, che è difficile per una serie di motivi. Un Load Balancer ti consente di riavviare una macchina nella tua flotta senza incorrere in tempi di inattività. I riavvii, come tutti sappiamo, sono un dato di fatto.

Fare quello che stai descrivendo è molto difficile. In realtà, direi che è quasi un problema impossibile da affrontare per un singolo sviluppatore.

Tu sei molto, molto, molto più probabile per ottenere risultati migliori utilizzando un database NoSQL esistente e spendere tutto il tuo tempo a lavorare sul vostro prodotto ....

Answer 4

Se un'impresa può investire nella distribuzione geografica delle Banca dati. Come tolleranza di failover; sembra tradizionale ma la replica dei dati (o la replica del datastore) non sarebbe un problema per il routing del traffico.

Opzione 2: - uso della cache (sviluppo personalizzato) & ciclismo. ex: - dalle 1 alle 2 am utilizzare l'istantanea 1 del database (diciamo server1/data center 1) 1:59 am server2/data center 2 consiste in una nuova architettura di database (nuovi campi, nuove tabelle ecc.) E @ 2am all trafila del traffico attraverso il data center 2.

Il cronometraggio dell'istantanea potrebbe essere una soluzione da considerare.

Answer 5

Quando molti server Web in un ambiente di produzione accedono a quel database e si ha una modifica di codice incompatibile (che rimuove un campo e aggiunge un nuovo campo), quindi consiglierei la soluzione multi-passo. È un po 'di lavoro, ma non si rischiano i tempi di inattività quando alcuni dettagli vanno male.

primo passo estendere l'applicazione in modo che il vecchio e la nuova versione ottiene scritto, distribuire quella versione

Secondo passo convertito per quanto possibile, i vecchi valori dei campi dati sul nuovo campo di dati (maggio prenditi un po 'di tempo).

Terzo passo modificare l'applicazione per leggere solo il nuovo campo, distribuirlo

Quarto Passo rimuovere il vecchio campo di valori

quinto passo rimuovere la scrittura dei vecchi valori di campo da codice, distribuirlo.

Answer 6

L'unico caso possibile in cui ciò può essere ottenuto è se si dispone di un'applicazione completamente apolidia. Il termine stateless include sia i dati dell'applicazione che la struttura dell'applicazione. Ricordare che l'aggiornamento può comportare la modifica della definizione degli oggetti di business oltre ai dati.Dato che tale applicazione apolidia non è pratica a causa di ovvi motivi, non esiste un modo pratico per ottenere tempi di inattività zero per gli aggiornamenti generali. Qualsiasi applicazione che non sia stateless avrà le definizioni di oggetti business e dati aziendali nella cache di utenti attivi (nel livello intermedio). Un aggiornamento può giustificare non solo nuovi dati aziendali ma nuove definizioni di oggetti di business. I dati memorizzati nella cache da utenti attivi possono sempre causare potenziali incoerenze con il nuovo schema. Pertanto, non è possibile eseguire la migrazione degli utenti dal vivo, a meno che non sia possibile eseguire la migrazione di dati e metadati (definizioni aziendali) memorizzati nella cache del livello intermedio. Se si soffia via la cache di medio livello, gli utenti in diretta ne risentiranno. Si può considerare di consentire agli utenti live di continuare a lavorare con il vecchio db e di migrare/unire qualsiasi modifica di dati al nuovo db in seguito. Ma questo è un problema complicato da risolvere. Ora è possibile limitare ciò che è consentito con un aggiornamento senza downtime senza influire sugli utenti in tempo reale o assicurarsi che dopo che il database sia aggiornato, gli utenti in tempo reale diventino utenti di sola lettura a meno che non si disconnettano e si connettano nuovamente al nuovo schema .