1. 地理空间数据平台需求分析与架构设计
建设一个地理空间数据平台，第一步不是安装 PostgreSQL，也不是立刻建表，而是把业务目标、数据规模、并发访问和服务等级要求说清楚。需求分析决定了后续的存储模型、索引策略、部署形态和运维投入；架构设计则把这些约束翻译成可落地的组件与数据流。本章围绕“先定需求、再定边界、最后定架构”的主线展开，并给出选型决策记录（ADR）的写法。
一、从业务目标推导技术指标
地理空间平台的业务目标通常可以归为几类：地图服务与瓦片发布、空间查询与检索、轨迹与位置流处理、空间分析与统计、数据共享与开放。不同目标对数据库的压力方向完全不同。例如，地图瓦片发布更关注高并发只读与缓存命中率；轨迹流处理更关注高频写入与时间+空间复合索引；空间分析更关注复杂几何运算的 CPU 与内存开销。
把业务目标转成可度量的技术指标，至少需要明确以下维度：
- 数据规模：要素总量、几何复杂度（节点数）、栅格影像体量、历史版本保留周期。示例假设：矢量要素 2 亿条，平均每条几何 200 个节点，年增长 30%。
- 并发访问：峰值 QPS、读写比例、长事务比例。示例假设：读 800 QPS、写 120 TPS，读写比约 7:1。
- 服务等级：查询 P95 延迟、可用性、恢复点目标 RPO、恢复时间目标 RTO。示例假设：简单空间查询 P95 ≤ 200 ms，可用性 99.9%，RPO ≤ 5 min，RTO ≤ 30 min。
- 一致性要求：是否允许最终一致，是否要求强一致的空间拓扑校验。
这些指标不是拍脑袋写下的，而应来自业务方访谈、历史系统监控数据和容量预估。指标一旦确定，就成为后续选型与压测的验收基线。
二、PostgreSQL+PostGIS 与专用空间数据库的适用边界
PostgreSQL+PostGIS 的优势在于：开源、生态成熟、SQL 标准支持好、事务与扩展能力强、可与业务库同库部署，降低数据同步成本。其边界主要出现在极端规模或特定场景：单表数十亿要素且要求毫秒级任意区域查询、超大规模栅格实时切片、需要原生分布式空间分片的场景。
专用空间数据库（如部分商业空间库或分布式空间引擎）在特定场景下具备优势：内置空间分片、列式存储与向量化执行、针对栅格与点云的专用压缩。但其代价是许可成本、运维复杂度、与业务系统集成难度，以及 SQL 生态兼容性差异。
判断边界时，可用以下经验规则：若单表要素量在千万到亿级、查询以索引过滤+几何精算为主、并发在千级 QPS 以内，PostgreSQL+PostGIS 配合分区、并行查询和只读副本通常足够；若单表超过十亿且要求跨区域任意查询毫秒响应，或需要原生分布式写入扩展，则应评估专用空间数据库或分布式方案。
三、整体技术架构
一个典型的地理空间数据平台可分为接入层、存储层、计算层、服务层和运维层。接入层负责数据采集与同步；存储层以 PostgreSQL+PostGIS 为核心，配合对象存储存放原始影像与归档数据；计算层承担空间分析与批处理；服务层对外提供 OGC 服务、REST API 与瓦片服务；运维层负责监控、备份与容量管理。
下图给出该架构的核心组件与数据流关系，重点表达写入路径、查询路径和归档路径的分工。
四、选型决策记录（ADR）
架构设计完成后，应输出一份选型决策记录，把“为什么这样选”固化下来，便于后续复盘和交接。ADR 的核心字段包括：决策编号、背景、候选方案、决策结论、理由、影响与风险、复审条件。
以下是一个可直接参考的 ADR 示例，针对“空间数据主存储选型”这一决策：
| 字段 | 内容 |
|---|---|
| 决策编号 | ADR-001 |
| 背景 | 平台需存储约 2 亿条矢量要素，读 800 QPS、写 120 TPS，简单空间查询 P95 ≤ 200 ms，可用性 99.9%。 |
| 候选方案 | A. PostgreSQL 16 + PostGIS 3.4；B. 专用分布式空间数据库；C. 对象存储 + 外部计算引擎。 |
| 决策结论 | 选择方案 A 作为主存储，方案 C 作为归档与冷数据层。 |
| 理由 | 数据规模与并发在 PostgreSQL+PostGIS 可承载范围内；GiST 索引与分区可满足查询延迟；与业务库同库降低同步成本；开源许可与团队技能匹配。 |
| 影响与风险 | 单表过大时需分区；复杂分析可能占用较多 CPU，需与在线查询隔离；后续若单表超十亿需重新评估分布式方案。 |
| 复审条件 | 单表要素超过 10 亿，或 P95 延迟连续一周超过 500 ms，或写入 TPS 超过 500。 |
五、关键参数与容量估算示例
为了让架构设计可验证，需要做初步容量估算。以下为示例假设下的估算过程，实际项目应以真实采样数据为准。
-- 示例：估算矢量表存储与索引规模
-- 假设：2 亿条要素，平均几何 200 节点，每节点约 16 字节
-- 几何数据量 ≈ 2e8 × 200 × 16 B ≈ 640 GB
-- 属性数据量 ≈ 2e8 × 200 B ≈ 40 GB
-- GiST 索引约为几何数据量的 30%～50% ≈ 200～320 GB
-- 合计约 0.9～1.0 TB，需预留 30% 增长空间
-- 分区策略示例：按行政区域或时间范围分区
CREATE TABLE geo_feature (
id bigserial PRIMARY KEY,
region_code text NOT NULL,
geom geometry(Geometry, 4326),
created_at timestamptz DEFAULT now()
) PARTITION BY LIST (region_code);
-- 空间索引示例
CREATE INDEX idx_geo_feature_geom ON geo_feature USING GIST (geom);
估算结果用于判断单机是否可行、是否需要只读副本、是否需要分区。若估算显示单表超过 1 TB 且查询延迟难以满足，应在架构阶段就引入分区或分布式方案，而不是等到上线后再补救。