点击蓝字 关注我们
GaussDB(for openGauss，以下简称GaussDB)是一款基于Shared-Nothing架构的企业级分布式关系型数据库。它采用众多拥有独立且互不共享系统资源的逻辑节点构成，通过协调节点的协同工作，实现了大规模数据的并行处理，从而保证了数据处理的高效性和快速响应能力。
存储引擎概述
在事务管理上，GaussDB采取了MVCC（多版本并发控制）结合两阶段锁的方式，这种多版本机制读写操作互不阻塞，提高了数据库的并发性能。然而，它也有一些缺点，比如会造成磁盘空间的膨胀问题，因为每个修改都会生成新的数据版本。此外，由于需要维护多个版本的数据，也可能增加系统的复杂性和维护成本。Astore与Ustore最大区别在于它们在多版本机制实现上处理新版本与历史版本数据方式的不同。
GaussDB的Astore存储引擎没有将历史版本数据统一存放，而是和当前元组的版本放在了一起，没有回滚段的概念，但是为了定期清除历史版本数据，Astore存储引擎引入了一个VACUUM线程。一般情况下，除非用户要做性能调优，否则不用特别关注VACUUM线程。Astore并不进行分离存储，即最新版本和历史版本的数据是混合存储在一起的。
Ustore作为GaussDB推出的一款原位更新的存储引擎，其设计理念与Astore截然不同。Ustore存储引擎是将历史版本数据统一存放到undo回滚段里，由undo回收线程统一清理历史版本数据。在Ustore中，最新版本的数据与历史版本的数据是分离存储的，这种设计使得数据的处理和管理更为高效和灵活，Ustore目前对于索引的处理还没有实现分离存储。Ustore已经逐渐发展为GaussDB的默认行存引擎，为数据库的性能和稳定性提供了有力的支持。
Astore介绍
1．使用Astore的优势
(1) Astore没有回滚段，而Ustore有回滚段。对于Ustore来说，回滚段是非常重要的，回滚段损坏会导致数据丢失甚至数据库无法启动的严重问题。且Ustore恢复时同步需要Redo和Undo。由于Astore没有回滚段，旧数据都是记录在原先的文件中，所以当数据库异常crash后，恢复时，不会像Ustore数据库那样进行复杂的恢复。
(2) 由于旧的数据是直接记录在数据文件中，而不是回滚段中，所以不会经常报Snapshot Too Old错误。
(3) 回滚可以很快完成，因为回滚并不删除数据。
(4) WAL日志要简单一些，仅需要记录数据文件的变化，不需要记录回滚段的变化。
2．使用Astore注意事项
Ustore介绍
1．使用Ustore的优势
2．使用Ustore注意事项
3．特性约束
类别 | 特性 | 是否支持 |
事务 | Repeatable Read/Serializable | 不支持 |
在事务块中对分区表执行DDL操作 | 不支持 | |
索引 | Gist Index/Gin Index | 不支持 |
可扩展性 | Hashbucket | 不支持 |
SQL | Table sampling/物化视图/键值锁 | 不支持 |
(1) 数据表最大列数不能超过1600列。
(3) Ustore表(不含toast情况)最大Tuple长度不能超过(8192-MAXALIGN(56+init_td*26+4)),其中MAXALIGN表示8字节对齐。当插入数据长度超过阈值时，用户会收到元组长度过长无法插入的报错。其中init_td对于Tuple长度的影响如下：
①表init_td数量为最小值2时，Tuple长度不能超过8192-MAXALIGN(56+2*26+4)=8080B。
②表init_td数量为默认值4时，Tuple长度不能超过8192-MAXALIGN(56+4*26+4)=8024B。
③表init_td数量为最大值128时，Tuple长度不能超过8192-MAXALIGN(56+128*26+4)=4800B。
(4) 索引最大列数不能超过32列。全局分区索引最大列数不能超过31列。
(5) 索引元组长度不能超过(8192-MAXALIGN(28+3*4+3*10)-MAXALIGN(42))/3，其中MAXALIGN表示8字节对齐。当插入数据长度超过阈值时，用户会收到索引元组长度过长无法插入的报错，其中索引页头为28B，行指针为4B，元组CTID+INFO标记位为10B，页尾为42B。
5．功能演进
(1) 本特性自V500R002C00版本开始引入。In-place Update（原地更新）行存储引擎，简称Ustore。相比于Append Update（追加更新）行存储引擎，Ustore存储引擎可以提高数据页面内更新的HOT UPDATE的垃圾回收效率，有效降低多次更新元组后存储空间占用的问题。
(2) Ustore存储引擎采用NUMA-aware的Undo子系统设计，使得Undo子系统可以在多核平台上有效扩展；同时采用多版本索引技术，解决索引清理问题，有效提升了存储空间的回收复用效率。
(3) Ustore存储引擎结合Undo空间，可以实现更高效、更全面的闪回查询和回收站机制，能快速回退人为“误操作”，为GaussDB提供了更丰富的企业级功能。Ustore基于Undo回滚段技术、页面并行回放技术、多版本索引技术、xLog无锁落盘技术等实现了高可用高可靠的行存储引擎。
6．客户价值
(1) 针对OLTP场景，实现Inplace-update，利用Undo实现新旧版本分离存储；降低类似于AStore存储引擎由于频繁更新或闪回功能开启导致的数据页空间膨胀，以及相应引起的索引空间膨胀。
7．关键特性
8．特性约束
(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表。
(10) 数据表与回滚段要同为页式或者段页式。
(11) 数据表与回滚段采用段页式存储方式时，不支持创建PCR索引。
(12) 数据表与回滚段采用段页式存储方式时，不支持基于冷热分离的行存压缩特性。
存储引擎对比
维度 | Ustore | Astore |
ACID | 支持原子性、一致性、隔离性（读已提交，不支持可重复和串行化隔离级别）、持久性 | 支持原子性、一致性、隔离性、持久性 |
闪回 | 有undo功能，更高效、更全面的闪回查询和回收站机制，能快速回退人为“误操作” | 不友好 |
空间膨胀 | 页面原地更新，提高数据页面内更新的HOT UPDATE的垃圾回收效率，有效降低多次更新元组后存储空间占用的问题 | 页面追加更新，导致的数据页空间、索引空间膨胀 |
性能抖动 | 不需要VACUUM，压测时性能抖动2.5% | 需要VACUUM，压测时性能抖动13.8% |
索引 | 默认Ubtree，索引页面增加了事务信息，使得UBtree索引具备MVCC能力以及独立过期旧版本回收能力；支持并行创建索引、索引空间管理算法优化，索引空间进一步压缩； | Btree |
大事务回滚 | 有undo功能、恢复时同步需要Redo和Undo，效率稍低 | 没有undo，旧数据都是记录在原先的文件中，当数据库异常crash后，恢复效率高 |
约束 | 不支持hash索引、GiST索引、SP-GiST索引、BRIN索引。 不支持压缩。 不支持批量访存接口。不支持rowid语义。 不支持创建、使用物化视图。 不支持设置透明数据加密。 |
存储引擎最佳实践
鉴于以上存储引擎的差异对比，已经上线的业务系统建议继续使用Astore，即将上线的业务系统，集中式部署建议用Ustore，分布式继续沿用Astore，待分布式Ustore在其他银行金融业务系统打磨成熟后，再平滑切换至Ustore引擎。对闪回有强诉求的业务系统、空间膨胀、性能抖动要求高的系统，建议使用Ustore存储引擎。
参考资料
