Мы рассмотрели несколько архитектур MongoDB и пытаемся понять, есть ли стратегия / подход, о которых мы не думаем, или лучше, чем то, о чем мы думаем.
У каждого пользователя есть документ со всей информацией о пользователе. Одно из полей в userDo c имеет объект релевантного времени элемента (ожидающая транзакция, которая является самой последней) и имеет социальные счета. Эти значения могут быть довольно высокими, 100k +, но также часто могут быть довольно низкими. Счетчики состоят из общего подсчета (отображается на верхнем уровне в приложении) и идентификаторов пользователей, которым он понравился, который отображается при нажатии в приложении.
Когда у пользователя есть новая транзакция, поэтому мы не t залить userDo c вверх, мы рассматриваем два варианта; сделайте документ для каждой транзакции, в которой есть счетчик, и справочный документ из него для идентификаторов пользователей, которым это понравилось. Или поместите все транзакции в один do c для пользователя *, но не в userDo c, а затем у каждой будет ссылочный do c для идентификаторов пользователей, которым он понравился.
В любом случае мы будем хранить одну последнюю ожидающую транзакцию в userDo c, поэтому нам нужно только заставить userDo c отображать клиентскую сторону (мы чаще всего просто отображаем эту транзакцию с социальными счетами) .
Дисковый ввод-вывод в масштабе, требующий обновления подсчетов в более высоком документе, вызывает беспокойство, и что произойдет, если транзакция в userDo c (ожидающая текущая) станет в редких 5% случаях слишком большой для userDo c, будет ли триггер сработать для создания спецификации c do c для этой транзакции?