我有一个移动解决方案(iOS),该解决方案正在使用Firebase来辅助用户设备之间的数据同步。我所拥有的作品可以让我保持想要的客户同步。但是从测试来看,对于较大的数据集,我的读取有些失控,我需要进行一些优化。为此,我想确保我对阅读计数的理解是正确的(我仍然是Firebase的新手)。
我的数据的结构如下:
我同意,它有点嵌套,但是对于所有用例来说,这似乎是做事以减少冗余的最佳方法,例如猫与狗,鸟之间有关系,但我只存储一个,而不是多个。此外,每个用户的数据都与其他用户分开,我需要能够对数据进行版本控制。将所有内容放在一起,并根据需要更改集合和文档,您将获得所见即所得。
基于此结构,我可以创建如下查询:
Firestore.firestore().collection("userid1").document("data").collection("version0").document("Cats").collection("data").whereField("modifiedDate" isGreaterThanOrEqualTo: someDoubleValue).getDocuments(completionCallback)
这为我获取了我需要的数据,似乎只返回了我认为应该的项目数。但是,我的说法是正确的,如果有100个Cat类型的文档(Cat1 ... Cat100),但是其中只有3个的ModifyDate大于我的查询参数,那么当数据返回给我时,我只会被“收费” 3次读取?还是我在这里没有完全愚蠢的东西,即使我在回调中只得到3个文档,我也要为全部100个收取费用。
答案 0 :(得分:0)
子集合的帐单工作与顶级集合的帐单工作没有任何不同。您只需为转移的文件付费,而不是为馆藏中的整个文件集付费(除非您确实要求所有文件)。
Cloud Firestore可以大规模扩展,并且预计您的集合中可能有大量文档。为该集合中的每个查询对集合中的每个文档的读操作计费是非常昂贵的。