---

前言

昨日受邀参加了 GBASE 技术大会，非常感谢C姐与南大通用的这次邀请。这次大会的内容比较密集。相比单纯讲“国产替代”，这次更多是在讲数据库后续怎么演进。

如果从技术角度看，大概可以分成两条线：

一条是传统数据库核心能力：事务、高可用、迁移、兼容、索引、MVCC、Online DDL。

另一条是新场景能力：HTAP、存算分离、湖仓一体、向量检索、自然语言问数、AI Agent、智能运维。

接下来向大家分享一下在大会中的所闻所感。

---

一、GBase 8s：核心交易系统里的几个关键点

GBase 8s 的定位更偏企业级集中式事务数据库，主要解决核心业务国产化替代的问题。

这类数据库最重要的不是概念，而是生产环境能不能稳。

1.1 Oracle / MySQL 兼容

数据库替代最麻烦的地方不是把数据导过去，而是应用能不能少改。

8s 提到对 Oracle 的兼容包括数据类型、堆表、分区表、临时表、视图、物化视图、索引、触发器、序列、同义词、定时任务、常用系统视图、系统函数、PL/SQL、包、游标、自治事务、异常处理等。

这些都是老系统里最容易卡迁移的地方。

MySQL 兼容这块也提到了数据类型、DML、DQL、索引、存储过程、触发器、系统视图等。对业务系统来说，兼容率越高，SQL 改造量和回归测试压力就越小。

比较完整的迁移链路大概是：

迁移评估-> 元数据迁移-> 全量数据迁移-> 增量同步-> 数据比对-> 并线运行-> 业务割接

这里 MTK 负责迁移评估、结构迁移、数据迁移、数据比对、断点续传等；RTSync 负责全量加增量同步。这个组合比较贴近真实项目，因为生产割接基本不可能只靠一次全量导入完成。

1.2 RPO、RTO 和 TAC

8s 里我比较关注高可用部分。

它提到 RPO=0，受控场景 RTO 小于 3 秒。这里可以简单理解：

RPO=0：
故障发生时数据不丢。

RTO<3s：
故障发生后业务恢复时间控制在秒级。

传统主备切换慢，很多时候不是因为检测故障慢，而是新主上线前要做前滚、回滚。如果遇到大事务，恢复时间会被拉长。

8s 的思路是前滚完成后让新主尽快上线，回滚期间通过多版本机制保证读写可继续进行。

TAC 这块可以理解为应用连续性能力。目标是数据库切换后，应用连接、会话、SQL 执行尽量不受影响。对业务侧来说，最理想的情况就是只感知到一次短暂延迟，而不是连接断开、事务状态丢失、应用报错。

1.3 内存化 MVCC

MVCC 是数据库并发控制里很核心的部分。

传统实现里，历史版本一般依赖 undo log 或者 in-place 多版本。问题也比较明显：

undo log：
历史版本读取可能带来额外 IO。

in-place：
历史版本和数据行共存，容易造成膨胀和清理压力。

8s 提到内存化 MVCC，我理解它的核心思路是：大部分 OLTP 事务生命周期很短，版本数据本质上是运行态数据，不一定都要落到磁盘上长期维护。

这样做的好处是：

• 减少历史版本读取 IO
• 降低磁盘膨胀
• 减少清理抖动
• 提升高并发事务场景稳定性

当然，这个能力真正要看长事务、大事务、高并发混合场景下的表现。但方向上是合理的，因为很多 TP 场景瓶颈确实不只是 SQL 本身，而是版本维护、日志、锁等待、IO 抖动叠加出来的。

1.4 HK-Tree 索引

HK-Tree 这个点我觉得比较有意思。

传统 B+Tree 对高选择性字段比较合适，但对低基数字段不一定划算，比如状态、类型、地区、性别这种字段。重复 key 多，索引存储效率低，回表也可能很重。

传统位图索引适合低基数字段分析，但 DML 并发能力弱，不太适合高频更新场景。

HK-Tree 主要想解决低基数字段上的读写平衡问题：

低基数字段：
减少重复 key 带来的存储浪费。

宽表多条件查询：
比普通 B+Tree 更适合多列组合过滤。

聚合分析：
对 group by、count、distinct 这类查询更友好。

事务场景：
相比传统位图索引，更强调 DML 和 MVCC 支持。

这个能力如果放在 HTAP 场景里看就更有意义，因为 HTAP 不只是查得快，还要能在有更新的情况下继续查得稳定。

