目录
一、数据库存储引擎
二、GaussDB Ustore存储引擎
总结
本文将介绍GaussDB中的Ustore存储引擎,包括Ustore的设计背景、特点介绍和适用业务场景等。
一、数据库存储引擎
数据库的存储引擎负责在内存和磁盘上存储、检索和管理数据,确保每个节点的数据能够长久保存。
存储引擎主要分为行存储(Row-Store)和列存储(Column-Store)两种方式。其中,行存储主要适合于在线交易型的OLTP场景;而列存储主要用于海量静态数据的分析,一般应用于OLAP场景。
二、GaussDB Ustore存储引擎
1. 背景介绍
在Ustore存储引擎出现之前,GaussDB的行存储引擎是Astore。Astore引擎采用了优化的Append Update(追加更新)存储格式设计,其元组(数据)的存储方式如图1所示。
图1 Astore引擎元组(数据)的存储方式
当一个更新操作将 v0 版本元组更新为v1 版本元组后,如果 v0 元组所在页面有空闲空间,则直接在该页面内插入更新后的v1元组,并将v0的元组指针指向v1的元组指针。在此过程中,新版本元组以追加写的方式和被更新的老版本元组混合存放,从而可以减少更新操作的I/O开销。
Astore在处理业务中的插入、删除及Hot-Update(同一页面内的更新)场景时表现出色。然而,对于跨数据页面更新的非Hot-Update场景,新数据需插入到新的页面,并插入新的索引,这不仅会引入额外的I/O操作,还可能导致索引膨胀。
由于新旧版本元组混合存放,需要通过vacuum操作遍历表数据并清理其中的死元组。vacuum操作不仅会占用一定系统资源,且在清理时需要对页面加写锁,读写锁的冲突也会影响用户的读写业务。因此,如果频繁vacuum操作可能会导致性能问题;反之,但如果vacuum操作频率太低,清理元组不及时,又会导致存储空间膨胀。
可以看出,Astore更适用于插入较多而更新较少的业务场景。为了应对频繁更新的业务场景,Ustore存储引擎应运而生。Ustore也是行存储引擎,又名In-place Update(原地更新)存储引擎,特别适用于频繁更新的业务场景。
2.核心目标
Ustore存储引擎的核心目标为:
第一,针对OLTP场景,降低Append-Update存储引擎由于频繁更新导致的数据页空间膨胀,以及由此引起的索引空间膨胀。
第二,去除vacuum依赖,vacumm不再清理ustore的页面,从而减少大量页面I/O操作,节省系统资源,同时避免因vacuum操作引起的性能波动。
3.原理介绍
In-place Update
Ustore存储引擎将新旧版本的数据分开存储,最新版本的数据被存储在数据页上,并且单独开辟一段Undo空间,专门用来统一管理历史版本的旧数据。因此,数据空间不会由于频繁更新而膨胀,旧版本的垃圾数据回收效率也会更高。
图2 Ustore的原地更新操作
Ustore的原地更新操作,如图2所示,当对数据页上的Tuple(元组)进行更新时,系统会将页面上的旧版本Tuple采用追加写的方式写入到Undo空间,这样旧版本数据的读取和写入不会发生冲突,同时在数据页上对Tuple的位置进行原地更新;当需要查询旧版本数据时,系统会检查TD(事务目录),然后从Undo空间中取出旧版本数据。
Ustore的原地更新机制保证了元组RowId稳定,对于在多个事务并发更新同一行的场景,更新时延相对稳定。同时,由于数据的最新版本和历史版本被分离存储,历史版本的批量回收不影响数据页的读写操作,因此,对最新版本的堆表数据空间膨胀友好。
多版本索引
Ustore实现了多版本索引Ubtree,Ubtree叶子节点的页面结构如图3所示。
图3 Ubtree叶子节点的页面结构
Ubtree的叶子结点中,每个索引元组的尾部附加了对应的xmin和xmax(插入和删除的事务ID)。通过检查xmin和xmax,可以判断这个索引元组是否对当前事务可见,这种机制允许进行独立的多版本并发控制(MVCC)。索引可见性检查使得Index Scan和IndexOnly Scan的性能有所提升,还增加了IndexOnly Scan的比例,大大减少回表操作的次数。
空间管理和回收
Ustore不依赖vacuum清理机制,实现了自治式的空间管理机制,堆表和索引的空间分配和回收都在业务运行的时候平稳进行,可以减少由于vacuum异步数据清理带来的大量页面I/O。
当页面上的数据元组被删除时,系统会在页面上记录对应的潜在空闲空间(Potential Free Space),用于估计页面上的空闲空间。在执行DML语句时,如果发现空间不足或者潜在空闲空间达到某个阈值,会尝试对页面进行清理。在执行DQL查询语句时,若检测到页面上潜在空闲空间达到阈值,此时会尝试申请页面的写锁,一旦拿到了页面的写锁,同样会尝试对页面进行清理。
对于那些一直不被访问的页面,也可能存在可清理的元组。清理这些元组的机制如下:
当DML业务通过FSM(Free Space Map,自由空间映射)发现没有足够的可用空间,并且在对堆表的物理文件进行扩展前,会随机选取一些页面进行清理。经过多次尝试后,选取的页面会覆盖整个表的全部页面。
支持NUMA-aware
Ustore采用了NUMA-aware(非统一内存访问感知)的Undo子系统设计,这使得Undo子系统可以在多核平台上实现有效扩展。Undo空间被划分为多个逻辑区域(UndoZone) ,线程会在自己的逻辑区域上进行分配,确保与其他线程完全隔离,从而写入旧数据分配空间时就不会有额外的锁开销。同时,UndoZone可以按照CPU的NUMA核进行划分,每个线程会从当前的NUMA核上的UndoZone进行分配,进一步提升分配效率。
4. Ustore闪回功能介绍
数据备份恢复是保护数据安全的重要手段之一。备份恢复类型一般可以分为物理恢复、逻辑恢复、闪回恢复。
物理恢复是通过物理文件拷贝的方式来备份数据库,通过备份的数据文件和归档日志(Redo Log),可以完全恢复数据库。这种恢复方式一般用于全量备份,能够恢复整个数据库到备份时的状态。
逻辑恢复是通过逻辑导出操作对数据库进行备份,但只能恢复到备份时保存的数据状态,无法恢复到具体某个时间点。由于逻辑恢复需要重建数据库并导入备份数据,因此,需要恢复的时间太长,这种恢复方式通常会用于数据迁移场景。
闪回恢复也是数据库恢复技术的一种,如图4所示。它可以有选择性地高效撤销一个已提交事务的影响,将数据从人为的不正确的操作中恢复出来。闪回恢复具有高效、可靠、精确的特点,通过恢复操作使得数据表可以回溯到某个历史状态,而不需要还原整个数据库。
图4 闪回恢复,快速回溯到历史状态
Ustore提供了闪回查询、闪回表、闪回Drop、闪回Truncate四类闪回功能,对于误操作数据后恢复十分有效。
闪回查询和闪回表
闪回查询:基于MVCC机制,定时捕获并存储快照作为闪回点,并且保留一定期限内的元组旧版本。通过使用保存的闪回点快照,可以检索出指定的旧版本数据,可以查询某个表在过去某个时间点的快照数据。这一特性可以用于查看和逻辑重建因意外删除或更改而受损的数据。
闪回表:基于MVCC机制,通过删除指定时间点和该时间点之后的增量数据,可以将表恢复至特定时间点,实现表级的数据还原。当逻辑损坏仅限于一个或一组表,而非整个数据库时,此特性可以快速恢复表的数据。
闪回Drop/Truncate
闪回Drop和闪回Truncate都是基于回收站(Recycle Bin)机制实现的,这一机制类似于windows系统的回收站,将已删除的表信息保存到回收站中,通过还原回收站中记录的表的物理文件,实现已Drop/Truncate表的恢复。
-
闪回Drop:可以恢复因意外而被删除的表,从回收站中恢复被删除的表及其附属结构,如索引、表约束等。
-
闪回Truncate:可以恢复因误操作或意外而被进行Truncate的表,从回收站中恢复被Truncate的表及索引的物理数据。
采用闪回技术后,恢复已提交的数据库修改前的数据只需要秒级,而且恢复时间和数据库大小无关,可以快速有效的进行数据恢复。
5.核心优势
1)高性能
对插入、更新、删除等不同负载的业务,系统可以做到性能和资源使用表现相对均衡,相比Append Update 引擎性能提升10%。
对于更新操作,由于采用原地更新策略,系统在频繁更新类的业务场景下,拥有更高、更平稳的性能表现。
通过DML操作中执行动态页面清理,系统成功去除对Vacuum依赖,减少由于异步数据清理而产生的大量读写I/O操作,适合事务短、更新频繁、性能要求高的OLTP类业务场景。
2)高效存储
支持原地更新机制,通过将数据页面和回滚段分离存储,具备更高效、平稳的I/O处理能力,TPCC负载平均节约空间15%~20%。
Undo空间采用统一分配,集中回收的方式,复用效率更高,使得存储空间使用更加高效、平稳。
3)细粒度资源控制
通过Undo子系统,实现事务级的空间管控,可基于事务运行时长、单事务使用Undo空间大小以及整体Undo空间限制等方式监管事务运行,防止异常行为出现,方便数据库管理员对数据库系统资源使用进行规范和约束。
总结
GaussDB的Ustore存储引擎在数据频繁更新场景下,依旧保持性能平稳,抖动范围缩减了81%,因此,适应更多业务场景和工作负载;同时,还支持闪回功能,可以恢复因误操作而丢失的数据,这使得Ustore存储引擎更适用于对性能和稳定性有更高要求的金融核心业务场景。