configurazione db back-end per un'app con utenti geograficamente diversi

Question

Il software sviluppato internamente in cui lavoro si collega direttamente a un server mysql qui nel nostro ufficio tramite il nostro devexpress orm (XPO). Le prestazioni sono eccezionali.

Stiamo aprendo un altro ufficio ... sci di fondo. Performance: non eccezionale. Il requisito è che il software sia reattivo in entrambi gli uffici come in questo ufficio e che i dati di un ufficio siano disponibili all'altro 'in tempo reale'.

Qualcosa di questa scala è totalmente nuovo per me. Non sono contrario a coinvolgere un consulente che ha già fatto qualcosa del genere prima, ma prima vorrei avere una buona immagine delle opzioni. Sono sicuro che questa è una situazione comune.

La replica è una buona idea? È abbastanza veloce? abbastanza stabile?

Esistono modelli di sviluppo che affrontano questo tipo di situazione se la replica non funziona?

Diamine, non sono nemmeno sicuro di come taggarlo, quindi se qualcuno lo sa meglio ... per favore, sentiti libero di ri-taggare

EDIT > Dettagli sui dati

Suppongo che, rispetto ad alcuni software aziendali, non stiamo trasferendo molti dati. Il software gestisce account cliente, appuntamenti ecc. E ogni utente lavora su circa 2-5 account / minuto separati (50 utenti attualmente, 200-400 dopo l'espansione pianificata), aggiornando i dati ogni volta.

L'aspetto in tempo reale entra in gioco quando qualcuno in ufficio A crea un appuntamento per qualcuno in ufficio B che, idealmente, deve essere in grado di visualizzarne i dettagli quasi immediatamente (< 2 minuti). Detto questo, ogni record di solito viene mutato solo un massimo di 5 volte al giorno. Ma è solo quello che sospetto; In realtà non ho alcuna statistica di utilizzo su di me.

Answer 1

Non è possibile utilizzare la replica asincrona in entrambe le direzioni senza creare conflitti di replica che sono impossibili da risolvere e rompere le cose.

Pertanto, la tua ovvia scelta è quella di utilizzare la suddivisione in lettura / scrittura: chiedi all'applicazione di eseguire letture non critiche da un DB locale (di sola lettura) e indirizzare tutte le scritture al master. Lo svantaggio di questo è che significherà che non puoi rileggere immediatamente le tue stesse scritture.

La replica di MySQL non è perfetta e richiede un certo sforzo per la configurazione e il monitoraggio continuo per mantenerlo; è necessario verificare frequentemente che i dati siano gli stessi negli slave. Alcune query vengono replicate in modo errato; dovrai capirli ed evitarli.

Answer 2

Uno dei tuoi ultimi resort è ovviamente quello di assicurarti che tutto il lavoro pesante venga eseguito nei thread in background in modo che il thread della GUI non sia mai bloccato.

Avere dati in tempo reale dipende dai dati, mi manca una descrizione dettagliata come la quantità di dati di cui stiamo parlando per richiesta (cioè quanto sono grandi gli oggetti), quanto è veloce la tua connessione Internet (potrebbe essere il collo di bottiglia?), il server mysql e tutte le infrastrutture tra quelle che controlli sono ben configurate? Quanto sono statici / dinamici i dati, se i dati in tempo reale vengono mutati una volta al giorno o vengono mutati a miliardi di volte al giorno è importante per la & Quot; soluzione & Quot;