場合によります。
それはあなたが持っていると期待するこれらのタイプのオブジェクトのそれぞれの数に依存します。それらすべてを特定のユーザーの単一のMongoDBドキュメントに収めることができますか？おそらくそうではありません。
それは関係に依存します-ユーザーアカウントは1対多の関係ですか、それとも多対多の関係ですか？ 1対多で、アカウントの数が少ない場合は、ユーザードキュメントのIListにそれらを配置することを選択できます。
個別のコレクションを使用してMongoDBで関係をモデル化することはできますが、データベースには結合がないため、コードで行う必要があります。ユーザーを読み込んでからアカウントを読み込むことは、パフォーマンスの観点からは問題ないかもしれません。
ドキュメントのINTO配列にインデックスを付けることができます。インデックスを、ドキュメントの単純なフィールド（SQLなど）の単なるインデックスとは考えないでください。たとえば、ドキュメントでタグコレクションを使用し、タグにインデックスを付けることができます。 （http://www.mongodb.org/display/DOCS/Indexesを参照してください＃Indexes-配列 ）
データを取得または書き込む場合、任意のドキュメントの部分的な読み取りと部分的な書き込みを行うことができます。 （http://www.mongodb.org/displayを参照してください。 / DOCS / Retrieveing + a + Subscription + of + Fields ）
そして最後に、コレクションとインデックスを使用して必要なものを取得する方法がわからない場合は、mapreduceを使用してそれを達成できる可能性があります。たとえば、現在使用されているすべてのタグを使用頻度で並べ替えて検索するには、マップします。 使用されているタグを発行する各ドキュメントを作成すると、削減されます。 あなたが望む結果を得るためにそのセット。次に、そのマップリデュースの結果を永続的に保存し、必要なときにのみ更新することができます。
もう1つの懸念事項：タグによる合計の計算について言及されています。アカウンティング品質のトランザクションの一貫性が必要な場合、MongoDBは適切な選択ではない可能性があります。 「結果整合性」はNoSQLデータストアのゲームの名前であり、通常、金融取引には適していません。たとえば、あるユーザーが3つのコメントを含むブログ投稿を表示し、別のユーザーが4つのコメントを表示するかどうかは関係ありません。これは、まだ同期されていない別のレプリカコピーにヒットするためですが、財務レポートの場合、そのような一貫性は重要です。レポートが合計されない可能性があります！