PostgreSQL on 个人技术随想

速通PostGIS地理数据分析

Mon, 23 May 2022 12:09:16 +0800

前言

因为一些缘故，接触了一下对空间地理数据的分析工作。忙完以后，想了想决定写下这篇文章，方便日后如有需要，可以快速查阅，也供后人参考。

背景条件

我们主要是针对给定的空间地理数据（如GeoJson，Shapefile）进行一些数据提取和分析，获得我们想要的分析结果。本文不讨论这些数据如何收集，抑或是如何编制，我们只讨论分析方面的内容，并且也不会涉及非常深，因为本文重点更在于，快速介绍对地理数据进行分析的大致方法，而具体的分析思路、分析流程，是各位灵感发挥的重要地方。

本文会涉及到对PostgreSQL数据库的使用，建议未接触过PostgreSQL的读者自行查阅相关的基础资料。不过，假如对基本的SQL，特别是MySQL/MariaDB有基本的了解，甚至是一定的使用经验，可以参考本文的前序文章在MySQL基础上速通PostgreSQL

因为我本身不是学地理信息专业的，因此以上知识与理解是临时抱佛脚速成学得，如果本文有什么错误，还请批评指正（请发邮件给我）！多谢各位包涵。

目标

我们的分析工作环境可能需要我们做到以下几点。

建立一个PostgreSQL数据库（下面简称psql），并启用PostGIS
将收集到的数据放到psql中
使用Python对这些数据进行进一步的分析计算

数据库为什么选择PostgreSQL呢？可能是由于PostgreSQL中的GIS插件PostGIS比较优秀，支持比较好。

而选用Python进行数据分析，是因为其提供了Numpy/Pandas/Geopandas/Scipy等十分通用的工具。如果你喜欢其他工具体系，完全可以替换，只要可以连接读取psql中的地理数据即可。这里我们以Geopandas作为主要工具。

环境配置

我觉得配环境向来是浪费口舌的，但又是最重要的一环，没有配好的环境，我们什么都做不了。

我们需要安装的软件有:

PostgreSQL + PostGIS插件
Python + Pandas/Numpy/Scipy/SQLAlchemy/Matplotlib模块
Geopandas/Geoalchemy

一般来说，最上面的两项是比较容易配置的，安装就好了，有非常多的方法，PostgreSQL在Windows上有安装包，在Linux上有软件包管理器。而Python部分无论是使用Conda还是使用Pip，都非常方便。

但有个例外，就是Geopandas/Geoalchemy两项。不知道是怎么回事，Conda源中Geopandas版本号比较古老，而使用conda-forge渠道会把安装卡在环境依赖关系检测部分。我当时是尝试了几次都没弄出理想的效果。

如果你也遇到了这样的问题，或许可以试试下面的方法：容器/Windows Subsystem of Linux

独立的环境

实际上这个方法比较诡异，但至少是能非常顺利地使用的。

我当时是无意中，看到Ubuntu的APT源中，存在python3-geopandas和python3-geoalchemy2两个软件包，版本号也不过时(Debian源中也有，但Debian Bullseye使用的版本号比Ubuntu 22.04的老一些)，遂直接放弃使用Conda配环境的念头，直接安装这两个软件包，运行一切正常。

当然，这样的方法能不出乱子，也得益于这些软件包没有依赖特定的硬件配置或者组件版本号。如果是需要依赖某个特定版本CUDA Toolkit的软件包，或许这样会出现更大的问题。

不过，这样一来，环境隔离就变成了一个需要考虑的问题。我们希望将这些环境隔离起来，万一日后发生错误，可以整个删除，而不对骨干系统造成影响。而APT安装的软件包，是全局性的。

因此，我们可以通过将这部分环境，整个作为一个容器进行隔离。

