Web サーバーのコンテストで:
( を使用して) 再クエリを回避するためにfind、 によって返されたカーソル参照を要求間で維持しようとすることができますfind。Cursorオブジェクトは、ソケット接続などを格納する複雑なオブジェクトです。このようなオブジェクトを保存して、後続の Web リクエストで再クエリを実行するのを避けるにはどうすればよいですか? 私は Node.js で作業していますが、どんなアドバイスも役に立ちます (言語に関係なく、レール、C#、Java、PHP)。
（私は永続的なセッションを使用しています）
Facebook と Twitter のストリーム機能は、データベースへの単純なクエリよりも複雑です。このようなシステムのアーキテクチャには、データを提供する 2 つの主要なバックエンド コンポーネント (低速と高速) が含まれる傾向があります。
1) 最初のバックエンド システムはデータベースであり、クエリを介してアクセスし、ストリーム (誰かの Twitter フィードまたは fb フィード) から結果のページを取得します。一番下にページを移動するか、[その他の結果] をクリックすると、ページ変数がインクリメントされ、現在のストリームのそのページの API に対してクエリが実行されます。
2) 2 つ目は、Websocket または API 呼び出しに対するページングを介してページにリアルタイムの更新を送信する、完全に独立したシステムです。これは、アーキテクチャの「高速」部分です。これはおそらくデータベースからではなく、どこかのキューからのものです。このキューから、ハンドラーはサブスクライバーであるページにデータを送信しています。
システムはこのように設計されています。これは、大幅にスケーリングするために、データベースがリアルタイムで更新されることに依存できないためです。それは大きなバッチで行われます。したがって、アーキテクチャの高速な部分でそのデータの非常に小さなサブセットを実行し、ユーザーが「高速」なバックエンドからデータを取得する方法が、最終的に「低速な」バックエンドでどのように見えるかを正確に理解することはできませんが、それは十分に近いです。
だから... 物語の教訓：
db カーソルを保持したくありません。1) リアルタイムで更新する必要がありますか? 2) もしそうなら、最初の呼び出しでほとんどのデータを取得し、2 回目の呼び出し/メカニズムで最新の状態に保つことができるようにシステムを設計するにはどうすればよいでしょうか。