フィルターする必要がある対応するフィールドに対して mongodb のインデックスを有効にします (mongodb は 1 つのコレクションで複数のインデックスをサポートします)。つまり、インデックスはハッシュテーブルを使用するため、はるかに高速になるはずです。また、並べ替えには mongodb 独自の API を使用できます。 、私は100Wの状況に遭遇したことはありませんが、比較として、1~10Wのサイズは500msの範囲内にあると記憶しています。

さらに、カウントする必要があるデータが非常に重要で呼び出し頻度が高い場合は、別のコレクションを作成し、定期的にキュー キャッシュを呼び出し、時間と引き換えにスペースを確保することをお勧めします。フィールド、ユーザー ID、最近 3 時間の合計購入数、過去 12 時間、過去 24 時間、過去 1 日、過去 1 か月、過去の合計購入量など。これの欠点は、スペースを無駄にし、データをリアルタイムに反映することはできませんが、ユーザーのショッピング量をクエリしたい場合は、ミリ秒単位の応答で簡単なクエリを実行できるというメリットは明らかです。

上記は一家族の意見であり、参考のみです

すべての収集データをメモリにロードして処理できます。

Mongodb は複数のコレクションからのデータを処理するのが苦手なので、データ自体を設計するときにそれらをすべて集約するのが最善です。

単一コレクションのクエリのインデックスを作成します。クエリの使用順序は次のとおりです: 基本的なクエリ -> 集計 -> クエリ方法は左から右に向かってますます柔軟になります。どんどん低くなっていきます。

複数のコレクションのクエリを自分で実装し、各コレクションから個別にクエリを実行し、複数のクエリ結果を処理する必要があります。

特に高い適時性要件がある場合は、中間キャッシュ層を使用し、更新戦略を設計します。