网站 的建设意义,网站切图大图,建立采样点感控监督机制,微信电脑网页版1、 Ustore和Astore存储引擎介绍
Ustore存储引擎#xff0c;又名In-place Update存储引擎#xff08;原地更新#xff09;#xff0c;是openGauss 内核新增的一种存储模式。此前的版本使用的行存储引擎是Append Update#xff08;追加更新#xff09;模式。相比于Append…
1、 Ustore和Astore存储引擎介绍
Ustore存储引擎又名In-place Update存储引擎原地更新是openGauss 内核新增的一种存储模式。此前的版本使用的行存储引擎是Append Update追加更新模式。相比于Append Update追加更新行存储引擎Ustore存储引擎可以提高数据页面内更新的HOT UPDATE的垃圾回收效率有效降低多次更新元组后存储空间占用的问题。Append Update和 In-place Update是两种不同的存储引擎策略适用场景有所不同。
Append UpdateAppend Update 存储引擎策略将更新操作视为一种追加操作即将新的数据追加到已有的数据之后。这种方式适合于写操作频率较高、更新操作较少的场景。在 Append Update 中旧数据不直接被修改或删除而是继续存储新数据将追加到数据集的末尾。这样可以避免数据的移动和重建提高写入的性能并且可以实现快速的回滚和历史数据的查询。
In-place UpdateIn-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_countson track_activitieson enable_ustoreon enable_default_ustore_tableon 创建Ustore表 create table city(id int, name varchar(120) ,code varchar(20)) with (storage_typeustore); 确认city表使用ustore存储引擎 openGauss# \d List of relations Schema | Name | Type | Owner | Storage ---------------------------------------------------------------------------------- public | city | table | omm | {orientationrow,storage_typeustore,compressionno} 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是否可以融合互补所长在存储引擎层做彻底的融合优化呢让我们拭目以待。
