configuration db backend pour une application avec des utilisateurs géographiquement divers

Question

Le logiciel développé en interne sur lequel je travaille se connecte directement à un serveur mysql ici, dans nos bureaux, via notre outil de développement (XPO). La performance est excellente.

Nous ouvrons un autre bureau ... cross-country. Performance: pas terrible. Il est impératif que le logiciel soit aussi réactif dans les deux bureaux que dans ce bureau et que les données d’un bureau soient disponibles pour l’autre "en temps réel".

Quelque chose de cette ampleur est totalement nouveau pour moi. Je ne suis pas opposé à faire appel à un consultant qui a déjà agi de la sorte, mais j'aimerais d'abord avoir une bonne idée des options. Je suis sûr que c'est une situation courante.

La réplication est-elle une bonne idée? Est-ce assez rapide? assez stable?

Existe-t-il des modèles de développement qui résolvent ce type de situation si la réplication ne fonctionne pas?

Heck, je ne sais même pas comment marquer cela, alors si quelqu'un sait mieux ... s'il vous plaît, n'hésitez pas à changer de tag

EDIT > Détails sur les données

Je suppose que, contrairement à certains logiciels d’entreprise, nous ne transférons pas beaucoup de données. Le logiciel gère les comptes clients, les rendez-vous, etc. et chaque utilisateur travaille sur environ 2 à 5 comptes distincts / minute (50 utilisateurs actuellement, 200 à 400 après l’extension prévue), en mettant à jour les données à chaque fois.

L’aspect temps réel entre en jeu lorsqu’un membre du bureau A crée un rendez-vous pour un membre du bureau B qui, idéalement, doit pouvoir afficher ses détails de manière immédiate (< 2 min). Cela dit, chaque enregistrement ne subit généralement une mutation que 5 fois par jour au maximum. Mais ce n'est que ce que je soupçonne. Je n'ai pas de statistiques d'utilisation sur moi.

Answer 1

Vous ne pouvez pas utiliser la réplication asynchrone dans les deux sens sans créer de conflits de réplication impossibles à résoudre et qui fassent des dégâts.

Par conséquent, votre choix évident est d'utiliser le fractionnement lecture / écriture: demandez à l'application de lire des lectures non critiques à partir d'une base de données locale (en lecture seule) et de diriger toutes les écritures vers le maître. L’inconvénient est que vous ne pourrez pas lire immédiatement vos propres écrits.

La réplication MySQL n’est pas parfaite et nécessite quelques efforts de configuration et une surveillance continue à maintenir; vous devez vérifier fréquemment que les données sont les mêmes dans les esclaves. Certaines requêtes ne sont pas correctement répliquées. vous devez les comprendre et les éviter.

Answer 2

L’un de vos derniers recours consiste bien entendu à vous assurer que tous les travaux pénibles sont effectués dans les threads d’arrière-plan, de sorte que le thread d’interface graphique ne soit jamais bloqué.

Comme les données en temps réel dépendent des données, il me manque une description détaillée, telle que la quantité de données dont nous parlons par demande (c'est-à-dire la taille des objets), la vitesse de votre connexion Internet (peut-être le goulot de bouteille?), le serveur mysql et toute l’infrastructure située entre vous que vous contrôlez sont-ils bien configurés? Quelle est l’état statique / dynamique des données, si les données en temps réel sont mutées une fois par jour ou plusieurs fois par jour, il est important pour la & "Solution &";