まず、INSTANT があなたにとって何を意味するかを定義する必要があります。ある人にとっては、それは 90% の確率で 1 秒以内を意味します。他の人にとっては、平均して 10 ~ 20 秒のギャップがあれば満足です。さらに重要なことは、要件の意味を理解する必要があることです。言い換えれば、あなたのビジネスの待ち時間がほぼゼロであることは価値があるでしょうか? 要件が緩和されればされるほど、構築費用は安くなり、保守も容易になります。
近いうちに通知を行うと、リソースの計算とロックに関して非常にコストがかかる可能性があることを知っておく必要があります。更新すればするほど、より多くの Web ラウンドトリップが必要になります (この場合は最小であっても)。大量のリクエストを作成する可能性があるため、データを最新の状態に保つことは、データベースにとってコストがかかる可能性があり、そうでなければパフォーマンスの良いリクエストに影響を与える可能性があります。たとえば、1000 人のユーザーがログオンして Web サイトを実行している場合、1 秒あたり 1000 のデータベース要求が必要になる可能性があり (それが INSTANT の定義であると仮定すると)、適切に設計されていない場合、SQL Azure でスロットリング状態が発生する可能性があります。
私が過去に使用した同様の要件 (精度は秒単位ではなく、分単位でした) に対して使用したアプローチは、テーブルからすべてのレコードをローカル Web サイト キャッシュのメモリ内にロードすることでした。バックグラウンド スレッドが、すべてのレコードのメモリ内データを 1 回でロックおよび更新していました。これにより、データベース トラフィックを 1000 分の 1 に減らすことができました。これは、画面に表示されるデータがローカル キャッシュから取得され、キャッシュを更新するために (Web サーバーごとに) 単一のデータベース接続が必要だったためです。複数の Web サーバーがあり、データがすべての Web サーバーで 1 秒以内にまったく同じである必要があったため、すべての Web サーバーの要求を同期して毎分キャッシュを更新しました。これをまとめるには何時間もかかりましたが、非常にスケーラブルなシステムを構築することができました。
上記のテクニックはあなたの要件には合わないかもしれませんが、私が言いたいのは、新鮮なデータの必要性が高いほど、システムが新鮮さの要件によってあまり影響を受けないようにするために必要な設計/エンジニアリング作業が増えるということです.
お役に立てれば。