地理的に多様なユーザーがいるアプリのバックエンドdbセットアップ

Question

社内で開発したソフトウェアは、devexpress orm（XPO）を介して、ここのオフィスのmysqlサーバーに直接接続します。パフォーマンスは素晴らしいです。

別のオフィスを開設しています...クロスカントリー。パフォーマンス：それほど良くありません。要件は、ソフトウェアがこのオフィスと同じように両方のオフィスで応答し、一方のオフィスからのデータがもう一方のオフィスで「リアルタイムで」利用できることです。

この規模の何かは私にとって全く新しいものです。私は以前にこのようなことをしたコンサルタントを連れてくることを嫌がりませんが、最初に選択肢の良い写真を撮りたいです。これは一般的な状況であると確信しています。

レプリケーションは良いアイデアですか？十分に速いですか？十分に安定していますか

レプリケーションが機能しない場合、この種の状況に対処する開発パターンはありますか？

まあ、これにタグを付ける方法すらわからないので、誰かがもっとよく知っていたら...どうか、お気軽にタグを付け直してください

編集<！> gt;データの詳細

一部のエンタープライズソフトウェアと比較して、大量のデータを移動しているのではないでしょう。ソフトウェアは顧客のアカウント、アポイントメントなどを管理し、各ユーザーは毎分約2〜5個の個別アカウント（現在50ユーザー、計画拡張後200〜400）で作業し、毎回データを更新します。

リアルタイムの側面は、オフィスAの誰かが、理想的にはすぐに（<！> lt; 2分）詳細を表示できるようにする必要があるオフィスBの誰かにアポイントメントを作成すると有効になります。ただし、通常、各レコードは1日に最大5回だけ変更されます。しかし、それは私が疑うことだけです。実際に使用統計はありません。

Answer 1

レプリケーションの競合を作成せずに、双方向で非同期レプリケーションを使用することはできません。

したがって、明らかな選択は、読み取り/書き込み分割を使用することです。アプリケーションに（読み取り専用）ローカルDBからの重要でない読み取りを実行させ、すべての書き込みをマスターに転送します。これの欠点は、自分の書き込みをすぐに読み戻せないことを意味することです。

MySQLレプリケーションは完全ではなく、設定するための努力と維持するための継続的な監視が必要です。スレーブでデータが同じであることを頻繁に確認する必要があります。一部のクエリは誤って複製されます。それらを理解して回避する必要があります。

Answer 2

もちろん、最後の手段の1つは、GUIスレッドがブロックされないように、すべてのヘビーデューティー作業がバックグラウンドスレッドで行われるようにすることです。

リアルタイムデータがデータに依存しているため、リクエストごとに話しているデータの量（オブジェクトの大きさ）、インターネット接続の速度（詳細ボトルネック？）、あなたが制御するmysqlサーバーとその間のすべてのインフラストラクチャは適切に構成されていますか？ <！> quot; solution <！> quot;

では、リアルタイムデータが1日に1回変異する場合、または1日に何億回も変異する場合、データがどのように静的/動的であるかが重要です