前阵子接了个活儿，给个同城配送平台搞位置检索，老板拍着胸脯说用elasticsearchnet geo肯定没问题，快得很。我信了，结果真刀真枪干起来，才发现这玩意儿就是个“看着简单，用起来想砸键盘”的主儿。今天不整那些虚头巴脑的理论，就聊聊我这几周摸爬滚打换来的血泪教训，全是真金白银砸出来的经验。
先说个最坑的，坐标系别乱用。很多兄弟觉得经纬度随便填就行，大错特错。国内必须用GCJ-02，也就是大家常说的火星坐标。如果你直接拿百度地图或者高德地图导出的数据往ES里塞，别怪查不出来或者偏移几公里。我一开始图省事，没做转换，结果定位偏差大到客户投诉电话被打爆。后来老老实实写了个转换工具，把WGS84转成GCJ-02再入库，这才稳当。这一步千万别省，省了就是给未来埋雷。
再说说mapping的设计。很多新手喜欢把lat和lon分开存，或者干脆存成字符串。听我一句劝，老老实实用geo_point类型。虽然看着麻烦点，但查询效率高得吓人。我见过有人为了省事，把经纬度拼成一个字符串存进去，结果每次查询都要先解析字符串，CPU直接飙到90%，服务器风扇转得跟直升机似的。用geo_point，ES底层会自动优化，查询速度能快好几倍。而且，geo_point支持多种精度，别嫌麻烦，根据业务需求设好精度，能省不少存储空间。
还有一个容易被忽视的点，就是地理围栏的查询。老板想要个功能，用户打开APP，自动显示附近5公里内的商家。这听起来很简单吧？用geo_distance查询不就行了？确实，但这里有个坑。如果你的数据量很大，比如几百万条记录，每次查询都全表扫描，那数据库迟早得挂。我的解决办法是，先根据经纬度大致筛选出一个范围，再用geo_distance做精确过滤。这样既能保证速度，又能保证精度。别嫌步骤多，这一步能救命。
说到这儿，可能有人要问，具体怎么操作？别急，我给你捋捋。
第一步，建索引的时候，mapping一定要写对。geo_point类型，别忘了设置coordinate_system为plane或者sphere，根据数据范围选。
第二步，入库前，务必做好坐标转换。别信什么“差不多就行”，差之毫厘谬以千里。找个靠谱的转换库，或者自己写个脚本，把数据清洗干净再入库。
第三步，查询的时候，别一上来就搞复杂查询。先用geo_distance做个简单过滤，看看结果对不对，再慢慢加条件。别嫌麻烦，这一步能帮你省下大量调试时间。
第四步，监控性能。上线后，盯着ES的监控面板看，特别是查询响应时间和CPU使用率。如果发现异常，第一时间检查是不是查询语句写得有问题，或者数据量突然暴增。
最后，说点掏心窝子的话。搞技术这行，真的没有捷径。elasticsearchnet geo这东西，看着高大上，其实全是细节。你每一个字节的优化，每一次查询的调优，都是在给用户体验加分。别想着抄抄代码就能跑通，那都是坑。
如果你也在搞类似的项目，或者遇到了什么奇怪的报错，别硬扛。多看看官方文档，多查查GitHub上的issue，实在不行，找个懂行的聊聊。我这人说话直，但都是实话。技术这东西，得靠实打实的经验堆出来。
本文关键词：elasticsearchnet geo
