Структура базы данных NoSQL для социального приложения (лайки видны только общим друзьям)

Question

Создание приложения реагирования с Firebase FireStore, где пользователи могут дружить друг с другом и ставить оценки друг другу.Тем не менее, вы можете видеть только голоса, поданные общими друзьями.

Т.е.: если Бобу нравится пост Джо.

Если я дружу с Джо и Бобом, я вижу, что Боб похож.

Если я дружу только с Джо, я не вижу Боба, как.

Как мне структурировать мои данные?Я планирую создать PostFeeds для каждого пользователя:

— PostFeed (collection)
     — Uid (document)
         — Posts (collection)
              — Likes (collection)

Если я напишу новый пост, он будет добавлен во все фиды постов моих друзей.Если у меня 1000 друзей, это сообщение будет добавлено в 1000 каналов.

Я сохраняю лайки для каждого поста внутри каждого поста в PostFeed.Таким образом, мы можем получать лайки без дополнительного запроса.Так что, если Боб любит публикацию сообщений joes, он будет добавлен к каждому сообщению в лентах сообщений друзей Джо.

Т.е.: если Джо любит запись Боба, а у Боба есть 500 друзей.Пост Боба находится на 500 друзей PostFeeds.Лайки Джо должны быть добавлены ко всем 500 постам в каждом посте.

Но лайки видны только в том случае, если мы общие друзья.

Т.е.: если Бобу нравится пост Джо, он будет добавлен в фид пользователей только в том случае, если мы общие друзья.Так что просмотрите посты Джо, где Боб - общий друг, и добавьте к ним подобные сообщения.

Это масштабируемо?Хотя большая часть записи выполняется в функциях Firebase, операция записи кажется очень дорогой.Особенно, если пользователь любит, не любит, а затем снова любит.Или, если я добавлю нового друга, мне нужно будет добавить все отклики, которые этот новый друг сделал в постах общих друзей.

Есть ли лучший способ справиться с этим?

Answer 1

У меня был соблазн не написать решающий ответ на этот вопрос, но после возвращения к вопросу я склоняюсь к тому, что не масштабируется.Конечно, вы можете утверждать, что Firebase может идти в ногу с этим и воздавать должное Firebase, если это возможно, но цифры кажутся слишком большими, чтобы игнорировать то, что это, вероятно, не лучшее использование ресурсов.

Давайте рассмотрим этот пример:

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

Если у меня 500 подписчиков, и мне нравится 20 вещей за один день,это 10000 раз, я проверяю, не является ли кто-то моим другом, и 10000 раз я пишу в БД просто так.Я надеюсь, что вы ожидаете более 20 друзей.

Я думаю, что альтернатива, если вы строите с учетом масштаба, может ли данные быть сохранены таким образом, чтобы разрешать вызовы, которые выполняются во время выполнениявместо того, чтобы хранить все эти данные?

Или, возможно, вначале начать с меньшего размера, можете ли вы сохранить локально список всех пользователей, с которыми я дружу, а затем вытащить список всех пользователей, которым понравилсяpost?

Для чего это стоит, если ваш пример верен для реального применения кода, я думаю, что это очень нетипичная ситуация, и многие пользователи увидят 0 или несколько «лайков» длякаждый пост.В некотором роде возникает вопрос, стоит ли сок выжать.