質問を1つずつ見ていきましょう：
1回の実行からパフォーマンスメトリックを確認することは、実際にはどのように機能するかではありません。いくつかの要因が関係しているため、結論を出す前に、いくつかの実行の平均を取る必要があります。とはいえ、MongoDBは、最も頻繁に使用されるドキュメントをメモリにキャッシュし、他のドキュメントのメモリを生成する必要がない限り、そこに保持します。したがって、クエリが前のクエリからすでにキャッシュされているドキュメントにアクセスする場合は、より高速になるはずです。
また、MongoDBでは、集約は最初にインデックスを使用します（存在する場合）。例： $ match および$sort フェーズはインデックスを使用できます。あなたの場合、 $ match は最初のパイプラインステージなので、それが勝利です。
MongoDBでは、データはBSON に保存されます。 、したがって、日付は基本的に数字です それらが比較されるとき。したがって、違いはありません。
私はそれをテストしていませんが、time_bucketアプローチがより速い応答を与えるかどうかは本当に疑わしいです。 created_at以降 常に増加します。この場合、インデックスもtime_bucketなしで最後に追加されます。さらに、単純な日付フィールドよりも配列で作成した場合、インデックスサイズは比較的大きくなります。インデックスをRAMにフィッティングする問題は発生しません。
time_bucketを使用することは、照合する前に日付フィールドで何らかの関数を使用している場合に意味があります。照合する前に日付フィールドから年のみを抽出すると、日付の既存のインデックスが使用できなくなります。
逆ではなく、データベースのデータ型に一致するようにパラメータをキャストすることをお勧めします。
はい、可能です。 $ andの場合 、 $ matchですべてのフィルターをコンマで区切って指定するだけです 段階。 $またはの場合 $ orを使用します
オペレーター。
2つの$macth<がある場合/ code> フェーズを1つずつMongoDBが1つに結合します
。したがって、複数の一致フェーズの結果を追加することを心配する必要はありません。
これで、最適化 ポイント
はい、対象クエリ はるかに高速です。
$ groupでドキュメントのサイズが縮小された場合 $ projectを使用してステージングする 、そうです、それは本当です。
それは必ずしも真実ではありませんが、一般的にはそうです。 この回答 を確認できます 。