これは次のとおりです。MSSQLServerの代わりにMongoDBを使用することの長所と短所。
なぜあなたが多くのコレクションを使用するようにアドバイスしようとしているのかわかりません。
MongoDBでこのように多くのコレクションを使用することは悪い考えと見なされます（そして、インデックスのオーバーヘッドの後で、おそらくnsサイズを増やす必要があります）。代わりに、一般的なドキュメントの単一のコレクションを水平方向にスケーリングする必要があります。他の回答者も同意しているようです。
私はおそらく（頭のてっぺんからすぐに）ドキュメント構造を持つ単一のコレクションを使用します：
{
_id: {},
camera_id: ObjectId(),
image: {},
hour: ts_of_hour,
day: ts_of_day
}
そうすれば、必要な金種に基づいて画像を選択するために必要なすべてのデータを取得できます。
注意：MongoDBのロックはデータベースレベルであり、コレクションレベルではないことも考慮してください。ここでは、クエリをより困難かつ複雑にし、データの保守を困難にするだけで、有用なものは何も得られません。
編集
あなたの懸念のいくつかに答えるために：
NB：私はあなたのアプリを設計していません、そしてこれは遅い答えです（夜遅くも）ので、基本的にこれは私がすぐに頭に浮かぶ基本的な概念を具体化することです。
カメラごとに1つのコレクション、つまりほぼ100のコレクション。
繰り返しになりますが、最適化の理由でこれを行う場合は、DBごとに1台のカメラとして行うことになりますが、それは公式にはやり過ぎです。正直なところ、30mのレコードは何もありません、私は今その懸念を解決します。SQLとMongoDBのどちらについて話している場合でも、データベースの可能性の観点から、30mのレコードコレクションは通常、小さく、分単位であると見なされます（MS SQLは、テーブルごとにペタバイトを格納できると言っています）。
- FromDateとToDate2の間のすべての画像を選択します
上記の回答を使用して、ドキュメントのBSON日付フィールドを使用してそれを実現できます。
- FromDateとToDateの間のTop（COUNT）画像を選択します
あなたはただすることができますcount()。
top()はすべてのDBシステムに実装されているわけではないため、これはここではMS SQL固有ですが、この特定のクエリでは、クエリは常に1行を返すため、何の役にも立ちません。
この特定のデータを別のコレクションに集約できます。それは問題ないので、別のコレクションでは、一連の日があります。
{
count: 3,
day: (date|ts)
}
そしてcount()、大規模なワーキングセットでは遅くなる可能性があるため、数日のうちに少しだけアップすることができます。したがって、コレクションの目的は、データを要約して、クエリのワーキングセットをより管理しやすくすることです。
したがって、他のコレクションを使用して、低速な集計関数の「キャッシュ」を保持したり、もちろんアプリ内の他のエンティティを保持したりすることができます（リレーショナルDBのように）。
基本的に、SQLの場合と同様に、一般的なスキーマまたはドキュメントはコレクションにグループ化されます。したがって、実際には、1つのテーブルのみを使用してSQLでアプリを設計しimagesますcamera。
5を除く他のすべてはここで大まかにカバーされているので：
- IDを持つ画像から/への前/次の画像を選択します
あなたは_idこのようにここを使うことができます：
db.images.find({_id: {$gt: last_id}}).limit(1)
そして、それはかなりうまくいくはずです。
あなたがここに投稿したコメントについても：
MongoDBで、30個のドキュメントを含むコレクションのクエリは、30,00,000個のドキュメントを含むコレクションのクエリと同じであるということですか？
これは、データベース設計全般についてどれだけ知っているか、およびデータベースアーキテクチャを拡張する方法によって異なります。これは、MongoDBだけでなくSQLにも当てはまるものです。正しく設定されていれば、SQLは30のような30mのレコードを簡単にクエリできます。
結局のところ、シャーディングです。高速であるかどうかは、クエリを実行するシャード全体のインデックスとそのワーキングセットサイズ（RAMに必要なデータ量、RAMにあるかどうか）に依存します。見た目では、image_id（ObjectId）と日付のシャードインデックスが必要なものを提供する可能性があります。ただし、これにはさらにテストが必要です。データベースのスケーリングは少し慣れていないので、Googleなどを介してこのテーマを検索する必要があります。
注意：30mのドキュメントはシャーディングを必要としない可能性があるため、これは適切なインデックスを作成する場合にすぎません。
うまくいけば、これがお役に立てば幸いです。私はここで輪になって回っていません。