针对集合中的文档数量设计数据库架构

时间:2019-06-25 07:04:21

标签: mongodb performance database-design

在使用mongodb构建数据库时,我需要每天存储用户活动。用户活动有5个字段。我对为其选择模式有疑问。

schema-1: 每个用户都有一个文档,其中包含以下字段:

{
user_id:<>,
user_activity :[array]
}

具有如下结构的数组:

{
date:<>
field1:<>
field2:<>
field3:<>
field4:<>
field5:<>
}

因此,在此架构中,您每天都将用户的活动追加到user_activity数组中。因此,每天您都会在“ user_activity”中附加一个对象。因此,在该集合中,我将有1000个文档(我有1000个用户),并且日常活动会推入单个用户的user_activity数组中。

模式2: 每个活动的字段都有不同的文档:

user_id:<>,
date:<>
user_activity :<object(with five fields as mentioned above)>

这就像每天为每个活动在sql表中插入新行一样。

使用schema-1 ,我不认为这是一个很好的模式,因为我会增加数组大小。我将为日期字段建立索引(以便以后搜索),因此增加数组大小将很昂贵。

使用schema-2 ,我觉得可以继续进行。它更像是每天添加行的sql表。索引日期字段将不是问题。但是我怀疑我有5k用户。因此,在一年之内,我将在一个集合中拥有180万个文档(5000 * 365)。这个可以吗 ?集合中的文档数量如何影响性能?是否与sql中的相同(对于表中的记录数而言,这无关紧要?)?

如果在任何方面和我提出的建议上有误,请指出我(至少详细说明每种方案的优缺点,以便我可以提出要求)

0 个答案:

没有答案