Подтвердить что ты не робот

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

Ответ 2

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

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

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

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

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

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