MongoDB的架构设计语言数据库

我需要的MongoDB架构设计的一些建议了自然语言数据库。MongoDB的架构设计语言数据库

我需要存储为每种语言文字和文字，如：

lang: { 
    _id: "English", 
    texts : [ 
     { text : "This is a first text", 
      date : Date("2011-09-19T04:00:10.112Z"), 
      tag : "test1" 
     }, 
     { text : "Second One", 
      date : Date("2011-09-19T04:00:10.112Z"), 
      tag : "test2" 
     } 
    ], 
    words : [ 
     { 
      word : "This", 
     }, 
     { 
      word : "is", 
     }, 
     { 
      word : "a", 
     }, 
     { 
      word : "first", 
     }, 
     { 
      word : "text", 
     }, 
     { 
      word : "second", 
     }, 
     { 
      word : "one", 
     } 


    ] 

}

然后我需要知道每个单词和文本用户有关联。单词/文本数量往往很大，我需要列出一种语言的所有单词以及用户为该语言关联的所有单词。

从我的角度我认为存储与给定词的单词的数组相关的user_ids也许是一个好办法，如：

lang: { 
    _id: "English", 
    texts : [ 
       ... 
    ], 
    words : [ 
     { 
      word : "This", 
      users: [user1,user2,user3] 
     }, 
     { 
      word : "is", 
       users: [user1,user2] 
       }, 
       ... 
    ] 
}

铭记，一个字可以关联到数百用户和文件限制（因为我读）为4MB和千，我需要：

名单给定用户和语言

所有单词10

这是一个好方法吗？或者你能想到一个更好的？

希望这个问题不够清楚，有人可以给我这样的帮助;）

谢谢大家！

来源

2012-05-21 jribeiro

我不认为这是一个好方法，只是你提到的原因是：该文件的大小限制。它看起来像你的方法，你肯定会跑到极限。我会采取更扁平的方式（这也会使您的收藏更容易查询）。事情是这样的：

[ 
    { 
     user: "user1", 
     word: "This", 
     lang: "en" 
    }, 
    { 
     user: "user1", 
     word: "is", 
     lang: "en" 
    }, 
    // et cetera... 
]

换句话说，通过将文件而不是水平通过添加更多的数据到一个文档垂直增长。你可以用db.find（{user：“user1”，lang：“en”}）查询给定用户的单词。。

这种做法是不是“正常化”，当然，如果你很在意空间，那么你可能要为用户创建，文字和语言分开收集，并通过ID引用它们的主要收集。但是，由于没有加入的MongoDB查询，你必须权衡空间效率的查询性能。

来源

2012-05-21 01:14:27 McGarnagle

这意味着，如果你需要单词“this”与user1和user2相关联，否则你必须在单词集合上正确地记录文档？ – jribeiro

是的，正确的，我的意思是一个完全平坦的结构，所以如果user1和user2都有“this”和“that”，那么你最终会收集4个文档。 – McGarnagle

我明白了。因此，如果我理解正确，以避免文档限制，并考虑到用户将有一千字的话，我可以有用户，文本和单词共享，并具有如上所述的文档。对？ – jribeiro

dbaseman是正确的（和upvoted），但其他几个要点：

首先，文件限制现在为16MB（3210），截至记者发稿，假设你运行的是最新的MongoDB versionof。

二，无限生长通常是在MongoDB中一个坏主意，这种类型的文档尺寸扩张可引起MongoDB的具有移动文件，如果超过分配给它的当前空间。您可以在文档的Padding Factor部分阅读更多关于此的信息。

这些类型的动作是比较昂贵的，特别是如果他们频繁发生。因此，如果你确实采用这种类型的设计来限制你的主要集合（最新的X，最流行的X等等）中相当于评论的大小（基本上限制了这种增长）），甚至可能会将文档字段（基本上手动填充）预填充到平均大小以外，从而减少导致添加/更改的移动。

这就是为什么在O'Reilly出版MongoDB的开发技巧和窍门书提示＃6的原因是：

提示＃6：有未绑定的增长不嵌入领域

来源

2012-05-21 11:33:21

+1供参考“MongoDB Developers tips” – jribeiro

MongoDB的架构设计语言数据库

回答

相关问题