Использование массива Query для Cloud Firestore Структура социальных сетей

1

У меня есть структура данных, которая состоит из коллекции, которая называется "Опросы". "Опросы" имеет несколько документов, которые имеют случайно сгенерированные идентификаторы. В этих документах есть дополнительный набор сбора, называемый "ответы". Пользователи голосуют за эти опросы, причем все голоса записываются в подколлекцию "ответы". Я использую метод .runTransaction() в узле "ответы", имея в виду, что эта подколлекция (для любого данного опроса) постоянно обновляется и записывается пользователями.

Я читал о структуре социальных сетей для Firestore. Однако недавно я наткнулся на новую функцию для Firestore, опцию запроса "array_contains".

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

Будет ли запрос "array_contains" еще одним практическим вариантом для масштабирования структуры социальных сетей? Моя мысль:

  1. Если пользователь A следует за пользователем B, напишите прямой массив child в моем узле "Users", который называется "последователи".
  2. Прежде чем какой-либо опрос будет создан пользователем B, устройство пользователя B считывает массив "последователей" из Firestore, чтобы получить список всех следующих пользователей и заполняет их на стороне клиента, в объекте Array.
  3. Затем, когда пользователь B пишет новый опрос, добавьте в опрос этот массив "последователей", чтобы к каждому новому опросу от пользователя B был прикреплен массив, содержащий все идентификаторы следующих пользователей.

Каковы ограничения по запросу "array_contains"? Целесообразно ли хранить в Firebase массив, содержащий тысячи пользователей/подписчиков?

Изображение 174551 Изображение 174551

Теги:
firebase

2 ответа

1
Лучший ответ

Будет ли запрос "array_contains" еще одним практическим вариантом для масштабирования структуры социальных сетей?

Да, конечно. По этой причине создатели Firebase добавили эту функцию.

Видя вашу структуру, я думаю, что вы можете попробовать, но ответить на ваш вопрос.

Каковы ограничения по запросу "array_contains"?

Нет никаких ограничений относительно того, какой тип данных вы храните.

Целесообразно ли хранить в Firebase массив, содержащий тысячи пользователей/подписчиков?

Не о практическом или нет, о другом типе ограничений. Проблема в том, что документы имеют ограничения. Таким образом, существуют некоторые ограничения в отношении объема данных, которые вы можете поместить в документ. Согласно официальной документации относительно использования и ограничений:

Максимальный размер документа: 1 МБ (1 048 576 байт).

Как видите, вы ограничены 1 МБ данных в одном документе. Когда мы говорим о хранении текста, вы можете хранить довольно много. Так что в вашем случае, если вы будете хранить только идентификаторы, я думаю, что это не будет проблемой. Но ИМХО, поскольку ваш массив становится больше, будьте осторожны с этим ограничением.

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

  • 0
    Очень ценю быстрый ответ. Знаете ли вы, если Firestore прокомментировал эти ограничения - возможно ли, что они увеличатся? Также, с 1 МБ места, можно ли сказать, что он состоит из 1 000 000 текстовых символов?
  • 1
    Я действительно понятия не имею, увеличат ли они эти ограничения в будущем. Вы должны спросить их. Итак, около 1000 символов равняется 1 килобайту. Вы можете сделать математику :)
1

Я сделал систему опросов в режиме реального времени, вот моя реализация:

Я сделал коллекцию опросов, где каждый документ имеет уникальный идентификатор, заголовок и массив ответов.

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

Пример:

polls/
  [pollID]
    - title: 'Some poll'
    - answers: ['yolo' ...]
    answers/
      [answerID]
        - title: 'yolo'
        - num_shards: 2
        shards/
          [1]
            - count: 2
          [2]
            - count: 16

Я сделал еще одну коллекцию под названием " Голоса", где каждый документ представляет собой составной ключ userId_pollId, чтобы я мог отслеживать, проголосовал ли пользователь уже за опрос. Каждый документ содержит pollId, userId, answerId...

Когда документ создается, я запускаю облачную функцию, которая захватывает pollId и answerId, и увеличиваю счетчик случайных сегментов в этой подколлекции answerId shards, используя транзакцию.

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

Для следующих вещей вы можете сделать то же самое, используя коллекцию среднего уровня, называемую " follow ", где каждый документ является составным ключом userAid_userBid, так что вы можете легко отслеживать, какой пользователь следует за другим пользователем, не нарушая ограничения хранилища.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню