Структура данных Firebase Firestore для профилей блокировки социальных сетей

Question

Я строю социальную сеть, используя Firebase Firestore, и у меня есть вопрос о структуре данных для функциональности, которая позволяет пользователям блокировать друг друга.

На данный момент у меня есть коллекция под названием «блокировка», в которой есть две вложенные коллекции, например:

/blocking/{uid}/userBlocking/{targetUid} <-- the uids the user is blocking
/blocking/{uid}/userBlocked/{targetUid} <-- the uids the user is blocked by

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

Тем не менее, для каждого поста мне также нужно проверить, заблокирован ли автор поста и не блокируется ли он и для каждого комментария к посту. , В списке из 25 сообщений это дополнительные 50 обращений к Firestore только для объекта публикации, и кто знает, сколько для комментариев, что кажется неоптимальным и чрезмерным для функциональности, которая, я надеюсь, будет использоваться не так часто.

Я мог бы хранить заблокированные / блокирующие uid как массивы в профиле пользователя (коллекция пользователей делает c), но это могло бы стать громоздким и раздуть документ профиля.

Как бы вы это сделали?

Answer 1

Я думаю, что вы на самом деле самая лучшая ситуация. Вы правильно определили, что существует компромисс между масштабируемостью и стоимостью, что является очень распространенным явлением для баз данных типа No SQL. Если вы хотите масштабируемости, вам придется принять стоимость.

Вы можете оптимизировать это, записав свой клиентский код в , проверяя только локальный кеш для каждого документа get(), и только периодически обновляйте sh кеш, загружая новые документы по мере необходимости.