120个mongodb集合与单个集合-哪一个更有效？

我是mongodb的新手，在DB模式设计方面，我面临着两难境地：

我应该创建一个集合还是将数据放入多个集合中（我想我们可以称这些类别）

现在我知道有人问了很多这样的问题，但我认为我的情况有所不同，原因有二：

• 如果我要买很多收藏品，我将不得不创造大约120个，仅此而已。这在未来不会增长
• 我知道我永远不需要查询或插入多个集合。因为集合X中的文档与存储在其他集合中的任何文档都不相关，所以我总是只需要查询一个文档。文档可能包含对数据库其他部分的引用（如userId等）

所以我的问题是：120个集合能否提高查询性能？在我的例子中，这是一个有用的优化吗

或者我应该只选择单集+分片

每一个藏品预计可容纳数百万份文档。如果只使用一个，它将存储数十亿个文档

提前谢谢

-------编辑：

谢谢你的回答

事实上，120个系列只是一个自制的限制，并不是真正的最佳：

集合中的数据与web发布者相关。可能有数百万个这样的网站（任何网站都可以加入）

我想理想的情况是，我可以为每个出版商创建一个集合（只保存他们的数据）。但显然，由于mongo的限制，这是不可能的

所以我想出了一个固定数量的集合的想法，至少以某种方式分发数据。例如：集合“A_XX”将为名称以“A”开头的出版商保存XX平台相关数据。。等等。我们只支持其中的几个平台，所以120个集合就足够了

在另一个网站上，有人建议使用多个数据库而不是多个集合。但这意味着开销，然后我将不得不使用/管理许多不同的连接

你觉得这个怎么样？有更好的解决办法吗

对不起，我的原始问题不够具体

---

提前感谢

这里的主要问题是，如果将集合分离到同一个数据库中，那么在当前的MongoDB版本中，您将获得很少的性能。要在单个集合设置上获得任何类型的额外性能，您需要将集合移出到单独的数据库中，然后您将有操作开销来判断应该查询哪个数据库等

所以，是的，你可以很容易地收集120个集合，但是，你目前不会得到任何东西，因为：没有实施（很快）

在一个集合中存放数十亿个文档并不太糟糕。我假设，即使您将其放在单独的集合中，它也可能不会在单个服务器上，就像切分单个集合一样，因此在这种情况下，由于多服务器设置而导致的任何速度降低也不重要

在我个人看来，使用单一收藏更容易。

单一碎片收藏 问题的编辑版本使实际需求更加清晰：您有一个可能会变得非常大的集合，并且您需要一种划分数据的方法。人工收集限制是您自己计划的分区方案

在这种情况下，我认为最好使用单个集合，并利用MongoDB的功能，根据需要将数据和工作负载分发到多个服务器。多个集合仍然是一种有效的方法，但与利用核心MongoDB功能相比，不必要地使应用程序代码和部署复杂化。假设您这样做，您的数据将在您的碎片之间自动平衡

你可以不必立即切分；您可以推迟做出决定，直到您看到您的工作负载实际上需要更多的写规模（但知道在需要时该选项就在那里）。在决定切分之前，您还有其他选择，例如升级服务器（特别是磁盘和内存）以更好地支持您的工作负载。相反，您不希望等到系统被工作负载压垮后再进行分片，因此您肯定需要监控增长。我建议使用10gen提供的免费软件

在另一个网站上，有人建议使用多个数据库而不是多个集合。但这意味着开销，然后我将不得不使用/管理许多不同的连接

多个数据库将显著增加更多的管理开销，这可能会造成过度杀伤力，并且可能对您的用例有害。存储是在数据库级别分配的，因此120个数据库将比一个包含120个集合的数据库消耗更多的空间

集合的固定数量（原始答案） 如果您可以计划固定数量的集合（根据您最初的问题描述为120个），我认为采用这种方法比使用单一集合更有意义

注意：下面的设计注意事项仍然适用，但由于问题已更新，以澄清多个集合是一种尝试的分区方案，因此将单个集合分片将是一种更为简单的方法

使用单独集合的动机是：

• 单个大型集合的文档可能必须包含集合子类型的某些指示，这可能需要添加到多个索引中，并且可能会显著增加索引大小。对于单独的集合，子类型已隐含在集合命名空间中

• 在集合级别启用分片。单个大型集合只提供“全部或无”的方法，而单个集合允许您控制需要保存哪些数据子集