Firestore中存储大量Geopoints的最优方案及数据库结构咨询

问题1：单集合存储地理点位的合理性与性能问题 #

提问：将所有包含Geopoints的对象统一存储在同一个大集合中是否不合理？随着数据量持续增加，查询速度是否会出现明显下降？

• 万级数据量下，单集合存储完全合理，不需要拆分。Firestore的查询性能仅与返回的结果集大小正相关，和集合的总数据量无直接关联，只要配置了正确的索引，哪怕集合总数据涨到十万级，单次半径查询返回几十到几百条结果的速度都不会有明显下降。
• 仅当你的数据量后续突破百万级、且查询请求QPS极高时，单集合才可能出现成本或吞吐量瓶颈，当前数千到数万的量级无需担心。
• 注意：Firestore原生不支持直接按圆形半径查询Geopoint，仅支持矩形范围查询，要实现半径查询必须结合geohash字段做二次过滤。

问题2：适配场景的数据库结构设计 #

基础结构（万级数据量首选） #

所有点位统一放在geo_points集合下，单个文档结构参考：

{
  "point_id": "xxx",
  "geo": Firestore Geopoint类型, // 存经纬度，用于后续精确距离计算
  "geohash": "wx4g0s", // 提前计算好的geohash字符串，长度根据查询精度选择，6位对应±1.2km精度
  // 其他业务字段，比如名称、地址、类型等
  "name": "xxx",
  "type": "shop"
}

• 索引配置：控制台添加geohash升序 + geo.latitude升序 + geo.longitude升序的组合索引，也可以跑一次查询后按Firestore返回的索引提示直接创建。
• 查询逻辑：先计算目标坐标对应半径范围内的所有geohash前缀，批量查询匹配前缀的文档，再在客户端/云函数侧计算每个点位和目标点的实际距离，过滤掉超出半径的结果即可。

扩展结构（后续数据量突破十万级可选） #

如果后续数据量持续上涨，可以按geohash前2位做集合拆分，比如前缀为wx的点位存在geo_points_wx集合，查询时先匹配目标点对应的geohash前缀集合，再执行后续查询，进一步降低扫描范围。

内容的提问来源于stack exchange，提问作者Yoann Far