搞地图开发这几年，我见过太多人在数据库选型上走弯路。很多人一听Geo就想到PG，觉得稳，但实际落地的时候，才发现很多业务根本用不到那么重。其实对于中小团队或者刚开始做位置服务的项目，轻量级方案才是王道。今天不扯虚的，直接聊聊我在实际项目中怎么用好这几类工具，以及那些坑我是怎么踩过来的。

先说最基础的情况，如果你的数据量不大，比如几万到十万级的点位，PostGIS是首选。别嫌它老，它的生态太成熟了。我接手过一个本地生活项目，需要查询“某商场周边300米内的咖啡馆”。用PostGIS的ST_DWithin函数，毫秒级就出结果了。这时候别听信网上那些说要搞什么Hadoop集群的鬼话，那是杀鸡用牛刀。记得当时有个实习生，非要给PG加个缓存层，结果配置出错，查询反而慢了十倍。这就是典型的过度设计，geo数据库使用说明的核心在于“匹配业务”，而不是炫技。

但是，如果你的场景是高频次的实时位置更新，比如外卖骑手定位、共享单车车辆状态，PostGIS的压力就会上来。这时候我建议看看ClickHouse或者StarRocks这类列式数据库。为什么？因为列存对聚合计算特别友好。我们曾做过一个分析看板，要算每个网格内过去一小时的车辆平均停留时间。用PG跑，光索引维护费都够呛，响应时间经常卡在秒级。换到ClickHouse后，配合稀疏索引，同样的查询逻辑，速度提升了至少两个数量级。这里有个细节很多人忽略，列式数据库处理几何字段时，空间索引的效率并不像行式数据库那么“丝滑”，所以需要你在ETL环节做好预计算，把复杂的几何关系转成简单的维度表关联。

再说说非结构化的空间数据，比如卫星影像、LiDAR点云。这种数据传统关系型数据库根本存不下。这时候MinIO这种对象存储加上DuckDB或者Parquet格式，是性价比极高的组合。我见过一个团队，硬是用S3存储点云，然后用Pandas去读，内存直接爆掉，服务器重启了三次才搞明白原因。正确的做法是利用Parquet的谓词下推特性，在读取阶段就过滤掉无关的坐标范围。这不仅是性能问题，更是成本控制。存储单价虽然低，但读写费用如果不控制，账单能吓死人。

还有一个容易踩的坑是坐标系。Geo数据里，WGS84和当地平面坐标系的转换，是很多BUG的源头。有一次线上事故，就是前端传来的经纬度和数据库里存的投影坐标没对齐，导致筛选出来的区域偏了几公里。排查花了一整天，最后发现只是个简单的转换遗漏。所以，无论你的架构怎么搭，入库前必须统一坐标系规范。这一条比任何高并发优化都重要。

至于费用，我不太想推荐那些云厂商的托管Geo服务，按量计费看着便宜，流量一大，费用就像滚雪球。如果是核心业务，自建集群虽然运维成本高，但长期看更可控。我算过账，一年下来的服务器成本，大概只有云端方案的一半，而且数据安全性更有保障。

最后给大家几条实在的建议。第一，别迷信单一技术栈，PG+Redis缓存是经典组合，适合大多数CRUD场景；第二，实时流处理别硬塞进数据库，用Kafka做缓冲，异步落库，用户体验会好很多；第三，数据清洗比存储技术更重要，脏数据进得去，出来的结果肯定是一堆浆糊。

技术选型没有银弹，只有最合适你当前业务阶段的锤子。如果你正在纠结怎么设计空间索引，或者在PG和ClickHouse之间摇摆不定，或者遇到奇怪的空间计算精度问题，欢迎随时来聊。具体的业务场景千差万别，最好带上你的数据规模QPS峰值，我们可以深入看看怎么调整索引策略和分片逻辑。别怕问，避坑都是靠一个个真实案例堆出来的。