Lightdb体系架构

本篇从内存结构，进程结构和存储结构三个部分，描述了Lightdb的基础体系架构

1、内存结构

共享内存：

Lightdb启动后会生成一块共享内存，共享内存主要用作数据库的缓冲区(shared buffer)。wal日志缓冲区和clog(commit log)缓冲区也在共享内存中，除此之外，也保存一些统计信息，进程信息，锁的信息等

本地内存：

后台服务进程除访问共享内存外，还会申请分配一些本地内存，以便暂存一些不需要全局存储的数据。这些内存缓冲区主要有以下几个：

temp buffer：用于访问临时表的本地缓冲区;

work_mem:内部排序操作和hash表在使用临时磁盘文件之前使用的内存缓冲区；

maintenance_work_mem:在维护性操作(vacuum,create index等)时使用

2、进程结构

主进程Postmater：

    主进程Postmaster是整个数据库实例的总控进程，负责启动和关闭数据库实例，fork出一些与数据库实例相关的辅助子进程；当用户与数据建立连接时，实际上先与Postmaster主进程建立连接，此时客户端会发出身份验证消息给Postmaster主进程，Postmaster主进程根据消息进行验证，如果验证成功，则会fork出一个子进程来为该连接服务，fork出的子进程称为服务进程(Backead Process, 主要处理一个连接的客户端发出的所有语句)

系统日志进程logger

logger辅助进程通过Postmaster主进程、所有服务进程以及其他辅助进程收集所有的stderr输出，并将这些输出写入日志文件中。在postgresql.conf配置文件中参数logging_collector控制是否启动logger进程，log_min_messages控制哪些消息级别被写入日志。

后台写进程bgwriter

bgwriter辅助进程是把共享内存中的脏页写到磁盘上

预写式日志写进程walwriter

WalWriter 进程就是写WAL日志的过程，把WAL缓存在适当的时间点往磁盘（目录pg_wal）写;；WAL log也被简称成xlog

归档进程archiver

wal日志循环使用，archiver进程会在覆盖前把wal日志备份出来

自动清理进程autovacuum

在postgresql数据中，对表进行delete/update操作后，原有数据并不会立即被删除/修改，而是会新生成一行数据，此时原有的数据只是被标识为删除状态，只有在没有被其他事务读到这些旧数据时，才会被清理。这个清理工作就是由autovacuum进程完成

统计数据收集进程stats

主要做数据的统计信息收集工作。收集的信息主要用于sql优化等。

3、存储结构：

参数文件：postgresql.conf:此数据库的主配置文件

控制文件: 在$PGDATA/global目录下的pg_control

数据文件：在$PGDATA/base下，默认表空间目录

日志文件：存储在$PGDATA/pg_wal，在Postgresql10版本之前此目录是pg_xlog

事物最终状态的日志：

存储在$PGDATA/pg_xact，在Postgresql10版本之前此目录是pg_clog

pg_clog是如何调用pg_fsync刷脏页的。每次申请新的事务ID时，都需要调用ExtendCLOG，如果通过事务ID计算得到的CLOG PAGE页不存在，则需要扩展（backend process主动刷CLOG PAGE，所以会有调用pg_fsync的动作）；但是并不是每次扩展都需要调用pg_fsync，因为checkpoint会将clog buffer刷到磁盘，除非在申请新的CLOG PAGE时所有的clog buffer都没有刷出脏页，才需要主动选择一个page并调用pg_fsync刷出对应的pg_clog/file

归档文件：可以自定义路径，详见 Lightdb归档模式配置__一_兮_的博客-CSDN博客

系统日志：存储在$PGDATA/log

该文件夹中的日志一般用来记录服务器与DB的状态，如各种Error信息，定位慢查询SQL，数据库的启动关闭信息，发生checkpoint过于频繁等的告警信息等

附：

思维导图