Mongodb 我是否应该将一个集合拆分为两个集合以提高性能？

我有一个用户集合

每个用户都有一些基本属性：姓名、地址、zipcode

但是每个用户都有一些占用空间更多的属性：统计信息

statistics属性包含的数组比所有其他属性加在一起的数组大10倍以上

我的问题如下：

我应该将我的集合拆分为用户集合和用户统计数据集合吗？用户集合将包含基本属性，用户统计集合将是具有统计信息的用户。然后，当我只想检索基本信息时，我可以使用user集合，当我真正需要统计信息时，我可以使用user_stats集合

例如，如果我搜索所有用户的所有名称：

userCollection.find({},{"name":true});

在我只有一个收藏和我有两个收藏的情况下，它们在性能上会有差异吗？这种差异是线性的吗（依我看是这样的，线性因素是一份文件大小的比率）

它推断出的一般问题是：当文档的大小变大（选择相同的属性）时，mongodb的性能会下降吗

更新 统计数据中的属性位于一个数组中，该数组将随着时间的推移而变大（用户使用应用程序的次数越多）。它们对该数组没有限制，但大多数用户（90%）的统计属性不会大于其他属性的10倍。然而，一小部分用户（1-2%）具有统计属性，其大小是其他属性的500倍

我需要这些数据，所以我不关心存储，而更关心性能

基本上有两种情况，我从用户集合中获取数据：

• 当我显示用户列表时，我不会获取统计信息：我只投影名称属性和一些其他属性，它们的空间有限

• 当我显示一个用户时，我获取统计信息：基本上我将投影所有统计信息属性+其他一些属性

---

在我看来，如果用户记录的大小远小于统计数据的大小，那么将统计数据移动到另一个集合就不会赢得任何东西。如果统计数据很大，则它们在任何集合中都很大。对吗？除此之外，任何事物的增长都有局限性——你不能永远让它增长。我不知道你的统计数据需要有多精细，但你能不能记录“汇总”的统计数据而不是详细的统计数据？您的统计数据可以按小时或每天汇总？

这取决于统计数据对查询性能的影响。如果您的查询延迟较低，那么拆分可能不值得。 即使只投影所需的字段，整个文档也会加载到内存中

---

注意：未绑定数组不是一个好的设计。

进一步充实您的问题。这些属性是否存储在数组中？该数组通常会增加到500个或更多条目吗？您的查询通常访问这些属性吗？您能否在同一文档中只保留这些属性的子集？考虑你的用例并直接提出，如果答案不是根据这些问题立即出现的。好的，我已经更新了我的问题，现在可以自由地问更多细节：<代码> CMD命令：更新{$MSG：“查询不记录（太大）”}。因此，我想我会将统计数据拆分成一个额外的表。是的，我想我只会将基本统计数据存储在集合中。