GaussDB技术解读——GaussDB架构介绍（二）

最新推荐文章于 2025-06-24 12:06:57 发布

原创

最新推荐文章于 2025-06-24 12:06:57 发布 · 2.8k 阅读

56 ·

CC 4.0 BY-SA版权

文章标签：

#gaussdb #架构 #数据库 #SQL #sql #oracle

上篇图文，从GaussDB关键架构目标、GaussDB分布式架构、数据计算路由层（Coordinator）关键技术方案等三方面对GaussDB架构进行了介绍。本篇将从数据持久化存取层(DataNode)关键技术方案、全局事务管理层（GTM）关键技术方案、集群管理层（CM）关键技术方案、OM运维管理关键技术方案等方面继续解读GaussDB架构。

4 数据持久化存取层(DataNode)关键技术方案

4 数据持久化存取层(DataNode)关键技术方案

Datanode节点主要负责数据的持久化和快速写入、读取。数据持久化采用物理日志wal，事务提交wal刷盘，对外提供逻辑日志功能，反解析物理日志为SQL逻辑日志。

图1 datanode数据持久化

Astore：存储格式为追加写优化设计，其多版本元组采用新、老版本混合存储方式。当一个更新操作将老版本元组更新为新版本元组之后，如果老版本元组所在页面仍然有空闲空间，则直接在该页面内插入更新后的新版本元组，并在老版本元组中记录指向新版本元组地址的指针。在这个过程中，新版本元组以追加写的方式和被更新的老版本元组混合存放，这样可以减少更新操作的IO开销。然而，需要指出的是，由于新、老版本元组是混合存放的，因此在清理老版本元组时需要从混杂的数据中挑出垃圾数据，清理开销会比较大。同时，由于新版本元组位置相对老版本元组位置发生了变化，而索引中只记录了老版本元组的位置，因此容易导致索引膨胀。为了缓解索引膨胀这个问题，对于同一个页面内的更新，采用了HOT技术，将同一个记录的多个版本按从老至新的更新顺序给串连起来，但是这种从老至新的更新链顺序，对于并发的OLTP类短查询是效率是比较低，需要遍历的版本个数较多。

Ustore：与astore相比，ustore的最大特点在于新、老版本记录的分离存储。当一个更新操作将老版本元组更新为新版本元组之后，直接在老版本元组的位置覆写新版本元组内容，同时，将老版本元组移到统一管理历史版本的undo区域。在这个过程中，既需要修改数据页面，也需要修改undo页面，更新操作开销较astore的追加更新稍大。但是，就如同垃圾分类回收一样，这样带来的好处也是显而易见的，在清理老版本元组时，不再需要遍历扫描主表数据，直接按需回收undo区域即可，垃圾清理开销较astore不仅大幅降低，而且稳定可控。同时，由于新版本元组复用老版本元组的物理位置，因此索引无需更新，索引膨胀得到有效控制。另外，在ustore中，多个版本的更新链按从新至老的顺序串连，对于并发查询更友好。总而言之，ustore更适合更新频繁的业务场景。

5 全局事务管理层（GTM）关键技术方案

GTM 仅处理全局时间戳请求， 64位CSN递增，几乎都是CPU ++和消息收发操作。不是每次都写ETCD, 而是采用定期持久化到ETCD 里，每次写ETCD的CSN要加上一个backup_step (100w), 一旦GTM故障，CSN从ETCD读取出来的值保证单调递增。当前GTM 只完成CSN++, 预估可以支持200M/s 请求。GTM处理获取csn消息和csn++的消息, TCP 协议栈消耗CPU会非常严重，采用用户态协议栈提高GTM单节点的处理能力。未来架构演进完全去中心化，采用高精度时钟解决扩展性问题。