Эффективный способ проверки существующих связанных документов в NoSQL (Firestore)?

Question

после текущего Datamodell

User
  User ID

Video
   VideoID
   LikedBy (Subcol) 
       User ID
       User ID
       User ID

Теперь, если пользователь посещает видео, я хочу показать, понравилось ли ему видео или нет (похоже на цвет кнопки youtubes, если вам уже понравилось).

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

Это само по себе создало примерно 3х начальных чтений, которые я имею при загрузке страницы. Я хотел бы услышать, есть ли более эффективный способ запросить такую ​​вещь или структурировать данные.

Имейте в виду, что, если вы предлагаете мне сохранять все понравившиеся Шоу в Пользовательском или Шоу-документе, это не масштабируется из-за ограничения в 1 МБ.

Answer 1

Мой текущий подход - запрос документа с ключом подписанного идентификатора пользователя, и если я его найду, это означает, что видео понравилось пользователю.

Да, это правильный подход.

Это само по себе создало примерно в 3 раза больше начальных чтений, которые у меня есть при загрузке страницы.

Я не знаю, откуда это исходит, но, безусловно, что-то не так.К сожалению, ничто в вашем вопросе не может помочь мне увидеть проблему.

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

Я мало что понимаю из вашей схемы, но я бы структурировал базу данных следующим образом:

Firestore-root
   |
   --- users (collection)
   |    |
   |    --- uid (document)
   |         |
   |         --- //user properties
   |
   --- video (collection)
        |
        --- videoId (document)
             |
             --- likedBy: ["uid", "uid", "uid"]

Как видите, свойство likedBy имеет тип array.Поэтому, получив видеодокумент, вы можете просто проверить uid зарегистрированного пользователя по отношению к массиву likedBy.Если он существует, это означает, что это видео уже понравилось пользователю, в противном случае - нет.

Answer 2

1) Вы можете иметь подколлекцию на пользователях, сохраняя идентификаторы постов в виде лайков.

2) Вы можете создавать users_likes коллекции, где идентификаторы - это идентификаторы пользователей, а внутри естьмассив с идентификаторами публикаций, которые нравятся пользователю.

3) Наконец, просто сделайте реквизиты, называемые лайками, в коллекции пользователей, чтобы сохранить идентификаторы сообщений.

Все варианты имеют сделку-off, я бы сделал запрос пользователя и posts_likes при загрузке и сохранил бы его в памяти (внешний пользователь не будет влиять на это).

Be aware that if you suggest me to store all liked Shows in the User or Show Document that this is not scalable due to the 1MB Limit.

Если вы ожидаетепользователю нравится более 1 миллиона сообщений ... в противном случае хранение 1Mb только идентификаторов - хорошая идея ... Я использую этот же шаблон для отслеживания user events, у меня определены события (эквивалентные вашим сообщениям) ипользователь делает действия, которые соответствуют этим событиям (ваши лайки), у меня есть дела с более чем 80K, и это работает как шарм.Я дал вам 3 варианта, я бы сказал, начните с 3, пока он не заработает, затем перейдите к 2 и выполните тот же процесс до 1. Поскольку вы будете работать с массивом идентификаторов, поддержите себя с помощью this