Firebase: Cloud Firestore: listDocuments: сделать c стоимость чтения 1 или N? Возможная альтернатива распределенному счетчику? - PullRequest
0 голосов
/ 25 мая 2020

Создание приложения для социальных сетей и соблюдение ограничения 1write / doc / se c. Следовательно, хранение данных о голосовании в почтовом документе не будет работать в масштабе. Я прочитал «Распределенные счетчики», но стоимость чтения / записи документа линейно масштабируется. Я изучаю доступные функции firebase и меня интересует «listDocuments ()», который возвращает List of DocumentReference's

К сожалению, копаясь в документации, я не могу определить, равна ли стоимость чтения listDocument 1 или 1 / do c в коллекции.

Мой план состоит в том, чтобы иметь две вложенные коллекции для каждого сообщения, vote1 / vote2. Это устраняет узкое место записи в масштабе. Чтобы получить количество голосов, я хотел бы использовать длину listDocuments () для каждой подколлекции.

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

1 Ответ

1 голос
/ 25 мая 2020

К сожалению, копаясь в документации, я не могу определить, равна ли стоимость чтения listDocument 1 или 1 / do c в коллекции.

Вызов listDocuments API стоит 1 прочитанный документ на каждый возвращенный им документ.

...