2012-05-21 3 views
1

Мне нужен совет по дизайну схемы MongoDB для базы данных на естественном языке.MongoDB Schema Design для базы данных языков

Мне нужно хранить для каждого текста языка и слов, как:

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 и что мне нужно:

  1. Список всех слов для данного пользователя и языка

Это хороший подход? Или вы можете подумать о лучшем?

Надежда этот вопрос достаточно ясно, и что кто-то может дать мне справку по этому вопросу;)

Спасибо всем!

ответ

4

Я не думаю, что это хороший подход, потому что вы только указываете: ограничение размера документа. Похоже, с вашим подходом вы наверняка столкнетесь с лимитом. Я бы пошел на более плоский подход (который также должен облегчить запрос вашей коллекции). Что-то вроде этого:

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

Другими словами, растут вертикально, добавляя документы, а не горизонтально, добавляя больше данных в одном документе. Вы можете запросить слова для данного пользователя с помощью db.find ({user: "user1", lang: "en"});.

Этот подход не является «нормализованным», конечно, поэтому, если вы обеспокоены пространством, вы можете создать отдельную коллекцию для пользователей, слов и языков и ссылаться на них в основной коллекции по идентификатору , Но так как нет присоединяйтесь к запросам в MongoDB, вам нужно взвесить производительность запросов против эффективности пространства.

+0

это означает, что если вы нужно, чтобы слово «это» ассоциировалось с user1 и user2, вам нужно будет иметь документы на сборке слов правильно? – jribeiro

+0

Да, правильно, я имел в виду абсолютно плоскую структуру, поэтому, если у user1 и user2 у каждого есть «это» и «это», тогда у вас будет 4 документа в коллекции. – McGarnagle

+0

Я вижу. Поэтому, если я правильно понимаю, чтобы избежать ограничения этих документов и принимая во внимание, что у пользователя будет тысяча слов, у меня могут быть пользователи, тексты и сборники слов, а также документы, представленные, как вы говорите выше. Правильно? – jribeiro

1

dbaseman правильно (и upvoted), но несколько других пунктов:

Во-первых, предельный документ 16МБ (Max Document Size), так как это письмо, если вы работаете в последнее время versionof MongoDB.

Во-вторых, неограниченный рост, как правило, является плохой идеей в MongoDB, этот тип расширения размера документа может заставить MongoDB перемещать документ, если он превышает текущее пространство, выделенное для него. Подробнее об этом можно узнать в разделе документации Padding Factor.

Эти типы перемещений относительно дороги, особенно если они происходят часто. Поэтому, если вы идете с этим типом дизайна, ограничивающим размер (существенно ограничивающий этот рост) эквивалентных комментариев в вашей основной коллекции (самый последний X, самый популярный X и т. Д.) и, возможно, даже предварительное заполнение этого поля документа (по существу, ручное заполнение) до среднего размера уменьшит ход, вызванный добавлением/изменением.

Это является причиной того, почему Совет № 6 в MongoDB разработчиков советы и приемы, книги от O'Reilly является:

Совет # 6: Не вставлять поля, имеющие несвязанный рост

+0

+1 для ссылки на «Советы разработчиков MongoDB» – jribeiro

Смежные вопросы