我有一个集合的查询。我正在过滤一个字段。我想，我可以加速查询，如果基于这个字段我制作许多单独的集合，哪个集合的名称将包含该字段名称，在我过滤的先前方法中。实际上我可以在查询中删除过滤器组件，因为我只需要选择正确的集合并将其中的文档作为响应返回。但是通过这种方式，ducoments将被冗余存储，之前的文档只存储一次，现在文档可能存储在更多的集合中。这种方法值得遵循吗？我使用Heroku作为云提供商。通过增加dynos的数量，很容易满足更多用户的要求。据我所知，MongoDB中的读操作是高度相互的，并行执行的。锁定在文档级别上发生。通过增加冗余可以获得任何优势吗？当然，该领域存在索引。
答案 0 :(得分：2)
如果它仍然在同一个服务器中，我相信这样做可能会有很少的并行化收益（来自数据库方面），因为对于单个服务器，文档逻辑结构的重要性很小。
所有服务器关心的是您拥有多少集合和索引，因为它将这些集合和关联的索引存储在许多文件中。在访问集合时需要加载这些文件。
可能存在的问题是，如果您有大量的集合，那么您可以达到打开文件限制。请注意，打开文件限制也与连接共享，因此对于大量集合，您间接减少了可能的连接数。
为了说明，我们假设你有一个大集合，例如他们有5个索引。 WiredTiger存储引擎将集合存储为：
_id索引总计= 7个文件。
现在你将这一个集合拆分为例如100个系列。假设集合还需要5个二级索引，总共需要WiredTiger中的700个文件（相对于原始7个）。从你的观点来看，这可能是也可能不合适。
如果您需要更多并行化，如果您达到某些操作限制，则建议使用分片。在适当选择的shard key设计用于最大化并行化的情况下，对多个不同分片（服务器）中的繁忙集合进行分片将立即为您提供更好的并行化与单个服务器/副本集。
话虽如此，分片还需要更多的基础架构，并且可能会使备份/恢复过程变得复杂。它还需要大量的规划和测试，以确保您的设计最适合您的用例，并将在未来扩展。