AI原生数据库与seekdb基础学习笔记

发布于 2026年9月8日

学习资料：OceanBase《2026 从 0 到 1 数据库实践教程》第一讲
主讲人：王泽林（OceanBase 开源研发专家）
记录日期：2026 年 9 月 6 日

1. AI 时代为什么仍然需要数据库

Agent 的能力除了来自模型本身，还依赖它能否获得准确、完整且及时的数据。课程从 RAG、Memory、Skill 和 MCP 几个方面解释了数据层的作用：

• RAG：知识库的数据质量、检索策略和召回效果会影响回答质量。
• Memory：需要从历史信息中提炼记忆，并在合适的时候准确取回。
• Skill：需要将经验或能力结构化，便于后续检索与使用。
• MCP：通过标准化接口连接外部数据和工具。

我的理解是，模型负责理解和推理，数据系统则负责把信息保存好、组织好，并在需要时提供出来。Agent 的效果因此也受到数据组织与访问方式的影响。

如果关系数据、文本和向量分别存储在不同系统中，应用就需要维护多套接口，以及系统之间的数据同步与一致性。seekdb 将这些能力集中到统一数据层中，为 Agent 提供存储、检索和数据操作能力。

seekdb 的定位

课程将 seekdb 定位为 Agent 的运行底座。它从 OceanBase 的能力基础出发，面向轻量化、单机和 AI 应用场景发展。

在持续写入场景中，写入路径与索引构建路径被拆开：事务提交和 Redo Log 之后，通过异步 Change Stream 处理索引更新；查询同时访问增量的 Delta HNSW 和主存储的 Snapshot HNSW。这种设计希望减少索引构建对写入和查询的相互影响。

这里需要区分两件事：Embedding 是将内容转换为向量，向量索引维护是组织已有向量以支持高效查询。图中主要展示的是后者，具体的数据可见性与同步机制还需要结合实现进一步理解。

2. seekdb 的核心特征与整体架构

2.1 核心特征

轻量化涉及功能取舍和内部结构调整。课程介绍的思路包括裁剪非核心功能、清理依赖、减少冗余线程和内存占用，以及继续优化、重构模块。

2.2 从应用接口到存储引擎

可以沿着“请求从哪里来、如何执行、数据放在哪里”理解整体架构：

这张图把 AI 能力与传统数据库模块联系了起来：混合检索和 AI 函数位于上层，但依然需要索引、事务和存储能力支撑。对于后续源码学习，可以选一条 SQL，顺着接入、解析、执行和存储逐层跟踪。

另外，架构图中的模型端点位于数据库外部。课程中的“数据库内 AI”指数据库提供统一的模型调用能力，实际推理由外部模型服务完成。

2.3 LSM-Tree：写入、后台整理与读取

背景补充：这一节结合官方文档补充存储基础，再回到课程架构图。下文的分数更新是用于理解原理的简化例子。

（1）先理解数据库要解决的存储问题

执行 UPDATE 时，SQL 描述的是“哪一行要改成什么”，存储引擎需要决定这些修改在内存和磁盘中如何保存。

顺序写入是连续追加一批内容；随机写入则需要修改分散位置的数据。对存储系统来说，将零散修改组织成批量写入通常更容易提高效率，具体收益取决于硬件和负载。

LSM-Tree（Log-Structured Merge-Tree）利用了这个思路：先在内存中接收修改，再将数据成批写入磁盘，之后逐步整理。 它并不意味着写入时完全不访问磁盘，因为还需要日志保证故障后的恢复。

（2）三个基本角色：MemTable、SSTable 和日志

“按键有序”可以先理解为按主键排列，例如 id=1、2、3……，这样便于查找和归并。实际数据库还需要组织版本信息及其他元数据。OceanBase 将内存中的可变数据与磁盘上的只读数据分别放在 MemTable 和 SSTable 中。参考：OceanBase 存储架构概述

一个容易混淆的问题是：既然修改先放内存，突然断电怎么办？

这就是日志的作用。在要求持久性的提交路径中，需要让相应日志满足持久化要求，之后即使内存丢失，也能利用日志恢复。追加日志通常比每次都立即重写已有数据文件更容易组织成高效写入。WAL（预写日志）是常见的相关机制；课程图中的 Redo Log 承担恢复职责，具体记录格式和提交时序需看实现。参考：RocksDB 的 WAL 说明

因此，“事务已提交”与“数据已转储成 SSTable”是两件事。日志负责恢复所需的信息，MemTable 和 SSTable 则是日常数据组织与查询的重要结构。

（3）写入：修改先成为新的增量

假设有一条学生记录，主键 id=1，分数最初是 80，随后依次改成 90 和 95。为了说明数据版本，先把每次修改理解为一条带版本号的记录：

