Имитация отношений в MongoDB

Question

Будучи одним из самых популярных NoSQL-решений, MongoDB обладает большинством преимуществ этого подхода.Но одна проблема, с которой я все еще сталкиваюсь, заключается в том, как отразить объектные отношения в хранилище данных NoSQL, в частности - MongoDB.

Например, давайте рассмотрим простую модель данных: User, Post и Comment.Мне ясно, что комментарии не имеют никакой ценности сами по себе и, следовательно, становятся встроенными объектами для сообщений.Но когда дело доходит до пользователей - это становится сложнее, потому что Пользователь является сущностью, не связанной с Почтой.Теперь, если мне нужно вывести список сообщений с полными именами пользователей и ссылками на профили на веб-странице, мне потребуется список сообщений и информация об авторах сообщений (по крайней мере, имя и идентификатор).

Iсм. 2 возможных решения здесь:

1. Денормализуйте данные таким образом, чтобы каждая запись в записи содержала идентификатор автора и полное имя (и любые другие атрибуты пользователя, которые могут понадобиться мне при перечислении записей).Таким образом, я бы сделал запрос данных очень простым, но когда каждый пользователь обновляет свой профиль, мне также необходимо обновить все сообщения пользователя.Но тогда мне нужно также хранить атрибуты пользователя в объектах комментариев, что означает, что обновление профиля пользователя по сути требует от меня обновления всех сообщений, которые содержат хотя бы один комментарий пользователя, если я не хочу хранить комментарии в отдельных коллекциях.
2. Сохраняйте только идентификатор пользователя в объекте публикации и выполняйте 2 запроса: один для получения списка сообщений и другой для получения списка пользователей, в которых идентификатор пользователя находится в списке авторов сообщений.Это требует 2 запроса и дополнительной обработки в коде моего приложения, чтобы сопоставить пользователей с сообщениями.

Я уверен, что я не первый, кто сталкивается с этой проблемой, но, к сожалению, я не нашел лучших практикна эту тему пока.Мнения?

Answer 1

Оба являются допустимыми решениями, преимущество решения 1 заключается в том, что вы можете показать страницу, подобную этой, с получением только одного документа из БД.Пользователи не обновляют свой профиль очень часто, и вы можете обновить все посты и встроенные комментарии асинхронно после изменения профиля пользователя.Вы можете индексировать сообщения и встроенные комментарии по идентификатору пользователя, поэтому обновление должно быть быстрым.Обновление в mongodb очень быстрое, потому что mongodb выполняет обновление на месте, и вы не можете откатить или зафиксировать, чтобы mongodb не регистрировал изменения.

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

Решение 2 требует извлечения большего количества документов на страницу, однако вы можете использовать оператор $ in со списком идентификаторов пользователей (идентификатор пользователя записей + комментарии пользователей), поэтому вам нужно только два «оператора выбора».

Answer 2

Я столкнулся с подобной проблемой, и вот как я ее решил:

(Когда я решил эту проблему, моей мотивацией было избегать объединений)

используйте 2 отдельных сбора: один для ПОЛЬЗОВАТЕЛЕЙ и один для ПОСТОВ. Храните пользовательский объект вместе с постом в коллекциях постов. Не обновляйте коллекцию сообщений при изменении объекта пользователя. поддерживать пользовательскую информацию в коллекции USERS. Конечно, данные постов в конечном итоге будут содержать устаревшую информацию о пользователе, но как часто пользователь меняет свой профиль.

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

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