Структура данных MongoDB с большим количеством внутренних документов - PullRequest
Новая
       12

Структура данных MongoDB с большим количеством внутренних документов

0 голосов
/ 17 февраля 2012

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

Надеюсь, я не слишком расплывчен, но не хочу быть слишком конкретным и слишком конкретнымдалеко по неверному пути, вплоть до настройки моей модели предметной области.

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

| USER |
--------
|ID
|Name
|Etc.

|TWEET__|
---------
|ID
|UserID
|Etc

Кажется, что логическая схема в Mongo будет 

User
|-Tweet (0..3000)
  |-Entities
    |-Hashtags (0..10+)
    |-urls (0..5)
    |-user_mentions (0..12)
  |-GeoData (0..20)
|-somegroupID

, но это не приведет к быстрому разрастанию документа User за пределы возможностей.Но я хотел бы провести анализ твитов, принадлежащих пользователям с похожим somegroupID.Это концептуально имеет смысл для макета модели, как указано выше, но в какой момент это слишком неудобно?И каковы жизнеспособные альтернативы?

Ответы [ 2 ]

1 голос
/ 23 февраля 2012

Вся заслуга прекрасных людей на MongoHQ.com. На мой вопрос ответили https://groups.google.com/d/msg/mongodb-user/OtEOD5Kt4sI/qQg68aJH4VIJ

Крис Уинслетт @ MongoHQ

Вы найдете это видео интересным:

http://www.10gen.com/presentations/mongosv-2011/schema-design-at-scale

По сути, в одном документе храните твиты на один день для одного человек. Рассуждение:

  • Запросы обычно состоят из дней и пользователей

Следовательно, вы можете иметь следующий индекс:

{user_id: 1, date: 1} # Дата должна быть последней, потому что вы будете в диапазоне и сортировать по дате

Веселись!

Крис МонгоHQ

Я думаю, что имеет смысл реализовать следующее:

Пользователь 

{ user_id: 123123,
  screen_name: 'cledwyn',
  misc_bits: {...},
  groups: [123123_group_tall_people, 123123_group_techies, ],
  groups_in: [123123_group_tall_people]
}

твит 

{ tweet_id: 98798798798987987987987,
  user_id: 123123,
  tweet_date: 20120220,
  text: 'MongoDB is pretty sweet',
  misc_bits: {...},
  groups_in: [123123_group_tall_people]
}
1 голос
/ 17 февраля 2012

Вы правы, что вы, вероятно, столкнетесь с лимитом документов MongoDB в 16 МБ здесь. Вы не говорите, какой анализ вы хотели бы провести, поэтому сложно рекомендовать схему. Схемы MongoDB разрабатываются с учетом шаблонов запроса данных (и вставки).

Вместо того, чтобы помещать свои твиты в пользователя, вы, конечно, можете довольно легко сделать обратное, добавить идентификатор пользователя и идентификатор группы в сами документы твита. Затем, если вам нужны дополнительные поля от пользователя, вы всегда можете получить их во втором запросе при отображении.

Я имею в виду дизайн для твита документа как: 

{
    'hashtags': [ '#foo', '#bar' ],
    'urls': [ "http://url1.example.com", 'http://url2.example.com' ],
    'user_mentions' : [ 'queen_uk' ],
    'geodata': { ... },
    'userid': 'derickr',
    'somegroupid' : 40
}

А затем для пользовательской коллекции документы могут выглядеть следующим образом: 

{
    'userid' : 'derickr',
    'realname' : Derick Rethans',
    ...
}
...