Mongo架构效率

Question

我目前正致力于设计依赖于mongoDB的本地内容库共享系统。我需要做出一个关键的架构决策，这无疑会对查询性能，扩展和整体长期可维护性产生巨大影响。

我们的系统有一个主题库，每个主题都在特定的城市/大都市区域提供。当一个人创建一段内容时，需要将其存储为特定城市中主题的一部分。我目前正在考虑采用三种方法来解决这些要求（并对其他想法持开放态度）。

选项1 （每个主题/城市的单一收集）： 示例：集合名称将为TopicID123CityID456，并且每个条目显然都是该集合中的文档。

选项2 （单一主题收藏） 示例：集合名称为Topic123，每个条目都将创建包含索引cityID的文档。

选项3 （单一城市收藏） 示例：集合名称为City456，每个条目都将创建包含索引的topicID

的文档

查询数据库时，我总是希望根据成员选择的主题和城市建立日期顺序的订阅源。由于成员可以将多个主题组合在一起构建自定义Feed，因此选项3似乎是最好的，但我关注此方法的长期性能。似乎选项1是性能最高的，但在需要选择多个主题时也会强制执行多个查询。

我需要考虑的另一件事是，某些主题会比其他主题更加活跃并且变得更大，这些主题也会因地点而异。

由于我仍然认为自己是MongoDB的初学者，我想确保在编写和检索数据的所有逻辑之前，一般的DB结构是最理想的。而且我不知道Mongo如何在一个集合中执行数十万甚至数百万的文档，因此我的方法存在不确定性。

从经验来看，这是解决这些数据存储和召回的最佳方式吗？任何见解将不胜感激。

更新：2016年6月22日 重要的是要注意我们从一个数据库服务器环境开始启动。一旦我们需要转移到多服务器（Sharded）环境，@ profesor79就提供了一个很好的扩展解决方案。

Answer 1

从你的3号提案中我将获得第4号： - ）

将一个集合分割为多个服务器。 因为可能有一个集合TopicCity，`我们可以有一个用于所有主题，一个用于所有城市。

然后集合topicCities将所有文档分片。

对密钥{topic:1, city:1}进行分片将允许通过分片服务器和enytime平衡负载，您将需要添加更多功能，您将能够将分片添加到群集。

欢迎任何评论！