我目前正在设计一个基于MongoDB的本地内容库共享系统。我需要做出一个关键的架构决策，这无疑会对查询性能、伸缩性和总体长期可维护性产生巨大影响。
我们的系统有一个主题库，每个主题都可以在特定的城市/大都市地区使用。当一个人创建一段内容时，它需要作为主题的一部分存储在特定的城市中。我目前正在考虑三种方法来满足这些需求（并向其他想法开放）。
选项1（每个主题/城市的单个集合）：
示例：集合名称将为topicid123cityid456，每个条目显然都是该集合中的文档。
选项2（单主题集合）
示例：集合名称将为topic123，每个条目将创建一个包含索引cityid的文档。
方案3（单一城市收藏）
示例：集合名为city456，每个条目都将创建一个包含索引主题id的文档
在查询数据库时，我总是希望根据成员选择的主题和城市以日期顺序构建提要。由于成员可以将多个主题组合在一起以构建自定义提要，因此选项3似乎是最好的，但是我关注这种方法的长期性能。选项1似乎是性能最好的，但在需要选择多个主题时也会强制执行多个查询。
另一件事，我需要考虑的是，一些主题将远远比其他主题更活跃，增长更大，这也会因地点而异。
因为我仍然认为自己是mongodb的初学者，所以在编写和检索数据的所有逻辑之前，我想确保一般的db结构是最理想的。我不知道mongo在一个集合中处理数十万甚至上百万个文档的性能如何，因此我在方法上的不确定性。
从经验来看，哪种方法是处理存储和调用这些数据的最佳方法？任何洞察都将不胜感激。
更新日期：2016年6月22日
需要注意的是，我们要在一个数据库服务器环境中启动。@Profesor79提供了一个很好的扩展解决方案，一旦我们需要移动到一个多服务器（分片）环境。
最佳答案
从你的3号提案中，我将挑选4号：-）
在多个服务器上共享一个集合。
因为可以有一个集合，我们可以有一个所有主题的集合和一个所有城市的集合。
然后collectionTopicCity将对所有文档进行切分。
sharding on keytopicCities将允许通过shard服务器平衡负载，并允许您在需要添加更多功率时将shard添加到集群。
欢迎评论！