如果你主力操作系统使用的是Windows，那么可以尝试在WSL中安装Ubuntu（目前WSL可以自己手动import发行版，只要空间足够，可以添加非常多个实例，作为各自隔离的子系统，即便它们是同一个发行版，这和应用商店安装的有所不同）。
如果你主力操作系统使用的是Linux，那么可以试试LXC/LXD解决方案，直接运行一个Ubuntu容器。Docker应该也是不错的选择。
如果你主力操作系统使用的是Mac OS X，那………我也不清楚有什么好的解决方案，毕竟我不是苹果用户，反正思路和上面的是一样的。实在不行还有虚拟机对吧。

创建容器后，就可以直接通过APT安装python3-geopandas和python3-geoalchemy2，以及其他需要的Python模块。

如果你喜欢使用Visual Studio Code 配合 Jupyter Notebook，那么只需要安装python3-ipykernel软件包，并将Visual Studio Code连接到你的WSL或者容器中，打开工作文件夹，创建一个.ipynb文件，选择内核为系统目录下的python，你喜欢的工作流程就呈现在你的面前了。

PostGIS速通

接下来，我们试着介绍以下，如何使用PostGIS对地理数据进行查询。假设我们需要在名为gis_test1的数据库上存储空间数据。

顺带一提，我好像并没有接触3D形状的查询分析，我接触的都是在平面上的地理数据分析。不过，方法几乎是相同的。

启用PostGIS

若想要在一个数据库(Database)中存储地理空间数据，则必须启用PostGIS扩展。

⚠️ 警告

这里的数据库(Database)概念，指的是PostgreSQL服务器下,一个个相对独立的Database，并不是指整个PostgreSQL服务器实例。

我们连接到目标数据库后，使用以下代码启用PostGIS。操作前请确认执行以下语句时，是否已经切换到对应的数据库。

`1`	`CREATE EXTENSION postgis`

GIS中的形状

小学数学课上学过的，点动成线，线动成面，面动成体，在我们三维空间中都遵循着这些道理。

而如果我们将目光投向真实世界平面地图，我们会发现，地图上的许多事物，可以概括为以下几种类型:

点(Point): 地图上的一个点，例如，家门口的小卖部，抑或是市内的一座医院，就是一个点
线(Linestring): 地图上的一条线，例如，一条没有分支的地铁线路，从头到尾就是一条线
多边形(Polygon): 地图上的一个多边形，例如，在中国，一个县级行政区划（市辖区、县级市、县、旗等）所管辖的区域，就是一个多边形

这几种类型，正是在GIS中，对二维地图上的空间事物进行描述的基本类型。参考9. Geometries — Introduction to PostGIS

在此之上，如果我们将多个同类型的事物，放到一起，就会得到几个集合类型(Collection)，其中几个都是以 Multi 开头的

点集(MultiPoint): 地图上的多个点，例如，市内同名连锁便利店的集合，就是一个点集
线集(MultiLineString): 地图上的多条线，例如，市内地铁网络的线路集合，就是一个线集
多边形集(MultiPolygon): 地图上的多个多边形，例如，在中国，一个地级市下属的所有县级行政区划（市辖区、县级市、县、旗等），就是多个多边形组成的集合
地理集合(GeometryCollection): 如你所猜想的，以上几种任意类型的集合，而且也可以包含集合类型

这时候一定会有人问，上文中为什么要将医院、便利店标记成点(Point)？许多地点都有一定的尺寸、占地面积，将其抽象成点是否合适

参照上面参考页面:

Points are used to represent objects when the exact details, such as shape and size, are not important at the target scale. For example, cities on a map of the world can be described as points, while a map of a single state might represent cities as polygons.

Polygons are used to represent objects whose size and shape are important. City limits, parks, building footprints or bodies of water are all commonly represented as polygons when the scale is sufficiently high to see their area. Roads and rivers can sometimes be represented as polygons.

省流版本: 这取决于考察的区域范围与这些地点大小的相对关系，以及这些地点的尺寸是否会对分析结果产生影响。

举个例子，我们如果想要在城市火车站一角，张贴一张地铁线网概览图，那么我们可以放心地将地铁线路抽象为一条条线，而且这些线在图中的粗细，除了影响游客的可读性外，在传达信息的准确性上，并不会带来什么负面影响。

