【问题标题】:GeoFire read ops efficiencyGeoFire 读取操作效率
【发布时间】:2019-08-15 19:22:50
【问题描述】:

当用户四处走动时,我正在使用 geofire 来查询 Firestore。这是我的问题:

假设我的 Firestore 数据库中有 5000 条地理哈希记录,它们随机分布在世界各地。记录都存储在数据库中的根节点之外。当我执行半径非常小的 geofire 查询时,会发生哪些情况(假设默认的 geofire 参数):

选项 1:第一个地理查询生成 5000 个计费 Firebase 读取操作,因为它搜索所有 5000 个键以进行匹配。此后的每个地理查询(来自相同位置或不同位置)都使用 5000 个密钥的缓存副本,并且不会生成计费读取操作。

选项 2:无论地理查询中心点或半径是否发生变化,每个地理查询都会生成一个新的 5000 次计费 Firebase 读取操作

选项 3:完全不同的东西!

【问题讨论】:

    标签: firebase google-cloud-firestore geofire geohashing geofirestore


    【解决方案1】:

    在 Cloud Firestore 中发生的唯一可计费读取是针对返回给客户端的那些文档。 GeoFire 并没有改变这个事实。 GeoFire 只需满足您的要求,将其转换为 Firestore 查询,该查询至少匹配将落入您请求的半径范围内的文档数量,可能还有一些额外的。它不考虑集合中的所有文档。那将是非常低效的,并且首先违背了 geohashes 的目的。

    来自他们的documentation

    GeoFire 有选择地仅加载特定位置附近的数据,让您的应用程序轻巧且响应迅速,即使是非常大的数据集。

    【讨论】:

    • 我认为这回答了我的问题的核心。
    • 您能否澄清一下这句话,“GeoFire 只接受您的要求,将其转换为至少匹配的 Firestore 查询”如果您连续两次运行相同的查询,GeoFire 是否会进行任何缓存还是相同的计费查询运行两次。
    • 这只是说 GeoFire 知道如何处理您的查询并将其转化为高效的 Firestore 查找。 Firestore 还知道如何缓存查询结果。如果您想了解更多信息,则必须研究 geohash 查询的工作原理。
    猜你喜欢
    • 1970-01-01
    • 2019-04-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-10-03
    • 2010-09-26
    • 1970-01-01
    • 2023-03-25
    相关资源
    最近更新 更多