SQLテーブルからのキャッシュの最適なアプローチ？

Question

特別なニーズとカスタマイズを加えて、フォーラムを一から開発したいと考えています。

私は集中的に使用するためのフォーラムを準備し、ユーザー投稿数とユーザー回答数などをキャッシュする方法を考えています。

テーブルが3つしかない場合、tblForum、tblForumTopics、tblForumReplies、キャッシュの最適なアプローチは何ですか？ユーザーのトピックと返信はどれくらいですか？

単純なシナリオを考えてみましょう。ユーザーはリンクを押してReplies.aspx？id = x &ページ= yページを開いて返信を開始します。 HTTPリクエストでは、サーバーはそのページのすべての返信を取得するSQLコマンドを実行します。「返信された各ユーザーのユーザー返信数を調べるためにtblForumRepliesで内部的に参加する」

select 
    tblForumReplies.*, 
    tblFR.TotalReplies 
from 
    tblForumReplies 
    inner join 
    (
     select IdRepliedBy, count(*) as TotalReplies 
     from tblForumReplies 
     group by IdRepliedBy 
    ) as tblFR 
    on tblFR.IdRepliedBy = tblForumReplies.IdRepliedBy 

残念ながら、このアプローチは非常にCPUに負荷をかけている、と私はテーブルのカウントのようなものをキャッシュする方法のアイデアを見てみたいです。

挿入/削除時に各ユーザーの返信をカウントし、別のフィールドに格納する場合は、手動でデータを変更して同期する方法。 SQLからの返信を手動で削除するとします。

Answer 1

これらは私が考えているはずだ3つのアプローチです。 SQL Serverがいかにうまく機能するかを過小評価するかもしれません。ジョインを正しく行うと、そのスレッドに含まれるすべてのユーザーの数をすべて取得することができます。これを1人のユーザーにつき1つのクエリと考えると、それは間違っています。

2）キャッシュしないでください。ユーザカウントをユーザテーブルに冗長的に格納します。投稿が挿入または削除されるたびにユーザ行を更新します。

3）数千人でも数百万人ではなく、何千ものユーザーがいる場合、Web層のメモリにASP.NETとアプリケーションキャッシュをキャッシュすることが現実的かもしれません。

Answer 2

私はこれが確実に必要になるまで、キャッシングを気にしません。私のexpirienceから、これはキャッシュを必要とする場所を予測する方法ではありません。反復的なアプローチを試してみましょう。そして、キャッシュキャッシングを実装してから、統計を取得して、正しいキャッシングを実装してください（コンテンツ、データ、集約、分散など多くの種類があります）。

ところで、私はあなたのクエリがCPUを消費しているとは思わない。 SQLサーバーはそれを最適化し、COUNT（*）はティックで実行されます...

Answer 3

tbl接頭辞suck - 同じくらいReplies.aspx?id=x&page=yがURIsします。 ASP.NET MVCを検討するか、単にルーティングする部分です。

第2に、時期尚早に最適化しないでください。ただし、実際に必要な場合は、TotalReplies列をForumTopicsテーブルに追加し、DAL/BLを使用してこのフィールドを最新の状態に保つか（それらを再同期するスケジュールされたタスクを使用する）、またはトリガーを使用します。

1）たぶん、SQL Serverのパフォーマンスは、あなたがキャッシュする必要がないことを十分になります。

Answer 4

返信ごとに、TotalRepliesとTotalDirectRepliesを保存する必要があります。こうすることで、ツリーのような返信構造をサポートし、毎回カウントする必要はなく、階層全体でカウントを更新し続けることができます。