0

ちょっとした問題にぶつかりました。ストーリーは次のようになります。

複数のクライアント（現在23）で実行されるドキュメントアーカイブシステム（PHPで記述）があります。彼らのシステムでは、彼らは彼らの文書しか持っていません。毎晩、それらはすべてサイト上のマスターデータベース（中央サーバー）に「同期」する必要があります。中央サーバーから各MySQLデータベースにアクセスできるので、それらに接続しても問題ありません。

クライアントデータベースに接続し、同期列= '0000-00-00 00:00:00'（同期されなかったことを示すデフォルト）のテーブルからすべてのエントリを選択するスクリプトがあります。次に、各レコードを反復処理して中央サーバーに挿入し、クライアントデータベースレコードの同期時間をスクリプトが実行された時間に設定します。これは機能しますが、明らかに複数のクエリで大きなオーバーヘッドが発生し、問題に気づきました。

各クライアントは、1日に最大2000〜3000の奇数ドキュメントを生成できます。これらの大きな数では、時間がかかりすぎます（1秒/ 2ドキュメント）。

私の問題に対するより良い解決策はありますか？すべてが成功したかどうかを確認するためにログを作成する必要があるため、PHPスクリプトソリューションが望ましいです。

ありがとう

編集： 私の現在のプロセスは：

  1. 同期されていないデータをすべて選択します
  2. トランザクションを開始します
  3. 中央データベースサーバーにレコードを挿入します
  4. クライアントからドキュメントレコードを選択します
  5. ドキュメントを中央データベースサーバーに挿入します
  6. クライアントの同期列を更新します
  7. サーバーの同期列を更新します
  8. トランザクションをコミットする

これは、中央サーバーで実行されるスクリプトです。考えてみると、ステップ7を削除して、ステップ5の一部にすることができますが、処理時間を大幅に短縮することはできません。

4

4 に答える 4

1

auto_increment_incrementを使用して、すべてのサーバーですべてのIDを一意に保つことをお勧めします。次に、必要なのは、SELECT * FROM blah WHERE sync = '0000-00-00 00:00:00'を実行してから、挿入ステートメントを生成して実行することだけです。競合する主キーの競合解決に対処する必要はありません...

長いクエリ時間については、データのサイズを確認する必要があります。各レコードのサイズが大きい場合（数百kb以上）、時間がかかります...

1つのオプションは、子サーバーのテーブルごとにフェデレーションテーブルを作成することです。次に、マスターでSQLですべてを実行します。 INSERT INTO master_table SELECT * FROM child_1_table WHERE sync = '0000-00-00 00:00:00'...すべてのデータをPHPに取り込むことを回避できます。すべてがうまくいったことを確認するためにいくつかのチェックを実行することができます。また、すべてがPHPランドから実行されているため、ログに記録することもできます...

于 2010-08-19T11:04:35.057 に答える
0

基本的な方法は問題ないように聞こえますが、1回の操作に0.5秒かかると、途方もなく過剰になります。ネットワーク全体でどのくらいのデータを取得していますか。画像全体？手術で何か他のことをしていますか？同期列にインデックスはありますか？

データベース上の同期されていないデータのエクスポートを行うことで、わずかなメリットを得ることができます。

1) mark all records available for sync with a transaction id in a new column
2) extract all records flagged in first step into a flat file
3) copy the file across the network
4) load the data into the master DB
5) if successful notify the origin server
6) origin server then sets the sync time for all records flagged with that transaction id

これには、3つのスクリプトが必要になります。2つはオリジンサーバー（データの準備と送信用、1つは完了としてフラグを立てる）、もう1つはデータのポーリングと結果の通知用です。

ただし、（イメージ自体ではなく）イメージに関するメタデータのみを複製する場合、これはおそらくパフォーマンスに大きな影響を与えることはないでしょう。

C。

于 2010-08-19T13:13:02.570 に答える
0

PHPベースのソリューションを好むことは知っていますが、MicrosoftSyncFrameworkをチェックすることをお勧めします-

http://msdn.microsoft.com/en-in/sync/default(en-us).aspx

これには、同期モジュールを.netで記述する必要がありますが、同期ロジックと例外処理（ネットワーク障害、同期の競合など）の点で大きな利点があり、時間を短縮できます。

フレームワークは、.net用のデータベースコネクタがある限り、SQL以外のサーバーデータベースも処理します。Mysqlは非常に簡単にサポートされるはずです-次のリンクからサンプルを取得してください-

http://code.msdn.microsoft.com/sync/Release/ProjectReleases.aspx?ReleaseId=4835

同じことをmysqlに適応させます。

于 2010-08-19T14:27:14.373 に答える
0

同期フレームワークを使用できない場合は、別の可能性があります-

一日の終わりではなく、一日を通して負荷を分散することは可能ですか？たとえば、10個の新しいドキュメントが届くたび、または10個の編集が行われるたびに、同期をトリガーしますか？（これは、同期がクライアント側から開始された場合に実行できます）。

同期ロジックをサーバー側に移行する場合は、クライアントが同期する必要があるときはいつでも、メッセージングキューを使用してクライアントからサーバーに通知を送信することを検討できます。その後、サーバーはデータをプルできます。これには、社内のサービスバスまたはazure appfabric /AmazonSQSなどのオンデマンドプラットフォームを使用できます。

于 2010-08-20T07:48:09.627 に答える