выбрать схему мангуста в приложении группового чата? - PullRequest
8 голосов
/ 03 мая 2019

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

В первом варианте это может быть показано как

var ChatMessageSchema = new Schema({
  fromUserId: ObjectId,
  toTroupeId: ObjectId, 
  text: String,
  sent: Date
}

, во втором варианте это может быть показано как

var ChatMessageSchema = new Schema({ 
  toTroupeId: ObjectId, 
  chats:[
     fromUserId: ObjectId,
     text: String,
     sent: Date
  ]
}

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

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

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

есть идеиэти варианты дизайна, является ли первый вариант оптимальным или как его оптимизировать?

Ответы [ 2 ]

1 голос
/ 23 мая 2019

MongoDB предназначен для обработки огромных объемов данных и их PDF Рекомендации по повышению производительности для MongoDB :

Avoir для больших документов

Что также ясно видно из предела 16 МБ.

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

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

1 голос
/ 17 мая 2019

Я бы предложил третий вариант; создание новой коллекции для каждой группы, например, room_$groupid. В такой коллекции вы можете вставить каждое сообщение отдельно. Это даст вам возможность получить полный чат без фильтра. Вы можете просто вернуть последние 200 или около того сообщений из коллекции.

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

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

Лимит сбора *

...