1

私のプロジェクトのシナリオを説明しましょう。

システム アーキテクチャには、多くのノード、少数の中間サーバー、および 1 つのメイン サーバーがあります。

問題の説明:

シナリオを単純化するために、中間サーバーについては説明しません。一般的なシナリオでは、システムに n 個のノード (ノード #1、ノード #2、...、ノード #n) と 1 つのサーバー (サーバー #1) があるとします。ローカル入力の大部分はノード レベルで行われ、主要な構成はサーバー レベルで行われます。これで、すべてのノードが自分のデータをサーバーに同期 (アップロード) し、同時に他のノードのデータをサーバーからダウンロードする必要があります。したがって、同期プロセスの後、すべてのノードとサーバーのデータは同じになります。同期時に任意のノードがオフラインになる可能性があるため、このノードはオンラインのときにサーバーからデータをアップロードおよびダウンロードします。

私のチームの解決策:

私のチームは、Microsoft の同期フレームワーク 2.1 を使用することを提案しました。概念実証用のサンプル アプリケーションを作成しました。サンプルには 1 つのサーバーと 1 つのノードがあり、ノード #2 から来たかのようにサーバーにデータを入力し、それをノード #1 と同期すると、同期と競合が適切に解決されました。ここで、主キーと競合はすでに処理済みです。

これまでに見られた問題は次のとおりです。

  1. サーバーとすべてのノード間の同期が成功したら、追跡テーブルのエントリを削除/空にする必要があります。そうしないと、テーブルのサイズが指数関数的に大きくなります。同期が成功すると、すべてのノードが追跡テーブルをクリアします。サーバーは、すべてのノードが同期している場合にのみ追跡テーブルをクリアし、それ以外の場合はテーブルを保持します。サーバーにトラッキング テーブル エントリがあり、ノードがテーブルをクリアすると、同期フレームワークはすべてのノードとの同期を再度試行し、これによりエントリが重複します。
4

2 に答える 2

1

追跡テーブルは変更の追跡に使用されます。これをクリアすると、Sync Fx は最後の同期以降に何が変更されたかをどのように認識しますか?

サイズを小さくしたい場合は、より低い保存期間を指定して定期的なメタデータのクリーンアップを実行できます。

于 2013-02-22T08:38:31.813 に答える
0

追跡データを消去することはできません。JuneTすでに述べたように。

各レコードには追跡レコードが必要です。したがって、追跡レコードの ID は、対応するレコードの ID と同じです。

データ量が多いのは事実です。私たちの環境には 200 を超えるテーブルがあります。これらのテーブルには、対応する追跡テーブルが含まれています。したがって、テーブルの総数は 400 を超えます。

10 GB のデータベースでは、追跡データは約 3 GB (30%) です。この比率はもちろんデータ モデルごとに異なりますが、追跡データのオーバーヘッドを示します。

于 2013-02-22T08:59:23.107 に答える