Как мне структурировать схему данных MongoDB?

Question

У меня есть система чата, и я хочу использовать MongoDB в качестве базы данных. Ниже перечислены объекты:

• Комната - чат (room_id)
• Пользователь - пользователь в чате (room_id, user_name)
• Msg - сообщение в чате (room_id, user_name, message)

Для разработки схемы у меня есть несколько идей: во-первых, 3 коллекции - комната, пользователь и msgs - и есть родительская ссылка в документах user и msg.

Другая идея заключается в создании коллекций для каждой комнаты. Такие как

• db.chatroom.victor
  • db.chatroom.victor.users
  • db.chatroom.victor.msgs
• db.chatroom.john
  • db.chatroom.john.users
  • db.chatroom.john.msgs
• db.chatroom.tom
  • db.chatroom.tom.users
  • db.chatroom.tom.msgs

...

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

Спасибо.

Answer 1

Вы всегда должны разрабатывать свою схему, отвечая на 2 вопроса:

• какие данные я должен хранить?(временно / постоянно)
• как я получу доступ к этим данным?(много прочтений по этому поводу, много записей по этому поводу, случайное число здесь)

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

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

, просто создавая дизайнздравый смысл и у тебя все будет хорошо

Answer 2

Вы определенно не хотите вставлять сообщения в другие документы. Они нуждаются в для хранения в виде отдельных документов.

Я говорю это, потому что MongoDB выделяет определенное количество места для каждого документа, который он пишет. Когда он пишет документ, он берет его текущий размер и добавляет к документу некоторое пустое пространство (заполнение), так что если он на самом деле имеет размер 1 КБ, он может стать большим 1,5 КБ, чтобы оставить место для увеличения размера документа.

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

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

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

Answer 3

Подумайте обо всех случаях использования.Какие типы запросов вы хотите выполнить?

• «Покажите мне комнаты, где пользователь общается».Это не будет работать с текущей схемой, и вам нужно добавить список комнат для пользователя или отдельную коллекцию, чтобы она работала.
• "Показать все сообщения, отправленные пользователем во всехкомнаты".Это, опять же, не будет работать.
• "Удалить всех незанятых пользователей из всех комнат".С предложенной схемой вы должны выполнить этот запрос для каждой коллекции room.users.

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

С 100 пользователями вы можете даже встроить это в объект комнаты в виде массива.Просто убедитесь, что есть индекс.