即使 v1 已经在磁盘上，v2 也可以先进入 MemTable，配合日志完成写入处理，暂时不必原地修改包含 v1 的 SSTable。这里的“增量”表示后续产生的变更；这个例子用新分数表达它，不应将增量简单理解成只保存 +10。

课程里的 DML 指 INSERT、UPDATE、DELETE 等数据修改操作。删除也可以先写入删除标记，表示这条记录在对应版本之后已被删除，之后再按规则整理旧数据。

（4）后台整理：内存不能一直增长，磁盘文件也不能一直堆积

MemTable 达到一定条件后，需要把其中的数据写入磁盘。为了让新请求继续写入，通常会将当前 MemTable 冻结，停止接收新的修改，由新的 Active MemTable 接手；冻结后的数据仍可参与读取。

可以把这段流程记成：

正在接收写入的 Active MemTable
                ↓ 冻结
不再接收新写入的 Frozen MemTable
                ↓ 转储
磁盘上的 SSTable

新写入由新的 Active MemTable 继续接收

转储（Flush）解决“内存里的数据如何成批落到磁盘”的问题。**归并整理（Compaction）**则解决“磁盘上的多份数据如何重新组织”的问题。

如果每次转储都产生一份 SSTable，文件会逐渐增多，同一个键的不同版本也可能散落在不同文件中。Compaction 会读取若干份有序数据，按键与版本规则归并，生成新的 SSTable；在满足版本保留要求时，才能清理不再需要的旧版本或删除标记。它不是把几个文件直接拼接起来，也不只是压缩文件体积。参考：OceanBase 转储和合并概述

对应课程图，先掌握各步骤的作用即可：

这些名称是课程中 OceanBase / seekdb 架构的划分，不是所有 LSM-Tree 系统都使用同样的层次和术语。

（5）读取：在多个来源中找到“当前可见”的版本

假设前面的例子现在变成：

查询 id=1 时，仅看某一份磁盘文件就可能漏掉更新。因此读取需要综合相关 MemTable 和 SSTable 中的信息。但“综合”并不代表每次查询都完整扫描所有文件，实际实现会利用索引、缓存等机制缩小读取范围。

接下来还要回答：应该返回 80、90 还是 95？这里就涉及 MVCC（多版本并发控制）。

MVCC 允许同一行保留多个版本，按事务的可见性规则选择结果。以已经提交的 v1、v2、v3 为例：

• 一个快照位于 v2 提交之后、v3 提交之前的读取，应看到 90。
• 一个快照位于 v3 提交之后的读取，可以看到 95。

这里的快照是逻辑上的可见时间点，不是每次查询都复制整份数据库；具体快照何时确定，还取决于事务隔离级别。旧版本可能仍被旧快照使用，所以不能一有新版本就全部删除。快照与版本保留的关系也体现在 LSM 系统的 Compaction 设计中。参考：RocksDB 快照与 Compaction 概述

图中的 “MVCC + 多路归并” 可以这样理解：从多个有序数据来源中整理出候选版本，再依据可见性规则得到查询结果。读取时的归并形成的是结果；后台 Compaction 的归并则会生成新的持久数据结构。

（6）回到课程架构图

现在可以按三条线阅读这张图：

1. 最上面是写入线：DML 产生修改，Redo Log 支持恢复，Active MemTable 保存内存中的增量。
2. 中间是整理线：冻结、转储、归并逐步把内存增量和磁盘数据整理成新的 SSTable。
3. 最下面是读取线：按事务快照访问内存与磁盘数据，通过版本判断和归并得到可见结果。

LSM-Tree 的设计取舍是将一部分整理工作放到后台，使前台写入更容易批量处理；相应代价是读取可能需要访问多个来源，后台归并也会消耗 CPU、磁盘带宽并重复写入数据。接下来再学习读放大、写放大以及 Compaction 调度，就能把这些机制与性能问题联系起来。

3. 混合检索与数据库内 AI

3.1 多模数据与混合检索

seekdb 在统一数据库中管理关系数据、向量、文本、JSON 和 GIS 数据。混合检索将其中不同的检索方式组合起来，使一个问题能够同时利用语义、关键词和结构化条件。

课程中的检索流程是：

用户问题 → 向量召回与全文召回 → 加权融合 / RRF → 可选重排 → 最终 Top-K。

• 向量召回：先生成查询向量，再通过向量索引找到语义接近的内容。
• 全文召回：通过全文索引和 BM25 等方法保留关键词匹配信号。
• 条件过滤：结合标量或 JSON 字段表达租户、权限、时间、状态等约束。
• 结果融合：将不同通道的候选结果统一排序。
• 重排：可进一步调用外部模型调整候选顺序，也可以不经过重排直接返回结果。

