POSTGRESQL 的数据库体系结构是了解POSTGRESQL 数据库的整体概念的一个开始,而数据库的结构体系这个词有点大,所以这里从三个角度出发来看POSTGRESQL 结构

1  从数据库的使用者的角度来看postgresql 的数据库的架构

POSTGRESQL 数据库架构,从用户的角度来看 postgresql cluster 主要由 用户,  databases --schema  以及 schema 下的 各种数据库的OBJECTS 组成,

用户可以是一个数据库的OWNER, 通过database下,建立不同的schema 可以管理数据库下的不同的objects , 可以理解为 以下的管理方式

database --- user ---  schema -- objects

当然实际上其他的用户也可以具有不同的schema下的OBJECTS的权限.

2 从postgresql 进程的角度来看, POSTGRESQL 是基于CS 结构, 通过postgres进程作为前端来对客户进行服务,所有POSTGRES 从进程的角度来看是服务器承接 客户前端服务的,后端服务

postgres: postgres postgres [local] idle

通过上面的图中的信息,可以看到一个连接会产生一个postgres的进程,(之前也有文字写到关于过多连接对POSTGRESQL 本身的性能影响问题)

除此以外我们从上图可以看到其他的进程在系统中所起的作用

postgres: logger

postgres: checkpointer

postgres: background writer

postgres: walwriter

postgres: archiver

postgres: stats collector

postgres: logical replication launcher

postgres: autovacuum launcher

下面就简单的说一下这些进程到底在做什么工作

从上面的图和名字看

postgres: logger    日志信息的打印进程

postgres:archiver   在WAL LOG 需要被归档的时候,触发的进程,通过这个进程来进行数据库日志的归档的工作

postgres: stats collector   这个进程的使用主要是收集系统的访问信息,例如pg_stat_activity 以及 表的使用的状态信息,相当于数据库状态的收集器

postgres: logical replication launcher  postgres 中进行逻辑复制的进程

postgres: autovacuum launcher   postgres autovacuum 自动VACUUM的进程

以上的进程都和系统本身的数据库运作关系不大,基本上周边的进程

postgres: checkpointer

postgres: background writer

postgres: walwriter

上边的三个进程

background writer 是主要的写进程,从内存到磁盘的过程,都要经过这个进程完成,如果这个进程DOWN 则数据库会出现严重的问题,导致无法工作

checkpointer 进程是在background writer 下面的进行数据页面定期的将脏页刷新到磁盘中的进程

postgres: walwriter wal log 写磁盘的进程

上面的三个进程任何一个出现问题,则数据库会出现无法工作的情况.

上图是一个网络上比较常见的介绍 后端进程的图,这里这些进程都是通过一个叫postmaster process的进程来工作的, 他的启动包含了初始化 shared memory, 加载我们提到过的各个进程, 并且创建backedn process 供用户来进行连接到POSTGRESQL 使用. 所以除了用户连接进来的继承, 我们管其他的进程叫background process。

所以POSTGRESQL 进程类型可以分为四类

1 postmaster process (Daemon)

2 background process

3 backend process

4 Client process

3 最后我们来说一说，POSTGRESQL的内存结构是什么样的, 在数据库中的内存结构是一个数据库中十分重要的一部分， 他关系着整体数据库的性能上的问题。

和其他的数据库类似， POSTGRESQL 的内存也分为两个部分

1   local memory     对于每一个客户进程的内存分配

2   Shared memory   对于所有进程的数据POOL 的内存使用

local memory 包含了 work men , maintenance_work_men 和 temp_buffers

其中每个项目牵扯一部分的性能

work mem 牵扯了order by distinct group by merge join , hash join ,bitmap join 等操作中使用的内存，较大的work_mem 可以提高一些复杂的SQL 的查询速度，但内存的消耗也会变高

maintenance_work_mem  参数的设定，主要在于系统层面使用内存加速系统的处理例如 添加内存， VACUUM  等操作的速度

temp buffers  对于临时表的内存的支持

剩下的就是我们的 shard memory area

shared buffer  pool 这个不用多说了，这个一般要配置成总体内存的25%到50%，具体看系统的偏向OLAP 还是OLTP  ，所有的数据都需要在这里进行处理，所以大小的设置严重影响整体系统的运行的性能

wal buffer  WAL BUFFER的设置 write ahead log 设置有时候会被忽略，wal buffer 的大小尤其对于频繁DML 的高并发的系统，配置会提高你系统的性能。

commit log  保存事务执行的状态， 如事务是在

1 In progress

2 COMMITED

3 Aborted

4 SUB-Committed

内存的使用关系到并发处理时的一些性能问题

今天浅析了相关从三种角度看POSTGRESQL 的结构的问题，其实也是从 用户， 整体数据库处理数据的逻辑， 以及性能方面去看POSTGRESQL 三个不同的面。实际上这还不够例如，还不够细致，如下面这张图