MongoDB, C # и NoRM + денормализация

Question

Я пытаюсь использовать MongoDB, C # и NoRM для работы над некоторыми примерами проектов, но в этот момент мне гораздо труднее сосредоточиться на модели данных. С данными, относящимися к РСУБД, проблем нет. Однако в MongoDB мне трудно решить, что с ними делать.

Давайте использовать StackOverflow в качестве примера ... У меня нет проблем с пониманием, что большинство данных на странице вопроса должны быть включены в один документ. Заголовок, текст вопроса, исправления, комментарии ... все хорошо в одном объекте документа.

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

Каков наиболее эффективный способ установить отношения с пользователем, не вызывая при этом тонны запросов при каждой загрузке страницы? Я заметил тип DbReference<T> в NoRM, но пока не нашел хорошего способа его использования. Что если у меня есть необязательные необязательные отношения?

Спасибо за понимание!

Answer 1

Баланс, который я нашел, использует SQL в качестве нормализованной базы данных и Mongo в качестве денормализованной копии. Я использую ESB, чтобы держать их в синхронизации друг с другом. Я использую концепцию, которую я называю «подготовленные документы» и «хранимые документы». Сохраненные документы - это данные, которые хранятся только в монго. Полезно для данных, которые не являются реляционными. Подготовленные документы содержат данные, которые могут быть восстановлены с использованием данных в нормализованной базе данных. Они действуют как живые кэши в некотором смысле - их можно восстановить с нуля, если данные когда-либо не синхронизируются (в сложных документах это дорогостоящий процесс, поскольку эти документы требуют много запросов для перестройки). Они также могут обновляться по одному полю за раз. Это где служебная шина входит. Она отвечает на события, отправленные после обновления нормализованной базы данных, а затем обновляет соответствующие документы, подготовленные монго.

Используйте каждую базу данных в своих сильных сторонах. Разрешить SQL быть базой данных записи, которая обеспечивает целостность данных. Пусть Mongo будет базой данных только для чтения, которая работает быстро и может содержать вложенные документы, так что вам нужно меньше запросов.

** РЕДАКТИРОВАТЬ ** Я просто перечитал ваш вопрос и понял, что вы на самом деле просили. Я оставляю свой первоначальный ответ на случай, если он вообще пригодится.

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

Затем вы просмотрите данные комментария и извлечете массив идентификаторов пользователей, которые вам нужно загрузить. Затем загрузите их как пакетный запрос (используя оператор запроса Q.In ()). Это всего два запроса. Затем вам нужно будет объединить данные в окончательную форму. Необходимо соблюдать баланс между тем, когда это нужно делать, и тем, когда нужно использовать что-то вроде ESB для обновления каждого документа вручную. Используйте то, что лучше всего подходит для каждого отдельного сценария вашей структуры данных.

Answer 2

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

Answer 3

Я думаю, вам нужно соблюсти баланс.

На вашем месте я бы просто указывал идентификатор пользователя вместо их имени / репутации в каждом сообщении.

В отличие от СУБД, вы бы предпочли, чтобы комментарии были встроены в документ.

Answer 4

Почему вы хотите избежать денормализации и обновления «тысяч записей документов»? Mongodb db предназначен для денормализации. Stackoverlow обрабатывает миллионы различных данных в фоновом режиме. И некоторые данные могут быть устаревшими в течение короткого периода времени, и это нормально.

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

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

Также я предлагаю взглянуть на архитектуру cqrs .