0

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

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

この規模の何かは私にとって全く新しいものです。私は以前にこのようなことをしたコンサルタントを連れてくることを嫌がりませんが、最初に選択肢の良い全体像をつかみたいと思います。これはよくあることだと思います。

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

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

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

編集>データに関する詳細

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

リアルタイムの側面は、オフィスAの誰かがオフィスBの誰かの予定を作成するときに機能します。この人は、理想的には、すぐに（<2分）詳細を表示できる必要があります。とはいえ、各レコードは通常、1日に最大5回しか変更されません。しかし、それは私が疑うことだけです。私は実際に使用統計を持っていません。

4

2 に答える 2

1

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

リアルタイムデータを取得することはデータに依存します。リクエストごとに話しているデータの量（つまり、オブジェクトの大きさ）、インターネット接続の速度（ボトルネックになる可能性がありますか？）などの詳細な説明がありません。 ）、mysqlサーバーとその間のすべてのインフラストラクチャは適切に構成されていますか？リアルタイムデータが1日に1回変更されるか、1日に無数に変更される場合、データはどの程度静的/動的であるかが「ソリューション」にとって重要です。

于 2009-06-23T19:17:20.523 に答える
1

物事を解決したり壊したりすることが不可能なレプリケーションの競合を作成せずに、双方向で非同期レプリケーションを使用することはできません。

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

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

于 2009-06-23T22:08:07.557 に答える