苏州住房建设局网站,高级搜索技巧,网站推广方法的费用,张家港做网站的推荐浅聊 openGauss 逻辑架构
概述
openGauss 数据库是一款由华为主导、各个生态合作伙伴共同建设的开源关系型数据库管理系统#xff0c;开源发行协议遵从木兰宽松许可证 v2。
openGauss 数据库源于 PostgreSQL-XC 项目#xff0c;内核源于 Postgres 9.2.4#xff0c;总代码…浅聊 openGauss 逻辑架构
概述
openGauss 数据库是一款由华为主导、各个生态合作伙伴共同建设的开源关系型数据库管理系统开源发行协议遵从木兰宽松许可证 v2。
openGauss 数据库源于 PostgreSQL-XC 项目内核源于 Postgres 9.2.4总代码量约 120W 行其中内核代码约 95W 行。华为结合企业级场景需求深度融合其在数据库领域多年的经验新增或修改了内核代码约 70W 行内核代码修改比例约占总内核代码量的 74%。保留了原先 PostgreSQL 的接口和公共函数代码(约 25W 行)仅对这些代码做了适当优化这样也使得 openGauss 与现有的 PG 生态兼容性较好。
总体而言华为主导的 openGauss 开源项目着重在数据库架构、事务管理、存储引擎、SQL 优化器、以及鲲鹏芯片做了大量优化以实现其企业级关键价值特性高性能、高安全、易运维、全开放。
第一次听说 openGauss 的小伙伴本能反应可能是什么国产数据库 那都是外国人的事情openGauss 应该算是 PostgreSQL 的增强版。
“数据库是外国人的事情” 这个观点适合 20 年前当武汉达梦、人大金仓、南大通用、神舟通用等传统国产数据库兴起的时候这个观点应该改为“数据库是中国人可以搞的事情”2020 年 11 月PingCAP 宣布完成 D 轮融资 2.7 亿美元创造了全球数据库历史新的里程碑其分布式开源数据库 TiDB 目前在国产数据库中排名第一位。同月阿里宣布山东移动核心系统正式上跑“OceanBase”使得用户处理效率提升 30%数据容量由 7TB 压缩为 0.7TB存储投入成本降低 90%同时凭借着 OceanBase、PolarDB、AnalyticDB 等数据库稳居 Gartner 魔力四象限的领导者地位。同时华为的 GaussDB 和腾讯的 TDSQL 等数据库也均入选 Gartner 魔力四象限。这些都是国产数据库的突破标志着国产数据库已经得到了国际认可。随着诸多国产数据库的新闻报道我们看到了一个又一个国产数据库入驻核心行业(互联网、金融、电力、政府等等)的案例国产数据库已进入百花齐放的时代“数据库这件事中国人做没有问题”而且从当前行业发展趋势看我国的数据库技术正在朝着分布式、云化、以及国产化的道路快速发展AI4DB、数据库自治等技术也将得到广泛应用相信在不久的将来面对数据库的应用场景国产数据库可以和“外国人”的数据库有相同的话语权。
那么关于 openGauss个人认为用“PG 增强版”这个概念替代很不合适。数据库内核是数据库的核心所在openGauss 的内核修改量高达 74%这基本上可以算是“脱胎换骨”般的改造并且从根本上解决了部分 PG 原生架构所带来的缺陷(如事务 ID 回卷等)。由于 PG 的公共函数和接口部分代码做了保留我们在 openGauss 里面能看到 PG 的影子很正常但核心技术和发展规划与 PG 有很大不同否则当初就合并到 PG 社区了。 openGauss 数据库于 2020 年 6 月 30 日对外宣布开源本人也是在 7 月份开始接触 openGauss 数据库相关资料。作为 DBA 出身的 IT 民工(本来想说是 IT 工匠结果发现还不够格嘿嘿…)本能的想先看看数据库的架构介绍通过架构可以很好的了解数据库的组成模块及相关技术原理对熟悉 openGauss 数据库有很大帮助毕竟一个能随心所欲“拆解”数据库的人才是一个优秀的数据库工程师嘛。
在源码包的 doc 目录里面可以找到下面所示的逻辑结构图。
鉴于对这张图比较感兴趣于是本人参考了部分 PG 文档和 openGauss 文档、结合部分源代码对逻辑架构图理解如下
内核部分
图中绿色部分属于 openGauss 数据库的内核部分该部分总代码量在 95 万行左右在 PostgreSQL9.2.4 的基础上华为修改和新增了 70 万行核心代码着重在架构、事务、存储引擎、优化器以及鲲鹏芯片上做了深度优化。
线程管理
最左侧部分属于 openGauss 后台线程部分通过对该部分的理解我们可以了解到数据库在运行时后台都有哪些工作要做。
业务处理线程
业务处理线程负责处理客户端请求的任务当客户端发送连接请求给 postmaster 管理线程后postmaster 线程会分配相应的业务处理子线程(命名为 gaussdb)给客户端使用后面该客户端的请求和操作由该业务处理子线程负责。当业务处理子线程接收到前端发送过来的查询(SQL)后会使用 openGauss 的 SQL 引擎对 SQL 语句进行词法解析、语法解析、语义解析、查询重写等处理操作然后使用查询优化器生成最小代价的查询路径计划。SQL 执行器会按照已制定的最优执行计划对 SQL 语句进行执行并将执行结果反馈给客户端。
日志写线程
日志写线程在 openGauss 中被命名为 WalWriter 线程。该线程负责将内存中的预写日志(WAL)页数据刷新到预写日志文件中确保那些已提交的事务都被永久记录不会丢失。 预写日志(WAL)和主流数据库中常见的重做日志功能类似里面记录了 openGauss 数据文件的变更操作数据库在执行 SQL 操作时会先将这些变更操作记录在预写日志文件中然后才定期刷数据至数据文件中。
日志写线程在 postmaster 线程启动后就会启动当这个线程的刷盘频率无法满足系统需求时其他常规的后端线程仍然有权限执行预写日志页的刷盘操作。如果日志写线程意外崩溃则 Postmaster 线程会认为整个 openGauss 后端线程崩溃此时将调用 SIGQUIT 强制关闭所有后端线程重置共享内存以恢复后端线程。
数据页写线程
数据页写线程在 openGauss 数据库中应该包含两个线程PageWriter 和 BgWriter。
操作系统数据块大小一般是 4k数据库一般是 8k/16k/32kopenGauss 默认是 8kb这样就有可能造成页面断裂问题一个数据库数据块刷到操作系统的过程中可能发生因宕机而造成块损坏从而导致数据库无法启动的问题。pagewriter 线程负责将脏页数据拷贝至双写(double-writer)区域并落盘然后将脏页转发给 bgwriter 子线程进行数据下盘操作这样可以防止该现象的发生因为如果发生数据页折断的问题就会从双写空间里找到完整的数据页进行恢复。
bgwriter 线程(BgWriter)主要负责对共享缓冲区的脏页数据进行下盘操作目的是让数据库线程在进行用户查询时可以很少或者几乎不等待写动作的发生写动作由后端写线程完成。这样的机制同样也减少了检查点造成的性能下降。后端写线程将持续的把脏页面刷新到磁盘上所以在检查点到来的时候只有少量页面需要刷新到磁盘上。但是这样还是增加了 I/O 的总净负荷因为以前的检查点间隔里一个重复弄脏的页面可能只会冲刷一次而现在一个检查点间隔内后端写进程可能会写好几次。但在大多数情况下连续的低负荷要比周期性的尖峰负荷好一些毕竟数据库稳定十分重要。
如果 bgwriter 的刷盘操作不能保证数据库拥有充足的可用共享缓冲区那么常规的后端线程仍然有权发出刷盘操作。 bgwriter 线程也是随着 Postmaster 线程启动而启动我们在执行 recovery 操作的时候也会启动该线程。Postmaster 线程可以调用 SIGTERM 正常关闭也可以调用 SIGQUIT 强制关闭。如果 bgwriter 线程意外崩溃则 Postmaster 线程会认为整个 openGauss 后端线程崩溃此时将调用 SIGQUIT 强制关闭所有后端线程重置共享内存以恢复后端线程。
检查点线程
检查点线程(Checkpointer)一般会周期性的发起数据库检查点检查点(CHECKPOINT)是一个事务日志中的点所有数据文件都在这个点被更新然后将数据脏页刷新到磁盘的数据文件中确保数据库一致。 当数据库从崩溃状态恢复后已经做过 checkpoint 的更改就不再需要从预写日志中恢复这大大加快了数据库系统 crash 后的恢复速度。 openGauss 的检查点有全量检查点和增量检查点。增量检查点开关打开的时候将不再使用 full_page_writes 防止页面折断而是依赖双(double-writer)特性保护当增量检查点打开后会小批量分阶段的滚筒式进行脏页刷盘同时更新 lsn 信息回收不需要的 xlog 日志。
统计线程
统计线程在 openGauss 数据库中被命名为 StatCollector该线程负责统计 openGauss 数据库的信息这些信息包括物理硬件资源使用信息、对象属性及使用信息、SQL 运行信息、会话信息、锁信息、线程信息等并且将这些收集到的统计信息保存在 pgstat.stat 文件中。这些统计信息经常被用来做性能分析、故障分析、健康检查和状态监控等。
日志发送线程和日志接收线程
日志发送线程在 openGauss 中被命名为 WalSender这个线程主要是在 openGauss 主备环境中主节点上运行发送预写日志给备节点。
日志接收线程在 openGauss 中被命名为 WalReceiver这个线程主要是在 openGauss 主备环境中备节点上运行接收预写日志记录。说到主备还有以下几个线程
主备通讯线程(RemoteSrv)日志下盘线程(WalRcvWriter) 将接收到的 WAL records 刷新到备机的 WAL 日志里并行恢复线程(ParallelRecov) 读取 WAL 日志内容在备机进行并行恢复集群心跳监测线程(Heartbeater)
清理线程
首先我们说一下为什么需要清理线程呢
那是因为 openGauss 默认使用 MVCC(Multi-Version Concurrency Control)来保证事务的原子性和隔离性。而 MVCC 机制使得数据库的更新和删除记录实际不会被立即删除并释放存储空间而是标记为历史快照版本openGauss 使用 MVCC 机制和这些历史快照实现数据的读写不冲突。但是这样会使得操作频繁的表积累大量的过期数据占用磁盘空间当扫描查询数据时需要更多的 IO 消耗降低查询效率。所以需要一个线程对这些过期数据进行清理并回收存储空间。
autovacuum 线程就是这个后台清理线程负责回收表或 B-Tree 索引中已经删除的行所占据的存储空间这个线程也是由一个发起线程和一个执行线程组成在 openGauss 中分别被命名为 AutoVacLauncher 和 AutoVacWorker。
当 autovacuum 参数打开后AutoVacLauncher 线程会由 Postmaster 线程启动并且会不断地将数据库需要做 vacuum 的对象信息保存在共享内存中当表上被删除或更新的记录数超过设定的阈值( 表中(update,delte 记录) autovacuum_vacuum_scale_factor* reltuples(表上记录数) autovacuum_vacuum_threshold ) 时调用 AutoVacWorker 线程对这个表的存储空间执行回收清理工作。
当需要发起数据库 vacuum 的时候AutoVacLauncher 线程会在共享内存设置相应的 flag然后发送信号给 Postmaster 线程postmaster 线程收到信号后只知道需要启动一个 AutoVacWorker 子线程连接共享内存AutoVacWorker 子线程将从共享内存获取待清理的任务信息并执行对象的清理回收工作。
归档线程
归档线程在 openGauss 数据库中被命名为 WalWriter当数据库归档周期(archive_timeout)到达的时候由 postmaster 调用归档线程(WalWriter)强制切换预写日志并执行归档操作。
管理线程
管理线程也就是指 postmaster 线程在 openGauss 中被命名为 GaussMaster。
管理线程可以看作是一个消息转发中心比如说前端程序发送一个启动信息给管理线程管理线程根据收到的信息会立即 fork()一个子线程这个子线程对请求进行身份验证成功后成为后端线程。 管理线程也会参与操作系统方面的操作比如启停数据库。但其本身不参与 openGauss 数据库内的基本操作它只是在必要的时刻启动相应的子线程去完成操作当某些后台线程 Crash 掉后管理线程还会负责重置该线程。 管理线程在启动时会创建共享内存和信号量池但原则上是不会干涉它们。另外它也不是后端 PGPROC 数组的成员因此它不参与锁管理器操作也不做共享内存的操作这样会使其更简单、更可靠。 管理线程几乎都是通过重置共享内存使得单个后端线程从崩溃中恢复过来如果它对共享内存也做大量操作那么它很容易与后端线程一起崩溃。
除了图中提到的线程以外还有一些线程需要简单了解一下
轻量锁监控线程
轻量级锁监控线程在 openGauss 中被命名为 LWLockMonitor轻量级锁(LWLock)主要提供对共享内存的互斥访问比如 Clog buffer事务提交状态缓存、Shared buffers数据页缓存、Substran buffer子事务缓存等。该轻量级锁监控线程主要检测轻量级锁(LWLock)产生的死锁。
审计线程
审计线程在 openGauss 数据库中被命名为 Auditor这个线程使用重定向的方式从管理线程、后台线程以及其他子线程获取审计数据并保存在审计文件中。审计文件的尺寸和保留时间可以使用 postgresql.conf 配置文件的参数进行配置如果达到任一个限制则审计线程会停止对当前审计文件的写入重新创建一个审计文件开始写入审计信息。
系统日志线程
系统日志线程在 openGauss 数据库中被命名为 SysLogger和审计线程一样也是使用重定向的方式捕获管理线程、后台线程以及其他子线程的 stderr 输出并写入一组日志文件中。可以使用 log_rotation_age 和 log_rotation_size 参数设置日志文件的保留时间的尺寸限制当达到任一限制时syslogger 线程将关闭对当前日志文件的写入重新创建日志文件并执行后续的写入。
告警检测线程
告警检测线程在 openGauss 数据库中被命名为 AlarmChecker是 openGauss 的告警检测线程。
JOB 线程(JobScheduler)
JOB 线程其实和 autovacuum 一样也分为调度线程和工作线程。 调度线程 JobScheduler 会根据 pg_job 表里面定义的 JOB 周期对已经过期的 JOB 进行调用由 Jobworker 线程执行实际的 JOB 任务。
百分比统计线程
百分比统计线程在 openGauss 数据库中被命名为 PercentileJob该线程根据 percentile 参数设置的值计算 sql 响应时间的百分比信息。目前 openGauss 的 percentile 参数仅支持 80 和 95。
服务启动线程
服务启动线程在 openGauss 数据库中被命名为 StartupProcess主要负责 openGauss 启动时的线程初始化或者执行 recovery 操作。
子线程回收线程
子线程回收线程在 openGauss 数据库中被命名为 Reaper主要负责回收处于 die 状态的子线程。
通信管理
通信协议处理
这部分主要涉及的是 openGauss 数据库所使用的前端和后端协议根据连接的状态不同存在几种不同的子协议如启动、查询、函数调用、COPY、终止等。
控制命令信号处理
信号是一种软件中断机制openGauss 数据库线程之间的通讯是离不开这些信号的比如常见的 SIGTERM、SIGQUIT、SIGCHILD、SIGUSR1、SIGUSR2 等这些信号在 openGauss 的线程源代码中随处可见。关于通信管理这一部分的技术内容有兴趣的小伙伴也可以参考 PG 的文档。
SQL 引擎
SQL 引擎部分包含了整个 SQL 处理流程所需要的模块
SQL 解析
当客户端发送 SQL 语句服务端业务处理线程接收后首先会对接收到的 SQL 语句进行解析这些解析依次包括词法解析(将用户输入的 SQL 语句拆解成单词(Token)序列并识别出关键字、标识、常量等确定每个词固有的词性)、语法解析(根据 SQL 的标准定义语法规则使用词法分析中产生的词去匹配语法规则如果一个 SQL 语句能够匹配一个语法规则则生成对应的抽象语法树)、语义解析(对语法树进行有效检查检查语法树中对应的表、列、函数、表达式等是否有对应的元数据将抽象语法树转换为逻辑执行计划)。
SQL 查询重写
当 SQL 语句生成逻辑执行计划后即到了 SQL 查询重写阶段利用已有语句特征和关系代数运算(如交换律、结合律、分配律等)来生成更高效的等价语句。
SQL 优化
SQL 优化依赖于 SQL 的查询重写它根据生成的高效等价 SQL 语句枚举不同的候选执行路径这些执行路径互相等价但是执行效率不同经过对他们进行执行代价的计算最终获得一个最优的执行路径。
这里所说的执行代价比如处理一条元组的 CPU 代价、加载一个数据页的 IO 代价、如果是分布式数据库数据元组的传输代价。 至于根据哪些统计信息计算这些代价呢 比如根据表的元组数、字段宽度、NULL 记录比率、distinct 值、MCV 值(表每一列的高频词汇)、HB 值(直方图不包含 MCV 值)等表的特征值以及一定的代价计算模型计算出每一个执行步骤的不同执行方式的输出元组数和执行代价(cost)。
SQL 执行
SQL 执行工作由 SQL 执行器完成而 SQL 执行器在数据库的整个体系结构中起承上启下的作用上联优化器下联存储。当 SQL 执行器接收到优化器返回的执行计划树后遍历整个执行树根据每个算子的不同特征进行初始化(比如HashJoin 这个算子在初始化阶段会进行 Hash 表的初始化这个初始化主要是内存分配)。 初始化完毕后就进入了执行阶段执行器会对执行树进行迭代遍历通过从磁盘读取数据根据执行树的具体逻辑完成查询语义。
最后将是执行器的清理阶段这里主要是释放内存清理资源。
DDL 命令处理
DDL 的命令也需要执行基本的词法解析、语法解析和语义解析等操作但是基本不需要做什么优化处理。DDL 命令在被解析完毕后查询对应的数据字典后就可以开始执行更新操作。
存储过程解析
存储过程是一组可以完成特定功能的 SQL 语句集合经编译后存储在数据库中。存储过程的执行效率比逐条执行的 SQL 语句高很多因为普通的 sql 语句每次都会对 SQL 进行解析、编译、执行而存储过程只是在第一次执行时进行解析、编译、执行以后都是对结果进行调用。而存储过程解析工作就是在 SQL 引擎模块中完成。
存储引擎
数据库存储引擎主要解决的问题是
存储的数据必须保证原子性(A)、一致性(C)、隔离性(I)、持久性(D)。支持高并发读写、高性能读写。充分发挥硬件的性能解决数据的高效存储和检索能力。
行存引擎
openGauss 的行存引擎是将表按行存储到硬盘分区上支持高并发读写、低时延。主要面向 OLTP 场景设计OLTP 即就是在线联机事务处理它的特点是随机小 IO 操作频繁数据变化较大常见于那些交易型事务处理场景例如银行交易系统、订货发货系统等。
openGauss 的行存引擎使用 MVCC 多版本并发控制MVCC 机制在更新的时候并不是就地更新而是在原有页面中保留上一个版本转而在这个页面(如果空间不够则会在新页面中)中创建一个新的版本进行历史版本的累计与更新。相应的页面中会同时存有不同版本的同一行数据当拿到不同快照版本的事务时事务之间对这一条数据的读写互不冲突有着很好的并发性能对历史版本的检索可以在页面本身或者临近页面进行也不需要额外的 CPU 开销和 IO 开销效率非常高。
列存引擎
列存引擎主要面向 OLAP 场景设计OLAP 即就是在线联机分析处理常见于分析决策型使用场景如某公司决策层想要获得今年某产品在各个区域的销售情况统计信息这就建议使用列存引擎。 列存引擎的存储基本单位是 CU(Compression Unit,压缩单元)表里面一列的一部分数据组成的压缩数据块就可以称为 CU。 行存引擎是以行为单位来管理而列存引擎则将整个表按照不同列划分为若干个 CU以 CU 为单位进行管理。列存有以下优势
CU 的数据特征一般比较相似适合压缩且压缩比很高节省大量的磁盘空间在多列表中如果仅访问少数几个列在这种场景中可以很大程度减少需要读取的数据量大幅降低 IO 消耗提升查询性能基于列批量数据向量运算结合向量化执行引擎CPU 的缓存命中率比较高OLAP 性能更好列存表同样支持基本的 DML 操作和 MVCC 多版本控制从使用角度看兼容性比较好基本对用户是透明的。
内存引擎
内存表、也就是指 MOT 内存引擎作为在 openGauss 中与传统基于磁盘的行存储、列存储并存的一种高性能存储引擎基于全内存态的数据存储为 openGauss 提供了高吞吐的实时数据处理分析能力和极低的事务处理延时在不同的业务负载场景下可以达到其他引擎事务处理能力的 3~10 倍。
内存引擎之所以有较强的事务处理能力并不是简单地因为它是基于内存而非磁盘更多的是因为它的索引结构以及整体的数据组织都是基于 Masstree 模型实现的Masstree 架构的乐观并发控制和高效的缓存块利用率使得 openGauss 可以全面地利用内存中可以实现的无锁化数据及索引结构、高效的数据管控、基于 NUMA 架构的内存管控、优化的数据处理算法及事务管理机制等。 需要注意的是全内存态存储并不代表着内存引擎中处理的数据会因为系统故障而丢失相反内存引擎有着与 openGauss 的原有机制相兼容的并行持久化、检查点能力(CALC 逻辑一致性异步检查点)使得内存引擎有着与其他存储引擎相同的容灾能力以及主备副本带来的高可靠能力。
详细的内存引擎关键技术介绍大家可以参考《openGauss 数据库核心技术》这本书。
CSN 快照
CSN(Commit Sequence Number)即就是待提交事务的序列号(一个 64 位无符号自增长整数)常用于多版本可见性判断和 MVCC 机制在 openGauss 内部使用 CSN 作为逻辑的时间戳模拟数据库内部的时序。 openGauss 在 MVCC 机制下每个事务都有一个单独的事务状态存储区域记录了该事务的状态信息和 CSN 信息。每个非只读操作都会取得一个事务号(xid)当事务提交的时候 openGauss 会向前推进 CSN同时会将当前的 CSN 与事务的 xid 映射关系保存在 CSN log 中。
openGauss 事务启动时会创建一个 CSN 快照CSN 快照创建的过程大致步骤可以理解为在事务启动的那一时刻会遍历当前所有活动的(还未提交)事务记录在一个活动 Transaction 的 ID 数组中选择所有活跃事务中最小的 TransactionID记录在 xmin 中选择所有已提交事务中最大的 TransactionID加 1 后记录在 xmax 中。
那么
所有事务 ID 小于 xmin 的事务可以被认为已经完成即事务已提交其所做的修改对当前快照可见所有事务 ID 大于或等于 xmax 的事务可以被认为是正在执行其所做的修改对当前快照不可见对于事务 ID 处在 [xmin, xmax)区间的事务, 需要结合活跃事务列表与事务提交日志 CLOG判断其所作的修改对当前快照是否可见。
空闲空间管理
openGauss 使用 MVCC 多版本并发控制机制更新和删除操作并不会在页面中删除数据本身这样在数据库长时间运行后会有大量的历史版本保存在存储空间中造成空间膨胀。为了解决这一问题存储引擎内部需要定期对历史数据进行清理以保证数据库的健康运行。
存储空间的清理分为页面级的清理、表级清理、数据库级清理等。
页面级的清理机制称为 heap_page_prune这是一种较为轻量化的清理方式这种机制由页面的空闲空间阈值触发仅改动页面本身不改动对应的索引页面可以很好的解决同一条数据记录的历史遗留版本。
表级别和数据库级别的清理机制称为 vacuum,vacuum 清理机制的触发可以由用户手动触发也可以根据参数阈值后台自动触发。vacuum 操作除了清理废旧的元组数据以外还会对索引进行清理以释放存储空间同时也会更新对应的统计信息。
锁管理器
锁管理器对事务并发访问过程中数据库对象的加锁操作进行管理判断两个事务访问同一个对象的时候加的锁的类型是否相容是否允许事务在相应对象上加锁。锁管理器对事务并发过程中使用的锁进行记录、追踪和管理。
大内存缓冲区管理
大内存缓冲区介于数据存储引擎和外部文件系统之间常用来同外部文件系统进行 page 页面交换并作缓冲对内存共享页面的脏页进行 LRU 算法淘汰并刷盘保证内存使用的高效减少磁盘的访问。
索引管理
索引可以有效提升数据的访问效率索引管理主要管理的是索引结构包括索引创建、更改、删除等。
存储管理适配
存储管理适配指的就是对存储介质层的管理对不同的存储介质进行适配封装对上层数据页面访问屏蔽底层真正存储系统的差异例如管理 HDD 的使用、管理 SSD 的使用。
日志管理
传统数据库一般都采用串行刷日志的设计因为日志有顺序依赖关系即一个事务产生的多条 redo/undo 记录的前后顺序依赖关系很强。
在日志管理这部分openGauss 主要对日志系统进行了并行设计采用多个 Log Writer 线程并行写的机制打散串行刷日志的锁控制瓶颈充分发挥 SSD 的多通道 IO 处理能力。在做并行日志系统设计时关键设计点包括以下几点
整个事务的 WAL 日志不能拆分到多个事务日志共享缓冲区必须写到一个事务共享缓冲区中故障恢复时并行回放 WAL 日志必须按照 LSN(日志序列号)的大小顺序恢复每个事务结束前需要保证对应的事务日志 LSN 已经刷盘完成事务分配事务日志共享缓冲区时与 NUMA 架构适配。
并行日志回放
并行日志的回放指的是将重做日志中已记录的数据文件变更操作重新应用到系统/页面中的过程这个过程通常发生在实例故障恢复抑或者是主备实例之间的数据同步过程中的备机实例上(即主实例的改动需要在备机实例回放重做以达到主备实例状态一致)。
openGauss 数据库为了能够充分利用 CPU 多核的特点加快数据库异常后恢复及备机实例日志回放的速度在备机的日志回放中使用了多线程并行回放技术。整个并行回放系统由分配模块和回放模块组成分配模块负责解析日志并分配日志给回放模块而回放模块负责将解析后的日志进行实际回放操作。
因为事务的提交和操作之间的顺序对于数据一致性至关重要所以重做日志中每条记录都有一个 64 位无符号整数的日志序列号(LSN)。openGauss 为了提升整体并行回放机制的可靠性会在对每一个页面执行回放动作之前对事务日志中的 LSN 和页面结构中的 Last_LSN 进行校验以保证回放过程中数据库系统的一致性。
openGauss 默认有 4 个并行回放线程当然这个也可以使用参数 recovery_max_workers 调整。
增量检查点
数据库中事务对数据文件操作的持久化与事务提交不是同步的即也就是说事务提交需要对应的重做日志强制刷盘但是并不强制要求对应的数据页被刷盘这样就使得当数据库实例从崩溃状态恢复时需要对重做日志进行回放读取所有没有被刷盘的数据页进行恢复这样就使得日志回放代价较高故障恢复时间较长。
数据库检查点可以让存储引擎将数据缓冲区中的脏页写入磁盘中并记录信息到日志文件和控制文件。当数据库实例从崩溃状态恢复时可以直接从检查点时刻的 LSN 位置开始执行回放降低数据库的日志回放代价缩小故障恢复时间。
但由于检查点本身需要将缓冲区的所有脏页刷盘从而造成每次检查点时刻对数据库实例造成了较大的物理 IO 压力导致数据库运行性能波动较大较大的性能波动对于核心业务系统可能造成灾难性故障。为了解决检查点造成的数据库性能波动问题openGauss 数据库引入了增量检查点机制默认 1 分钟执行一次。
在增量检查点机制下会维护一个按照 LSN 顺序递增排列的脏页面队列定期由 pagewriter 线程对这些队列中的脏页进行刷盘操作并记录已被刷盘的脏页最新的 LSN(recLSN)。当触发增量检查点的时候并不是等待所有脏页刷盘而是使用当前脏页队列的 recLSN 作为检查点 LSN 位置这样的增量检查点使得整个数据库系统 IO 性能更加平滑且系统故障恢复时间更短。
pagewriter 线程在前面的线程管理部分已经做过基本介绍当增量检查点机制打开时不再使用 full_page_writes 防止半页写问题而是依赖双写(double-writer)特性保护。pagewriter 线程将脏数据页拷贝到双写(double-writer)区域并落盘然后将脏页转发给 bgwriter 子线程进行数据下盘操作这样就防止了数据页折断故障的发生。
NUMA 化数据架构 openGauss 根据鲲鹏处理器的多核 NUMA 架构特点做了一系列的相关优化比如 采用 NUMA 绑核的方式尽量减少跨核内存访问的时延问题为了充分发挥鲲鹏多核算力优势使用并行日志系统设计、CLog 分区等大幅提升 OLTP 系统的处理性能。 openGauss 基于鲲鹏芯片所使用的 ARMv8.1 架构利用 LSE 扩展指令集替代传统的 CAS 指令实现高效的原子操作从而提升多线程间同步性能XLog 写入性能等。
安全管理
高安全是 openGauss 数据库给企业带来的重要价值之一为了有效保障用户隐私数据、防止信息泄露构建了由内而外的数据库安全保护措施。 openGauss 的安全机制充分考虑了数据库可能的接入方包括 DBA、用户、应用程序以及通过攻击途径连接数据库的攻击者等。
身份管理
在身份管理方面openGauss 使用了一系列的认证机制来实现通过认证模块限制用户对数据库的访问通过口令认证、证书认证等机制保障认证过程中的安全通过黑白名单限制访问 IP通过数据库属性或用户属性限制连接数。
访问控制
在访问控制方面用户以某个角色登录数据库系统后通过基于角色的访问控制机制获得相应的数据库资源和对象访问权限用户每次在访问数据库对象时均需要使用存取控制机制进行权限校验。为了解决系统管理员用户权限高度集中的问题openGauss 系统引入了三权分立角色模型在该模型中安全管理员负责用户角色的创建系统管理员对创建的用户进行赋权(不再拥有创建角色和用户的权限、也不再拥有查看和维护数据库审计日志的权限、同时还不再拥有管理其他用户模式及对象的权限)审计管理员则审计所有用户的操作行为。
通信加密
用户对对象的访问操作本质上是对数据的管理包括增加、删除、修改、查询等操作。数据在存储、传输、处理、显示等阶段都会面临信息泄露的风险。 openGauss 提供了数据加密、数据脱敏、加密数据导入导出等机制保障数据的隐私安全。
另外openGauss 还将引入全程加密技术数据在客户端进行加密后进入服务端服务端基于密文场景对密文进行查询和检索。并且openGauss 将构建基于可信硬件的可信计算能力在可信硬件中完成对数据的解密和计算计算完毕后再加密返回构成完整的 openGauss 全程加密方案架构。
审计
openGauss 针对用户所关心的行为提供了基础审计能力审计内容包括事件的发起者、事件的发生时间和事件的内容。openGauss 可以从以下维度做审计
用户的登录、注销审计数据库启动、停止、恢复审计用户越权访问、锁定、解锁审计数据库对象的 DDL、DML 以及函数的操作审计权限的赋权和回收审计参数修改审计。
openGauss 将这些审计所产生的内容以二进制格式单独存储于文件中审计管理员可以通过 pg_query_audit()函数查看审计日志内容。
公共能力
橙色部分的代码量大约在 25W 行左右这一部分主要包含一些接口驱动、公共函数、数据字典等大部分与 PostgreSQL 兼容openGauss 对这部分的代码主要做了一些优化改进这样也使得 openGauss 可以兼容绝大部分 postgreSQL 的应用程序复用部分 PG 生态。
客户端驱动
CLI
CLI这里的 CLI 指的就是 openGauss 自带的 gsql 客户端。
gsql 是 openGauss 提供在命令行下运行的数据库连接工具可以通过此工具连接服务器并对其进行操作和维护。
gsql 的基本功能包括连接数据库、执行 SQL 语句、执行元命令。
其中元命令可以帮助管理员查看数据库对象的信息、查询缓存区信息、格式化 SQL 输出结果以及连接到新的数据库等。
gsql 还有一些高级特性比如变量设置、自定义提示符设置、客户端操作历史记录设置等。
JDBC
JDBC(Java Database ConnectivityJava 数据库连接)是一种用于执行 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
openGauss 没有对这个接口在应用程序开发场景下的使用做验证。所以使用这个接口做应用程序开发存在未知风险所以不推荐用户使用这个接口做应用程序开发。推荐用户使用 ODBC 或 JDBC 接口来替代。
通用组件
数据字典
数据字典可以看做是数据库的元数据所谓元数据就是描述数据属性的一些数据。
用户可以通过查询系统表的内容获取数据库相关信息如表的属性信息、数据库的属性信息、数据类型的属性信息等。
在 SQL 执行的过程中辅助执行语义的解析。
内存管理
内存管理模块负责根据 openGauss 数据库的参数配置规划数据库各种内存的分配。例如使用 max_process_memory 参数控制数据库节点可用内存的最大峰值使用 work_mem 参数控制 SQL 内部排序和 Hash 表写入临时磁盘之前可以使用的内存大小等。
数据类型
数据类型支撑了数据库的访问和计算它定义了数据库中数据的属性。表的每一列都属于一种数据类型数据库根据数据类型使用对应的函数对数据内容进行操作例如openGauss 可对数值型数据进行加、减、乘、除操作等。
内置函数
函数是在数据库内定义的子程序数据库通过内置函数可以实现特定的功能需求比如数学计算、数据库管理、数据库信息查询等操作。
OMCM
蓝色部分的代码主要是华为自研的客户端和服务器端工具帮助用户更好地维护 openGauss。
工具
客户端命令行工具
客户端命令行工具这里典型的代表就是 gsql,这个在 CLI 部分已经做了简单解释这就不再重复解释。
数据库实例控制工具
openGauss 常见的实例控制工具例如
gaussdb(启动数据库)gs_ctl(启停数据库、加载配置文件、主备状态切换和查询等)gs_initdb(初始化数据库实例生成数据库目录、系统表并创建默认的数据库和模板数据库等)。
物理备份/恢复工具
openGauss 提供了 gs_basebackup 工具做基础的物理备份。
gs_basebackup 的实现目标是对数据库文件进行二进制拷贝远程执行 gs_basebackup 时需要使用系统管理员账户。这个工具当前支持热备份模式和压缩格式备份。
数据恢复操作比较简单因为 gs_basebackup 是对数据库按二进制进行备份因此恢复时可以直接拷贝替换原有的文件或者直接在备份的库上启动数据库。
另外openGauss 还提供了 gs_backup 工具帮助用户备份集群各个节点的二进制应用程序、参数文件(postgresql.conf)、客户端认证文件(pg_hba.conf)
逻辑导入导出工具
在逻辑导入导出工具部分openGauss 主要向大家提供了 gs_dump 和 gs_dumpall 工具。
gs_dump 工具可以帮助用户以纯文本格式、目录归档格式、tar 归档格式、以及用户自定义格式对一个数据库的对象导出这些对象包括模式、表、视图等。
gs_dumpall 工具可以以纯文档格式导出 openGauss 数据库的所有数据包括默认数据库 postgres 的数据、自定义数据库的数据、以及 openGauss 所有数据库公共的全局对象。 在数据库恢复方面纯文本的备份数据可以直接使用 gsql 工具导入通过-f 参数指定备份文本即可。
关于其他格式的备份集恢复可以使用 gs_restore 工具完成。该工具可以将备份文件内容导入数据库中也可以导入到指定文本文件中等效于直接使用 gs_dump 导出为纯文本格式。
OM 安装
OM 是 openGauss 的运维管理模块Operation Manager。提供集群日常运维、配置管理的管理接口、工具。
openGauss 提供了 gs_om 工具帮助大家对 openGauss 数据库实例进行维护包括启动 openGauss、停止 openGauss、查询 openGauss 状态、生成静态配置文件、刷新动态配置文件、显示帮助信息和显示版本号信息的功能。
CM 监控
CM 监控CM 是集群管理模块(Cluster Manager)由 CM Agent、CM Monitor 和 CM Server 组成。CM 模块这个常见于分布式的 gauss 数据库负责集群内高可用。管理和监控分布式系统中各个功能单元和物理资源运行情况确保整个系统稳定运行。但是这个模块在当前的 openGauss 中还没有看到至于 openGauss 的分布式架构后面会不会发布暂时还不清楚个人还是比较期待 openGauss 的分布式架构。
CM 组件
CM Agent负责监控所在主机上主备 GTM、CN、主备 DN 的运行状态并将状态上报给 CM Server。同时负责执行 CM Server 下发的仲裁指令。集群的每台主机上均有 CM Agent 进程。CM Server 会将集群的拓扑信息保存在 ETCD。
OM Monitor看护 CM Agent 的定时任务其唯一的任务是在 CM Agent 停止的情况下将 CM Agent 重启。如果 CM Agent 重启不了则整个主机不可用需要人工干预。 CM Server根据 CM Agent 上报的实例状态判定当前状态是否正常是否需要修复并下发指令给 CM Agent 执行。
硬件OS 平台
ARMopenEuler
ARMopenEuler这里的 ARM 主要指的就是华为的鲲鹏处理器目前在鲲鹏处理器上openGauss 支持的操作系统是 openEuler 和麒麟 V10 这两款 Linux 操作系统openEuler 是华为发布的开源 Linux 操作系统支持 x86 架构和鲲鹏 ARM 架构处理器目前已发布的版本有 openEuler 20.03LTS 和 openEuler 20.09LTS。
x86CentOS
在 x86 平台上openGauss 目前支持 CentOS 和 openEuler 这两款 Linux 操作系统。
CetnOS 操作系统推荐版本是 CentOS7.6openEuler 操作系统推荐版本是 20.03LTS