二、GBase 8c：分布式、HTAP 和 AI 原生

GBase 8c 的技术路线更偏新一代数据库形态。

它同时讲了主备、分布式、存算分离，多模数据，行存、列存、行列混存，还有向量检索和 AI Agent。

2.1 多部署形态

8c 支持几种部署方式：

主备形态：
适合数据量相对可控、追求简单交付和高可用的场景。

分布式形态：
适合大数据量、高并发、需要水平扩展的场景。

存算分离形态：
适合资源波动明显、需要弹性扩缩容和降低成本的场景。

存算分离里，计算节点尽量无状态，数据持久化放到存储层。扩缩容时不需要大规模搬迁数据，这对云原生和 AI 场景比较重要。

AI 任务有个特点：负载波动很明显。训练、推理、实验、空闲状态之间资源需求差异很大。如果计算和存储强绑定，资源利用率就会比较差。

2.2 HTAP：行存、列存和行列混存

8c 里一个重点是 HTAP。

传统架构通常是：

OLTP 业务库
   |
CDC / ETL
   |
OLAP 数仓

这个架构成熟，但问题是链路长、延迟高、组件多。一旦要做实时分析，复杂度会明显上升。

8c 讲的行列融合，大概是：

行存：
服务 OLTP，适合点查、插入、更新、高并发事务。

列存：
服务 OLAP，适合宽表扫描、聚合、压缩。

Delta / 行转列：
更新先进入行存或增量区，再异步转成列存单元。

优化器：
根据 SQL 类型、访问列、过滤条件选择行存或列存路径。

也就是说，一份数据可以同时支撑交易和分析。

我理解这里关键不只是“有行存和列存”，而是优化器、事务可见性、数据同步机制要打通。否则只是两个存储引擎拼在一起，实际使用时还是会有一致性和延迟问题。

2.3 向量标量融合检索

AI 应用里，单独的向量检索是不够的。

很多查询会长这样：

SELECT doc_id, title
FROM documents
WHERE tenant_id = 1001
  AND industry = 'finance'
  AND publish_time >= '2026-01-01'
ORDER BY vector_distance(embedding, :query_vector)
FETCH APPROX FIRST 10 ROWS ONLY;

这里同时包含：

租户隔离、结构化过滤、时间范围过滤、向量相似度排序、TopK 返回

如果关系库和向量库分开，就会出现几个问题：

数据要同步两份
权限控制要做两遍
结果一致性不好保证
复杂 Join 很难处理
运维链路变长

8c 的向量标量融合检索，本质上是把向量检索纳入 SQL、优化器和执行引擎里。这样业务可以继续用 SQL 表达复杂条件，而不是在应用层手动拼多个系统的结果。

这个能力对 RAG、语义搜索、推荐系统、智能客服都比较关键。

2.4 基于 WAL 的数据分支

8c 里还有一个数据分支能力。

它的思路类似 Git 分支，但对象是数据库数据。

创建分支：
记录当前 WAL 位置，不复制全量数据。

读取历史数据：
分支和主库共享历史页面。

写入新数据：
使用 Copy-on-Write，只复制被修改的页面。

回滚或丢弃：
直接丢弃分支元数据和增量修改。

这个能力对 AI 实验和测试场景很有用。

以前要做一套测试数据，可能需要：

备份生产库
-> 脱敏
-> 恢复到测试环境
-> 同步增量
-> 控制权限

如果数据库支持秒级分支，就可以快速创建实验环境。模型训练、A/B 测试、数据分析、问题复现都会方便很多。

三、GBase 8a：数仓、湖仓一体和 DataAgent

GBase 8a 更偏分析型数据库和数仓体系。

这次讲的重点已经不只是 MPP 数仓，而是云数仓、湖仓一体和 Data + AI。

3.1 存算分离

传统 MPP 数仓里，计算和存储通常绑定比较紧。扩容时可能涉及节点增加、数据重分布、任务调度调整。

8a 云数仓 GCDW 提到元数据、数据、计算解耦：

计算层：
负责 SQL 执行，可弹性扩缩容。

存储层：
负责数据持久化，可使用对象存储。

元数据层：
通过 Catalog 统一管理表、分区、权限、格式。

这样做的优势是资源利用率更高。计算资源可以按任务弹性申请，空闲时释放；存储可以独立扩容，不需要跟计算节点强绑定。

3.2 湖仓一体

湖仓一体的核心不是换个名字，而是解决湖和仓割裂的问题。

以前常见情况是：

