Ustore 在 openGauss 闪亮登场,重构 openGauss 数据存储的灵魂
9 月 30 日,openGauss 正式推出重大内核新特性——Ustore 存储引擎,为企业级用户提供更高性能的数据库服务,进一步为企业数字化转型注入新动力。同时,也将与众多的数据库内核开发者一道继续探索数据库的理论前沿与最佳实践。
Ustore 存储引擎,又名 In-place Update 存储引擎(原地更新),是 openGauss 内核新增的一种存储模式。openGauss 内核此前的版本使用的行存储引擎是 Append Update(追加更新)模式。追加更新对于业务中的增、删以及 HOT(HeapOnly Tuple) Update(即同一页面内更新)有很好的表现,但对于跨数据页面的非 HOT UPDATE 场景,垃圾回收不够高效,因此,Ustore 存储引擎应运而生。
Ustore 存储引擎设计原理
Ustore 存储引擎将最新版本的“有效数据”和历史版本的“垃圾数据”分离存储。将最新版本的“有效数据”存储在数据页面上,并单独开辟一段 UNDO 空间,用于统一管理历史版本的“垃圾数据”,因此数据空间不会由于频繁更新而膨胀,“垃圾数据”集中回收效率更高。Ustore 存储引擎采用 NUMA-Aware 的 UNDO 子系统设计,使得 UNDO 子系统可以在多核平台上有效扩展;同时采用多版本索引技术,解决索引清理问题,有效提升了存储空间的回收复用效率。
Ustore 存储引擎结合 UNDO 空间,可以实现更高效、更全面的闪回查询和回收站机制,能快速回退人为“误操作”,为 openGauss 提供了更丰富的企业级功能。
Ustore 存储引擎核心优势
高性能:对插入、更新、删除等不同负载的业务,性能以及资源使用表现相对均衡。更新操作采用原地更新模式在频繁更新类的业务场景下可拥有更高、更平稳的性能表现。适应“短”(事务短)、“频”(更新操作频繁)、“快”(性能要求高)的典型 OLTP 类业务场景。
高效存储:支持最大限度的原位更新, 极大节约了空间;将回滚段、数据页面分离存储,具备更高效、平稳的 IO 使用能力,UNDO 子系统采用 NUMA-ware 设计,具有更好的多核扩展性,UNDO 空间统一分配,集中回收,复用效率更高,存储空间使用更加高效、平稳。
细粒度资源控制:Ustore 引擎提供多维度的事务“监管”方式,可基于事务运行时长、单事务使用 UNDO 空间大小、以及整体 UNDO 空间限制等方式对事务运行进行“监管”,防止异常、非预期内的行为出现,方便数据库管理员对数据库系统资源使用进行规范和约束。
Ustore 存储引擎可以在数据频繁更新场景下性能依旧稳如泰山,使业务系统运行更加平稳,适应更多业务场景和工作负载,特别是对性能和稳定性有更高要求的金融核心业务场景。
技术无止境,未来 openGauss 将结合 AI 自治技术,对 Ustore 存储引擎进行更智能、更安全、更高效的技术优化,为客户打造更领先、更优质的数据库服务。
USTORE 存储引擎使用指导
引言
USTORE 与原有的 ASTORE(Append Update)存储引擎并存。USTORE 存储引擎屏蔽了存储层实现的细节,SQL 语法和原有的 ASTORE 存储引擎使用基本保持一致,唯一差别是建表和建索引有些细微区别。
创建表的方式
USTORE 存储引擎含有 undo log,创建 USTORE 存储引擎表的时候需要提前在 postgresql.conf 中配置 undo_zone_count 的值,该参数代表的时候 undo log 的一种资源个数,建议配置为 16384,即“undo_zone_count=16384”,配置完成后要重启数据库。
[postgresql.conf 配置]
创建方式 1:创建表时指定存储引擎类型
创建方式 2:GUC 参数配置指定 USTORE 存储引擎
步骤 1:数据库启动之前,在 postgresql.conf 中设置“enable_default_ustore_table=on”,默认指定用户创建表时使用 USTORE 存储引擎。
[postgresql.conf 配置]
步骤 2:创建表
创建索引的方式
USTORE 存储引擎使用的索引为 UBtree, UBtree 是专门给 USTORE 存储引擎开发的索引,也是该引擎目前唯一支持的索引类型。
假定有如下 test 表结构,计划在 test 表的 age 列上增加一个 UBtree 索引
创建方式 1:不指定创建索引类型,默认创建 UBtree 索引
创建方式 2:创建索引时使用 using 关键字指定索引类型为“ubtree”
评论