MongoDB设计问题 - 2路参考

时间:2013-01-25 16:01:23

标签: mongodb database nosql

我是MongoDB的新手,所以如果这些问题很简单,我会道歉。

我正在开发一个应用程序,它将跟踪特定的用户交互,并将有关用户和交互的信息放入MongoDB。有几种类型的交互将从用户收集不同的信息。

我的第一个问题是:所有这些交互都应该在同一个集合中,还是应该按类型分开(就像在RDBMS中那样)?

此外,我希望能够查找:

  1. 特定用户的所有互动
  2. 已进行特定互动的所有用户
  3. 我正在考虑为用户在其文档中执行的每个交互添加手动引用交互文档,以及对在每个交互文档中执行交互的用户进行手动引用。

    我的第二个问题是:手动参考的“加倍”是否有意义或有更好的方法吗?

    任何想法都会非常感激。

    谢谢!

2 个答案:

答案 0 :(得分:1)

  

我的第一个问题是:所有这些交互都应该在同一个集合中,还是应该按类型分开(就像在RDBMS中那样)?

我不会太了解您的数据大小,写入数量,读取数量,查询需求等等。是的,所有在一个集合中。

我不确定是否将它们分开是我如何在RDBMS中设计它。

  

"这是"倍增"手动参考有意义还是有更好的方法来做到这一点?"

不,它没有为我做出声音数据库设计。

在交互集合文档上放置user_id听起来不错。

因此,当您想要获得所有用户互动时,您只需通过互动集合user_id进行查询。

当您想要以相反的方式执行此操作时,查询适合您的查询区域的所有交互,提取这些user_id,然后对用户集合执行$in子句。

答案 1 :(得分:0)

  

我的第一个问题是:所有这些交互都应该在同一个集合中,还是应该按类型分开(就像在RDBMS中那样)?

文档存储对关系数据库的最大优势正是您可以这样做。将所有不同的交互放入一个集合中,不要害怕给它们不同的字段集。

  

此外,我希望能够查找:

     
    

特定用户的所有互动

  
     

我正在考虑为用户在其文档中执行的每个交互添加手动引用交互文档,以及对在每个交互文档中执行交互的用户进行手动引用。

请注意,拥有无限增长的文档通常不是一个好主意。 MongoDB具有文档大小的上限(默认值:16MB)。 MongoDB不擅长处理大型文档,因为文档完全加载到ram缓存中。当你有许多大型对象时,不会有太多适合缓存的对象。此外,当文档增长时,有时需要将它们移动到另一个硬盘驱动器位置,这会减慢更新速度(同时也会使用natural ordering,但不管怎样你都不应该依赖它。)

  
    

已进行特定互动的所有用户

  

您指的是特定的交互实例(假设多个用户可以是一个交互的一部分)或已经执行了特定交互类型的所有用户?

在后一种情况下,我想补充执行的交互类型的用户文档的数组,因为否则你将不得不执行连结状操作,这要么需要的MapReduce或一些应用双面逻辑

与Sammaye建议的相反,第一种情况我建议不要使用用户集合的_id字段,而是使用用户名。当您在user.username上使用具有唯一标志的索引时,它与使用user._id进行搜索一样快,并且保证唯一性。

原因是当您搜索特定用户的交互时,您更有可能知道用户名而不是ID。当您只有用户名并且您通过id引用用户时,首先必须搜索users集合以获取用户名的_id,这是一个额外的数据库查询。

这当然假设您并不总是拥有user._id。当你这样做时,你当然可以使用_id作为参考。