Back-End-db-Setup für eine App mit geographisch unterschiedlichen Benutzern

Question

Das im Hause entwickelte Software, wo ich eine Verbindung zu einem MySQL-Server hier in unserem Büro über unseren DevExpress ORM (XPO) direkt arbeiten. Die Leistung ist groß.

Wir öffnen ein weiteres Büro ... Cross-Country. Leistung: nicht so groß. Voraussetzung ist, dass die Software in den beiden Büros so reagieren, wie es in diesem Büro und dass die Daten von einem Büro zur Verfügung stehen, um die anderen ‚in Echtzeit‘ ist.

Etwas von dieser Skala ist völlig neu für mich. Ich bin nicht abgeneigt, einen Berater zu bringen, die vor so etwas getan haben, aber ich möchte zuerst ein gutes Bild von den Möglichkeiten bekommen. Ich bin sicher, dass dies eine gemeinsame Situation ist.

Ist die Replikation eine gute Idee? Ist es schnell genug? stabil genug?

Gibt es Entwicklungsmuster, die diese Art von Situation angehen, wenn die Replikation nicht funktionieren?

Heck, ich bin nicht einmal sicher, wie dies zu markieren, so dass, wenn jemand weiß besser ... bitte, fühlen sich frei, neu zu Tag

EDIT> Details über die Daten

Ich denke, im Vergleich zu einigen Enterprise-Software, sind wir nicht viele Daten zu bewegen. Die Software verwaltet Kundenkonten, Termine usw. und jeder Benutzer arbeitet auf ca. 2-5 getrennte Konten / Minute (50 Benutzer zur Zeit, 200-400 nach geplanter Expansion), Aktualisieren von Daten jedes Mal.

Der Echtzeit-Aspekt kommt ins Spiel, wenn jemand im Büro A einen Termin für jemanden im Büro B erzeugt, die im Idealfall in die Lage sein muss, seine Angaben in der Nähe sofort (<2 min) anzuzeigen. Das heißt, jeder Datensatz in der Regel nur maximal 5 mal pro Tag mutiert wird. Aber das ist nur das, was ich vermute; Ich eigentlich keine Nutzungsstatistiken auf mich haben.

Answer 1

Sie können nicht asynchrone Replikation in beiden Richtungen verwenden, ohne Replikation Konflikte zu schaffen, die unmöglich zu lösen und brechen Dinge.

Daher Ihre offensichtliche Wahl ist / Schreib-Splitting verwenden liest - hat die Anwendung nicht kritische tun liest aus einer (Read-only) lokalen DB und direkt alle Schreibvorgänge an den Master. Der Nachteil dabei ist, dass es bedeutet, dass Sie nicht sofort Ihre eigenen Schreib lesen zurück.

MySQL-Replikation ist nicht perfekt und erfordert einigen Aufwand einzurichten und eine kontinuierliche Überwachung zu halten; Sie müssen häufig die Daten überprüfen, die gleichen in den Slaves sind. Einige Abfragen erhalten falsch repliziert; Sie werden sie verstehen müssen, und solche zu vermeiden.

Answer 2

Einer von euch sind letzte Resorts natürlich ist sicher zu stellen, dass alle schwere Arbeit im Hintergrund Fäden durchgeführt wird, so dass der GUI-Thread wird nie blockiert.

Mit Echtzeit-Daten auf den Daten abhängen, ich vermisse eine detaillierte Beschreibung, wie, wie viele Daten sprechen wir pro Anfrage (dh wie groß die Objekte), wie schnell Sie Internet-Verbindung sind (das könnten Halsflasche?), ist der mySQL-Server und die gesamte Infrastruktur in zwischen, dass Sie gut konfiguriert kontrollieren? Wie statisch / dynamisch sind die Daten, wenn die Daten in Echtzeit einmal täglich mutiert werden oder es wird eine Unmenge mal am Tag mutiert ist wichtig für die „Lösung“