4

私が取り組んでいるプロジェクトは、データベースからオブジェクトとオブジェクトのコレクションを取得する方法に関する設計上のジレンマに直面しています。*すべて*のオブジェクトをそのプロパティとともにデータベースからメモリにバッファリングすると便利な場合もあれば、オブジェクト ID を設定してそのプロパティをオンデマンドでクエリするだけで便利な場合もあります (すべてのプロパティを取得するには、オブジェクトごとに 1 db を呼び出します)。また、多くの場合、コレクションは、オブジェクトをメモリにバッファリングすることと、オンデマンド アクセスのために最小限の情報で初期化されることの両方をサポートする必要があります。結局のところ、すべてをメモリにバッファリングできるわけではなく、すべてをオンデマンドで読み取ることもできません。これは、ユビキタス メモリと IO の問題です。

誰かが同じ問題に直面しなければなりませんでしたか？デザインにどのような影響を与えましたか? 厳しい教訓は何ですか？他に考えや推奨事項はありますか？

編集:私のプロジェクトは、Web アプリケーション、Web サービス、およびデスクトップ アプリケーションによって消費されるビジネス レイヤー dll の典型的な例です。デスクトップ アプリケーションで製品のリストが要求され、製品名だけが表示される場合、すべての製品を表示するために次の一連の手順を使用しても問題ありません (データベースに 100 万の製品があるとします)。
1. 1 回の db 呼び出しすべての製品名を取得するには
2. ユーザーが製品をクリックして詳細を表示した場合 (オンデマンド アクセス)、すべての製品情報を取得するための 1 回の db 呼び出し

ただし、この同じ API を Web サービスで使用して、すべての製品を詳細とともに表示すると、ネットワーク トラフィックが頻繁に発生します。この場合のより良いシーケンスは次のようになります
:

4

2 に答える 2

6

データが変更される頻度によって異なります。静的およびほぼ静的なデータをキャッシュするのが一般的です (通常は、キャッシュの有効期限ウィンドウを使用します)。

データベースはすでにデータをキャッシュするように設計されているため、ネットワーク I/O がボトルネックにならない場合は、データベースに得意なことをさせてください。

利用可能なキャッシング技術のいくつかを見たことがありますか?

于 2011-02-08T02:30:49.733 に答える
2

これは人気のある立場ではありませんが、絶対に必要な場合、または「インターネット規模」が必要になることがすぐにわかっている場合を除き、すべてのキャッシュを避けてください。データベースの上にレイヤードキャッシュをスケールアウトしようとしましたか? キャッシュを介してライトスルーし、読み取りのみを行いますか、それとも LRU オブジェクトが変更を書き込むのを待ちますか? 別のアプリまたは Web サービス層が DB の上にあり、一貫性のない読み取りが行われるとどうなりますか?

最近のほとんどのデータベースには既にキャッシュがあり、おそらくあなたよりもうまく実装できます。何かが必要になるたびにDBワイヤをヒットするかどうかを判断するだけです. ほとんどの場合、DB は問題なく動作し、一貫性を維持できます。BASE と CAP の理論は、話したり想像したりするのが楽しくて楽しいものですが、古き良きデータベースにアクセスするだけでは、市場投入コストに勝てない場合があります。ストレス テストを行ってホットスポットを特定し、必要に応じて控えめにキャッシュを実装します。

于 2011-02-08T02:46:11.030 に答える