Какова хорошая структура документа MongoDB для наиболее эффективного запроса подписчиков/фолловеров пользователей?
Меня интересовала идеальная структура документа для максимальной эффективности запросов в различных ситуациях, и я хочу задать один вопрос. Это действительно подтверждается тем, что я действительно не знаю, как MongoDB ведет себя в памяти в этом конкретном случае. Позвольте мне предложить вам гипотетический сценарий.
Представьте себе систему подписчиков и подписчиков в стиле Twitter -. После, по общему признанию, беглого взгляда основные варианты кажутся:
В каждом пользовательском документе массив «followers», содержащий ссылки на все документы других пользователей, на которые они подписаны. Подписчиков можно найти, найдя нашего текущего пользователя в массиве «user.followers» других пользователей. Основным недостатком, по-видимому, являются потенциальные накладные расходы на поиск Followee. Кроме того, для запроса содержимого «user.followers»MongoDB просто обращается к требуемому полю в документах пользователей, или найден весь пользовательский документ, а затем оттуда просматриваются требуемые значения полей, и это кэшируется/хранится таким образом, что запрос по большой пользовательской базе потребует значительных больше памяти?
В каждом пользовательском документе хранятся как «последователи», так и «подписчики» для более быстрого доступа к каждому из них. Это, очевидно, имеет обратную сторону дублирования данных в том смысле, что запись для пользователя A, следующая за пользователем B, существует в обоих пользовательских документах в соответствующем поле, а удаление из from требует соответствующего удаления в другом. Технически это может означать удвоение количества точек потенциального отказа для простого удаления. И страдает ли MongoDB до сих пор от того, что я слышал как «швейцарский чизинг» памяти -хранимых данных, когда происходят удаления, и поэтому удаление из 2 полей, а не из 1, удваивает эффект этой проблемы с дырой в памяти?
Отдельная коллекция для хранения подписчиков пользователей, запрашиваемая аналогично документам пользователя в 1 -, за исключением того, что, очевидно, единственным доступом к данным являются подписчики, поэтому, если документы пользователя содержат довольно много других данных, относящихся к каждому пользователю, мы избегаем доступа к этим данным. Это, кажется, имеет что-то вроде реляционной базы данных, и хотя я знаю, что это не всегда ужасный подход только из принципа, очевидно, если один из других подходов, упомянутых (или тот, который я не рассматривал ), лучше под архитектурой Монго я хотел бы учиться!
Если у кого-то есть какие-либо мысли по этому поводу, или кто-то хочет сказать мне, что я где-то пропустил очень важную и очевидную страницу документации, или даже хочет сказать мне, что я просто веду себя глупо (с объяснением, почему, пожалуйста ;))Я хотел бы услышать от вас!