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 三个不同的面。实际上这还不够例如，还不够细致，如下面这张图
