firebase 使用Firestore高效存储地理点

wfsdck30  于 2023-10-22  发布在  其他
关注(0)|答案(2)|浏览(111)

我正在考虑如何建模一个集合,其中每个文档都是一个具有地理位置的建筑物。我知道我应该使用Geohashes,但我担心的是,对于每个查询,我将获得数十个(如果不是数百个)文档的阅读。将单个文档用作数十个建筑物的集群是一个坏主意吗?有没有更好的办法解决这个问题?

mfuanj7w

mfuanj7w1#

我知道我应该使用Geohashes,但我担心的是,对于每个查询,我将获得数十个(如果不是数百个)文档的阅读。
根据official documentation
Firestore针对存储大量小文档进行了优化。
如果你认为你会有大量的文档读取,那么你应该考虑学习Realtime Database,它有一个不同的计费机制。
将单个文档用作数十个建筑物的集群是一个坏主意吗?
不,只要您保持低于最大1 MiB限制。
对于这个问题,有没有更好的解决方案?
no "perfect", "the best" or "the correct"解决方案用于构建Cloud Firestore数据库。在您的情况下,您必须做一些数学运算,以确定上述三种解决方案中哪一种最适合您的需求。

n3ipq98p

n3ipq98p2#

我曾经尝试过将多个geohash值存储到一个文档中,文档ID是这些散列的公共前缀,然后对于每个点,我们保留对应点的精确纬度/经度及其文档ID。
对所有文档都这样做,最终会得到多个额外的文档(我称之为地理索引文档)和额外的元数据。下面是这样一个文档的示例:

因此,这里的公共前缀是cu,这意味着文档包含以cu开头的所有geohash的元数据。
为了执行地理查询,我会计算包含潜在匹配文档的地理哈希范围,读取这些范围的地理索引文档,并根据地理索引文档中的纬度/经度来限定/取消实际文档。
通过这种方法,我能够大幅减少必须阅读以确定匹配的文档数量。但另一方面,它需要我创建新的数据结构,基本上是为数据库构建自己的索引类型。
您必须确定对于您的用例和其他需求来说,复杂性与成本的权衡是否值得。

相关问题