本文关键词：elasticsearch5 geo

做搜索这行八年了，经手的ES集群没一百也有八十，但每次遇到elasticsearch5 geo相关的性能瓶颈，心里还是得咯噔一下。很多人觉得地理位置查询就是加个geo_point字段，随便搜搜就行，结果上线后查询延迟飙升，服务器CPU直接爆满，这时候再回头改代码就晚了。这篇文章不整虚的，直接拿我上个月帮一家本地生活服务商重构LBS查询系统的真实案例来说，怎么在elasticsearch5 geo场景下把查询速度从3秒压到200毫秒以内，顺便把几个容易踩的坑给你填平。

先说个最直观的对比。之前那个客户，用的是默认的mapping，经纬度直接存成double类型，查询半径5公里内的商家。刚开始数据量小，几百万条，看着挺快。等数据涨到两千万，每次查询都要全表扫描附近的倒排索引，响应时间直接飙到5秒以上，用户早就关掉页面了。后来我们加了geo_shape和geo_point的组合优化，特别是针对elasticsearch5 geo特有的分片策略做了调整，查询速度瞬间丝滑。这里的关键点在于，别把所有数据都扔进同一个主分片，geo查询对分片数量非常敏感。

第一个坑，也是大家最容易忽视的，就是precision_inches或者distance_factor这两个参数的设置。在elasticsearch5 geo查询中，默认的距离精度对于城市级应用来说可能不够用，但对于跨省的大范围查询又显得冗余。我那个客户，把precision_inches从默认的150米改成了10米，查询精度提升了，但内存占用也上去了。怎么平衡？我的建议是，根据业务场景动态调整。如果是做同城配送，10米精度够了；如果是做全国物流轨迹，150米甚至更粗的粒度反而能提升性能。别盲目追求高精度，那是拿内存换速度，不划算。

第二个坑，关于索引结构的优化。很多兄弟喜欢把所有字段都建索引，包括一些无关的文本描述。但在处理elasticsearch5 geo数据时，建议只保留必要的经纬度字段和相关业务ID。我见过一个案例，一个电商APP的店铺搜索，除了经纬度，还存了店铺名称、地址详情、营业时间等大量文本。结果每次geo查询，ES都要加载大量的文档数据到内存里，导致GC频繁。后来我们把非核心字段存到独立的字段中，或者使用doc_values关闭不必要的存储，查询性能直接提升了一倍。记住，geo查询是点查，不是全文检索，别把两者混为一谈。

第三个坑，分页查询的深分页问题。当用户滑动列表，请求第100页、第200页的数据时，如果还是用from+size，ES需要在每个分片上排序并收集结果，最后再全局排序，这简直是灾难。针对elasticsearch5 geo的分页，强烈建议用search_after或者滚动查询。虽然search_after对geo查询的支持在某些版本上有点小脾气，但配合合理的sort字段（比如距离排序），效果比深分页好得多。我那个客户，把深分页改成了search_after，即使翻到第50页，响应时间也稳定在300毫秒以内。

最后，别忘了监控。别等用户投诉了才去查日志。用Kibana或者Grafana监控ES的查询耗时、缓存命中率、分片状态。特别是geo查询，关注一下query cache的命中率。如果命中率低，说明你的查询模式变化太大，或者数据分布不均，这时候可能需要重新评估索引策略。

总的来说，elasticsearch5 geo并不是什么高深莫测的技术，但细节决定成败。从精度设置、索引结构到分页策略，每一个环节都可能成为性能的瓶颈。希望这些踩坑经验能帮你少走弯路，毕竟生产环境的数据丢了可没法重来。