このような収穫ソリューションの場合、多段階のアプローチをお勧めします。 Redisはリアルタイムコミュニケーションが得意です 。 Redisは、メモリ内のキー/値ストアとして設計されており、メモリデータベースであるという非常に優れた利点をいくつか継承しています。O（1）リスト操作です。サーバーで使用するRAMがある限り、Redisはリストの最後へのプッシュを遅くしません。これは、このような極端な速度でアイテムを挿入する必要がある場合に適しています。残念ながら、Redisは、使用しているRAMの量を超えるデータセットを操作することはできません（書き込みのみ） ディスクへの読み取りは、サーバーを再起動するため、またはシステムがクラッシュした場合に行われます）。スケーリングはあなたが行う必要があります。 およびアプリケーション 。 （一般的な方法は、キーを多数のサーバーに分散することです。これは、一部のRedisドライバー、特にRuby on Rails用のドライバーによって実装されます。）Redisは、単純なパブリッシュ/サブスクライブメッセージングもサポートしており、これも便利な場合があります。
>このシナリオでは、Redisは「ステージ1」です。特定の種類のイベントごとに、Redisで一意の名前のリストを作成します。たとえば、「ページ表示」と「リンククリック」があります。簡単にするために、各リストのデータが同じ構造であることを確認します。クリックされたリンクにはユーザートークン、リンク名、URLが含まれる場合がありますが、表示されるページにはユーザートークンとURLのみが含まれる場合があります。あなたの最初の懸念は、それが起こったという事実と、絶対に必要なものを取得することです。 必要なデータがプッシュされます。
次に、リストの最後からアイテムを取り出して渡すように依頼することで、この必死に挿入された情報をRedisの手から取り除く簡単な処理ワーカーがいます。ワーカーは、データを適切にファイリングし、より永続的なストレージサイトに渡すために必要な調整/重複排除/IDルックアップを行うことができます。 Redisのメモリ負荷に耐えられるようにするために必要な数のこれらのワーカーを起動します。ワーカーは、Redisドライバー（現在ほとんどのWeb言語で使用可能）と目的のストレージ（SQL、Mongoなど）があれば、任意の形式（Node.js、C＃、Javaなど）で記述できます。 ）
MongoDBはドキュメントストレージが得意です 。 Redisとは異なり、RAMより大きいデータベースを処理でき、それ自体でシャーディング/レプリケーションをサポートします。 SQLベースのオプションに対するMongoDBの利点は、事前に定義されたスキーマを用意する必要がないことです。データの保存方法はいつでも自由に変更できます。
ただし、処理用のデータを保持する「ステップ1」フェーズにはRedisまたはMongoを提案し、後処理されたデータを格納するために従来のSQLセットアップ（おそらくPostgresまたはMSSQL）を使用することをお勧めします。クライアントの行動を追跡することは、私にはリレーショナルデータのように聞こえます。「このページを閲覧するすべての人を表示する」、「この人がこの日に閲覧したページ数」、「合計で最も多くの視聴者があった日は何日ですか？」 "。分析目的でさらに複雑な結合やクエリが発生する可能性があり、成熟したSQLソリューションではこのフィルタリングの多くを実行できます。 NoSQL（具体的にはMongoまたはRedis）は、さまざまなデータセット間で結合や複雑なクエリを実行できません。