这与我的最后一个问题有关。
我们有一个应用程序，我们在其中为每个用户存储大量数据。由于数据的性质，之前我们决定为每个用户创建一个新数据库。这将需要一个很大的数字。数据库（可能数百万） - 正如有人在评论中指出的那样，这表明设计错误。
所以我们改变了设计，现在我们正在考虑将每个用户的全部信息存储在一个集合中。这意味着一个集合完全映射到一个用户。由于每个数据库有 12,000 个可用的集合，我们可以在每个数据库中存储 12,000 个用户（这个限制可以增加）。
但是，现在我的问题是 - 是否有任何限制。集合可以拥有的文档数。由于我们需要为每个用户存储数据的方式，我们预计会有一个巨大的（在极端情况下为数千万）没有。每个文件的文件。这对 MongoDB 和设计来说可以吗？
编辑
感谢您的回答。我想那么每个集合使用大量文档是可以的。
该应用程序是一个专门的库存控制系统。每个用户都有一个很大的编号。与他们相关的小信息。每条信息都有一个类别和该类别下的一些相关内容。此外，没有两个集合需要查看彼此的数据——因此不需要涉及多个集合的索引。
要调整您可以拥有的集合/索引的数量（~24k 是限制——~12k 是他们所说的集合，因为默认情况下您有 _id 索引，但请记住，如果您在集合上有更多索引，也将使用命名空间），您可以在启动 mongod 时使用 --nssize 选项。
在一个集合中有数十亿个文档的很多实现（我敢肯定有几个有数万亿个），所以“数千万”应该没问题。有一些数字（例如返回的计数）具有 64 位的约束，因此在您点击 2^64 个文档后，您可能会发现一些问题。
您要查看什么样的查询和更新负载？
你的设计仍然没有多大意义。为什么将每个用户存储在单独的集合中？
您对数据有哪些索引？如果您按某个字段进行索引，该字段的内容在所有用户中都是通用的，那么您将通过使用一个索引的单个集合来显着节省总索引大小。
就性能而言，索引大小通常不是总数据库大小的限制因素。
为什么每个用户有这么多文档？它们有多大？
Craigslist 在 MongoDB 中放置了超过 2 亿个文档，因此如果您有硬件支持它并且索引效率不低，那么这应该不是问题。
如果您在此处发布更多架构，您可能会得到更好的建议。