POSTGRESQL 数据库结构体系 ||| 东来西去 三个角度看

2020-11-16 00:00:00 数据库 系统 内存 进程 性能


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


从数据库的使用者的角度来看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 三个不同的面。实际上这还不够例如,还不够细致,如下面这张图



 


相关文章