网站与新媒体建设测评方案,网站建设宣传软文范例,wordpress文本框代码,做抽纸行业网站目录
一、数据库存储引擎
二、GaussDB Ustore存储引擎
总结 本文将介绍GaussDB中的Ustore存储引擎#xff0c;包括Ustore的设计背景、特点介绍和适用业务场景等。
一、数据库存储引擎
数据库的存储引擎负责在内存和磁盘上存储、检索和管理数据#xff0c;确保每个节点的…目录
一、数据库存储引擎
二、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实现了多版本索引UbtreeUbtree叶子节点的页面结构如图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业务通过FSMFree 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存储引擎更适用于对性能和稳定性有更高要求的金融核心业务场景。
