特定の日のデータの 1 日ごとのコレクションを作成することをお勧めします (データが多すぎる場合は、1 日ごとから始めて、1 時間ごとに移行できます)。mongodb で作成できるコレクションの数に制限はありますか、それともパフォーマンスの低下につながりますか (mongodb が非常に多くのコレクションを維持するためのオーバーヘッドですか)。多数のコレクションはパフォーマンスに悪影響を及ぼしますか?
より多くのコンテキストを提供するために、データは Facebook フィードのようになり、最新のデータ (たとえば、過去 1 週間または 1 か月) のみが重要になります。1 日あたりのコレクションを作成すると、ドキュメントの数が少なくなり、おそらくアクセスが高速になります。古いデータが必要な場合でも、古いコレクションにフォールバックできます。これは理にかなっていますか、それとも間違った方向に向かっていますか?
実際に必要なのは、古いデータをアーカイブすることです。mongodb メーリング リストのこのスレッドを参照することをお勧めします
:
https://groups.google.com/forum/#!topic/mongodb-user/rsjQyF9Y2J4
「OSはデータのLRU化を処理するため、すべてのクエリがデータの同じ部分に触れている場合、コレクションの合計サイズとは無関係にメモリに留まる必要があります。」
したがって、単一のコレクションにとどまることができ、適切なインデックスが機能すると思います。
とにかく、コレクションが大きくなりすぎた場合は、いつでも手動のアーカイブ プロセスを実行できます。
はい、作成できるコレクションの数には制限があります。Abhishek が参照した Mongo ドキュメントから:
名前空間の数の制限は、名前空間ファイルのサイズを 628 で割った値です。
16 メガバイトの名前空間ファイルは、約 24,000 の名前空間をサポートできます。各インデックスも名前空間としてカウントされます。
名前空間にはインデックスなどが含まれていますが、それでもその限界に達するまでには 60 年ほどかかります。
でも！複数のコレクションにまたがるデータが必要な場合に何が起こるか考えたことはありますか? つまり、1 週間に何人のユーザーがフィードを更新したかを知りたい場合は、少し窮地に陥っています。コレクション間でクエリを実行するのは簡単ではありません。
代わりに、データを保存するための1 つのコレクションを作成し、Tamir が推奨するように定期的にデータを移動することをお勧めします。毎週または毎月コレクションからデータを移動するジョブを簡単に作成できます。
コレクションを作成してもオーバーヘッドは大きくありませんが、コレクション内で新しいドキュメントを作成するよりもオーバーヘッドが大きくなります。
作成できるコレクションの数には制限があります: " http://docs.mongodb.org/manual/reference/limits/#Number of Namespaces "
私に新しいコレクションを作成しても、実際にクエリを実行するデータのみを RAM にキャッシュするため、パフォーマンスに違いはありません。あなたの場合、それは最近のフィードなどになります。
しかし、1 日/1 時間ごとに収集すると、古いデータを非常に簡単に取得するのに役立ちます。