但如果，我们需要在地铁线路附近新建一栋大楼，需要向下挖掘地基，那么我们就不能用上面例子中的概览图来确定施工范围边界！毕竟一条线本身并没有粗细，在考察施工边界这样精度的问题时，这样的一条条线不能告诉我们地铁隧道具体位于何处，也不能告诉我们应该从何处向下挖掘地基。我们必须将地下的铁路隧道视为具有具体粗细的线，也就是一个多边形，才能在地图中准确表现出地铁隧道的位置，从而让我们准确避开地铁隧道进行施工。

PostGIS的形状运算

我们定义出上述元素，自然是为了方便接下来的运算工作。

通常，我们存储到数据库中的数据，常常是地图上事物的原始数据，如城市中公交车站的位置，各建筑物的具体地理边界等。然而，对于我们的分析需求来说，从数据库中读取这些原始数据往往是不够的，我们通常需要进行更复杂的运算，例如查询某个区域内公交车站的数量，或是某个区域内道路的总长度。

PostGIS提供的函数可以帮助我们通过SQL语句，构造上述查询目标的SQL表达式，从而轻松从数据库中获得上述信息。

形状的关系

在中小学时期，我们就学习过，两个图形是否相交，如何相交，会构成不同的模式。在PostGIS中，这一问题进一步和图形的内部、边界、外部结合起来，构成了GIS系统中的九维相交模型(9-Intersection Model)。

具体的解释，可以参考https://postgis.net/docs/manual-3.2/using_postgis_query.html

简单来说，我们常常涉及到的运算，其实主要以计算相交(Intersect)和包含(Contain)关系为主。而PostGIS的函数，通常以ST_开头。上述链接也提供了相关的示例，可以看看。

以我编写的一个SQL查询为例。

SELECT 
    n.area_id,
    n.area_name,
    ca.crime_area,
    ST_Area(ssa2.geometry) AS nei_area
FROM
    neighbourhoods n
JOIN
(
    SELECT
        n.area_id,
        SUM(ST_Area(ST_Intersection(ssa.geometry, bae.geometry))) AS crime_area
    FROM
        neighbourhoods n
    JOIN sa2_statistical_areas ssa ON
        n.area_id = ssa."SA2_MAIN16"
    JOIN break_and_enter bae ON
        ST_Intersects(ssa.geometry,
        bae.geometry)
    GROUP BY
        n.area_id
) ca
ON
    ca.area_id = n.area_id
JOIN sa2_statistical_areas ssa2 
ON
    n.area_id = ssa2."SA2_MAIN16"

在上述查询中，我们用ST_Intersects函数，计算ssa表中的geometry列，与bae表中的geometry列的交集，如果有两条记录产生了交集，则JOIN条件为真，联表查询生成的结果中会多出一行。

在MySQL基础上速通PostgreSQL

Mon, 23 May 2022 12:09:16 +0800

前言

因为一些缘故，接触了一下对空间地理数据的分析工作。忙完以后，想了想决定写下这篇文章，方便日后如有需要，可以快速查阅，也供后人参考。

背景条件

在我的分析过程中，需要使用PostgreSQL，但我之前用MySQL/MariaDB比较多，稍微花了一点点时间适应。怕下次忘了，干脆写出来。

本文还假设你已经具备了最基本的SQL，尤其是MySQL知识。有了这些基础知识，我们的适应就会非常迅速。

PostgreSQL速通

我们会着重介绍几个概念。

数据库实例 - Cluster

和我们平时常说的计算集群(Computer Cluster)不同，也和SQL中的聚合索引(Clustered Index)不同，PostgreSQL中的Cluster，其实可以简单理解成一个数据库实例。

具体来说，同一套PostgreSQL的二进制文件，可以运行多个实例(Cluster)，每个实例具有不同的数据目录，配置文件，监听不同的端口。

而如果想要创建一个Cluster，使用initdb命令是最简单的方法。其手册可以参考https://www.postgresql.org/docs/current/app-initdb.html

也可以参考这里https://www.postgresql.org/docs/current/creating-cluster.html

数据库初始化

