★ FEATURED ARTICLE 最近在做某区域车辆轨迹数据可视化的时候被一个老问题卡住了数据每天都在变今天生成的瓦片明天就过期了总不可能天天凌晨爬起来重新跑一遍切片任务。后来我把方案从预生成静态瓦片改成了“PostgreSQL PostGIS 动态出片”这个问题才算彻底解决。整个实现过程踩了不少坑但也有很清晰的路径可循这篇就完整梳理一遍给后续有类似需求的朋友做个参考。先说明一下这里说的“动态地图切片”到底指什么。传统的地图切片是把数据按照固定的缩放级别和网格规则提前渲染成图片文件PNG/JPG或矢量包放到CDN或静态服务器上供地图引擎调用。动态切片则相反它不预先绘制而是在前端地图请求某个瓦片的时候实时从数据库里查询该瓦片范围内的数据通过算法当场生成瓦片内容并返回。这么做最大的好处是——数据永远是最新的插入一条记录前端刷新地图就能看到完全绕开了“重新切片”的噩梦。那为什么我会选择直接用 PostgreSQL 来做这件事呢两个原因一是项目里原本就在用 PostgreSQL 存储业务数据引入 PostGIS 扩展后空间查询能力直接拉满不用再额外搭一套 GIS 服务或中间件二是动态切片的核心其实是“把瓦片坐标换算成空间范围再对这个范围做高效查询”这套逻辑用 SQL 表达非常自然全文都在数据库内部完成链路短、响应快。当然我并不是说其他方案不好像 GeoServer、MapServer 也是成熟的动态出图方案但如果你的数据量、并发量还在可控范围且本身已经重度依赖 PostgreSQL那“PostgreSQL 原生动态切片”绝对是一个值得认真考虑的轻量替代。这篇就从技术选型、库表设计、切片核心算法、接口封装、性能调优、以及生产环境里的踩坑实录这几个方面展开。我尽量把每一步的“为什么”也讲清楚而不只是堆代码。1. 整体设计与方案选型为什么是 PostgreSQL PostGIS1.1 动态切片要解决的核心矛盾做地图应用的人基本都会遇到这样一个矛盾数据更新频率高但地图瓦片生成慢。如果使用预生成切片的方案流程通常是数据入库 → 触发切片任务 → 渲染全量或增量瓦片 → 发布到对象存储 → 前端更新。这套流程在数据量小、更新频率低比如一天一次的场景下没毛病但一旦数据变成实时性要求高的轨迹点、车辆定位、订单分布、设备状态时麻烦就来了。全量切片费时费力还吃存储增量切片则需要维护复杂的变更检测逻辑。而且如果你用的还是第三方切片工具格式不兼容、样式难控制的问题会一个接一个地冒出来。动态切片的核心思想是把“切”这个动作从提前执行变成实时执行。每一个瓦片请求都等价于一次“按范围查数据 按样式渲染”的即时计算。前端用户放大缩小、拖拽地图时看到的永远是当前数据库里最新的数据。它所付出的代价是响应时间有所上升但通过合理的缓存和索引设计这个代价完全可以被压到很低。1.2 为什么不是 GeoServer而是直接写 SQL很多人一听到动态地图服务第一反应是上 GeoServer。确实GeoServer 是 J2EE 里非常成熟的地图服务器支持 WMS、WMTS、WFS 各种协议配好数据源就能输出瓦片。但我在几个项目里的感受是当你的需求只是“把某几张业务表的空间数据按 xyz 规则切成瓦片并且融入自己的鉴权、缓存、业务逻辑”时GeoServer 反而显得笨重。你需要在它外面再套一层代理去控制访问权限需要单独维护它的样式配置文件SLD遇到数据量大时还得给它调 JVM 内存。整体下来你其实是在为一个通用工具付出额外的复杂度。而这边的方案直击本质地图切片无非就是坐标换算 空间查询 结果编码。PostGIS 已经把空间查询和结果编码比如矢量切片的 MVT 格式都封装成了 SQL 函数那么剩下要做的只是写好 SQL、做好索引、设计好缓存。一切都还在你的数据库里事务、权限、备份体系天然复用不需要再维护一套新的服务。选型逻辑很简单能用 SQL 解决的问题就不要盲目引入中间件。1.3 矢量切片 vs 栅格切片我为什么首选矢量动态切片从输出格式上可以分为两大类矢量瓦片和栅格瓦片。栅格瓦片比如 PNG核心逻辑是数据库查出矢量数据后借助一些工具或库把它绘制成图片再返回。好处是前端不用自己渲染兼容所有地图 SDK坏处是每一次缩放级别变化、样式调整都要重新生成图片灵活性差而且返回的数据量也偏大。矢量瓦片MVT 格式则是把空间数据按瓦片裁剪后以紧凑的二进制格式返回给前端由前端如 MapLibre GL、Mapbox GL JS自己负责渲染。好处是传输数据量小、样式完全由前端控制切换主题、调整颜色只改样式文件根本不需要后端重新出图而且缩放过程中矢量瓦片可以做平滑插值视觉效果更好。所以本项目的核心实现采用了 MVT 矢量瓦片方案。如果你的应用场景是卫星影像、高程图这种必须出图片的那就得走栅格路线但只要你是做业务数据可视化、图层叠加、实时监控这类场景矢量切片基本都是更优解。2. 数据模型与空间化准备这一步没做好后面全白搭2.1 表结构设计空间字段与业务字段分离动态切片的数据来源是业务表但业务表往往不是为 GIS 设计的。比如一张订单表可能有“纬度”“经度”两个普通字段、也可能有“最近更新时间”字段但唯独没有空间字段。这时第一步就是需要将普通经纬度转成 PostGIS 的 geometry 类型。我建议直接在主表上维护一个专用的空间字段而不是每次查询时都现算。原因很简单如果每次查询都调用ST_SetSRID(ST_MakePoint(lng, lat), 4326)现算查询优化器没法有效利用空间索引每一条记录都要做一次函数计算性能直接崩盘。表结构调整的建议如下用订单位置举例ALTER TABLE biz_orders ADD COLUMN geom geometry(Point, 4326); UPDATE biz_orders SET geom ST_SetSRID(ST_MakePoint(lng, lat), 4326); CREATE INDEX idx_biz_orders_geom ON biz_orders USING GIST (geom);字段设计要点包括几个方面。空间字段统一使用geometry(Point, 4326)经纬度坐标用 WGS84 地理坐标系这是数据入库和业务侧通用标准索引必须用 GiST这是空间索引的核心加速手段如果表里数据量极大建议后续做分区或按时间归档否则索引膨胀和更新成本都会上来。另一个容易被忽略的问题是如果业务表频繁更新经纬度每次 UPDATE 都需要同步更新 geom 字段。可以在应用层代码里做好双写也可以通过触发器自动同步但务必保证两边一致。我出现过一次某字段更新失败但 geom 还在旧值的情况导致地图上出现大量“鬼影点”排查了半天才发现。2.2 坐标系换算4326 与 3857 的纠葛地学里有两个主流坐标系需要分清楚EPSG:4326也就是 WGS84用经纬度表示位置单位是度适合数据存储和交换EPSG:3857也就是 Web Mercator是绝大多数在线地图如某地图 WEB API、OSM使用的投影坐标系单位是米适合按屏幕像素做切片计算。实际做切片时前端传来的瓦片规则是基于 3857 的而数据库里存的是 4326 坐标。因此必须做换算。PostGIS 提供了直接转换函数SELECT ST_Transform(geom, 3857) FROM biz_orders WHERE ...;但这里有个性能陷阱ST_Transform不是一个特别轻量的函数如果数据量很大且每次都现算会给 CPU 带来很大压力。更聪明的做法是在库里同时维护两个字段一个是原始 4326一个是由触发器同步维护的 3857。查询切片时直接用 3857 字段去匹配瓦片范围不要现算也不要让索引建在 4326 字段上然后靠函数硬转——索引会失效。2.3 索引策略与维护节奏GiST 索引建好后动态切片的查询性能基本就稳了一半。但索引不是建完就不管了频繁的插入更新会导致索引页膨胀查询性能逐渐下降。日常维护建议如下低频更新场景每天批量导入一次在批量导入完成后执行一次VACUUM ANALYZE让统计信息和索引页保持健康状态。高频写入场景实时定位点可以考虑分区表按天/按月分表分区避免单表索引无限膨胀空间索引按分区建立查询时优化器自动剪裁到对应分区。我实测过一张千万级订单表没有分区但有良好的 GiST 索引单瓦片查询范围在几十平方公里以内时响应时间基本能控制在 3080ms 之间。一旦索引膨胀或统计信息过期执行计划会从索引扫描退化成全表扫描响应直接飙到几秒。这个差距会让你非常直观地理解“为什么索引需要日常维护”。3. 核心实现从瓦片坐标到 SQL 再到 MVT 的一整套链路3.1 瓦片坐标体系与范围换算地图切片有一套全球统一的标准规则通常叫 XYZ 规则。把整个世界在 Web Mercator 投影下看成一张大图缩放级别 z 决定这张大图被切成多少块在 z 级别下横向分成2^z块纵向同样是2^z块。每个瓦片的位置用 (x, y, z) 三个整数表示。前端地图引擎请求某个瓦片时后端要做的第一件事就是把 (x, y, z) 换算成该瓦片对应的地理范围。PostGIS 提供了一个非常方便的函数ST_TileEnvelope直接传入 z、x、y 就能返回对应的 3857 坐标系范围。SELECT ST_TileEnvelope(15, 27915, 12499);这个函数返回的是一个多边形代表瓦片覆盖的矩形范围。拿到这个范围之后就可以去查询所有落入该范围内的几何对象了。但光是“范围内”还不够因为一个跨多个瓦片的大多边形会让同一个要素出现在多个瓦片里导致前端渲染时出现重复绘制。这里就涉及到了“裁剪”。PostGIS 的ST_AsMVT是一套完整的矢量切片编码工具里面包含了裁剪逻辑所以核心任务可以简化成“查出范围内数据 交给 ST_AsMVT”。ST_TileEnvelope在换算时默认使用 3857 坐标系且边界略微外扩这也是为了留出边缘缓冲避免裁剪时出现锯齿。3.2 矢量切片的“三剑客”ST_AsMVT、ST_AsMVTGeom、ST_TileEnvelopePostGIS 从 2.4 版本开始就集成了完整的 MVT 矢量切片生成能力。它和栅格切片最大的不同在于返回的不是图片而是 protobuf 二进制数据。直接看一段我在项目里使用的核心 SQLWITH bounds AS ( SELECT ST_TileEnvelope($1, $2, $3) AS geom ), mvt_geoms AS ( SELECT ST_AsMVTGeom( ST_Transform(t.geom, 3857), bounds.geom, -- 瓦片范围 extent 4096, -- 缓冲像素处理边缘要素 buffer 64 ) AS geom, t.id, t.name, t.category FROM biz_orders t, bounds WHERE t.geom ST_Transform(bounds.geom, 4326) AND ST_Transform(t.geom, 3857) bounds.geom ) SELECT ST_AsMVT(mvt_geoms, orders, 4096, geom, id) FROM mvt_geoms;这个 SQL 拆解出来是三个步骤。第一步ST_TileEnvelope算出当前瓦片的范围和缓冲范围。extent 4096是瓦片内部的坐标精度通常是 4096 或 8192数字越大概率越精细但同时也会让 MVT 文件变大buffer 64是在瓦片边界外额外扩展的像素量目的是让那些延伸到相邻瓦片里的要素在这一瓦片里也能被正确绘制避免边缘出现断线。第二步ST_AsMVTGeom将业务几何对象从数据库坐标系转换到瓦片内部的本地坐标系同时进行裁剪。这一步是整个切片链路中计算量最大的部分。注意我在这里写了两个范围条件一个是在原始 4326 坐标系下用做粗筛一个是在转换后的 3857 下再精筛。第一道粗筛可以很好地利用 GiST 索引第二道精筛保证数据准确。如果你只用 3857 的索引字段第一道粗筛可以直接写成t.geom_3857 bounds.geom会更快。这里有几种常见写法的取舍。一种是先查询ST_Transform(bounds.geom, 4326)再与 4326 字段做运算这样能用上 4326 的索引另一种是直接使用 3857 字段建议维护自然能命中索引。两者都可以但一定不要出现“对带索引的字段套函数再比较”的情况否则索引失效。上述 SQL 里为了直观用了ST_Transform(t.geom, 3857)生产环境我建议直接使用冗余的 3857 字段。第三步ST_AsMVT把所有几何对象聚合成一个完整的 MVT 二进制流。注意最后一个参数传了id这是作为 MVT feature 的主键属性前端拿到后可以做要素去重和状态管理。ST_AsMVT的第一个参数是行集合第二个参数是图层名前端 MapLibre 里用这个名称来引用图层。3.3 按需过滤如何根据前端参数动态拼 WHERE实际业务中切片通常不是把整张表的所有数据一股脑端给前端的。比如只想看某个类别的设备、某个时间范围内的轨迹、某种状态的订单。这时就需要把动态切片和动态过滤结合起来。我的做法是把切片接口设计成通用的前端通过 query string 传入过滤条件后端拼接成 SQL 片段。但这里有一个原则要守住——绝不能用字符串拼接方式直接拼接前端输入那样会带来注入风险。建议的做法是定义一份白名单映射表前端只能传入白名单内的字段名和字段值后端根据字段名去查映射表里对应的合法表达式。举个例子-- safe_filters 是根据前端参数构造的 JSONB WITH bounds AS (...), filtered AS ( SELECT * FROM biz_orders WHERE geom ST_Transform((SELECT geom FROM bounds), 4326) AND (($1::jsonb)-category) IS NULL OR category ($1::jsonb)-category) AND (($1::jsonb)-status) IS NULL OR status ($1::jsonb)-status) ) SELECT ST_AsMVT(...) FROM filtered;实际实现时我会把过滤条件全部参数化前端传参后用白名单校验字段名再用CAST($n AS type)绑定值。这样既安全又能利用 PostgreSQL 的预编译能力。3.4 栅格切片的另一种实现备选方案如果你的项目真的需要输出 PNG 栅格瓦片PostgreSQL 并非不行只是相对会绕一些。思路是数据库查出范围内的矢量数据后使用 PL/Python 或其他能调用图像库的扩展把数据画成一个图片。但说实话这个方案我并不是很推荐因为渲染工作本质上是图形学问题不应该塞进数据库里。数据库擅长的永远是数据的存储、索引和查询。如果一定要出栅格瓦片更合理的做法是在后端应用层比如某个地图服务模块拼接这么一条链路PostgreSQL 查数据 → 应用层用绘图库如 Pillow、Canvas绘制图片 → 返回 PNG。这样数据库只承担它最擅长的工作渲染交给专业工具。顺带提一句如果你做的是“本地栅格底图切片”比如离线卫星图按标准规则切成 PNG 供移动端使用这个方案其实无所谓数据库重点在图像裁剪和金字塔存储。和这里的场景并非同一回事不要混淆。4. 服务接口与缓存设计把动态切片的响应时间打下来4.1 接口设计与路由规范动态切片服务的接口本质就是一个返回二进制数据的 HTTP 接口。前端地图引擎会按照标准规则请求GET /tiles/{z}/{x}/{y}.mvt后端拿到 z/x/y 后调用上面那套 SQL把结果作为application/x-protobuf返回并附上必要的响应头Content-Type: application/x-protobuf Content-Encoding: gzip Cache-Control: public, max-age600Cache-Control这里比较讲究。如果数据更新频率高缓存时间不宜太长10 分钟左右是一个比较均衡的选择如果是纯静态数据可以放到 24 小时甚至更长。动态切片并不意味着完全抛弃缓存而是“缓存策略动态化”。4.2 两级缓存本地内存 倾斜型 Redis动态切片虽然不用预生成文件但不代表每一次请求都必须实时查数据库。实际上绝大多数地图应用的数据分布是很不均匀的主城区、中心商圈等区域的瓦片被高频请求而边缘地区无人问津。这就是典型的“倾斜访问”。应对它最好的办法是瓦片级缓存。我的做法分两层第一层是后端服务内存缓存用一个 LRU 结构容量比如 2000 个瓦片键格式为{z}_{x}_{y}_{过滤条件哈希}。命中率通常能到 30%50%因为这个层级的响应是最快的小于 1ms。第二层是 Redis 缓存键同样加过滤条件哈希过期时间按业务需求设置为 530 分钟。Redis 命中率可以补足内存层未命中的那些请求从而保护 PostgreSQL 不被打爆。这里有一个容易踩的坑缓存键必须把过滤条件一起算进去否则不同参数请求会互相串数据。比如 A 用户只看status1B 用户看全部数据若键一样就会导致 A 刷出 B 的数据。我的做法是把过滤条件先做排序后拼接再做个 MD5 摘要作为键的一部分。4.3 数据库连接与并发控制动态切片接口是典型的高并发读场景。PostgreSQL 默认配置下max_connections通常是 100如果每个请求都独占一个连接热点瓦片一多连接池就会被打满。两个建议一是后端服务使用连接池不主动关闭连接而是复用空闲连接二是尽量避免在事务内做长时间查询切片查询应该是一条语句快进快出。另外建议打开pg_stat_statements扩展用来追踪高频 SQL 的执行计划和耗时。这个工具帮我在生产环境里定位到不少“慢在隐式类型转换”的查询非常值得依赖。如果一个瓦片查询特别慢比如某个 z 级别下范围过大、返回要素上万就不要死磕数据库了。更合理的做法是把大范围查询退化为“聚合下钻”即在前端较低的缩放级别显示热力、聚类、或者用十万条数据抽稀后的代表性点位只有放大了才去加载明细瓦片。这是地图产品里很常见的优化路径比单纯调 SQL 效果更显著。5. 性能优化与生产参数调优实录5.1 SQL 执行计划分析怎么判断切片 SQL 是否健康每次写完切片 SQL第一步不是直接上线而是打开执行计划看几条关键信息。用EXPLAIN ANALYZE跑一遍典型的瓦片请求重点关注Index Scan是否生效有没有退化成Seq Scan。实际返回行数和预估行数差距大不大偏差大说明统计信息过期。耗时占比最高的节点是哪一个是范围查询还是ST_AsMVTGeom的裁剪计算。分享一个我实际遇到的案例某次在 z13 级别请求瓦片EXPLAIN ANALYZE显示查询耗时 900ms其中 80% 耗在ST_AsMVTGeom上。原因是该瓦片范围内有 4000 多个多边形要素每一个都要做一次几何变换和裁剪。优化方式是低缩放级别时先对空间数据做一次预处理简化用ST_SimplifyPreserveTopology把少量顶点后传给ST_AsMVTGeom如果业务允许甚至可以先做一次空间聚簇只返回中心点大幅减少 MVT 中的要素数量。优化后这个瓦片耗时降到了 120ms 左右。5.2 PostgreSQL 相关参数调优如果服务器内存比较充裕建议调整这几个参数对 PostGIS 场景帮助很明显shared_buffers通常设置为物理内存的 25% 左右比如 16G 内存可以配4GB。work_mem这个参数决定了单个排序/哈希操作能用的内存PostGIS 部分复杂计算涉及临时构建适当调大到 64MB 左右能减少落盘但注意不要调得太大否则并发一大内存直接吃满。maintenance_work_mem用于VACUUM、CREATE INDEX等维护操作可以调到 2GB 以上加快索引重建。random_page_cost如果数据存储在 SSD 上建议从默认 4 降到 1.1 左右让优化器更倾向于索引扫描而不是顺序扫描。5.3 数据分区与历史数据归档动态切片服务面对的往往是一个持续增长的数据表。如果不做任何归档三年后你会在一个巨大的表上做范围查询即使有索引也很吃力。我在这类项目里常用的策略是时间分区CREATE TABLE biz_orders ( id bigint, ... created_at timestamptz, geom geometry(Point, 4326), geom_3857 geometry(Point, 3857) ) PARTITION BY RANGE (created_at); CREATE TABLE biz_orders_202411 PARTITION OF biz_orders FOR VALUES FROM (2024-11-01) TO (2024-12-01);分区之后切片查询在 SQL 中带上时间过滤条件PostgreSQL 的分区裁剪会自动跳过无关分区。我见过分区前后的性能差距一次全表范围查询从 1.5s 降到 90ms。所以如果你的数据是持续产生的“流水型”数据分区最好在一开始就规划好不要等表大了再迁移那会儿迁移成本会非常痛苦。但同时也要留意分区表上创建全局索引、约束等都有一些限制PostGIS 的分区配合也需要小心。如果你不太熟悉分区表的运维前期也可以退而求其次用“按时间分表 视图合并”来过渡。6. 常见问题与避坑记录6.1 瓦片边缘出现“白线”或要素断裂这是一个典型问题。原因是ST_AsMVTGeom的默认buffer为 0会导致瓦片边缘要素被精确裁剪前端渲染时出现半截要素或裂缝。解决办法是在生成 MVT 时把buffer参数调到 64 或 128。这个值不是越大越好太大会增加瓦片体积和渲染负担64 是多数场景下的均衡值。6.2 前端地图偏移、位置对不上大概率是坐标系没对齐。前端用的地图底图是 3857数据却还在 4326。注意两点数据库存储统一用 4326对外输出切片时统一转成 3857。如果你发现所有地物整体偏移了几百米或几十米优先怀疑投影坐标系匹配问题而不是数据本身。6.3 ST_AsMVT 返回空结果通常原因有两个一是ST_AsMVT的前几个参数没对应好特别是图层名必须和前端匹配二是查询结果里的几何字段名和传给ST_AsMVT的geom参数不一致。常见错误是SELECT ST_AsMVTGeom(...) AS geometry但ST_AsMVT里指定的是geom导致生成的 MVT 里字段名缺失前端无法渲染。6.4 切片服务响应很慢CPU 飙升先别怀疑数据库慢大概率是缓存被打穿、或 SQL 里出现了隐式类型转换。比如前端传的id是字符串而表里是 bigintPostgreSQL 可能没法直接用索引导致全表扫描。建议统一接口入参类型并在 SQL 里都显式写清楚类型。6.5 动态切片接口如何做权限控制动态切片往往涉及敏感数据不能随便让人拉全表。建议在接口层统一做鉴权登录态验证、范围限制比如只能看某个区域、字段脱敏。鉴权通过后把用户权限范围内的时间、区域、字段条件一并作为过滤条件传入切片 SQL。这块代码写在应用层不要在数据库层临时拼 SQL因为应用层能更灵活地接入既有权限体系。7. 几个值得认真思考的经验细节写到这里按我的经验再补充几个容易影响成败的细节。第一如果你打算把动态切片投入生产请务必做好监控告警。至少监控三个指标瓦片接口 P95 耗时、PostgreSQL 活跃连接数、以及瓦片缓存命中率。P95 超过 500ms 就要排查 SQL 或索引问题活跃连接数长期高位说明连接池配置不合理缓存命中率如果在 20% 以下说明缓存策略失效或缓存键设计有问题。没有监控动态切片服务出问题时你会非常被动。第二动态切片不要等到生产环境出问题才想起优化。我建议在写第一版 SQL 的时候就直接带上EXPLAIN ANALYZE把一套典型瓦片请求的执行计划打印出来确认走的是索引扫描再上线。前期的这几分钟会在后期为你省下大量排查时间。第三数据更新频率越高越需要关注基础表的autovacuum状态。PostGIS 的 GiST 索引在频繁更新时膨胀速度比普通 B-Tree 快很多如果 autovacuum 跑得不够积极索引消耗的磁盘和内存会越来越大切片查询慢慢变慢。建议给大表单独设置更高的 autovacuum 频率。第四前端渲染 MVT 时如果发现某些图层在放大后过于粗糙可以在ST_AsMVTGeom的extent参数上做调整比如从 4096 提到 8192同时把前端maxzoom重新梳理一遍。不要盲目的把所有层都设为同一个精度要根据图层复杂度分别对待。第五关于数据实时性和缓存之间的平衡我可以给一个经验值如果业务对实时性要求是秒级缓存过期时间设置在 510 秒就足够如果是分钟级30 分钟缓存是个比较推荐的折中如果对实时性要求不高可以考虑小时级缓存。但无论哪种都建议把“最后更新时间”作为响应头里的自定义字段返回前端可以根据这个时间做增量刷新用户感知会更友好。这个动态切片方案我目前已经用在某跨平台系统上稳定跑了大半年数据量千万级、日增量十万级、QPS 在百级左右整体表现可以说是游刃有余。后续如果哪一天数据量再上一个数量级我大概率会把“PostgreSQL 预处理 对象存储边缘缓存”结合起来进一步压测优化但就目前而言这套 PostgreSQL 原生方案依然是我面对“数据实时变化 地图切片服务”这类需求时第一反应会选择的一条务实路线。
阅读完成 · 觉得有帮助？
