问题：

Mongoose子文档与嵌套模式

云长恨

2023-03-14

我很好奇在我的主模式中使用子文档和更深层文档的利弊：

var subDoc = new Schema({
  name: String
});

var mainDoc = new Schema({
  names: [subDoc]
});

或者

var mainDoc = new Schema({
  names: [{
    name: String
 }]
});

我目前到处都在使用subdocs，但我主要想知道我可能遇到的性能或查询问题。

共有3个答案

田成仁

2023-03-14

如果是静态文档或由于性能影响而不超过几百个，则应使用嵌入式文档。关于那个问题我已经讨论了一段时间了。最近，作为MongoDB解决方案架构师的Asya Kamsky写了一篇关于“使用子文档”的文章。

我希望这有助于世卫组织寻找解决方案或最佳做法。

http://askasya.com/post/largeembeddedarrays的原始帖子。你可以在https://stackoverflow.com/users/431012/asya-kamsky找到她的Stackoverflow档案

首先，我们必须考虑为什么我们要做这样的事情。通常情况下，我会建议人们在获取此文档时嵌入他们总是想得到的东西。另一方面，您不想在文档中嵌入您不想返回的内容。

如果您将我执行的活动嵌入到文档中，一开始它会非常有效，因为我的所有活动都在那里，只需一次阅读，您就可以获得您可能想要显示给我的所有内容：“您最近点击了此项，这是您最后的两条评论”但是六个月后会发生什么，我不在乎我很久以前做过的事情，你也不想给我看，除非我特别去寻找一些旧的活动？

首先，您将返回越来越大的文档，并关心其中越来越小的部分。但是您可以使用投影只返回阵列的一部分，真正的痛苦是磁盘上的文档将变得更大，即使您只将其中的一部分返回给最终用户，它仍然会被读取，但由于只要我处于活动状态，我的活动就不会停止，文档将继续增长。

最明显的问题是最终会达到16MB的文档限制，但这根本不是您应该关心的。一个不断增长的文档每次必须在磁盘上重新定位时都会带来越来越高的成本，即使您采取措施减轻碎片化的影响，您的写操作总的来说也会过长，从而影响整个应用程序的总体性能。

您还可以做一件事，这将完全扼杀您的应用程序的性能，那就是索引这个不断增加的数组。这意味着每次重新定位带有该数组的文档时，需要更新的索引条目的数量与该文档中索引值的数量成正比，数组越大，该数量就越大。

我不想让你害怕在数组非常适合数据模型时使用它们——它们是文档数据库数据模型的一个强大功能，但与所有强大的工具一样，它需要在正确的环境中使用，并且应该小心使用。

经慈

2023-03-14

如果您有在模型的各个部分重复使用的模式，那么为子文档定义单独的模式可能会很有用，这样您就不必重复自己。

符风畔

2023-03-14

根据文件，完全一样。但是，使用模式也会添加一个\u id字段（只要您没有禁用该字段），并且可能会使用更多的资源来跟踪子文档。

备用声明语法

v3中的新增功能如果不需要访问子文档架构实例，还可以通过简单地传递对象文本[…]来声明子文档

共有3个答案