大部分情况下，包括Windows安装包安装，以及Debian/Ubuntu APT源中的安装包安装，都会自动为我们创建好一个可以直接使用的Cluster，我们一般不需要手动创建一个Cluster。

不过，如果在Windows上使用Zip压缩包进行安装时，需要运行initdb.exe，指定一个数据目录，创建一个新的Cluster。毕竟没有程序自动地帮你做这件事。

用户与权限

在较新版本(>=8.1)的PostgreSQL中，用户和组都统称为角色(ROLE)。在我看来，区别用户和组的最大的区别，或许在于，是否给一个角色赋予登录权限。

在Debian/Ubuntu系统下，当从APT源安装PostgreSQL时，会在系统中自动创建一个postgres用户，这个用户可以通过Unix Socket访问到PostgreSQL默认Cluster中创建的同名超级用户。

root@MyPC:~# sudo -u postgres -i psql
psql (14.2 (Ubuntu 14.2-1ubuntu1))
Type "help" for help.

postgres=#

如果你需要创建其他角色，则需要具有CREATEROLE权限。

要创建一个可以登录的角色（下面我就简称用户啦），可以使用以下SQL语句:

`1`	`CREATE ROLE alice LOGIN PASSWORD '12345';`

这会创建一个名为alice的用户，赋予（通过网络）登录权限，密码为12345。我们可以运行psql命令登录到这一用户。

