Question

我遇到了一些选择架构设计的问题，我有一个文件，其中包含用户信息，每个用户都有一大堆可以达到20k项目的项目。

一个项目有一个日期和一个id以及另外19个字段，还有一个内部数组，可以有20-30个项目，它可以被修改，删除，当然也可以由它拥有的任何属性重新插入和查询。 / p>

所以我提出了两种可能的模式。

1.将所有内容都放入单一文件中

    {_id:ObjectId("") type:'user' name:'xxx' items:[{.......,internalitems:[]},{.......,internalitems:[]},...]}
    {_id:ObjectId("") type:'user' name:'yyy' items:[{.......,internalitems:[]},{.......,internalitems:[]},...]}

2.分离用户的项目并让每个项目都有自己的项目文件

    {_id:ObjectId(""), type:'user', username:'xxx'}
    {_id:ObjectId(""), type:'user', username:'yyy'}
    {_id:ObjectId(""), type:'useritem' username:'xxx' item:{.......,internalitems:[]}]}
    {_id:ObjectId(""), type:'useritem' username:'xxx' item:{.......,internalitems:[]}]}
    {_id:ObjectId(""), type:'useritem' username:'yyy' item:{.......,internalitems:[]}]}
    {_id:ObjectId(""), type:'useritem' username:'yyy' item:{.......,internalitems:[]}]}

正如我之前所解释的，单个用户可以拥有数千个项目，而且我有数十个用户，内部项目可以有20-30个项目，并且它有9个字段

考虑到不同用户可以查询单个项目，并且只能由所有者和其他流程进行修改。

如果你选择哪种设计表现真的很重要？
如果您不选择它们，您可以建议哪种架构？

在侧面说明我将进行分片，我有一个单独的集合。

Answer 1

我不推荐第一种方法，最大文档大小有限制：

“最大BSON文档大小为16兆字节。

最大文档大小有助于确保单个文档无法使用过多的RAM，或者在传输过程中使用过多的带宽。为了存储大于最大大小的文档，MongoDB提供了GridFS API。有关GridFS的更多信息，请参阅mongofiles和驱动程序的文档。“

来源：http://docs.mongodb.org/manual/reference/limits/

如果在更新（http://docs.mongodb.org/manual/core/write-performance/“文档增长”）时超过当前分配的文档空间，还会有性能影响。

您的第一个解决方案容易受到这两个问题的影响。

第二个是（免责声明：在20-30个内部项目的情况下）不太容易达到限制但仍然可能需要在进行更新时重新分配。我没有遇到类似情况的问题，所以这可能是要走的路。您可能需要查看记录填充（http://docs.mongodb.org/manual/core/record-padding/）以获取更多详细信息。

并且，如果所有其他方法都失败了，您也可以随时拆分内部项目。

希望这有帮助！

具有聚合集合的聚合集合

1 个答案: