4

2つの主な理由から、Azureにキャッシュを実装する必要があります。

  1. 反復的なデータアクセスを高速化
  2. データベースへのストレスを軽減します

キャッシュする予定のデータの特徴は次のとおりです。

  1. 比較的小さい（1〜100 kb）
  2. 各顧客に固有
  3. プライベートではありませんが、ランダムな人がキャッシュ全体をナビゲートすることは望んでいません
  4. XMLまたはJSON
  5. C＃によって消費されます（つまり、htmlで直接リンクされていません）
  6. ほとんどの週はデータが変更されませんが、一部の日はデータが数回変更される可能性があります

この特定の目的では、テーブルストレージはBlobストレージよりも優れているように見え（画像、CSS、JavaScript用にBlobストレージを実装しただけです）、WindowsAzureキャッシングはWindowsAzure共有キャッシュよりも優れているように見えます（おそらくほとんどの場合、共有キャッシングはほとんどレガシーです）この時点で の機能）。

両方のプログラミングAPIは単純に見えます。私たちがクラウドサイトに支払うものと比較すると、それぞれのコストはごくわずかであるように思われます。

これまでのところ、Azure Cachingの長所と短所であると認識しているため、テーブルストレージに傾倒しています。古い.Netの人として、私たちはNoSqlスタイルのソリューションよりもインメモリキャッシュに精通しています。

Windows Azureキャッシングの問題：

  1. VMが別のサーバーに移動された場合（負荷分散またはその他の理由でMicrosoftによって）、メモリ内キャッシュはそのまま移動されますか？
  2. 変更をクラウドに公開するたびに、既存のメモリ内キャッシュが消去されると推測しています。
  3. ユーザーが変更を加えたときにキャッシュデータに変更を加えることはめったにありませんが、数秒以内に複数の更新を行う可能性があり、特にトラフィックが増加している場合に、Webロールを実行している複数のノードにまたがるキャッシュでこれがどのように機能するかはわかりません。（これはおそらくテーブルストレージにも関係します！）
  4. テーブルストレージは、デバッグが容易になるように見えます

WindowsAzureキャッシングの利点

  1. やや速い
4

1 に答える 1

5

インメモリキャッシングに精通していることは、WindowsAzureにキャッシングを実装するために理解する必要のあるモデルです。「NoSqlスタイル」はキャッシュではなく、ストレージです。したがって、テーブルストレージは、キャッシュを置き換えるのではなく、SQLを置き換えます。テーブルストレージは、永続的で信頼性の高いストレージ用です。メモリ内キャッシュには存在しない、永続性のすべての遅延とその他の欠点があります。

キャッシュへの書き込みは常にセカンダリです。ユーザーが「キャッシュされたデータに変更を加える」と、常にデータをディスク（SQLなど）に書き込み、次に同じデータをキャッシュに書き出すことになります。これは、データが手元にあるためです。 （ただし、書き込まれたデータへの二次的な影響は、キャッシュされたアイテムを無効にするか、再読み取りする必要があることを意味する場合があります）。

データは他の場所に保存されているため、マシンのリサイクル時にデータを消去することはそれほど問題にはなりません。キャッシュからのすべての読み取りの後には、「見つからない場合はデータベースから読み取る」という種類のステートメントを続ける必要があります。ロールが必要になることがわかっているアイテムの事前入力を開始したときに、キャッシュをウォームアップできます。

Azureでのキャッシュはノード全体に分散され、既存のアイテムを更新すると、それが存在するノードで常に更新されます。クイックアップデートは、あなたが思っているよりも問題が少ないかもしれません。

インメモリキャッシングには、Windows Azureキャッシングを使用し（共有キャッシングがレガシーであることについては正しいです）、ニーズに応じて、memcachedなどの他のキャッシングテクノロジーを検討してください。キャッシングとテーブルストレージは比較できません。テーブルストレージは長期的な永続性のためのものです。キャッシュを行うためにテーブルストレージを不必要にハッキングしないでください。テーブルストレージを一時的にすると、有効期限や無効化など、自分で心配する必要のあるものがたくさん作成されます。

于 2013-03-12T16:10:53.390 に答える