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

Question

Вот наша проблема:

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

В настоящее время мы рассматриваем два различных подхода к хранению и управлению сотрудниками:

Подход A

Поддерживать подборку сотрудников в каждой организации. В этой модели каждый сотрудник будет иметь свой собственный документ.

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

Основная проблема этого подхода заключается в том, что у нас будет тонна читает. Если мы возьмем компанию с 1000 сотрудников и предположим, что каждый сотрудник посещает каталог 5 раз в день, мы смотрим 1,000 * 5 * 1,000 = 5,000,000 reads/day. Похоже, что слишком много операций чтения для набора ресурсов, которые будут меняться только несколько раз в день (при условии оттока сотрудников).

Очевидное решение этой проблемы - кэширование сотрудников, но я Я не совсем уверен, как мы можем сделать это без использования облачной функции для извлечения сотрудников?

Подход B

Ведение массива или сотрудников в каждом документе организации. В этой модели все сотрудники будут существовать в документе организации.

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

Основная проблема этого подхода заключается в том, что нам придется разделить документ организации по мере увеличения размера массива сотрудников. Это не должно быть слишком большой проблемой, пока не будет> 5 тыс. Сотрудников, но это все еще кажется довольно грязным. После того, как массив разделит его на части, нам также потребуется определить, к какому блоку принадлежит каждый сотрудник, что усложняет обновления.

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

Есть ли другой лучший подход к этой проблеме, или я пропускаю какое-то простое решение?

Заранее спасибо.

Answer 1

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

Подход A является логичным выбором. Это чище и чувственнее. И 5 миллионов операций чтения - это всего 3 доллара, что является ничтожной суммой для компании, в которой работает 1000 человек. Это намного меньше, чем усилия по разработке для правильной реализации B. Если вам действительно нужно сократить эту стоимость, просто не позволяйте всем загружать все пользовательские документы за один go. Вместо этого используйте pagination , если пользователям необходимо просмотреть список.