当前位置: 首页 > news >正文

GaussDB新特性Ustore存储引擎介绍

1、 Ustore和Astore存储引擎介绍

Ustore存储引擎,又名In-place Update存储引擎(原地更新),是openGauss 内核新增的一种存储模式。此前的版本使用的行存储引擎是Append Update(追加更新)模式。相比于Append Update(追加更新)行存储引擎,Ustore存储引擎可以提高数据页面内更新的HOT UPDATE的垃圾回收效率,有效降低多次更新元组后存储空间占用的问题。Append Update和 In-place Update是两种不同的存储引擎策略,适用场景有所不同。

Append Update:Append Update 存储引擎策略将更新操作视为一种追加操作,即将新的数据追加到已有的数据之后。这种方式适合于写操作频率较高、更新操作较少的场景。在 Append Update 中,旧数据不直接被修改或删除,而是继续存储,新数据将追加到数据集的末尾。这样可以避免数据的移动和重建,提高写入的性能,并且可以实现快速的回滚和历史数据的查询。

In-place Update:In-place Update 存储引擎策略将更新操作视为一种就地修改操作,即直接在原有位置上进行数据的更新。这种方式适用于需要频繁更新和随机访问的场景。在 In-place Update 中,数据库系统会在原有位置上修改被更新的数据,而不是追加新的数据。这可以减少存储空间的占用,并且支持更高的并发性能。然而,In-place Update 可能涉及到数据的移动和重建,特别是在更新操作导致数据大小变化时,可能需要重新分配和调整存储空间。

2、 Ustore存储引擎优势

相比于Append Update(追加更新)行存储引擎,Ustore存储引擎可以提高数据页面内更新的HOT UPDATE的垃圾回收效率,有效降低多次更新元组后存储空间占用的问题。

Ustore存储引擎结合Undo空间,可以实现更高效、更全面的闪回查询和回收站机制,能快速回退人为“误操作”,为GaussDB Kernel提供了更丰富的闪回功能。

Undo技术相对成熟,Ustore基于Undo回滚段技术、页面并行回放技术、多版本索引技术等实现了Ustore作为一款高可用高可靠的行存储引擎。

闪回作为数据库恢复技术的一环,能够使得DBA有选择性的高效撤销一个已提交事务的影响,将数据从人为的不正确的操作中进行恢复。在采用闪回技术之前,只能通过备份恢复、PITR等手段找回已提交的数据库修改,恢复时长需要数小时甚至数天。采用闪回技术后,恢复已提交的数据库修改前的数据,只需要秒级,而且恢复时间和数据库大小无关。Ustore支持闪回表、闪回查询、闪回TRUNCATE、闪回DROP,而且适用于分区表。

Ubtree与有的Btree索引相比,索引页面增加了事务信息,使得UBtree索引具备MVCC能力以及独立过期旧版本回收能力。In-place Update引擎支持 UBtree索引,UBtree也是In-place Update引擎的默认索引类型。支持并行创建索引、索引空间管理算法优化,索引空间进一步压缩。

Ustore整体架构图

3、 Ustore存储引擎实践

USTORE与原有的ASTORE(Append Update)存储引擎并存。USTORE存储引擎屏蔽了存储层实现的细节,SQL语法和原有的ASTORE存储引擎使用基本保持一致,唯一差别是建表和建索引有些细微区别。同时和Astore相比,Ustore没有VM文件。

在postgresql.conf配置文件中添加如下选项并重启数据库:

track_counts=on

track_activities=on

enable_ustore=on

enable_default_ustore_table=on

创建Ustore表:

create table city(id int, name varchar(120) ,code varchar(20)) with (storage_type=ustore);

确认city表使用ustore存储引擎:

openGauss=# \d

                                  List of relations

 Schema | Name | Type  | Owner |                       Storage                        

--------+------+-------+-------+------------------------------------------------------

 public | city | table | omm   | {orientation=row,storage_type=ustore,compression=no}

