竹笋

注册

 

发新话题 回复该主题

浅聊openGauss体系架构 [复制链接]

1#

年7月openGauss刚刚开源,我便开始对openGauss数据库的学习。根据以往学习数据库的经验,最先想了解的是openGauss数据库的架构,希望对即将使用的数据库各个模块有所了解。但鉴于时间有限,仅有的资料图是源码doc目录内的“openGauss逻辑结构图”,便针对该图做了简单介绍,并形成文档《浅聊openGauss逻辑架构》,感兴趣的小伙伴可以参考。虽然已发表关于openGauss逻辑架构介绍的文章供大家参考,但总感觉缺少点什么(想念学习Oracle时的那张体系架构图)。今年初准备培训资料时参考相关资料绘制了一份简易的openGauss体系架构图,后来因为忙于其他工作,把这个事情忘记了。借着本次墨天轮举办的“我的国产数据库之路”,使我重新想起了这件事情,希望将这张图和相关介绍分享出来供大家参考。

说明:本文内容仅代表个人观点。

一、首先了解一下架构图中的Instance部分

学习过Oracle等主流数据库的小伙伴都清楚,Instance部分其实主要指的是数据库运行时的内存部分。openGauss属于单进程多线程模型的数据库,客户端可以使用JDBC/ODBC/Libpq/Psycopg等驱动程序,向openGauss的后端管理线程GaussMaster发起连接请求。补充知识点:

JDBCJDBC(JavaDatabaseConnectivity,Java数据库连接)是一种用于执行SQL语句的JavaAPI,可以为多种关系数据库提供统一访问接口,应用程序可基于它操作数据。openGauss库提供了对JDBC4.0特性的支持,需要使用JDK1.8版本编译程序代码,不支持JDBC桥接ODBC方式。ODBCODBC(OpenDatabaseConnectivity,开放数据库互连)是由Microsoft公司基于X/OPENCLI提出的用于访问数据库的应用程序编程接口。应用程序通过ODBC提供的API与数据库进行交互,增强了应用程序的可移植性、扩展性和可维护性。openGauss目前提供对ODBC.5的支持。但需要注意的是,当前数据库ODBC驱动基于开源版本,对于tinyint、smalldatetime、nvarchar2类型,在获取数据类型的时候,可能会出现不兼容。LibpqLibpq是openGauss的C语言程序接口。客户端应用程序可以通过Libpq向openGauss后端服务进程发送查询请求并且获得返回的结果。需要注意的是,在官方文档中提到,openGauss没有对这个接口在应用程序开发场景下的使用做验证,不推荐用户使用这个接口做应用程序开发,建议用户使用ODBC或JDBC接口来替代。PsycopgPsycopg可以为openGauss数据库提供统一的Python访问接口,用于执行SQL语句。openGauss数据库支持Psycopg2特性,Psycopg2是对libpq的封装,主要使用C语言实现,既高效又安全。它具有客户端游标和服务器端游标、异步通信和通知、支持“COPYTO/COPYFROM”功能。支持多种类型Python开箱即用,适配PostgreSQL数据类型;通过灵活的对象适配系统,可以扩展和定制适配。Psycopg2兼容Unicode和Python。

当GaussMaster线程接收到客户端程序发送过来的服务请求后,会根据收到的信息会立即fork()一个子线程,这个子线程对请求进行身份验证成功后成为对应的后端业务处理子线程(gaussdb)。之后该客户端发送的请求将由此业务处理子线程(gaussdb)负责处理。当业务处理子线程(gaussdb)接收到客户端发送过来的查询(SQL)后,会调用openGauss的SQL引擎对SQL语句进行词法解析、语法解析、语义解析、查询重写等处理操作,然后使用查询优化器生成最小代价的查询路径计划。之后,SQL执行器会按照已制定的最优执行计划对SQL语句进行执行,并将执行结果反馈给客户端。

在SQL执行器的执行过程中通常会先访问内存的共享缓冲区(如:sharedbuffer、cstorebuffer、MOT等),内存共享缓冲区缓存数据库常被访问的索引、表数据、执行计划等内容,共享缓冲区的高速RAM硬件,为SQL的执行提供了高效的运行环境,大幅减少了磁盘IO,极大地提升了数据库性能,是数据库非常重要的组件之一。

如图所示:sharedbuffer是行存引擎默认使用的缓冲区,openGauss的行存引擎是将表按行存储到硬盘分区上,采用MVCC多版本并发控制,事务之间读写互不冲突,有着很好的并发性能,适合于OLTP场景。

cstorebuffers是列存引擎默认使用的缓冲区,列存引擎将整个表按照不同列划分为若干个CU(CompressionUnit,压缩单元),以CU为单位进行管理,适合于OLAP场景。

MOT是内存引擎默认使用的缓冲区,openGauss的MOT内存引擎的索引结构以及整体的数据组织都是基于Masstree模型实现的,其乐观并发控制和高效的缓存块利用率使得openGauss可以充分发挥内存的性能,同时,在确保高性能的前提下,内存引擎有着与openGauss原有机制相兼容的并行持久化和检查点能力(CALC逻辑一致性异步检查点),确保数据的永久存储,适合于高吞吐低时延的业务处理场景。

SQL执行器在共享缓冲区中对数据页的操作会被记录到WALbuffer中,当客户端发起事务的

分享 转发
TOP
发新话题 回复该主题