openGauss行存储引擎采用Ustore原地更新引擎(in-place update)设计，支持 MVCC(Multi- Version Concurrency Control，多版本并发控制)，同时支持本地存储和存储与计算分离的部署方式。行存储引擎的特点是支持高并发读写，时延小，适合 OLTP交易类业务场景。
openGauss的行存储引擎在设计上支持 MVCC，采用集中式垃圾版本回收机制，可以提供 OLTP业务系统的高并发读写要求，支持存储、计算分离架构，存储层异步回放日志。行存储引擎架构如图1所示。
图1 行存储引擎架构
图注:
数据页面缓存池中缓存数据页面,在数据页面中存放组以及组的历史版本并集中管理,使用 Vacuum(垃圾清理)线程进行定期的空间回收。
行存储引擎的关键技术有:
- 基于事务ID以及ctid(行号)的多版本管理。
- 基于 CSN(CommitSequenceNumber，待提交事务的序列号，它是一个64位递增无符号数)的多版本可见性判断以及 MVCC机制。页面，在数据页面中存放组以及组的历史版本并集中管理，使用Vacuum(垃圾清理)线程进行定期的空间回收。
- 基于大内存设计的缓冲区管理。
- 平滑无性能波动的增量检查点(checkpoint)。
- 基于并行回放的快速故障实例恢复。
主要模块如图2所示。
图2 行存储主要模块
行存储的组结构以及页面组织，是行存储 DML实现、可见性判断以及行存储各种功能与管理机制的基石。
由于行存储是基于磁盘的存储引擎，因此存储格式的设计遵从段页式设计，存储结构需要以页面(page)为单位，方便与操作系统内核以及文件系统的接口进行交互。也是由于这个原因，页面的大小需要和目标系统中一个 block(块)的大小对齐。在比较通用的 Linux内核中，页面大小一般默认为8192字节(8KB)。一个基本的 Heap (堆)页面如图3所示。
图3 Heap页面示意图
页面开头的位置为整个页面的头部信息，记录了这个页面的公用信息以及一些关键标识。line_pointer被 放 置 于 Header后 面，并 向 页 面 尾 部 扩 展。line_pointer为 指 向Tuple实际数据的一个指针，类似于行指针(sentinel)的作用。
这里需要一提的是，每个 Tuple在系统中的唯一标识ItemPointer，也被称为ctid，
今天的文章 goldendb数据库架构（goldendb底层架构）分享到此就结束了，感谢您的阅读。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/bian-cheng-ri-ji/42172.html