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是否可以融合互补所长,在存储引擎层做彻底的融合优化呢?让我们拭目以待。