Лучшая схема MongoDB для твиттер-клона?

Question

Я знаю, что подобные вопросы задавались, но я искал очень простой ответ на основной вопрос.Я новичок в MongoDB и создаю приложение в стиле твиттера (блоги, подписчики и т. Д.), И мне интересно, какую схему лучше использовать.

Сейчас у меня есть (на очень высоком уровне):

Member {
  login: string,
  pass: string,
  posts: [
    {
      title: string,
      blog: string,
      comments: [ { comment: string } ]
    }
  ]
}

Есть еще кое-что, но это дает вам идею. Теперь проблема в том, что я ищу, чтобы добавить функцию «следовать», и я не уверен, что лучший путь.

Я мог бы добавить «следующий» встроенный документ вУчастник, но я просто не уверен, используя mongoDB, какой будет самый умный метод.Моим главным увлечением, очевидно, была бы главная страница «подачи», где вы видите всех людей, на которых вы подписаны.

Answer 1

Это не идеальная схема для клона Twitter.Основная проблема заключается в том, что «posts» - это постоянно растущий массив, что означает, что mongo будет вынужден перемещать ваш массивный документ каждые несколько постов, потому что в нем заканчивалось заполнение документа.Кроме того, существует жесткое ограничение (16 МБ) для документов, что в лучшем случае ограничивает эту схему.

Идеальная схема зависит от того, ожидаете ли вы загрузку Twitter.«Идеальная» схема mongodb с точки зрения удобства обслуживания и простоты использования отличается от той, которую я использовал бы для чего-то с пропускной способностью Twitter.Например, в первом случае я бы использовал коллекцию постов с документом на пост.В сценарии с высокой пропускной способностью я бы начал создавать групповые документы для небольших групп сообщений (скажем, по одной на страницу «получить больше»).Кроме того, в сценарии с высокой пропускной способностью вам придется поддерживать актуальность временной шкалы подписчика в отдельных документах временной шкалы пользователя, тогда как в сценариях с низкой пропускной способностью вы можете просто запросить их.

Answer 2

Добавление «следующего» массива в документ Member должно работать хорошо. Он должен содержать идентификаторы пользователей, за которыми подписался участник. Ваш код должен будет получить список и создать запрос, который извлекает твиты этих пользователей. Поскольку Mongo нереляционный, нет способа создать запрос, который объединяет коллекции Member и Tweet и делает это в одном запросе, но вы должны быть в состоянии уменьшить нагрузку на сеть, выполняя это на сервере базы данных, используя выполнение кода на стороне сервера : http://www.mongodb.org/display/DOCS/Server-side+Code+Execution.

Answer 3

Этот вопрос тот же, который широко используется в примере поста блога и как моделировать посты и комментарии блога. Вы просто должны применить те же понятия здесь. У вас есть следующие варианты:

• вложенные документы
• выделенные коллекции и выполнение нескольких запросов

Плюсы и минусы широко обсуждались. Размер встроенных документов может составлять всего 16 МБ, и невозможно вернуть отдельные части соответствующего массива в MongoDB ... сделайте свой выбор.

Не пойдем дальше, потому что, как сказано: один и тот же вопрос обсуждался в многочисленных вопросах о «дизайне схемы». Просто Google "Схема Дизайн MongoDB" или искать то же самое на SO.