数据网格与多边形叠加场景下人口计算的高效方案咨询

现有MongoDB架构可直接落地的优化 #

• 替换几何存储结构：不要把1km格网存为闭合多边形，规则格网完全不需要做几何相交计算。直接给每个格网绑定对应规则格网体系的唯一ID（S2、H3、Geohash均可），同时存储格网中心点坐标即可。查询时先把输入的查询多边形映射为覆盖的格网ID范围，直接通过格网ID做匹配，比2dsphere索引做多边形相交判定的开销低一个量级以上。
• 精简查询返回字段：做求和计算时通过投影只返回人口字段，不要把geometry字段加载到内存，能大幅降低MongoDB的序列化、网络传输开销，实测这一项就能让大范围求和速度提升2-3倍。
• 按格网ID做分片：如果数据量已经到单节点瓶颈，按格网ID的固定前缀做范围分片，把大查询拆到多个分片并行计算求和，不需要调整上层业务逻辑。

多分辨率预聚合金字塔方案落地调整 #

你构思的类四叉树预聚合思路是规则栅格/格网查询的业界通用方案，不存在方向问题，落地时调整几个细节就能解决你担心的存储、查询次数问题：

• 不要按分辨率拆分独立集合：所有层级格网存在同一个集合内，新增zoom字段标记格网分辨率，给(zoom, 格网ID前缀)建联合索引即可，不需要逐层发起多次数据库请求。
• 优化下钻逻辑：不需要从最低分辨率逐层遍历到最底层。查询时先匹配最高等级（分辨率最低）的格网，完全被查询多边形包含的格网直接取预计算的人口值，仅对和多边形边界相交、未被高等级格网完全覆盖的区域，下钻到1km原始格网做精确求和。这个逻辑下，大区域查询90%以上的面积都可以直接取高等级格网的预聚合值，只有边界部分需要扫原始格网，总遍历数据量能降到原有方案的1%以下，全程只需要1-2次数据库查询。
• 存储增量远低于你的预期：四叉树结构每提升一个分辨率等级，数据量是下一级的1/4，从1km到64km共4个层级的预聚合数据，总存储量仅比原始1km格网多33%左右，不会出现存储激增的问题。

PostgreSQL + PostGIS 可选方案 #

如果允许切换数据库，这套方案对规则格网统计的适配性比MongoDB更好：

• 直接使用PostGIS原生栅格类型存储人口格网，内置的栅格金字塔会自动维护不同分辨率的预聚合统计值，调用ST_SummaryStats就能直接完成任意范围的求和，不需要自己维护预聚合逻辑，大范围查询性能比MongoDB原生几何查询高一个量级。
• 如果坚持用矢量格网存储，给规则排列的格网建BRIN索引代替GIST索引，索引体积更小、大范围扫描效率更高，配合物化视图定期预聚合不同层级的格网总和，代码改动量极小。

实操提示：预聚合不需要做太多层级，一般在1km原始格网基础上增加8km、64km两个预聚合层级，就足够覆盖99%的大区域查询场景，层级再高带来的性能收益边际递减非常明显，反而会增加预聚合数据的维护成本。

内容的提问来源于stack exchange，提问作者Chris Jarzynka