了解一下架构图中的Instance部分
学习过Oracle等主流数据库的小伙伴都清楚，Instance部分其实主要指的是数据库运行时的内存部分。 openGauss属于单进程多线程模型的数据库，客户端可以使用JDBC/ODBC/Libpq/Psycopg等驱动程序，向openGauss的后端管理线程GaussMaster发起连接请求。
补充知识点：
JDBC
JDBC(Java Database Connectivity，Java数据库连接)是一种用于执行SQL语句的Java API，可以为多种关系数据库提供统一访问接口，应用程序可基于它操作数据。openGauss库提供了对JDBC 4.0特性的支持，需要使用JDK1.8版本编译程序代码，不支持JDBC桥接ODBC方式。
ODBC
ODBC(Open Database Connectivity，开放数据库互连)是由Microsoft公司基于X/OPEN CLI提出的用于访问数据库的应用程序编程接口。应用程序通过ODBC提供的API与数据库进行交互，增强了应用程序的可移植性、扩展性和可维护性。openGauss目前提供对ODBC 3.5的支持。但需要注意的是，当前数据库ODBC驱动基于开源版本，对于tinyint、smalldatetime、nvarchar2类型，在获取数据类型的时候，可能会出现不兼容。
Libpq
Libpq是openGauss的C语言程序接口。 客户端应用程序可以通过Libpq向openGauss后端服务进程发送查询请求并且获得返回的结果。需要注意的是，在官方文档中提到，openGauss没有对这个接口在应用程序开发场景下的使用做验证，不推荐用户使用这个接口做应用程序开发，建议用户使用ODBC或JDBC接口来替代。
Psycopg
Psycopg可以为openGauss数据库提供统一的Python访问接口，用于执行SQL语句。openGauss数据库支持Psycopg2特性，Psycopg2是对libpq的封装，主要使用C语言实现，既高效又安全。它具有客户端游标和服务器端游标、异步通信和通知、支持“COPY TO/COPY FROM”功能。支持多种类型Python开箱即用，适配PostgreSQL数据类型；通过灵活的对象适配系统，可以扩展和定制适配。Psycopg2兼容Unicode和Python 3。
当 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不是一个必要的进程，可以在请求时快速关闭。
maintenance_work_mem 一般是在openGauss执行维护性操作时使用，如：VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等操作，maintenance_work_mem内存区域的大小决定了维护操作的执行效率。
temp_buffer 是每个数据库会话使用的LOCAL临时缓冲区，主要缓存会话所访问的临时表数据。需要注意的是，openGauss支持全局临时表和会话级临时表，全局临时表的表定义是全局的，而临时表的数据是各个会话私有的。
work_mem 是事务执行内部排序或Hash表写入临时文件之前使用的内存缓冲区。
原文链接：https://blog.csdn.net/GaussDB/article/details/118383049
