一、体系架构图
二、Instance部分
Instance部分其实主要指的是数据库运行时的内存部分。 openGauss属于单进程多线程模型的数据库，客户端可以使用JDBC/ODBC/Libpq/Psycopg等驱动程序，向openGauss的后端管理线程GaussMaster发起连接请求。
当 GaussMaster 线程接收到客户端程序发送过来的服务请求后，会根据收到的信息会立即fork()一个子线程，这个子线程对请求进行身份验证成功后成为对应的后端业务处理子线程( gaussdb )。之后该客户端发送的请求将由此业务处理子线程(gaussdb)负责处理。当业务处理子线程(gaussdb)接收到客户端发送过来的查询(SQL)后，会调用openGauss的SQL引擎对SQL语句进行词法解析、语法解析、语义解析、查询重写等处理操作，然后使用查询优化器生成最小代价的查询路径计划。之后，SQL执行器会按照已制定的最优执行计划对SQL语句进行执行，并将执行结果反馈给客户端。
在SQL执行器的执行过程中通常会先访问内存的共享缓冲区(如：shared buffer、cstore buffer、MOT等)，内存共享缓冲区缓存数据库常被访问的索引、表数据、执行计划等内容， 共享缓冲区的高速RAM硬件，为SQL的执行提供了高效的运行环境，大幅减少了磁盘IO，极大地提升了数据库性能，是数据库非常重要的组件之一。
如图所示：
- shared buffer 是行存引擎默认使用的缓冲区，openGauss的行存引擎是将表按行存储到硬盘分区上，采用MVCC多版本并发控制，事务之间读写互不冲突，有着很好的并发性能，适合于OLTP场景。
- cstore buffers 是列存引擎默认使用的缓冲区，列存引擎将整个表按照不同列划分为若干个CU(Compression Unit,压缩单元)，以CU为单位进行管理，适合于OLAP场景。
MOT 是内存引擎默认使用的缓冲区，openGauss的MOT内存引擎的索引结构以及整体的数据组织都是基于Masstree模型实现的，其乐观并发控制和高效的缓存块利用率使得openGauss可以充分发挥内存的性能，同时，在确保高性能的前提下，内存引擎有着与openGauss原有机制相兼容的并行持久化和检查点能力(CALC逻辑一致性异步检查点)，确保数据的永久存储，适合于高吞吐低时延的业务处理场景。
SQL执行器在共享缓冲区中对数据页的操作会被记录到 WAL buffer 中，当客户端发起事务的commit请求时，WAL buffer的内容将被WalWriter线程刷新到磁盘并保存在WAL日志文件中，确保那些已提交的事务都被永久记录，不会丢失。 但需要注意的是，当walwriter的写操作跟不上时数据库实际的需求时，常规后端线程仍然有权进行WAL日志的刷盘动作。这意味着WALWriter不是一个必要的进程，可以在请求时快速关闭。
三、openGauss的后台辅助线程
线程名称 | 描述 |
jemalloc_bg_thd | 管理并实现内存的动态分配 |
StatCollector | 负责统计openGauss数据库的信息，包括：物理硬件资源使用信息、对象属性及使用信息、SQL运行信息、会话信息、锁信息、线程信息等，并且将这些收集到的统计信息保存在pgstat.stat文件中 |
Auditor | 使用重定向的方式从管理线程、后台线程以及其他子线程获取审计数据，并保存在审计文件中 |
LWLockMonitor | 负责检测轻量级锁(LWLock)产生的死锁，轻量级锁主要提供对共享内存的互斥访问控制，比如Clog buffer（事务提交状态缓存）、Shared buffers（数据页缓存）、Substran buffer（子事务缓存）等 |
sysLogger | 使用重定向的方式捕获管理线程、后台线程以及其他子线程的stderr输出，并写入日志文件中 |
Jobworker | JOB线程分为调度线程和工作线程。调度线程(JobScheduler)会根据pg_job表里面定义的JOB周期，对已经过期的JOB进行调用，由工作线程(Jobworker)执行实际的JOB任务 |
percentworker | 根据percentile参数设置的值计算sql响应时间的百分比信息，目前percentile参数仅支持80和95 |
snapshotworker | 收集snapshot信息，openGauss数据库的WDR报告依赖于snapshot |
ashworker | 统计历史活动会话相关信息 |
alarm | openGauss的告警检测线程 |
清理线程(AutoVacLauncher+AutoVacWorker) | AutoVacLauncher线程由Postmaster线程启动，它不断地将数据库需要做vacuum的对象信息保存在共享内存中，当表上被删除或更新的记录数超过设定的阈值时，会调用AutoVacWorker线程对表的存储空间执行回收清理工作 |
WalSender | 运行在openGauss主备环境中主节点，发送预写日志给备节点 |
WalReceiver | 运行在openGauss主备环境中备节点，接收预写日志记录 |
pagewriter | 负责将脏页数据拷贝至双写(double-writer)区域并落盘，然后将脏页转发给bgwriter子线程进行数据下盘操作，如果发生数据页"折断"的问题，就会从双写空间里找到完整的数据页进行恢复 |
bgwriter | 负责对共享缓冲区的脏页数据持续的进行刷盘操作，目的是让数据库线程在进行用户查询时可以很少或者几乎不等待写动作的发生，这样的机制同样也减少了检查点造成的性能下降 |
Checkpointer | 周期性的发起数据库检查点，在这个检查点时刻，所有的数据文件都被更新，脏数据页也被刷新到磁盘，此刻数据库是一致的。openGauss支持全量检查点和增量检查点，增量检查点打开后会小批量的分阶段的滚筒式的去进行脏页刷盘 |
四、Database相关文件
目录名称 | 描述 |
base | openGauss数据库对象默认存储在该目录，如默认的数据库postgres、用户创建的数据库及关联的表等对象 |
global | 存储openGauss共享的系统表或者说是共享的数据字典表 |
pg_tblspc | 即是openGauss的表空间目录，里面存储openGauss定义的表空间的目录软链接，这些软链接指向openGauss数据库表空间文件的实际存储目录 |
pg_xlog | 存储openGauss数据库的WAL日志文件 |
pg_clog | 存储openGauss数据库事务提交状态信息 |
pg_csnlog | 存储openGauss数据库的快照信息，openGauss事务启动时会创建一个CSN快照，在MVCC机制下，CSN作为openGauss的逻辑时间戳，模拟数据库内部的时序，用来判断其他事务对于当前事务是否可见 |
pg_twophase | 存储两阶段事务提交信息，用来确保数据一致性 |
pg_serial | 存储已提交的可序列化事务信息 |
pg_multixact | 存储多事务状态信息，一般用于共享行级锁(shared row locks) |
五、openGauss配置相关文件
文件名称 | 描述 |
postgresql.conf | openGauss的配置文件，在gaussmaster线程启动时会读取该文件，获取监听地址、服务端口、内存分配、功能设置等配置信息，并且根据该文件，在openGauss启动时创建共享内存和信号量池等 |
pg_hba.conf | 基于主机的接入认证配置文件，主要保存鉴权信息(如：允许访问的数据库、用户、IP段、加密方式等) |
pg_ident.conf | 客户端认证的配置文件，主要保存用户映射信息，将主机操作系统的用户与openGauss数据库用户做映射 |
gaussdb.state | 主要保存数据库当前的状态信息(如：主备HA的角色、rebuild进度及原因、sync状态、LSN信息等) |
六、openGauss其他重要文件
目录名称 | 描述 |
Archived WAL | openGauss数据库WAL日志的归档目录，保存openGauss的历史WAL日志 |
pg_audit | 存储openGauss数据库的审计日志文件 |
pg_replslot | 存储openGauss数据库的复制事务槽数据 |
pg_llog | 保存逻辑复制时的状态数据 |
标签：体系,存储,架构,数据库,信息,线程,pg,openGauss From： https://blog.51cto.com/u_13236892/6176468