搞了13年Geo，elasticsearch5 geo 这坑我替你踩了，别在经纬度上栽跟头

搞了 13 年 Geo，elasticsearch5 geo 这坑我替你踩了，别在经纬度上栽跟头

本文关键词：elasticsearch5 geo

做地理空间数据这么多年，见多了因为一个坐标点搞崩集群的惨案。很多人以为加了 geo_point 类型就万事大吉，结果查出来的距离不对，或者干脆搜不到数据，这时候才想起找我。这篇不整虚的，直接告诉你 elasticsearch5 geo 在实战里最容易翻车的三个地方，照着做能省一半调试时间。

先说最让人头疼的精度问题。很多新手为了省事，存经纬度时直接截断小数位，比如只保留 5 位。在 elasticsearch5 geo 场景下，这 5 位大概对应 1 米多的误差。如果你做的是外卖配送或者共享单车调度，这点误差可能让你把骑手派到河对岸去。我见过一个客户，因为前端传参时把 double 类型存成了 float，导致搜索半径 500 米内的数据漏了一半。记住，除非你存的是城市级别的粗略位置，否则经纬度必须用 double，而且尽量保留 7 位以上小数。别为了省那点存储空间，丢了数据的准确性，后期清洗数据的时间成本远高于那点磁盘开销。

再说说查询时的性能陷阱。很多开发喜欢用 geo_distance 查询，而且不加任何过滤条件，直接全表扫描。在数据量超过千万级的时候，这种写法简直就是自杀。elasticsearch5 geo 虽然底层用了 GeoHash 和 Trie 树优化，但如果你不配合其他字段过滤，比如时间范围或业务状态，它还是会遍历大量文档。正确的做法是，先用普通字段缩小范围，再用 geo 查询做二次筛选。比如先查“今天”的数据，再查“5公里内”的人。这样能把查询耗时从几秒降到几十毫秒。还有，别在聚合查询里直接用 geo_distance，除非你确定数据量很小，否则很容易 OOM（内存溢出）。

最后是个隐蔽的坑，就是坐标系不一致。国内大部分地图用的是 GCJ-02 或 BD-09，而 elasticsearch 默认假设输入的是 WGS-84。如果你直接把高德或百度的坐标丢进 ES，搜出来的位置可能偏差几百米甚至几公里。我在处理一个物流轨迹项目时，就因为没做坐标转换，导致司机轨迹和实际道路完全对不上，客户投诉差点把服务器砸了。解决方案很简单，在数据入库前，通过脚本或中间件把 GCJ-02 转成 WGS-84。这一步不能省，也别指望 ES 能自动帮你转换，它是个搜索引擎，不是地图服务商。

总结一下，elasticsearch5 geo 不是不能用，而是得用对地方。第一，精度要给足，别省小数位；第二，查询要组合，别裸奔全表扫；第三，坐标要统一，入库前必转换。这三点做到了，你的地理空间查询基本稳如老狗。别等线上出事了再哭，现在就去检查你的索引映射和查询语句。

希望这些血泪经验能帮你避开雷区。如果你还在为 geo 查询慢而头疼，不妨回头看看是不是犯了上面这些低级错误。技术这东西，细节决定成败，尤其是跟位置打交道的时候，差之毫厘谬以千里。