做位置服务的朋友，最近是不是被 elasticsearch geo 搞得头大？
我懂那种感觉。
明明代码没写错，查询结果却差之千里。
有的用户说，明明就在隔壁小区，搜出来却在五环外。
尴尬不？
其实，这真不是你的锅。
是很多人对 elasticsearch geo 的理解，还停留在表面。
今天咱们不整那些虚的。
直接上干货。
全是血泪换来的经验。
先说个最常见的坑。
很多新人喜欢用 geo_point 类型。
觉得它万能。
能存经纬度，能查距离，能圈范围。
确实，它很强大。
但问题也出在这。
精度。
默认情况下，elasticsearch geo 的精度是有限的。
如果你存的是高精度的经纬度。
比如小数点后6位甚至更多。
ES 可能会自动截断。
或者在计算距离时，产生细微的偏差。
别小看这0.0001度。
在地图上，那就是几十米的误差。
对于打车软件，这能把你甩到另一个街区。
对于外卖配送，这能让骑手多跑两公里。
怎么解决？
简单。
在 mapping 里，显式指定 precision。
比如 precision: 50m。
或者更细，10m。
这样 ES 就会用更精细的网格来存储。
当然，代价是索引体积变大。
这点你要权衡。
如果做城市级导航，50m 够了。
如果做室内定位，那得换方案。
ES 不适合做厘米级的定位。
别硬刚。
再说说查询。
geo_distance 查询。
很多人喜欢直接查距离。
比如，查5公里内的所有商家。
听起来很合理。
但注意。
如果数据量很大。
比如你有几百万条位置数据。
每次查询都全表扫描距离。
CPU 会爆。
响应时间会慢到让你怀疑人生。
这时候，你得用 geo_distance_range。
或者，结合 geo_shape。
但最推荐的，其实是先缩小范围。
用 geo_bounding_box。
先框出一个矩形区域。
再在这个小区域里算距离。
这样性能提升不止一倍。
这是行业里的老套路了。
别嫌麻烦。
用户体验就是靠这些细节堆出来的。
还有啊。
别忽略坐标系。
国内一般用 GCJ-02。
也就是火星坐标。
如果你的数据源是 GPS 原始数据。
那是 WGS-84。
直接存进 ES。
查出来的位置，会偏几公里。
这就是为什么你明明在楼下，地图显示你在河里。
一定要在入库前做转换。
或者，在 ES 里用脚本字段处理。
虽然麻烦点。
但比后期修 bug 强一万倍。
说到这，想起个真实案例。
有个客户做共享单车。
初期没做优化。
高峰期查询超时。
运维小哥急得满头大汗。
后来加了 geo_point 的 precision。
又改了查询逻辑。
先框选，再算距。
响应时间从2秒降到200毫秒。
老板高兴了。
小哥也活了。
所以，别一上来就追求高大上。
先保证准。
再保证快。
最后才是炫技。
elasticsearch geo 这东西。
看似简单。
实则暗藏玄机。
你踩过的坑，我都踩过。
你遇到的报错，我都见过。
如果你还在为定位不准发愁。
或者查询慢得像蜗牛。
别自己瞎琢磨了。
容易走弯路。
浪费服务器资源。
更浪费你的头发。
找专业的人问问。
有时候，一句点拨。
顶你自己调三天。
我是老陈。
干了十年大数据。
见过太多因为一个小配置。
导致系统崩盘的事。
真心劝你。
别省咨询费。
省下的时间，够你喝好几杯咖啡了。
有问题，直接来聊。
不绕弯子。
只给方案。
毕竟，技术这行。
互助才能走得远。
你现在的痛点。
也许正是别人正在解决的问题。
别一个人扛着。
来，说说你的具体情况。
坐标？数据量？QPS？
咱们对症下药。
这才是正道。
