构建社交媒体应用程序并应对 1write/doc/sec 限制。因此，将投票数据保留在邮寄文档中将无法大规模发挥作用。我已阅读“分布式计数器”，但文档读/写成本呈线性缩放。我一直在探索可用的 firebase 函数，并对“listDocuments()”感兴趣，它返回 DocumentReference 的列表
不幸的是，通过深入研究文档，我无法确定集合中 listDocument 的读取成本是 1 还是 1/doc。
我的计划是每个帖子有两个子集合，vote1/vote2。这大规模地消除了写入瓶颈。为了检索投票计数，我想在每个子集合上使用 listDocuments() 的长度。
我知道 firebase 有一些巧妙的索引技巧，但我也很好奇这是否是对数据库的低效操作。即，用户在检索计数时会注意到延迟吗？
不幸的是，通过深入研究文档，我无法确定集合中 listDocument 的读取成本是 1 还是 1/doc。
Calling the listDocuments API cost one document read per document that is returned by it.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
