3

分散キャッシュのシナリオでは、一般的に、キャッシュに格納されたモノリシック オブジェクトを使用または回避することをお勧めしますか?

私は EAV スキーマに裏打ちされたサービスを使用しているため、データベースからすべてのプライマリ レコードとそれぞれの属性コレクションを取得するときに、EAV によって課せられる認識されたパフォーマンスの低下を最小限に抑えるためにキャッシュを配置しています。サービスの起動時にキャッシュを準備します。

すべての製品について特に頻繁に電話をかけるわけではありません。クライアントは、ローカル キャッシュにオブジェクト マップを最初に入力した後で差分を呼び出します。その差分を実行するために、分散キャッシュは、任意の基準で実行されるデータベース内の個々のレコードへの変更を反映し、差分がクライアントによって要求されたときに変更を処理する必要があります。

最初に考えられたのは、リストまたはディクショナリを使用してレコードを分散キャッシュに格納することでした。コレクション全体を取得し、ローカルでメモリ内で操作または検索し、コレクション全体をキャッシュに戻します。しかし、後になって考えた結果、キャッシュに個々のレコードを入力するというアイデアが生まれました。それぞれのレコードは、キャッシュから個別に取得/更新できるようにキーが設定されています。これにより、すべてのデータを更新する場合、どの方法がより効率的かという疑問が生じました。

Windows Server AppFabric を使用しているため、BulkGet 操作を利用できます。ただし、一括更新の概念はないと思います。

分散キャッシュ オブジェクトのサイズに関する一般的な考え方はありますか? すべてのアイテムに対してより多くのリクエストがあった場合、ネットワーク帯域幅について懸念が生じますが、少なくとも今のところ、すべてのアイテムに対する需要は最小限に抑えられるはずです。

はい、それぞれの方法をテストしてプロファイリングしますが、ここで考慮すべき現在の考え方の範囲外に何かがあるかどうか疑問に思っています.

4

1 に答える 1

3

したがって、このシナリオでは、モノリシック キャッシュ オブジェクトが優先されるようです。データセンター内の太いパイプでは、シリアル化された最大 30 MB の製品データがネットワークを通過するのにほとんど時間はかかりません。を使用するDictionary<TKey, TValue>と、個々のアイテムを返品または更新するために、コレクション内の製品をすばやく見つけることができます。

何千もの個別のエンティティがすべて 1 MB をはるかに下回るキャッシュ内にあるため、一括操作には時間がかかりすぎます。オーバーヘッドが多すぎる、ネットワーク操作の遅延。

編集: 現在、エンティティとエンティティのモノリシック コレクションの両方を維持することを検討しています。

于 2011-04-22T18:03:20.933 に答える