MongoDB 模式设计适用于应用程序、嵌入式文档或单独的集合？

Question

我有一个工作中的应用程序需要以下列方式工作：
- 当应用用户设置过滤器并且应用返回一组引号时。
- 然后用户可以喜欢或不喜欢那个“报价”

我们有大约 60K 的报价和大约相同数量的用户。 而且我在使用嵌入式数组存储喜欢和不喜欢的引号 id 或创建单独的集合然后进行查找之间感到困惑。 我知道 2and 选项需要两个查询，而且会更慢。

如果我使用嵌入式数组方法，在我开始见证性能下降之前，我可以存储多少个报价 ID，因为 .

var UserSchema = mongoose.Schema({
                 fullName : {type: String,trim: true},
                 gender   : {type: String,enum: ['male', 'female']},
                 age      : {type: Number,required: true},
                 viewed   : []
});`

PS：如果有更好的方法来实现类似的功能，请在 cmets 或解决方案中提及

编辑 1：
谢谢@niral Patel 的提示。

根据我对 mongodb 的研究和这个问题的可能解决方案，我设计了一个测试，我创建了一个大约 10K 随机数的数组，在现实世界中将 come from another collection 并将它传递给一个 mongoose 查找查询$nin 运营商 虽然我预计查询在较高负载下会很慢，但在我的测试中它非常快！
关于在 Ubuntu 16 上运行的 4 GB 双核 Box 上的 195 requests per second 有两个节点进程在 http-proxy 后面运行。

我的最终查询看起来像这样

var userIDs = [];

 // filling userIDs with random numbers
for(var i=0;i<10000;i++){
    userIDs.push(Math.floor(Math.random() * (90000 - 50000)) + 50000);
}

users.find(user_id:{$nin:userIDs}}).limit(10).lean().exec(function(e,d){
    console.log(d); // results
});

Answer 1

根据来自 mongodb.com 的这篇内容丰富的文章

6 rules of thumb for MongoDB schema

如果您知道喜欢或不喜欢的报价数量不会增长超过几千。您可以在 UserSchema 中拥有一组报价单并使用 populate()。 这种方法还将提供更好的性能，因为您只需触发一个查询。我假设当您显示用户的信息时，您还会显示他/她喜欢和不喜欢的报价。在这种情况下，这将是一个更好的方法。

如果您知道这将是一个很大的数量，您也可以拥有一个包含所有 id 的单独集合。在这种情况下，您必须触发额外的查询。