現在、mongoDBに依存するローカルコンテンツベース共有システムの設計に取り組んでいます。間違いなく、クエリのパフォーマンス、スケーリング、全体的な長期的な保守性に大きな影響を与える重要なアーキテクチャの決定を行う必要があります。Mongo Architecture効率
私たちのシステムは、トピックのライブラリを持って、各トピックは特定の都市/首都圏地域で利用可能です。ある人がコンテンツを作成するときには、トピックの一部として特定の都市に格納する必要があります。私は現在、これらの要件に取り組むことを検討している3つのアプローチがあります（そして、他のアイデアも公開しています）。
オプション1（トピック/市あたりのシングルコレクション）： 例：コレクション名はTopicID123CityID456となり、各エントリは明らかにそのコレクション内のドキュメントになります。
オプション2（シングルトピックコレクション） 例：コレクション名はTopic123となり、各エントリは、インデックス付きcityIDを含むドキュメントを作成します。
オプション3（シングル市コレクション） 例：コレクション名はCity456だろうと私はいつもにフィードを構築したいDBを照会する場合、各エントリはインデックスさTOPICID
を含むドキュメントを作成しますメンバーが選択したトピックおよび都市に基づいて、日付順に並べ替えることができます。メンバーは複数のトピックをまとめてグループ化してカスタムフィードを作成できるため、オプション3が最適と思われますが、私はこのアプローチの長期的なパフォーマンスに懸念しています。オプション1は最もパフォーマンスが良いと思われますが、複数のトピックを選択する必要がある場合は複数のクエリを強制します。
私が考慮する必要がある別のことは、いくつかのトピックがはるかに活発になり、場所によって異なる他のトピックよりもはるかに大きくなります。
私はまだMongoDBの初心者だと思うので、データの書き込みと取り出しのロジックのすべてをコーディングする前に、一般的なDB構造が最も理想的であることを確認したいと思います。そして、Mongoが何百万人もの文書を収集していてもそれがどれほどうまくいっているかわからないので、私のアプローチの不確実性。
このデータの保存とリコールに最適な方法である経験から、どんな洞察力も大変高く評価されます。
更新日：2016年6月22日 開始するには、1つのDBサーバー環境から開始することが重要です。 @ profesor79は、マルチサーバ（Sharded）環境に移行する必要がある場合に、大きなスケーリングソリューションを提供しました。
:-)私はなりますピックアップ番号4、複数のサーバー上の1つのコレクションのシャードを持つあなたの3案から
これは疑念のある質問です。私はあなた自身の研究を行い、あなたのニーズに最も適したものを選択することをお勧めします – Saleem