PostGIS与ES怎么选?空间查询谁更强?

“我的空间查询怎么又卡死了？”——别急，先搞清你用的是锤子还是手术刀

上周一个做智慧城市项目的朋友半夜给我发消息：“Dr. Gis，我用 Elasticsearch 做缓冲区分析，500米半径查周边POI，结果服务器直接崩了！是不是我代码写错了？”

我一看他的SQL，差点笑出声——他把 ES 当成 PostGIS 在用。这就好比拿瑞士军刀去砍树，不是刀不好，是你没选对工具。

PostGIS 是地理数据库里的“老法师”，专精空间关系运算；Elasticsearch 是搜索界的“闪电侠”，擅长模糊匹配与高并发检索。硬要PK“谁更强”，就像问关羽和吕布谁更牛——得看你打什么仗。

从国土调查到外卖骑手调度：它们各自在实战中怎么赢的？

我在参与某省第三次国土调查数据整合时，遇到一个经典场景：需要计算全省每个乡镇与最近高速公路的空间距离，并叠加土地利用类型做统计。这种涉及精确几何运算 + 复杂JOIN + 空间索引优化的任务，PostGIS 闭着眼都能搞定：

-- PostGIS 经典三连击：距离 + 缓冲区 + 空间连接
SELECT 
  town.name, 
  ST_Distance(town.geom, highway.geom) AS dist_to_highway,
  landuse.type
FROM towns town
JOIN highways highway ON ST_DWithin(town.geom, highway.geom, 5000)
JOIN landuse ON ST_Intersects(town.geom, landuse.geom);

而同样的需求如果丢给 ES？它会一脸懵：“你要的是‘附近’还是‘精确距离’？要不要考虑地球曲率？缓冲区是圆形还是椭圆？”——ES 的空间能力本质是“近似搜索”，它的强项在于：

• 毫秒级响应“查找我家3公里内评分4.5以上的奶茶店”
• 支持文本+空间+时间的混合条件过滤（比如“带‘火锅’关键词且在朝阳区且最近一周有优惠”）
• 横向扩展能力强，轻松扛住百万QPS的LBS请求

剥橘子皮教学：用生活场景看懂底层原理差异

想象你面前有一颗橘子（代表地球表面），PostGIS 和 ES 的处理方式截然不同：

• PostGIS：先把橘子皮完整剥下来，铺平成一张精确地图（投影坐标系），然后用尺子和圆规做几何计算——结果绝对精准，但步骤繁琐。
• Elasticsearch：直接在球面上贴满六边形网格（Geohash 或 H3），你要找“附近”，它就查相邻几个格子——速度飞快，但边界可能模糊。

这就是为什么 ES 的 geo_distance 查询默认使用“球面弦距离”而非“测地线距离”，误差在小范围内可接受，但在大尺度分析中可能差出几百米。

终极决策树：下次选型时，问自己这三个问题

1. 你需要“算得准”还是“跑得快”？
   做洪水淹没模拟、用地红线校验？选 PostGIS。做用户附近商家推荐、实时车辆围栏报警？选 ES。
2. 数据更新频率如何？
   PostGIS 支持 ACID 事务，适合频繁增删改的业务库；ES 更适合“写多读多”的日志/轨迹流。
3. 团队技术栈是什么？
   已有 PostgreSQL 生态？加装 PostGIS 扩展成本极低。已在用 ELK 做日志分析？直接复用 ES 空间功能更省事。

最后送你一句我在阿里云做架构师时的血泪经验：“没有银弹，只有场景适配。强行让数据库干搜索的活，或让搜索引擎干分析的活，都是灾难的开始。”

你的项目在用哪个？评论区说出你的踩坑故事

是被 PostGIS 的复杂函数折磨过？还是被 ES 的空间精度坑惨了？留言告诉我你的场景，我来帮你诊断工具选型是否合理！