第3章时空数据存储技术

3. 时空数据存储技术：PostgreSQL + PostGIS 环境搭建、空间索引（R-Tree、Grid）、时序数据库（InfluxDB）基础

好，咱们进入第三讲。前面聊了数据采集和清洗，现在数据到手了，放哪儿？这是个关键问题。环境监测数据有两个明显特征：有位置（每个监测点都有经纬度），有时间（数据是连续采集的）。所以，普通的关系型数据库存起来很别扭。我个人的经验是，选对存储方案，后续分析能省一半力气。

核心思路：空间数据用 PostgreSQL + PostGIS，时序数据用 InfluxDB。两者配合，各司其职。

3.1 PostgreSQL + PostGIS 环境搭建

PostgreSQL 本身是个强大的关系型数据库，但原生不支持地理空间操作。PostGIS 就是它的空间扩展，把它变成了一个真正的空间数据库。说白了，装上 PostGIS，你就能在 SQL 里直接算距离、算面积、做空间连接了。

安装步骤（以 Ubuntu 20.04 为例）：

# 1. 安装 PostgreSQL
sudo apt update
sudo apt install postgresql postgresql-contrib

# 2. 安装 PostGIS
sudo apt install postgresql-12-postgis-3

# 3. 创建数据库并启用 PostGIS 扩展
sudo -u postgres psql
CREATE DATABASE env_monitor;
\c env_monitor;
CREATE EXTENSION postgis;
CREATE EXTENSION postgis_topology;

嗯，这里要注意一点。安装完成后，最好验证一下 PostGIS 版本，避免后续踩坑。

SELECT PostGIS_Full_Version();

如果看到版本号输出，就说明装好了。我曾经在一台旧服务器上装过，因为系统源里的 PostGIS 版本太老，导致空间函数调用报错。后来我改用源码编译才解决。所以，建议直接用官方源或者 PostgreSQL 官方仓库，省心。

3.2 空间索引：R-Tree 与 Grid

数据量一上来，查询就慢了。比如你要查某个监测点周围 5 公里内的所有站点，如果没有索引，那就是全表扫描，几百万条数据查一次可能要几十秒。这谁能忍？

空间索引就是用来解决这个问题的。PostGIS 默认使用 R-Tree 索引，它的原理是把空间对象按最小外接矩形（MBR）进行层级划分。你想想看，查询时先判断矩形是否相交，再精确计算，效率提升是几何级的。

创建空间索引的 SQL：

-- 假设我们有一个监测站点表
CREATE TABLE monitoring_stations (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    geom GEOMETRY(Point, 4326)  -- 4326 是 WGS84 坐标系
);

-- 创建 R-Tree 索引（GIST 索引）
CREATE INDEX idx_stations_geom ON monitoring_stations USING GIST (geom);

除了 R-Tree，还有一种 Grid（网格）索引。它的思路更简单粗暴：把地图切成固定大小的网格，每个网格里记录有哪些对象。查询时，先定位到网格，再在网格内查找。

什么时候用 Grid？我个人习惯是：数据分布非常均匀，或者查询模式固定（比如按行政区划查询）时，Grid 索引性能反而更好。R-Tree 适合数据分布不均匀的场景，比如城市中心站点密集，郊区稀疏。

索引类型	原理	适用场景	缺点
R-Tree (GIST)	基于最小外接矩形层级划分	数据分布不均匀，查询范围多变	构建和维护成本较高
Grid	固定网格划分	数据均匀，查询模式固定	网格大小难调，边界查询效率低

避坑指南：我曾经在一个项目中，对全国 10 万个空气质量监测站建了 R-Tree 索引，但查询时发现某些区域特别慢。后来排查发现，是因为这些站点的坐标精度不一致，有的精确到小数点后 6 位，有的只有 2 位。PostGIS 在处理时会产生大量无效的矩形重叠。解决办法是：统一坐标精度，或者对几何对象做简化处理。

3.3 时序数据库 InfluxDB 基础

环境监测数据是典型的时序数据——每个监测点每隔几分钟上报一次数据。如果用 PostgreSQL 硬扛，时间一长，表会变得巨大，查询历史趋势时慢得让人抓狂。

InfluxDB 就是专门为这种场景设计的。它有几个核心概念：

Measurement：相当于关系型数据库的表
Tag：标签，用于索引和分组（比如站点ID、监测类型）
Field：实际数值（比如 PM2.5 浓度、温度）
Timestamp：时间戳，自动索引

安装 InfluxDB（以 2.x 版本为例）：

# 下载并安装
wget https://dl.influxdata.com/influxdb/releases/influxdb2-2.7.0-linux-amd64.tar.gz
tar xzf influxdb2-2.7.0-linux-amd64.tar.gz
sudo cp influxdb2-2.7.0-linux-amd64/influxd /usr/local/bin/

# 启动服务
influxd --reporting-disabled &

写入数据示例（使用 InfluxDB 的 HTTP API）：

curl -XPOST "http://localhost:8086/api/v2/write?org=myorg&bucket=env_data&precision=s" \
  --header "Authorization: Token YOUR_TOKEN" \
  --data-raw "air_quality,station_id=S001,type=PM25 value=35.6 1695000000"

你看，一行数据就包含了 measurement（air_quality）、tag（station_id、type）、field（value）和时间戳。这种结构写入速度极快，我实测过，单机每秒能写入几十万条数据。

注意：InfluxDB 的 Tag 是有索引的，Field 没有。所以，经常用于过滤的字段一定要设为 Tag。比如站点ID、监测指标类型。数值本身（如浓度值）设为 Field。我曾经见过有人把数值也设为 Tag，结果查询时索引爆炸，内存直接打满。

3.4 知识体系总览

为了让你更直观地理解这三部分的关系，我画了一张图：

这张图把整个体系串起来了。左边是数据源，中间是两种存储引擎，右边是最终的分析输出。说白了，PostGIS 管“在哪”，InfluxDB 管“什么时候、值是多少”。两者结合，才能回答“某个区域在某个时间段内污染浓度如何变化”这类问题。

3.5 实战建议

最后，给你几个我在项目中总结的实用建议：

数据量不大（百万级以内）：只用 PostgreSQL + PostGIS 就够了，时序数据也存成普通表，配合时间索引即可。
数据量中等（千万到亿级）：PostGIS 存空间数据，InfluxDB 存时序数据。查询时通过站点ID和时间范围做关联。
数据量巨大（十亿级以上）：考虑分库分表，或者引入分布式方案（如 TimescaleDB 或 ClickHouse）。

一个小技巧：如果你不想维护两套数据库，可以试试 PostgreSQL 的 timescaledb 扩展。它把时序数据自动按时间分区，查询性能也不错。但空间分析能力还是不如 PostGIS + InfluxDB 的组合灵活。具体选哪个，看你的业务场景。

好了，这一章的内容就到这里。存储层搭好了，下一章我们就可以开始真正的时空分析了。

📚 课程目录

3. 时空数据存储技术：PostgreSQL + PostGIS 环境搭建、空间索引（R-Tree、Grid）、时序数据库（InfluxDB）基础

3.1 PostgreSQL + PostGIS 环境搭建

3.2 空间索引：R-Tree 与 Grid

3.3 时序数据库 InfluxDB 基础

3.4 知识体系总览

3.5 实战建议