我的理解是，混合检索的价值在于综合不同检索方式提供的信号。是否加入重排，需要结合效果和开销判断。后续实验应使用固定的问题与证据，对比纯向量、纯全文、混合检索和加入重排后的结果，同时记录命中情况与耗时。

3.2 三类 AI SQL 函数

数据库维护逻辑模型与模型端点。端点包含服务地址、提供方、访问凭据、实际模型名和调用参数；AI SQL 函数通过逻辑模型找到相应端点，再调用外部服务。

这部分需要同时理解使用方式和内部执行过程：一条包含 AI 函数的 SQL 如何进入执行流程、怎样找到模型配置、如何发起请求并接收结果。讲师在 17:29–17:43 特别提到，本届比赛有与数据库内 AI 函数编写相关的内容。

4. Fork / Diff / Merge：Agent 的数据试验流程

Agent 在执行任务时可能需要反复尝试。如果直接修改主数据，错误操作就可能影响原始状态。课程介绍的 Fork / Diff / Merge 为这类尝试提供了数据分支和结果采纳机制。

1. Fork：从主数据创建分支，形成可供 Agent 操作的沙箱。COW（写时复制）分支共享初始数据页。
2. Diff：查看新增、删除、修改及冲突，判断试验产生了哪些变化。
3. Merge：在决定采纳结果后，将变更合入主数据；不采纳时可以丢弃沙箱。

合并时有三种冲突处理策略：

这组能力将“尝试修改”和“正式采纳”分成两个步骤，适合 Agent 的多步试验与重试场景。后续可以用主表与沙箱同时修改同一行的例子，观察三种策略的具体结果。

5. 轻量化与性能指标

5.1 资源占用

课程在 19:14 展示了以下轻量化指标：

讲师口述还提到，内存稳定低于 250 MB，多数时间低于 200 MB。理解这类指标时，需要保留构建方式、空载状态和测试环境等条件。

5.2 持续写入时的查询性能

性能测试页给出的条件是 Cohere 768 维、持续写入 500 行/秒、16 vCPU / 64 GiB。以下 QPS 指查询吞吐量：

后续压力测试页对比了 seekdb、Elasticsearch 和 Milvus，重点观察并发写入下的尾延迟变化。对我而言，这部分更值得关注的是评测方法：除了吞吐量，还要一起观察 P99、召回率和持续写入带来的影响。

以上数据均来自课程展示，本次尚未复现实验，也不能将其直接作为比赛的评分要求。

6. 应用场景

课程将 seekdb 的典型应用归纳为四类：

这几类应用与前面的技术能力能够对应起来：混合检索服务于知识获取，AI 函数连接模型处理，数据分支支持试验，轻量化和嵌入式形态则拓展了部署场景。

7. 比赛相关记录

7.1 初赛题目结构

课程最后给出的初赛安排为 30 道题、总分 620 分：

seekdb 方向关注功能正确性、检索效果、系统性能、工程质量与创新应用。PowerContext 方向还关注上下文相关性、任务效果、推理成本与可解释性，涉及长短期记忆、冗余和冲突处理、上下文压缩与预算控制等问题。

7.2 对备赛方向的理解

讲师在 25:13–25:42 提到，seekdb 的题目基本以内核为主，难度从简到难，包含 AI 能力体验、已有功能增强、性能优化和新功能编写。前面介绍的 AI SQL 函数、Fork / Diff / Merge 等能力也与赛题相关。

因此，准备 seekdb 方向需要把应用使用与底层实现联系起来。一个 RAG 示例可以帮助理解数据如何入库、检索和参与生成，但还需要继续学习 SQL 执行链路、C++ 编译调试、正确性测试与性能分析。

课程也解释了从 MiniOB 转向 seekdb 的考虑：seekdb 的 AI 能力更强，更贴近真实业务需求；MiniOB 仍然适合数据库教学与实验。我的学习重点可以放在 seekdb 的使用与实现上，遇到内核基础问题时再结合 MiniOB 补充理解。

7.3 培训与资料

• 讲师介绍培训大约包含五讲 seekdb、三讲 PowerContext。
• 比赛鼓励使用 Agent 辅助开发，并会提供 Token 额度、技术资源和平台支持等。
• 讲师提到语雀上的比赛资料，便于提供给 Agent 使用；本视频没有给出完整链接。
• 课件中的钉钉交流群号为 35326455。

仍需通过后续题面确认的内容包括：必做与选做规则、是否可以跨方向选题、每题分值、参考分支、提交方式和评测环境。当前的题目数量与方向介绍还不足以确定具体选题方案。