Configuración de backend db para una aplicación con usuarios geográficamente diversos

Question

El software desarrollado internamente donde trabajo se conecta directamente a un servidor mysql aquí en nuestra oficina a través de nuestro devexpress orm (XPO). El rendimiento es excelente.

Estamos abriendo otra oficina ... a campo traviesa. Rendimiento: no tan bueno. El requisito es que el software sea tan receptivo en ambas oficinas como lo es en esta oficina y que los datos de una oficina estén disponibles para la otra 'en tiempo real'.

Algo de esta escala es totalmente nuevo para mí. No soy reacio a contratar a un consultor que haya hecho algo como esto antes, pero me gustaría obtener una buena idea de las opciones primero. Estoy seguro de que esta es una situación común.

¿La replicación es una buena idea? ¿Es lo suficientemente rápido? lo suficientemente estable?

¿Existen patrones de desarrollo que aborden este tipo de situación si la replicación no funciona?

Diablos, ni siquiera estoy seguro de cómo etiquetar esto, así que si alguien sabe mejor ... por favor, siéntase libre de volver a etiquetar

EDITAR > Detalles sobre los datos

Supongo que, en comparación con algunos softwares empresariales, no estamos moviendo muchos datos. El software gestiona cuentas de clientes, citas, etc. y cada usuario trabaja en aproximadamente 2-5 cuentas / minuto separadas (50 usuarios actualmente, 200-400 después de la expansión planificada), actualizando los datos cada vez.

El aspecto en tiempo real entra en juego cuando alguien en la oficina A crea una cita para alguien en la oficina B que, idealmente, necesita poder ver sus detalles de inmediato (< 2 minutos). Dicho esto, cada registro generalmente solo se muta un máximo de 5 veces al día. Pero eso es solo lo que sospecho; En realidad no tengo ninguna estadística de uso sobre mí.

Answer 1

No puede usar la replicación asincrónica en ambas direcciones sin crear conflictos de replicación que son imposibles de resolver y romper.

Por lo tanto, su opción obvia es utilizar la división de lectura / escritura: haga que la aplicación realice lecturas no críticas desde un DB local (solo lectura) y dirija todas las escrituras al maestro. La desventaja de esto es que significará que no puede volver a leer de inmediato sus propios escritos.

La replicación MySQL no es perfecta y requiere cierto esfuerzo para configurarla y mantenerla continuamente; Debe comprobar con frecuencia que los datos son los mismos en los esclavos. Algunas consultas se replican incorrectamente; tendrás que entenderlos y evitarlos.

Answer 2

Uno de sus últimos recursos es, por supuesto, asegurarse de que todo el trabajo pesado se realice en subprocesos en segundo plano de modo que el hilo de la GUI nunca se bloquee.

Tener datos en tiempo real depende de los datos, echo de menos una descripción detallada, como la cantidad de datos de los que estamos hablando por solicitud (es decir, qué tan grandes son los objetos), qué tan rápido es su conexión a Internet (podría ser el cuello de botella?), ¿está bien configurado el servidor mysql y toda la infraestructura intermedia que controla? Qué tan estáticos / dinámicos son los datos, si los datos en tiempo real se mutan una vez al día o si mutan un millón de veces al día, es importante para la & Quot; solución & Quot;