2009-07-23 5 views
4

私はwinformアプリケーションを開発しています。このアプリケーションは、米国および海外のグループで使用され、古いテクノロジーで構築された既存のアプリケーションを置き換えます。半静的データを新鮮に保つための戦略

海外の古いアプリのパフォーマンスは、米国のデータベースサーバーへのコールバックが非常に遅いため、できるだけ多くのものをクライアントにキャッシュしたいと考えています。

頻繁に変更されないもののデータをキャッシュする最良の方法はありますか?データを各ロードで完全に取り込むことなく、データが古くならないようにするにはどうすればよいですか?

答えて

2

クイックソリューションは、データのチェックサムを作成することで、クライアントは最初にそれを求めます。それが同じであれば、それ以上のデータは必要なく、その部分は最新です。データが変更されると、合計が変更され、クライアントは新しいデータと一緒に新しい合計を取得します。

転送されるたびに、すべてのデータがすべてのデータよりも少なくなるようにする必要があります。

+0

これは動作しません。チェックサムが変更された場合、データは異なりますが、データが変更された場合、チェックサムは変更されません。ポスターはチェックサムではなく、データがいつ変化するかを知る必要があります。 –

0

リビジョンIDを報告する可能性のある特定のオブジェクトセットに対してウォーターマークまたはその他のインジケータを持つ可能性のあるSQLテーブル関数またはビューなどを軽く保つことができます。変更しない場合は0、変更した場合は1、更新を必要とするオブジェクトのみ。

1

データがほとんど変更されない場合は、SQLトリガーを使用して「更新済み」フラグに相当する値を設定し、他のクライアントとサーバー間の通信でそのフラグをピギーバックすることができます。すべての準静的テーブルと1つのウォッチドッグテーブルに挿入/更新/削除トリガを追加する場合は、適切に行ってください。

0

私は最良の方法は、データを追跡するために別のテーブルを作成することだと思います。テーブルには、テーブル名のリストと、そのテーブルが最後に変更された時刻が含まれます。次に、そのテーブルで挿入/更新/削除が発生したときにフィールドを更新するトリガーを作成します。クライアントがデータをチェックしたいときは、データを取得してそのテーブルから日付を取得して保存します。次にクライアントがデータを必要とするときは、そのテーブル内のテーブル名を探し、日付を取得して、それをあなたのものと比較してください。データベースの値が大きい場合は、サーバーからフェッチする時間です。

このアプローチの唯一の欠点は、変更が特定のSQLクエリに影響を与えない場合でも、テーブル内のすべての変更に対して、データベースにアクセスしてすべてのデータを再度取得することです。データが頻繁に変更されない場合、これはあまり重要ではありません。

0

アプリケーション自体がデータの更新があるかどうかを知ることができる場合は、要求遅延のスケーリングが最も簡単な方法です。アプリケーションが起動すると、データを要求し、最低限のリフレッシュ遅延後に再度要求します。データが変更されていない場合は、要求間のリフレッシュ遅延を2倍にします。変化が検出されない場合(おそらく最大限の制約がある場合)、遅延を倍増させ続けることになります。これはサーバーの負荷を軽減するための一般的なパターンであり、スキーマやWebサービスを変更せずにクライアント側を実装するのは非常に簡単です。

1

データセットの外観はわかりませんが、データセットに対してSHA256などのハッシュを計算し、そのハッシュをクライアントとサーバーに格納する方法についてはわかりません。次に、サーバーからフェッチする前に、ハッシュのみをフェッチし、クライアント上のローカルハッシュと比較します。ハッシュが一致する場合は、ローカルに格納されているデータセットを使用します。

+0

申し訳ありませんが、上記のluvatが同様の解決策を見ただけです。私はちょうど追加することができます:あなたは、そのためにハッシュと一緒に使用するSQLクエリを格納するあなたのサーバー上のテーブルを持つことができます。したがって、リクエストを行うときは、最初にクエリ文字列のハッシュを計算してから、クエリ文字列ハッシュに関連付けられたデータハッシュをサーバーに問い合わせます –

0

キャッシュするデータベースまたはテーブルが変更されるたびに、タイムスタンプを保持する必要があります。関連するテーブルがある場合や、同様の時間枠で変更されるテーブルがある場合は、それらを同じタイムスタンプを共有するファミリにグループ化できます。

データが必要なときは、まずタイムスタンプを尋ねる必要があります。変更されていない場合は、キャッシュされたデータを使用します。変更されている場合は、新しいデータを要求し、キャッシュを更新し、すべての祖先データのタイムスタンプを再帰的に尋ねます。

衝突が発生する可能性があるため、チェックサムは機能しません。衝突をチェックするには、新しいデータを求めなければなりません。古い/変更されたフラグは、データがいつ変更されたか分からないために機能しません。以前のタイムスタンプの前にあった可能性があります。変更ごとに常に増加し、減少しないバージョンIDも機能します。

RESTful Webサービスを使用している場合、GET HEADコードはタイムスタンプを含むHTTPヘッダーのみを返します。 Webサービスにタイムスタンプが含まれていない場合は、タイムスタンプを返す新しいタグを定義する必要があります。

関連する問題