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底层架构）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/kjbd-jg/33123.html