北京惟望科技发展有限公司010-64283188 登录 | 注册

当前位置:首页 > 经验交流

南大通用GBase8s国产数据库架构

发布日期:2021-07-30 来源:https://wenku.baidu.com/view/2e2353c0f58a6529647d27284b73f242326c31f2.html 浏览次数:1507

【导读】:数据库管理系统如GBase8s在架构上是非常类似Unix操作系统。它包含三个主要部分组成,过程管理,内存管理,磁盘存储管理。

数据库管理系统概览

§ 数据库管理系统如GBase8s在架构上是非常类似Unix操作系统。它包含三个主要部分组成,过程管理,内存管理,磁盘存储管理。 Unix的作业系统是设计用来处理“文件” (File) 类型的数据。而数据库系统,是专门用来处理“表” (Table or relation)的数据类型。

§ 每个“文件”是由无数的字符所组成。每个“表” 是由许多的“列” (Row)所组成。由于他们被设计来处理不同的数据类型。Unix操作系统或数据库管理系统的数据都有自己的方法来优化他们的组件,但他们基本的方式是非常相似。

§ GBase8s架构将分为如下四个方面进行介绍

– 架构概览 – GBase8s Architecture

– 进程/多线程结构 – Process/Multithreading Structure

– 内存结构 – Memory structure

– 存储结构 – Disk Storage structure

 

GBase8s架构概览

 

image.png

 

Fan In for OLTP – (多到少)少数进程能同时处理数千笔交易,避免数千进程运行于操作系统之上

Fan Out for DSS/OLAP –– (少到多)一件大型事务能拆成上百个小事务来并行处理

 

GBase8s的实现多线程架构

  - 更少的进程进行数据库管理系统的活动

  - 一个进程可以为多个应用程序提供工作线程

  - 过程可以根据需要动态分配

  - 更好的可扩展性,更多的客户可以用最低限度的额外资源服务

 

GBase8s 服务器的部件(component)

image.png 

 

§ 进程

– 执行数据库服务器实例instance)请求的任务

§ 共享内存

– 缓存数据表的数据

– 维护和控制着进程所需的资源

§ 磁盘

– 存储了数据表的数据和数据库服务器的系统信息

 

如下两张图介绍了这三种部件的职责和关系

image.png

 image.png

image.png

GBase8s架构_02_进程多线程结构

 

基于进程的数据库服务器的缺陷

§ 每个进程使用了一些时间片,如下图所示:

 

 

多个进程一个接一个地运行。

当更多的用户连接进来时,进程的数目将会增加,所需的资源也要增加。

 

• 每个用户连接代表需要一个新的进程为新连接提供服务。

• 每个进程的启动(initialization) 与结束(termination)耗费系统资源。

• 每次进程执行交换即需执行 Context Switch 耗费系统资源。

 

image.png 

 

 

 

 

 

 

 

 

 

 

 

 

动态可扩展架构

§ 动态可扩展架构(Dynamic Scalable Architecture, DSA) 。

§ 真正的多线程架构

§  专为“动态可扩展数据库架构设计的多线程库 (thread library)

–  资源利用率高

–  不依赖于操作系统

•  容易移植 (AIX, Solaris, HPUX, Linux, etc)

–  非依赖于操作系统的 POSIX多线程库

• (POSIX是 Portable Operating System Interface of Unix 的缩写)

•  集成的并行机制 (Parallel Processing)

–  动态的

–  可扩展的