4、 Ustore使用场景

  • 高性能:对插入、更新、删除等不同负载的业务,性能以及资源使用表现相对均衡。更新操作采用原地更新模式,在频繁更新类的业务场景下可拥有更高、更平稳的性能表现。适应“短”(事务短)、“频”(更新操作频繁)、“快”(性能要求高)的典型OLTP类业务场景。

  • 高效存储:支持最大限度的原位更新, 极大节约了空间;将回滚段、数据页面分离存储,具备更高效、平稳的IO使用能力,Undo子系统采用NUMA-aware设计,具有更好的多核扩展性,Undo空间统一分配,集中回收,复用效率更高,存储空间使用更加高效、平稳。

  • 细粒度资源控制:Ustore引擎提供多维度的事务“监管”方式,可基于事务运行时长、单事务使用Undo空间大小、以及整体Undo空间限制等方式对事务运行进行“监管”,防止异常、非预期内的行为出现,方便数据库管理员对数据库系统资源使用进行规范和约束。

5、 Ustore使用约束

尽管Ustore设计几乎能够覆盖SQL和未来特性集;支持大多数的SQL标准,也支持常见的数据库特性。但也存在如下约束:

1)不支持可重复读和串行化隔离级别。

2)对于支持row movement的分区表,不支持并发更新或删除同一行操作。

3)不支持的DDL功能:在线vacuum full/cluster、在线alter table(除新增字段、重命名等无需全量重写数据的操作外)、table sampling、并行查询。

4)不支持hash索引、GiST索引、SP-GiST索引、BRIN索引。

5)不支持压缩。

6)不支持批量访存接口。不支持rowid语义。

7)不支持创建、使用物化视图。

8)不支持设置透明数据加密。

9)不支持单事务块或语句中既包含Astore表又包含Ustore表。

6、 展望未来

Ustore和Astore都有各自的使用场景,在使用时需要根据具体的业务场景进行选择,因此GaussDB把选择权交给了用户。那么Ustore和Astore是否可以融合互补所长,在存储引擎层做彻底的融合优化呢?让我们拭目以待。

http://www.lryc.cn/news/238321.html

相关文章:

  • 人工智能基础_机器学习046_OVR模型多分类器的使用_逻辑回归OVR建模与概率预测---人工智能工作笔记0086
  • 【LeetCode刷题-链表】--23.合并K个升序链表
  • 强化学习笔记
  • 经典双指针算法试题(一)
  • MATLAB | 绘图复刻(十三) | 带NaN图例的地图绘制
  • netty整合websocket(完美教程)
  • 选择PC示波器的10种理由!
  • 【pytorch深度学习 应用篇02】训练中loss图的解读,训练中的问题与经验汇总
  • uniapp 微信小程序如何实现多个item列表的分享
  • .NET 8 正式 GA 遥遥领先
  • 2216. 美化数组的最少删除数 --力扣 --JAVA
  • DDD 领域驱动设计
  • 转型做视频了,博客就是稿子,继续坚持写博客,同时发布视频,能写博客说明思路清晰了,能再讲明白,理解就更透彻了,紧跟上时代发展。
  • 小众市场:探索跨境电商中的利基领域
  • C++中的mutable关键字
  • java: 无效的目标发行版: 17 问题解决
  • C#的LINQ查询
  • Python不会调试不够丝滑?那事你不会logging---剖析!
  • OpenAI的Whisper蒸馏:蒸馏后的Distil-Whisper速度提升6倍
  • Ubuntu18.04安装LeGO-LOAM保姆级教程
  • git修改commit历史提交时间、作者
  • 【C++历练之路】list的重要接口||底层逻辑的三个封装以及模拟实现
  • Kubeadm部署Kubernetes Containerd集群
  • OpenCV入门9——目标识别(车辆统计)
  • 2023前端大厂高频面试题之JavaScript篇(5)
  • 物联网网关在工业行业的应用案例
  • 5、基础入门——资产架构端口应用WAF站库分离负载均衡
  • golang学习笔记——接口和继承比较1
  • chatGPT快捷键(最新版本)
  • 77基于matlab的蚁群优化路径算法,二维路径和三维路径优化