做GIS这行久了，真觉得有时候被那些复杂的坐标系统折磨得够呛。前两天跟一帮同行喝酒，聊起项目交付，大家吐槽最多的就是数据格式转换。尤其是那种既要存属性又要搞空间索引的，GeoJSON虽然通用，但一旦数据量稍微大点，解析起来那叫一个慢，前端渲染直接卡成PPT。我就在想，有没有那种不用搞那么复杂，又能把地理位置这事儿办妥了的方案？
说实话，以前我也迷信过PostGIS，那玩意儿确实强大，但学习曲线陡峭得像爬珠穆朗玛峰。对于很多中小项目，或者只是需要简单标记一下门店位置、物流轨迹的场景，用PostGIS简直就是杀鸡用牛刀，还容易把刀给崩了。最近我在几个实际项目里尝试了一些更轻量级的思路，发现真有不少比geo简单的数据库用法值得推荐。
先说个真实的坑。有个做社区团购的小客户，让我帮他们做个团长分布图。一开始我照旧上了PostGIS，结果部署环境折腾了半天，服务器内存占用高得离谱，最后客户嫌贵直接换了一家。后来我换了思路，直接用MySQL的普通字段存经纬度，配合简单的范围查询。虽然失去了复杂的空间索引能力，但对于查询“方圆5公里内的团长”这种需求，完全够用。而且MySQL大家都会用，维护成本低，数据量在百万级以内，响应速度其实并不慢。这种“土办法”，往往比高大上的GIS引擎更接地气。
再聊聊NoSQL里的MongoDB。这玩意儿在存非结构化数据方面是一绝，它内置了GeoSpatial索引，用起来比PostGIS简单太多。你只需要在字段里定义好位置信息，就能直接进行距离排序、范围查询。我有个做外卖配送轨迹分析的项目，就是用MongoDB存的。每天产生的轨迹数据量大得惊人，但通过MongoDB的分片集群，处理起来游刃有余。最关键的是，开发速度快，前端拿到数据直接就能用，不用像GeoJSON那样还要做一层解析转换。
还有种情况，就是数据量其实不大，但查询逻辑特别简单。这时候甚至不需要专门的地理数据库，用Redis就挺合适。Redis有个Sorted Set结构，配合简单的经纬度转换算法，可以实现实时的附近的人、附近的店铺等功能。虽然精度不如专业的GIS数据库，但对于社交类、LBS类应用来说，这个精度已经绰绰有余了。而且Redis的速度那是真的快，毫秒级响应，用户体验极佳。
当然，选择比geo简单的数据库，并不是说要抛弃专业性。如果你们做的是国土规划、高精地图这种对精度要求极高的领域，那还是乖乖用PostGIS或者Oracle Spatial吧。但对于大多数互联网应用，尤其是那些只需要简单位置标记、范围筛选的场景，过度设计反而成了负担。
我见过太多团队，为了追求技术先进性，强行上复杂的GIS架构，结果项目延期，bug一堆。反观那些采用轻量级方案的项目，虽然技术栈看起来“不够高大上”，但交付快，稳定性好，客户满意度反而更高。技术这东西，没有最好，只有最合适。
最后想说，别被那些复杂的术语吓住了。很多时候，解决问题不需要最复杂的工具，只需要最顺手的家伙。试着放下对GeoJSON的执念，看看周围那些被我们忽略的简单方案，也许你会发现，比geo简单的数据库，才是提升效率的关键。毕竟，能把事情做成，才是硬道理。
