MongoDB - проект схемы отношений «многие ко многим / немногим к немногим» без проблем с производительностью поиска

Question

Мы разрабатываем приложение, которое в основном работает аналогично Instagram, но с groups. Пользователи могут приглашать других пользователей в группы. Члены группы делятся posts фотографиями, мультимедиа и т. Д. У пользователя есть feed со всеми сообщениями, недавно опубликованными в группах, с подкачкой страниц. Пользователи также могут получать доступ к сообщениям внутри групп.

feed query медленный из-за характера нашей текущей схемы. На практике время запроса будет увеличиваться с увеличением объема данных, что не очень хорошо масштабируется сейчас, когда мы видим больше пользователей на платформе.

Вопрос 1 Как лучше всего смоделировать наши данные, используя MongoDB, чтобы сделать наш запрос фида более быстрым и масштабируемым?

Наш текущий бэкэнд построен с использованием Parse Server с MongoDB и Node.js

A simplified version of our schema is as follows:

Class/Document
    - Attribute

Users
    -  id
Group
    - id
    - members (array of user pointer objects)- basically an array of ids
    - admins (array of user pointer objects) - basically an array of ids
    - createdBy (pointer to user object) - basically an id of the owner of the group
Posts
    - id
    - groups (array of group pointer objects) - basically an array of ids

Итак, сейчас, когда мы хотим получить posts в пользовательском feed, мы должны пройти следующий процесс:

1. Просмотрите все groups, проверив массивы членов / администраторов группы для пользователя, и получите все группы для пользователя
2. Просмотрите все posts, проверив массив групп сообщений, чтобы узнать, должен ли он быть в ленте.

Возможное решение вопроса 1 ( MongoDB - отношение многие ко многим? )

Это будет означать:

1. В User class есть group array (указатели для группирования объектов), указывающие на группы, где пользователь является администратором / участником или владельцем. Имейте, как и прежде, массивы member / admin и создали Byy в классе Group.

2. Имейте post array (указатели для размещения объектов) в Group class. Иметь, как и прежде, массив groups в классе Post.

   This would translate into the following schema:  
   
   Class/Document
       - Attribute
   Users
       -  id
       - groups (array of group pointer objects, where the user is either admin/member or owner) - basically an array of ids
   Group
       - id
       - members (array of user pointer objects)- basically an array of ids
       - admins (array of user pointer objects) - basically an array of ids
       - createdBy (pointerObject to user) - basically an id of the owner of the group
       - posts (array of post pointer objects) - basically an array of ids
   Posts
       - id
       - groups (array of group pointer objects) - basically an array of ids
   

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

Вопрос 2 Целесообразно ли использовать MongoDB в долгосрочной перспективе для нашего типа приложений или нам следует перейти, например, к PostgreSQL? (Я немного предвзят, поскольку я больше работаю с RDMS- чем базы данных NoSQL)

Мы также продолжим расширять интерфейс статистики для отображения различных действий и их stats в groups, и мы прогнозируем, что у нас будет больше many-to-many ситуаций или few-to-few отношений. Мы начали экспериментировать, добавляя PostgreSQL к смеси. Mirroring данные в MongoDB с PostgreSQL и использование SQL для некоторых из вышеперечисленных запросов, которые плохо масштабируются с нашей текущей схемой в MongoDB. Мы также думаем о постепенном переходе на PostgreSQL. Однако это может быть преждевременным решением, если мы сможем заставить все работать хорошо с MongoDB. Поскольку мы продолжим расширять наш интерфейс статистики, лучше ли перейти к использованию RDMS, такой как PostgreSQL?

Вся помощь приветствуется. Хорошего дня!