root@MyPC:~# psql -U alice -W postgres -h localhost
Password:
psql (14.2 (Ubuntu 14.2-1ubuntu1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=> \conninfo
You are connected to database "postgres" as user "alice" on host "localhost" (address "127.0.0.1") at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)

如果你希望赋予这个用户一些权限，例如CREATEDB, CREATEROLE, 甚至是SUPERUSER，都可以在上方指定。例如，我们可以在创建时指定Alice为Superuser

`1`	`CREATE ROLE alice SUPERUSER LOGIN PASSWORD '12345';`

查看

root@MyPC:~# psql -U alice -W postgres -h localhost
Password:
psql (14.2 (Ubuntu 14.2-1ubuntu1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=# \du+
                                          List of roles
 Role name |                         Attributes                         | Member of | Description
-----------+------------------------------------------------------------+-----------+-------------
 alice     | Superuser                                                  | {}        |
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}        |

postgres=#

但使用SQL语句直接创建用户的记录，会将密码明文存储在数据库的历史查询中。我们觉得这样不好。

PostgreSQL提供了许多命令行工具，即便不用显式登录到psql，也可以管理数据库。createuser便是其中用于创建角色的工具。其文档可以参考https://www.postgresql.org/docs/current/sql-createrole.html

基于此，我们可以将上面的创建用户代码，替换成Shell指令: createuser -l -s -e -P alice

postgres@MyPC:~$ createuser -l -s -e -P alice
Enter password for new role:
Enter it again:
SELECT pg_catalog.set_config('search_path', '', false);
CREATE ROLE alice PASSWORD 'SCRAM-SHA-256$4096:91DfHk6BEMX4Ay7S8TsfQw==$2tGBIh4PC/ce4ThLajfvm9ZwwVzidWCorlsHuHBKhX8=:0HZpvT5kReucYmGGwKR6I1OLsaZo3aOjcSMlBI7vrfQ=' SUPERUSER CREATEDB CREATEROLE INHERIT LOGIN;

这一串命令中，

-l代表赋予LOGIN登录权限
-s代表赋予SUPERUSER超级用户身份
-e指示该命令将最终发送给PostgreSQL服务器的SQL语句打印出来（最后2行）
-P指示命令将提示输入该新用户的密码

可以看到，我们发送给数据库服务器的SQL命令，已经将密码哈希处理了。

当然如果你觉得这一串参数记忆复杂，也可以直接使用--interactive选项，回答程序提出的一系列问题，即可创建用户。

数据库 & 模式 & 数据表

这三个词分别对应着:

数据库 - Database
模式 - Schema
数据表 - Table

数据表很好理解。但前两个常常带来争议。

MySQL的Schema

在MySQL中，我们可以在MySQL :: MySQL 8.0 Reference Manual :: MySQL Glossary中看到这一段话:

In MySQL, physically, a schema is synonymous with a database. You can substitute the keyword SCHEMA instead of DATABASE in MySQL SQL syntax, for example using CREATE SCHEMA instead of CREATE DATABASE.

Some other database products draw a distinction. For example, in the Oracle Database product, a schema represents only a part of a database: the tables and other objects owned by a single user.

简单来说，在MySQL中，Database 等价于 Schema.

PostgreSQL的Schema

但PostgreSQL不完全这么想。在PostgreSQL: Documentation: 14: 5.9. Schemas中，是这么说的:

A PostgreSQL database cluster contains one or more named databases. Roles and a few other object types are shared across the entire cluster. A client connection to the server can only access data in a single database, the one specified in the connection request.

A database contains one or more named schemas, which in turn contain tables. Schemas also contain other kinds of named objects, including data types, functions, and operators. The same object name can be used in different schemas without conflict; for example, both schema1 and myschema can contain tables named mytable. Unlike databases, schemas are not rigidly separated: a user can access objects in any of the schemas in the database they are connected to, if they have privileges to do so.

简单来说，在PostgreSQL中，一个实例(Cluster)可以包含多个数据库(Database)，一个数据库(Database)可以包含多个模式(Schema)，一个模式(Schema)下面有很多表(Table)，数据就存储在表(Table)中。

PostgreSQL中的默认Schema

在PostgreSQL中创建一个数据库时，该数据库会默认包含一个public模式。对在该数据库上执行的所有SQL语句来说，如果没有显式指定模式名称，则都会被认为是对public的操作。

假设数据库中存在一个名为public的模式，其下有一个mytable表，则以下两个SQL语句是等效的。

`1`	`SELECT * FROM mytable;`

或者

`1`	`SELECT * FROM public.mytable;`

跨库查询

两个数据库在组织这些术语时的差异，就进一步导出了一个，非常明显，但仔细思考之下显得比较有道理的限制条件：MySQL允许跨数据库查询，而PostgreSQL不允许跨数据库查询。

更进一步，PostgreSQL虽然不允许跨数据库(Database)查询，但允许跨模式(Schema)查询。

或许是因为，PostgreSQL认为，不同数据库存储的数据，涉及到的业务内容相互间应该是没有紧密关联的（如果有紧密联系，就应该放在同一个数据库内！）

因此，PostgreSQL选择，从逻辑上将数据库彼此隔离。

或许，只要我们把跨数据库查询(Cross-Database Query)，改名为跨模式查询(Cross-Schema Query)，或许就变成这两个数据库都能支持的操作了呢？

构建数据库的思考

紧接而来的问题是，在PostgreSQL中，我们应该如何选择数据库的构建形式？

这样的问题在应用程序不涉及跨Schema查询时会更令人举棋不定，而跨Schema查询在构建微服务时从来都不是一个建议的选择。

现在考虑这两种构建形式:

第一种，大致如下图所示。每个数据库中只有一个Schema，即public。使用多个数据库存储不同业务模块数据，每个数据库彼此分离。

- PostgreSQL
|---- mydatabase1
|     |---- public
|           |---- mytable1
|           |---- mytable1
|           |---- mytable3
|
|---- mydatabase2
|     |---- public
|           |---- mytable4
|           |---- mytable5
|           |---- mytable6

第二种，大致如下图所示。每个数据库中使用多个Schema，尽可能减少PostgreSQL服务器下，Database的数量。

- PostgreSQL
|---- mydatabase1
      |---- myschema1
      |     |---- mytable1
      |     |---- mytable1
      |     |---- mytable3
      |
      |---- myschema2
            |---- mytable4
            |---- mytable5
            |---- mytable6

这两种方案从实现角度都是可行，现成的。第一种方案相较于第二种方案，失去了跨库查询的能力，但提高了隔离性。

这时候一定有人问：性能如何？

目前似乎在网上暂时搜不到这两种方案性能差异的对比。StackOverflow上2009年的帖子里，有人曾经引用Heroku PostgreSQL上的文档，认为 一个数据库内多个Schema(One Database - Many Schema) 的方案会严重拖累服务器性能，但似乎目前在该文档中已经找不到这一段文字，且实际上也没有给出两个方案具体的性能差异。

因此我更倾向于认为，两者在性能上不会有天差地别的影响。

📝 备注

当数据越来越多时候，数据库的效率会自然下降。或许考虑其他方法，如分表，索引等手段加快性能，收益会更为明显。

至于选择，我个人认为，第一种方案，即 One Database - One Schema 会更方便我们管理数据库的权限，我更倾向采用这种方案。

命名规则

虽然PostgreSQL的命名规则并不离经叛道，但我个人并不建议在数据库名、模式名、表名、字段名中使用大写字母！

因为，在PostgreSQL中，如果上述名字含有大写字母，需要将这一部分用双引号包起来！

📌 重要

逃课方法: 使用GUI数据库管理工具，如DBeaver、Beekeeper Studio等。 可以直接无视此部分问题。生成SQL语句复制粘贴即可。

例如，如果我们创建一个数据表如下所示。注意到Name字段包含了大写字母。

CREATE TABLE public.mytb1 (
	id integer NOT NULL GENERATED BY DEFAULT AS IDENTITY,
	"Name" varchar NULL,
	CONSTRAINT mytb1_pk PRIMARY KEY (id)
);

插入一些数据

1
2

INSERT INTO public.mytb1 ("Name") VALUES('Bob');
INSERT INTO public.mytb1 ("Name") VALUES('Cindy');

执行简单的查询

mytest1=# SELECT * FROM mytb1;
 id | Name
----+-------
  1 | Bob
  2 | Cindy
(2 rows)

如果我们在语句中，包含对Name的操作但没有将其用双引号包围，会出现错误

mytest1=# SELECT * FROM mytb1 WHERE Name = 'Cindy';
ERROR:  column "name" does not exist
LINE 1: SELECT * FROM mytb1 WHERE Name = 'Cindy';
                                  ^
HINT:  Perhaps you meant to reference the column "mytb1.Name".

稍作修改，给Name加上双引号，就可以正常工作

mytest1=# SELECT * FROM mytb1 WHERE "Name" = 'Cindy';
 id | Name
----+-------
  2 | Cindy
(1 row)

如果你在查询时，总是找不到对应的关系，不妨检查一下有没有遗漏双引号。

数据类型

PostgreSQL的数据类型也没啥特别的。不过，根据SQL规范，整型的名称默认应该是integer，因此从MySQL迁移过来时需要稍微注意。

另外值得一提的还有自动增长类型的功能。在PostgreSQL中，自动增长常用Identity指代。注意，另有一种实现方法是通过serial实现，但这似乎是旧的方法，推荐采用Identity的方法。

Identity 有两种模式，即BY DEFAULT和ALWAYS。它们的区别在PostgreSQL: Documentation: 14: CREATE TABLE中有说明:

The clauses ALWAYS and BY DEFAULT determine how explicitly user-specified values are handled in INSERT and UPDATE commands.

In an INSERT command, if ALWAYS is selected, a user-specified value is only accepted if the INSERT statement specifies OVERRIDING SYSTEM VALUE. If BY DEFAULT is selected, then the user-specified value takes precedence. See INSERT for details. (In the COPY command, user-specified values are always used regardless of this setting.)

In an UPDATE command, if ALWAYS is selected, any update of the column to any value other than DEFAULT will be rejected. If BY DEFAULT is selected, the column can be updated normally. (There is no OVERRIDING clause for the UPDATE command.)

省流: ALWAYS在接受用户对数据表中，该自增序列作插入或修改时，条件比BY DEFAULT更严苛。

⚠️ 警告

BY DEFAULT比较听用户的话，ALWAYS有自己的执着。

如果你之前有使用其他SQL的经验，上面的内容足够让你开心地在PostgreSQL上执行一系列查询了。