Нужен совет по схеме MongoDB для приложения чата. Встроенные и связанные документы

Question

Я запускаю проект MongoDB просто для удовольствия и как шанс изучить схемы MongoDB / NoSQL. Это будет приложение для живого чата, а в стек входят: Rails 3, Ruby 1.9.2, Devise, Mongoid / MongoDB, CarrierWave, Redis, JQuery.

Я буду обрабатывать опросы чатов / очереди сообщений отдельно. Пока не знаете, как это сделать: Node.js, APE или пользовательское приложение EventMachine. Но что касается Монго, я думаю использовать его для всего остального в приложении, в частности, для журналов чата и исторических записей.

Мой вопрос заключается в том, как лучше всего спроектировать схему, поскольку весь мой предыдущий опыт был с MySQL и схемами реляционных БД. И как подвопрос, когда нам лучше внедрить документы, чем связанные документы.

Приложение будет иметь:

• Несколько аккаунтов с несколькими комнатами
• Несколько номеров
• Несколько пользователей на номер
• Список номеров, в которых пользователю разрешено находиться
• Несколько пользовательских чатов на номер
• Доступные для поиска журналы чата для каждой комнаты и для каждого пользователя
• Дополнительное вложение файла для данного чата

Учитывая, что Mongo (по крайней мере, в прошлый раз, когда я проверял) имеет лимит документов 4 МБ, я не думаю, что иметь коллекцию для комнат и хранить все комнатные чаты, поскольку встроенные документы сработают так хорошо.

Из того, о чем я думал до сих пор, я думаю сделать что-то вроде:

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

Моя главная проблема в том, как далеко я зайду, пока это не станет похожим на реляционную схему, и я не одержу победу над целью? Определенно, здесь происходит нечто большее, чем встраивание.

Другая проблема заключается в том, что ссылки на связанные документы намного медленнее, чем доступ к встроенным документам, которые я слышал.

Я хочу сделать общие запросы, такие как:

• Дайте мне все комнаты для учетной записи
• Дайте мне все чаты в комнате (или отфильтрованные по диапазону дат)
• Дайте мне все чаты от определенного пользователя
• Дайте мне все загруженные файлы в данной комнате или для данной организации
• и т.д.

Есть предложения о том, как эффективно структурировать схему таким образом, чтобы она масштабировалась? Спасибо всем.

Answer 1

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

Единственное другое изменение, которое я бы предложил, это сохранить загрузки в отдельной коллекции.

Answer 2

Я большой поклонник mongodb в качестве базы данных документов.Но вы уверены, что используете mongodb по правильной причине?В чем сила mongodb?

Это субъективный вопрос, но для меня обновление на месте (атомарное) документов - это то, что делает mongodb мощным.И я не могу видеть, чтобы ты использовал это так много.И вдобавок ко всему, вы также сталкиваетесь с проблемой ограничения размера документа (с опытом я могу сказать, что встраивание файлов в mongodb не очень хорошая идея).Вы также хотите иметь приложение для чата в реальном времени поверх базы данных.

Схема вашего документа выглядит логичной.Но я бы не стал использовать mongodb для такого рода проектов, где ваше приложение сильно зависит от вставок.Я бы выбрал CouchDB.

С CouchDB вам не придется беспокоиться о проблеме вложений, вы можете легко их встраивать.«_changes» сделает вашу жизнь намного проще, если вы просто создадите приложение для чата в реальном времени / поисковик с длинным пулом / подачей (если вы захотите его реализовать).

И я увидел демонстрационный проект с открытым исходным кодом. в кушоне.Это имеет некоторые сходства с вашими целями: Anologue .Вы должны это проверить.

PS: Извините, это было немного не по теме, но я не мог удержаться.