0

いくつかのファイルに基づいて重い処理を行うソフトウェアがあります。その過程で SQL Server のいくつかのテーブルにクエリを実行する必要があり、これにより DB とアプリケーションのパフォーマンスが低下しています。(他のアプリケーションは同じテーブルを使用します)。

クエリとコードを最適化した後、結果は改善されましたが、十分ではありませんでした。調査の結果、いくつかのクエリ結果をキャッシュするという解決策にたどり着きました。私の考えは、処理中のファイルが必要とする 1 つの特定のテーブル (オーバーヘッドとして識別される) 行をキャッシュすることです。

私は AppCache Fabric を使用することを考えていました (私は MS スタックを使用しています)、いくつかのテストを行い、小さなオブジェクトに大量のメモリを使用しました (appcache サービスは、オブジェクトなしで最大 350MB の RAM を使用しています)。しかし、これらの結果テーブルでいくつかのクエリを作成する必要があります ( lastname、ssn、birthdateなどの検索など)。

2 番目のオプションは、キャッシュ ストアとしての MongoDb です。私はこれについて調査しましたが、私が読んだほとんどの人は memcached または Redis の使用を推奨していますが、私は Windows サーバーを使用しており、公式にはサポートされていません。

この場合、キャッシュストアとしてmongoを使用するのは良いアプローチですか? または、AppFabric キャッシング + タグ検索の方が優れていますか?

4

2 に答える 2

1

ボトルネックについて十分に把握していないため、何が優れているかを判断するのは困難です。多くは、議論しているデータの品質に依存しています。データが非常に静的で、頻繁に呼び出されるわけではなく、データ セットのコンパイルに時間がかかる場合は、マテリアライズド ビューを使用することをお勧めします。このデータが頻繁に呼び出される場合は、一部のサーバー (アプリ ファブリックなど) にキャッシュする方が適切です。多くの技術と可能性があります。しかし、実際にはネットワーク トラフィック、需要、サイズなどを考慮する必要があります。すべての詳細を知らずに、ここでこれに答えるのは困難です。あなたは正しい道を進んでいるように見えますが、必要なのはパラメータ化されたクエリだけかもしれません。わかりにくい。しかし、あなたが投稿した名簿に具体化されたビューを追加します。

于 2013-04-28T20:23:53.233 に答える
0

あなたへの私の質問は、あなたのアプリケーションの長期的な目標または見積もりは何ですか? これが経験する最大の負荷である場合は、DB を調整するか、MVL を使用することが答えになります。しかし、これに対する長期的な解決策は分散キャッシングであり、あなたはすでにその方針に沿って考えています。データ要件は、私たちが「参照データ」または「ルックアップ データ」と呼んでいたものであり、限られた DB リソースで複数のルックアップを実行すると、パフォーマンスの問題が発生し、DB がパフォーマンスのボトルネックになります。

したがって、すでに考えている解決策は、データベースにアクセスする必要なく、この「参照」データをキャッシュにキャッシュすると同時に、キャッシュをデータベースと同期させておくことです。

Appfabric については、あなたが言及したのと同じサポートの問題があるため、あまり確信が持てません。ご予算はいかがですか？NCacheのようなキャッシング ソリューションへの支出について考えてみませんか?

于 2013-05-17T12:46:23.597 に答える