mongo db дизайн подписчиков и каналов, куда мне встраивать?

Question

У меня есть основной вопрос о том, где я должен встраивать коллекцию подписчиков / подписчиков в базу данных Монго.Имеет смысл иметь встроенную коллекцию подписок в пользовательском объекте, но имеет ли смысл также встраивать коллекцию обратных последователей?Это означало бы, что мне придется обновить и вставить в запись профиля оба следующих элемента:

1. , следующий за встроенным списком в подписчике
2. И встроенный список подписчиков подписчика

Я не могу гарантировать атомарность, если я не сохраню транзакцию или не обновлю статус где-нибудь.Стоит ли встраивать их в обе сущности или я просто обновляю # 1, вставляю подписку в профиль подписчика и добавляю в нее индекс, чтобы можно было запрашивать конвертеры-последователи по всем профилям?Не слишком ли сильно сказывается производительность?

Является ли это кандидатом в коллекцию, которую нельзя встраивать?Должен ли я просто иметь коллекцию ребер, в которой я храню подписку в своей собственной коллекции с followerid и followbyId?

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

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

Answer 1

Как правило, вставлять следующие / сопровождаемые отношения в пользовательские документы по нескольким причинам плохая идея:

(1) максимальный размер документа составляет 16 МБ, и вполне вероятно, чтопопулярный пользователь хорошо подписанного сайта может получить сотни тысяч подписчиков, которые приблизятся к максимальному размеру документа,

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

Так что да, это такЛучше всего разбить следующее / сопровождаемое отношение на отдельную коллекцию записей, каждая из которых имеет два поля, например, {_id:, oid:}, с индексами _id (для запроса «за кем я следую?») и oid (для запроса «кто следует за мной?»).Любое отдельное изменение состояния моделируется добавлением или удалением одного документа, хотя, если вы также отображаете такие вещи, как число подписчиков, вам, вероятно, следует сохранять отдельные счетчики, которые вы обновляете после любой вставки / удаления ребра.

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