构建社交媒体应用，并面对1write / doc / sec的限制。因此，将投票数据保留在后期文档中将无法正常工作。我已经读过“分布式计数器”，但是文档的读/写成本呈线性增长。我一直在探索可用的firebase函数，并对“ listDocuments（）”感兴趣，该函数返回DocumentReference的列表。
不幸的是，在文档中我无法确定listDocument的读取成本是集合中的1还是1 / doc。
我的计划是每个帖子有两个子集合，vote1 / vote2。这消除了大规模的写瓶颈。为了获取投票计数，我想在每个子集合上使用listDocuments（）的长度。
我知道firebase有一些巧妙的索引技巧，但是我也很好奇这是否对数据库无效。即用户在检索计数时会注意到延迟吗？
答案 0 :(得分：2)
不幸的是，在文档中我无法确定listDocument的读取成本是集合中的1还是1 / doc。
调用listDocuments API会花费一个读取的文件（由它返回的每个文件）。