本文关键词：geo_shape查询性能

干了十二年Geo行业，从最早的ArcInfo到现在的Elasticsearch，我见过太多人把geo_shape这块硬骨头啃得满嘴是血。今天不整那些虚头巴脑的理论，就聊聊怎么让geo_shape查询性能真正起飞，顺便吐槽一下那些坑爹的文档。

说实话，刚转Elasticsearch那会儿，我天真地以为只要建了索引，随便查都飞快。结果呢？一个包含复杂多边形的geo_shape字段，查询一次要好几秒。老板在旁边盯着，我冷汗都下来了。后来才发现，90%的人都在踩同一个坑：数据量没控制，索引结构没优化。

先说个真事。去年给某物流大厂做路径分析，他们要把全国几万个配送区域存进ES。起初直接用默认设置，结果高峰期查询延迟直接飙到5秒以上。我排查了半天，发现是他们的多边形坐标点太多，而且没有做简化。ES底层用的是Lucene的GeoHash或者QuadTree，坐标点一多，树结构就变深，查询自然慢。

怎么解决？第一，数据预处理必须做。别直接把原始GIS数据扔进去。用GDAL或者PostGIS做一下简化，把那些没意义的细碎折线砍掉。我一般要求业务方提供的数据，每个多边形的顶点数不超过200个。超过这个数，查询性能断崖式下跌。这点很关键，很多开发觉得这是小事，其实是大忌。

第二，索引映射要讲究。别偷懒用dynamic mapping。一定要显式定义geo_shape字段，并且设置tree参数。我用的是geohash，层级设为4或者5，对于大多数城市级甚至区域级的查询，精度完全够用。如果设成geohash_tree，层级太高，写入性能会受影响，查询倒是快一点，但权衡之下，我觉得geohash更稳妥。记住，tree层级不是越高越好，要根据你的数据分布和业务精度需求来定。

第三，查询方式也有讲究。别一上来就用intersects，尤其是当你的查询形状也很复杂的时候。intersects需要计算两个多边形的交集，计算量巨大。如果业务允许，尽量用within或者contains，或者干脆用点查询代替面查询。比如，用户搜索“朝阳区”，其实只需要查几个关键点的bbox，而不是去算整个朝阳区多边形的交集。这种优化思路，能提升好几倍的geo_shape查询性能。

还有个容易被忽视的点：缓存。ES本身有查询缓存，但对于geo_shape这种计算密集型操作，缓存命中率不高。我建议在应用层加一层Redis缓存，把热点区域的查询结果存起来。比如，北京五环内的区域查询，一天可能重复几千次，完全没必要每次都去算。

当然，硬件也得跟上。geo_shape查询吃CPU，尤其是涉及复杂几何运算的时候。如果你的服务器CPU频率低，或者核心数少，再好的优化也白搭。我现在的生产环境，专门划了一批高主频的节点给ES集群，虽然成本高点，但用户体验上去了，值。

最后，别迷信“万能配置”。每个业务场景的数据分布都不一样，有的区域密集，有的稀疏。一定要做压测。用你的真实数据，模拟高并发场景，看看瓶颈在哪里。是写入慢？还是查询慢？如果是写入慢，考虑批量导入；如果是查询慢，那就回头检查索引结构和查询语句。

总之，geo_shape查询性能这事儿，没有银弹。得一步步调优，从数据清洗到索引设计，再到查询优化，环环相扣。希望这些血泪经验能帮你们少走弯路。别等线上出问题了再哭，那时候黄花菜都凉了。

（配图建议：一张Elasticsearch Kibana查询耗时分析截图，显示优化前后的对比，ALT文字：Elasticsearch geo_shape查询性能优化前后对比图）