数据湖：
存放原始数据、半结构化数据、非结构化数据，成本低，但治理弱。

数据仓库：
结构清晰，查询性能好，但成本高，灵活性差。

湖仓一体希望做到：

• 统一 Catalog
• 统一 SQL 入口
• 统一权限
• 统一元数据
• 一份数据多引擎共享
• 减少 ETL 和重复存储

8a 里提到支持访问 HDFS / S3 上的 Parquet、ORC 等开放格式，这说明它在往开放数据架构靠。

3.3 列存事务

列存数据库通常适合分析，不适合频繁事务更新。但企业数仓里也会有轻量事务需求，比如管理会计、CRM、日志修正、指标维护等。

8a 提到在列存上增强事务能力，包括 GTM、ROWINFO、REDOLOG、TRANSLOG、CLOG 等机制。

大概可以这样理解：

GTM：
生成事务 ID，维护事务状态和可见性。

ROWINFO：
保存 MVCC 多版本可见性信息。

REDOLOG：
保证故障恢复。

CLOG：
记录事务提交状态。

行级锁：
支持一定并发更新。

这个方向不是要让列存数据库变成强 OLTP，而是让分析系统具备更好的数据修正和轻量事务能力。

3.4. DataAgent

DataAgent 是 8a 里和 AI 结合比较明显的一块。

自然语言问数看起来像 NL2SQL，但真正难点不是 SQL 生成，而是语义正确。

比如业务人员问：

上个月华东区高价值客户的逾期风险怎么样？

这里至少包含几个隐含概念：

上个月怎么算？
华东区对应哪些组织？
高价值客户定义是什么？
逾期风险来自哪些指标？
权限是否允许查看？
结果是否需要脱敏？

所以 DataAgent 背后必须有语义层：

业务语义：
客户、订单、区域、产品、风险等业务概念。

指标语义：
收入、活跃、逾期率、转化率等指标口径。

数据语义：
表、字段、关联关系、血缘关系。

权限审计：
用户能查什么，生成了什么 SQL，返回了什么结果。

没有语义层，AI 很容易“看起来回答了，实际答错了”。

所以 DataAgent 真正拼的不是模型本身，而是数据治理、指标体系和权限体系。

四、openGauss

openGauss 是我最早接触的国产数据库，这次也听到了 openGauss 生态相关内容。

我比较关注几个技术点：

DataVec：
向量检索能力，把向量查询和 SQL 查询结合起来。

Data Branching：
数据库分支能力，服务开发测试和 AI 实验。

oGMemory：
面向 AI Agent 的长期记忆系统。

AI Pipeline：
让向量化、检索、RAG 等流程尽量在库内完成。

oGRAC：
多写数据库方向，强调共享存储、多节点读写和高可用。

这里面比较值得注意的是 AI Pipeline。

传统 RAG 链路一般是：

业务库
-> ETL
-> Python 脚本向量化
-> 向量库
-> 应用层召回
-> 拼 Prompt
-> LLM

链路长，而且数据会在多个系统之间流转。

如果数据库内置向量化、混合检索、AI Function，那么链路可以变成：

业务数据
-> 库内向量化
-> SQL 混合检索
-> RAG 返回

这样可以减少数据冗余，也更利于权限控制和审计。

---

总结

这次听下来，可以感觉到 GBASE 的几个产品线技术方向是比较清晰的。

GBase 8s 重点是核心交易系统，技术关键词是兼容、迁移、高可用、TAC、内存化 MVCC、HK-Tree、Online DDL。

GBase 8c 重点是新一代分布式和 AI 原生，技术关键词是 HTAP、行列混存、向量标量融合检索、存算分离、数据分支。

GBase 8a 重点是分析型场景，技术关键词是云数仓、湖仓一体、Catalog、列存事务、DataAgent。

这次大会给我的感觉是，国产数据库的发展重点已经从“能不能替”逐渐走向“替完之后能不能支撑新业务”。

以前看数据库，更多关注事务、日志、索引、锁、备份恢复这些传统能力。现在再看数据库，还要看它能不能支撑 HTAP、湖仓一体、向量检索、自然语言问数、AI Agent 和智能运维。

但这些新能力不是空中楼阁，最终还是要建立在稳定的数据库内核、高可用架构、成熟迁移工具和完善运维体系之上。

所以后面真正有竞争力的数据库，不会只是某一个单点能力强，而是能把交易、分析、AI、运维、安全和生态这些能力组合起来，并且在真实业务里稳定跑起来。