§ 进程(Processes

– 每个数据库服务器进程被认为是一个虚拟处理器(virtual processor, VP)

– 多种数据库服务器进程 – CPUVP, AIOVP, LIOVP, ADMVP

– 每种VP管理和运行属于它的线程(thread)

– GBase8sVP的功能对VP进行分类

• 例如:写逻辑日志(LIOVP)或物理日志(PIOVP)、从磁盘读数据

§ 线程(Threads

– 用户线程(user thread):为从客户端应用程序来的请求提供服务

– 内部线程(internal thread):完成内部任务,例如数据库I/O、日志I/O

– 一个线程可运行在与它类别相同的任意一个VP

– VP从线程准备队列(Ready Queue)中获取线程的数据和环境信息,然后运行线程

 

5.1 GBase8s进程

启动后通过onstat –g glo命令可以查看GBase8s的全部vp每个vp对应一个进程如下图

image.png

通过这个命令可以查看GBase8s运行的时候有多少进程。这些进程和Virtual processors一一对应

5.2 物理的进程和虚拟的进程的对应关系

image.png


 

5.3 DSA – 基于线程的数据库服务器

image.png 

当更多的用户连接进来时,线程的数目将会增加,进程的数目可能不变

• 每个用户连接代表一个新的线程的起使为新连接提供服务。

• 每个线程的启动(initialization) 与结束(termination)耗费较小系统资源。

• 每次线程执行交换即无需执行Context Switch 耗费系同资源。

image.png 

 

5.4 高度的并行模型举例

image.png 

 

 image.png

 image.png

 

 

 

共享内存

image.png

 

数据库服务器进程通过共享内存池来达到共享数据的目的

 

通过缓存磁盘数据(cached data)来减少磁盘I/O

 

提供了进程间通信的最快捷方式

 

为使用IPC通信的本地客户端程序提供了通信渠道

 

此方法为多数专业数据库所共同采用。

 

 

共享内存段

共享内存总共分为5段:

驻留段Resident segment

– 常驻内存, 不会被操作系统换出到磁盘上(page-out)

– 固定大小,不随工作量而增加或减少

 

虚拟段Virtual segment

– 包含与线程和session相关的信息

– 虚拟段里的页面(page) -可被操作系统换出到磁盘上(page-out)

– GBase8s运行时可能添加新的虚拟段

 

消息段Message segment

– 如果GBase8s“客户端-服务器端”通信要使用消息缓冲区(message buffer),消息段将包含这些消息缓冲区

 

缓冲池段(Buffer Pool segment

– 存储从dbspace中读取数据不同的页面大小的dbs会对应一个不同的buffer pool 段

 

扩展段Extension segment

– data blade使用

 

共享内存的配置

可以通过修改onconfig中的resident值对segment的常驻状态进行设置

0:关闭所有segment常驻

1:只有resident segment是常驻的

n:  resident segment是常驻的, n-1个virtual segment是常驻的n < 100

-1: 全部resident segment和virtual segment是常驻的

!=0: buffer pool segment是常驻的

Message segment和extension segment是永远不会常驻内存的

 

共享内存的状态跟踪

命令

作用

onstat –g seg

显示segment的统计信息

onstat –g rbm

显示常驻段的block映射信息

onstat –g nbm

显示非常驻段的block映射信息

onstat –g mem

显示所有内存池的信息。

onstat –g afr

显示某内存池的内存分配信息,需指定查看内存池的名字。

onstat –f ffr

显示某内存池的空闲内存信息,需指定查看内存池的名字。

onstat –g bfr

显示blkpool的内存分配信息需要指定查看blkpool的地址

onstat -o

将共享内存中的内容dump到文件中默认为onstat.out

 

 

10 存储结构

image.png

这个图展示的存储结构的各个层次

chunk是最大的物理存储单位dbspace是chunk的逻辑组合

Extents是chunk下的一块区域tablespace是Extents的逻辑组合

Extents内部是若干page构成的

Page是读写的最小单位

 

11 (page)

image.png

 

§ 基本的存储单元

§ 所有的数据库和系统信息被存储在数据页上

§ 在服务器上,最小的IO单元是数据页

§ 在大多数的UNIX系统中,缺省的数据页大小是2KB。在AIXWindows系统中,缺省的数据页大小是4KB

§ 数据页大小是可配置的 (最大可以是 16KB只能是缺省页大小的整数倍)

 

12 ExtentsTablespaces

§ Extent

– 连续数据页的集合

– 数据表(table)的存储空间是以extent为单位来分配的

§ Tablespace

– extent的逻辑集合

– 用于存储数据表(table)

– 一个数据表(table)可以有多个tablespaces

 

image.png

创建表的时候可以指定这个表保存在哪个dbspace中并且可以设定extent的大小以及随后扩展的extent的大小

CREATE TABLE sample (…..)

    IN dbspaces1

    EXTENT SIZE 512

    NEXT SIZE 1024;

 

 

13 Chunks

image.png

 

§ 用于存储数据的连续磁盘空间

§ 一个chunk可以是一个裸设备(raw device)、一个裸设备中的一部分、一个UNIX文件(cooked file)

§ 一个chunk最大可以是4TB

§ 最多可以有32767chunk

§ 创建 Chunk 于文件档案(File system)范例如下

onspaces –c –d datadbs1 –p  /DATA/dbs1 –o 0 –s 102400

 

14 Dbspaces

§ 一个或多个chunk的逻辑集合

§ 一个dbspace可以有132767 chunk

§ 最多可以有2047dbspace

§ 表格创建于dbspaces 之上

§ 表格空间成长时,即加新chunk dbspaces 中成长 dbspaces 空间即可,表格schema 无需变动。

 

15 Blobspaces

§ 用于存储简单大对象(simple large objectTEXTBYTE类型的对象)的专门dbspace

§ blobspace中的基本存储单元是blobpage

§ Blobpage的大小可被配置为数据库服务器的数据页(page)大小的整数倍

§ 对于blobspace里的数据,数据库服务器在将它们写回磁盘时不使用缓冲区(buffer)

 

16 Sbspaces

§ 用于存储智能大对象(smart large objectBLOBCLOB类型的对象)的专门dbspace

§ Sbspace的基本存储单元是sbpage

§ Sbpage的大小与数据库服务器的数据页大小一样,不是可配置的

§ sbspace中分配存储空间时基本单元是extent

§ GBase8s Excalibur Text Search DataBlade Module 以多种方式使用智能大对象空间。

 

17 读取(Reading)和缓存(Caching)数据

§ 多使用者数据库如何读取(Reading)和缓存(Caching)数据

– 数据库服务器进程通过共享内存池来达到共享数据的目的

§ 当用户发出一个查询请求时,数据被从磁盘读入共享内存池缓冲区(buffer pool)中,I/O 的单位是数据页(page)。

§ 紧接着的对该数据的读取操作将从读取缓冲区中得到该数据而不用再从磁盘中读入。共享数据是多使用者数据(Multi-user database)的基本原里。

§ 使用者线程(User’s thread)对该数据的修改对所有的数据库进程都是可见的。

18 物理日志和逻辑日志

§ 数据事务(transaction)

• 使用COMMIT WORK 语句提交从事务开始时对数据库所作的全部修改

• 使用ROLLBACK WORK 语句取消某个事务,并撤销该事务开始以来所有发生的更改。

• 物理日志与逻辑日志 是数据事务提交或取消事务的机制与手段

• 物理日志(Physical logging

– 如果一个数据被更改了,物理日志将存储该数据页的before-image(即该数据页被更改前的数据)

– 物理日志由由磁盘上连续的数据页组成

– 用于系统失败时的恢复(recovery

§ 逻辑日志(Logical logging

– 记录了事务(transaction)的细节

– 事务的记录(Transaction records)被保存在逻辑日志中

– 逻辑日志由逻辑日志文件组成。每个文件由磁盘上连续的数据页组成

– 用于事务回滚(transaction rollback)和系统失败时的恢复(recovery

 

19 检查点(Checkpoints)和恢复(Recovery

§ 数据库完整性 - 如何保障数据库完整性

– 系统失败后如何恢复到系统失败之前的最后一个一致状态。

§ 检查点(Checkpoints

– 检查点事件是周期性的系统事件。检查点事件发生时,所有被修改的缓冲区将都被写回磁盘。

– 维护了数据库服务器的一致状态。

– 关于检查点事件的信息被记录在系统数据页和逻辑日志中(用于数据库服务器失败时的恢复)。

§ 恢复(Recovery

– 如果一个系统失败发生了,数据库服务器将被重启。

– 接着根据物理日志,数据库服务器将最后一个检查点之后被修改的数据页恢复为before-images

– 然后根据逻辑日志,最后一个检查点之后的事务(transactions)被重做。这样数据库服务器就能恢复到系统失败之前的最后一个一致状态。

 

 

 

 


分享到:
相关阅读