在什么时候通过prop查询nosql比在文档中存储一个大数组更好

Question

我正在将文档存储在json格式的nosql（mongo或其他）html" target="_blank">数据存储中，如下所示

*编辑开始时间*

{
    _id : 9182798172981729871
    propertyBBBB: [
       {
           propertyCCCCC: "valueCCCC",
           propertyDDDDD: [ "valueDDDD", "valueEEEE", "valueFFFF" ]
       }, {
           propertyCCCCC: "valueGGGG",
           propertyDDDDD: [ "valueHHHH", "valueIIII", "valueFFFF" ]
       }
       ....
    ]
}


.find( { _id : "9182798172981729871" } , 
       { propertyBBBB : { propertyDDDD : {"$elemMatch":{"$in":['refineaquerystringvar']}}}} )

MongoDB嵌套数组查询

****编辑结束****

目前，我正在通过_id查询，并在获取返回文档后对嵌套数组执行逻辑。

但是我正在寻找查询的更大灵活性，所以我正在考虑创建一个新的nosql（mongo或其他）集合，其中包含看起来像propertyBBBB值的文档。

*编辑开始时间*

   {
       _id: 9234792837498237498237498
       parentid: 9182798172981729871
       propertyCCCCC: "valueCCCC",
       propertyDDDDD: [ "valueDDDD", "valueEEEE", "valueFFFF" ]
   }

   {
       _id: 9234792837498237498237497
       parentid: 9182798172981729871
       propertyCCCCC: "valueCCCC",
       propertyDDDDD: [ "valueDDDD", "valueEEEE", "valueFFFF" ]
   }


.find( { parentid : "9182798172981729871" } , 
       { propertyDDDDD : {"$elemMatch":{"$in":['refineaquerystringvar']}}} )

MongoDB嵌套数组查询

****编辑结束****

但是我不想失去我的查询速度，因为在这种做事的方式中，我使用了更多的逻辑来查询作为补充参数的括号，而不是主获取。我还获取了许多对象，而不是每次都确定我正在获取一个。

所以我的问题是：

在什么情况下按属性查询mongo比在文档中存储一个大数组并查询document _id更好？数组(或返回查询)的长度应该有多大才能使使用一种约定比使用另一种更有利？

Answer 1

是的，您可以在数组中加载集合。
集合由文档组成。每个文档都可以映射为一个对象。
最后，您可以将mongo集合加载为对象数组。
我认为在服务器中处理一个巨大的对象数组没有问题，尤其是因为node.js和mongoDB通常托管在同一台服务器上。因此，在节点中处理巨大数组时所做的工作平衡了在mongo中处理的工作

Answer 2

答案实际上取决于数据的用例以及您希望在查询中检索的内容。需要注意的是：；

>

MongoDb不做连接，所以任何需要将数据粘在一起的地方都需要应用程序中的额外逻辑，并且需要额外的CPU功率来完成这一任务——因此，更多较小的记录可能无法加快应用程序的速度，事实上，大多数人都觉得使用规范化数据模式的应用程序比使用非规范化模式的应用速度慢得多。

MongoDB不支持超过16Mb的记录——因此，如果您的阵列结构可以无限增长，您可能会遇到问题——例如，拥有一个包含应用程序所有用户的阵列将是一个糟糕的设计。

您已经在查询中使用了$elemMatch指令，这很好，因为它可以将通过网络传输的数据大小减少到实际需要的数据大小——然而，对于磁盘io来说，非常大的记录大小仍然是一个问题，但在许多Mongo数据库中，活动数据集完全适合内存，因此io的重要性要小得多，假设大多数操作是读取。如果写入（更新）的次数是操作的大部分，那么值得考虑的是，仅更新数组中的一个元素就会导致整个对象写入数据库，因此，如果记录非常大，那么仅更改一个字节将导致显著的IO——在会话中收集用户事件将是一个这样的用例，将事件添加到数组可能会导致糟糕的设计。

如果您在非规范化数组中的查找将返回多个记录（在您的情况下不会，因为您使用_id进行查询），那么在规范化模式中，客户端的应用程序逻辑可能很难构建以缝合记录和您可能希望避免的事情。

在规范化模型中，它可以想到的唯一好处是，如果您有大量的mongo碎片，并且您希望find返回大量的记录，因为您可以并行化从多个主机检索数据，但是每次查找返回的数据量必须非常大，才能注意到差异。

因此，总的来说，我认为出于性能原因而希望规范化数据的情况非常罕见，或者对大多数人来说几乎没有。如果你对你的数据有很好的理解，你可能想要运行一个基准测试，除非你得到一个实质性的(x2或x3)差异，我仍然会使用非规范化的模型，仅仅是因为你必须编写的代码的简易性。

当您要求提供“官方来源”时，我可以参考mongodb博客，其中包含一系列关于如何设计数据模型的文章，它们迭代了我上面提出的相同观点以及一些额外的提示。