说实话，刚接触Elasticsearch的时候，我真是被那个geo_point给整吐了。网上那些教程，一个个写得跟教科书似的，什么经纬度精度、什么空间索引原理，看得我头大。结果呢？一上生产环境，直接炸锅。今天我就掏心窝子跟大伙聊聊这个geo_point数组，不整那些虚头巴脑的理论，全是踩坑踩出来的血泪史。
咱们先说个真事儿。前阵子有个做本地生活服务的哥们找我，说他们的搜索功能出了大问题。用户搜“附近的餐厅”，结果出来的列表乱七八糟，有的离着十里八里远，有的明明就在隔壁街却搜不到。我一看日志，好家伙，人家存数据的时候，把经纬度当成了字符串存进去了，或者更离谱，把多个地点的坐标混在一个字段里，还没用对格式。这就好比你去超市买苹果，结果人家把苹果、香蕉、橘子全装在一个袋子里，你还指望能挑出最甜的那个？简直是扯淡。
这里就得提到geo_point数组这个概念了。很多新手以为，只要是个数组就能存多个坐标，其实大错特错。在ES里，geo_point本身支持存储多个点，但前提是你得搞清楚它的底层逻辑。如果你是想存一个地点的多个入口坐标，比如一个大商场有好几个门，那你确实可以用数组。但如果你是想存一堆不同的地点，那千万别这么干，得用嵌套或者单独建索引。我见过太多人把一堆无关的地点塞进一个geo_point数组里，结果查询的时候，ES根本没法做有效的空间过滤，查询慢得像蜗牛爬。
再说说价格，哦不，是成本。用错数据结构，最直接的后果就是磁盘空间爆炸和查询性能暴跌。我有个朋友，为了省事，把所有用户的打卡记录都压缩成一个大的geo_point数组存起来。结果呢？数据量稍微大点，集群直接OOM（内存溢出）。后来我让他拆分成独立的文档，虽然文档数多了，但查询效率提升了不止一个量级。这就是典型的因小失大。
还有啊，别轻信那些“万能解决方案”。有些人说，哎呀，直接用geo_point数组不就行了吗？多简单！简单个屁。你得考虑你的业务场景。如果是做轨迹追踪，那确实可能需要数组，但要注意，数组里的点是有顺序的，而且ES对数组的长度有限制，别存个几千个点进去，到时候查询超时，你哭都来不及。我见过一个做外卖骑手的系统，把骑手一天的轨迹全存一个数组里，结果每次查轨迹都要加载几十MB的数据，服务器直接扛不住。
说到这儿，我得吐槽一下那些只会复制粘贴的博主。他们根本不管你的数据量级，不管你的并发量，就在那儿喊“加个索引就好了”。加个索引能解决所有问题吗？天真！你得知道，geo_point的索引是基于网格的，如果你的数据分布极度不均匀，比如大部分数据都在市中心，边缘地区很少，那索引的效果就会大打折扣。这时候，你可能得考虑分片策略，或者调整索引的大小。
最后，给大家提个醒，别怕麻烦。在数据入库之前，一定要做充分的测试。别等到上线了，用户投诉了，你才慌慌张张地改数据结构。那时候，损失的可不仅仅是时间，还有用户的信任。记住，geo_point数组不是银弹，它只是工具。用对了，事半功倍；用错了，万劫不复。
本文关键词：geo_point数组
