MongoDB / NOSQL: лучший подход к обработке прочитанного / непрочитанного статуса в сообщениях

Question

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

В Stackru есть несколько вопросов, задающих этот вопрос для реляционных баз данных, но я не видел ни одного с рекомендациями для баз данных документов:

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

Внедрение эффективной системы счетчиков "непрочитанных комментариев"

Обычно ответы включают таблицу со списком всего, что прочитал пользователь: (т. Е. Наборы идентификатора пользователя, идентификатора документа) с некоторыми возможными оптимизациями для даты отсечения, позволяющей пометить все как прочитанное, чтобы стереть базу данных и начать заново, зная, что что-нибудь до этой даты "читать".

Итак, эксперты MongoDB / NOSQL, какие подходы вы видели на практике для решения этой проблемы и как они работали?

Answer 1

{
_id: messagePrefs_uniqueId,
type: 'prefs',
timestamp: unix_timestamp
ownerId: receipientId,
messageId: messageId,
read: true / false,
}

{
_id: message_uniqueId,
timestamp: unix_timestamp
type: 'message',
contents: 'this is the message',
senderId: senderId,
recipients: [receipientId1,receipientId2]
}

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

db.messages.find({
messageId : { $in : [messageId1,messageId2,messageId3]},
ownerId: receipientId, 
type:'prefs'
})

Если вам нужно только чтение / непрочитанное, вы можете использовать это с возможностями upsert MongoDB, поэтому вы не создаете prefs для каждого сообщения, если пользователь фактически не читает его, тогда в основном вы создаете объект prefs со своим собственным уникальным идентификатором и вставляете его в MongoDB, Если вам нужна большая гибкость (например, теги или папки), вы, вероятно, захотите сделать преф для каждого получателя сообщения. Например, вы можете добавить:

tags: ['inbox','tech stuff']

к объекту prefs, а затем, чтобы получить все prefs всех сообщений, помеченных как "технические вещи", вы должны сделать что-то вроде:

db.messages.find({type: 'prefs', ownerId: recipientId, tags: 'tech stuff'})

Затем вы можете использовать messageIds, которые вы найдете в prefs, для запроса и поиска всех сообщений, которые соответствуют:

db.messages.find((type:'message', _id: { $in : [array of messageIds from prefs]}})

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

Answer 2

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

{
  _id: 'document#42',
  ...
  read_by: ['user#83', 'user#2702']
}

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

db.documents.find({read_by: 'user#83'})

db.documents.find({_id: 'document#42}, {read_by: 1})

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