深度拆解seekdb：AI Native Database 的技术架构与核心能力

"Future users of large data banks must be protected from having to know how the data is organized in the machine."

"宜使后来之人，得其用，而不必知其藏。"

------ E. F. Codd，《A Relational Model of Data for Large Shared Data Banks》 $1$ ，1970

AI 时代，正在把数据库从"持久化结果"的基础设施，推向"参与检索、推理与试验过程"的数据底座。

应用既要保存结构化业务状态，也要管理向量、文本、JSON 与空间数据；既要精确查询，也要完成语义召回、关键词召回、过滤、融合和重排；Agent 还需要安全地试写、比较和选择性采纳结果。

如果让这些能力分散在多个系统中，应用通常需要承担数据同步、事务一致性、权限管理、故障处理与运维编排的额外复杂度，而 AI Native DataBase ------ seekdb 的到来，就是为了解决这道难题。

欢迎大家关注 OceanBase 社区公众号 "老纪的技术唠嗑局"。在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~

1. seekdb 概述

seekdb $2$ 是一款 MySQL 高度兼容、AI 原生且轻量的跨平台数据库，支持嵌入式与服务器两种运行形态。

它以 Agent 为核心设计场景，同时适用于 RAG、企业知识检索、智能应用后端与本地数据处理等场景。

seekdb 将关系数据管理、向量检索、全文检索、半结构化与空间数据处理、数据库内 AI 调用，以及面向 Agent 的 Fork/Diff/Merge 数据工作流放入同一个数据库内核。应用既可以采用服务器模式，通过 MySQL 协议和 SQL 接入，也可以采用嵌入式，将 seekdb 随应用部署（相关实现与版本信息可在 seekdb GitHub $3$ 开源仓库中查看，其他产品信息详见：seekdb V1.4.0 产品概览 $4$ ）。

2. 整体技术架构

seekdb 采用统一数据库内核，将 SQL 处理、AI 与检索、数据与索引、事务、日志和持久化存储组织在同一体系中。

关系、向量、文本、JSON 与 GIS 数据共享事务和查询执行框架，上层可通过 SQL、MySQL 协议或多语言 SDK 使用这些能力。

2.1 分层架构

架构自上而下分为六个层次：

应用与工具层：承载 Agent、RAG、智能业务应用、运维工具及既有 MySQL 应用。
统一接入层：提供 MySQL 协议、SQL、常见语言驱动，以及面向 Python、JavaScript 等语言的 SDK。
查询与 AI 层：完成 SQL 解析、优化与执行，组织标量查询、向量查询、全文查询、混合检索及 AI 函数调用，并提供 Fork/Diff/Merge 数据工作流。
数据与索引层：统一管理关系、向量、文本、JSON、GIS 数据，以及 B-Tree、全文和向量等索引结构。
事务与日志层：提供 ACID 事务、MVCC 并发控制、Redo Log 与故障恢复，为一致性读写和数据分支提供事务基础。
LSM-Tree 存储层：管理 MemTable、SSTable、冻结、转储、后台 Compaction、缓存和持久化空间，并为 COW 数据分支提供存储基础。

2.2 LSM-Tree 存储架构

seekdb 的持久化存储采用 LSM-Tree 架构，将数据组织为内存中的可读写增量层 MemTable 和磁盘上的不可变 SSTable。INSERT、UPDATE 和 DELETE 在 MemTable 中形成增量版本，事务变更通过 Redo Log 获得持久化保障；因此，已提交数据在尚未转储为 SSTable 时仍可通过日志恢复。

数据从事务写入、日志持久化到后台 Compaction，以及快照读取的关系如下：

MemTable 冻结后，Mini Compaction 将其转储为 SSTable；Minor Compaction 进一步归并多个增量 SSTable；Medium/Major Compaction 将增量数据与既有基线整合为新的基线 SSTable。

查询根据事务快照同时读取相关的 MemTable 与 SSTable，由 MVCC 和多路归并选择当前事务可见的版本，对 SQL 层呈现一张统一的逻辑表。这种"前台事务写入、后台数据整理"的方式避免在写入关键路径中原地改写磁盘数据页；后台 Compaction 则持续控制 SSTable 数量、读取放大和空间占用。

3. 数据库基础能力

AI 与检索能力建立在通用数据库基础之上。seekdb 不是把若干检索组件简单包装成 API，而是以 SQL、事务、索引、权限和恢复能力管理应用数据。

3.1 SQL、数据类型与索引

seekdb 支持常见的 DDL、DML、DCL 与事务控制语句，提供数值、字符、日期时间、二进制、JSON、空间、向量等数据类型。除主键和普通二级索引外，还提供全文与向量索引。查询优化器负责选择访问路径、下推条件、组织连接与排序，使检索能力能够与关系查询组合，而不局限于单独的向量 API。

3.2 ACID 与 MVCC

事务系统提供原子性、一致性、隔离性与持久性，MVCC 允许读写并发并提供一致性视图。日志记录和恢复机制用于在异常退出后恢复已提交数据并处理未完成事务。对同时修改业务状态、文档和向量字段的应用，统一事务边界可以避免"业务记录已提交但检索数据未写入另一系统"一类跨系统不一致。

3.3 MySQL 高度兼容

seekdb 兼容 MySQL 协议以及 MySQL 5.7/8.0 的大量常用语法和行为。应用可使用常见 MySQL 驱动、客户端、连接池与数据库工具接入，开发者可以延续熟悉的 SQL 和事务使用方式。

兼容范围主要包括：

常用建表、增删改查、连接、子查询、聚合、排序和事务控制语句；
常用数据类型、表达式、函数、视图、存储过程与触发器；
MySQL 协议、系统元数据视图及常见驱动接入方式；
用户与密码、GRANT/REVOKE、角色和对象级权限；
TLS 加密连接，用于保护客户端与服务器之间的数据传输。

3.4 权限与连接安全

服务器模式可通过账号、密码、角色和对象权限控制访问，并使用 GRANT 与 REVOKE 管理授权。应用应遵循最小权限原则，为业务读写、模型服务配置、索引管理和数据分支操作分配不同角色。TLS 负责链路加密；凭据轮换、密钥托管、网络边界、审计留痕与数据脱敏仍需结合整体部署方案实施。

3.5 主备可用性

对服务连续性和数据冗余有要求时，seekdb 可采用主备部署：主节点承载业务读写，备节点保持数据副本，为节点故障后的恢复与切换提供基础。主备部署可结合故障检测与切换机制，构建面向生产环境的高可用运行体系。

4. 一体化数据管理与混合检索

seekdb 将关系、向量、文本、JSON 与 GIS 数据统一纳入 SQL 与事务体系。在此基础上，混合检索组合向量召回、全文召回和标量过滤，并通过融合与重排形成完整的检索链路。

4.1 一个数据库管理多类数据

seekdb 在同一数据库中管理以下数据与访问方式：

多类数据同表存储时，一条记录可以同时包含业务主键、权限字段、正文、向量、JSON 元数据和空间字段。数据写入由同一事务系统管理，查询在同一 SQL 执行上下文中完成，从而减少跨系统复制、异步同步和应用层结果拼接。对于同步维护的索引，索引随事务提交进入可查询状态；对于异步索引，基表提交与索引可见性之间存在明确的最终一致窗口，应用可按需要主动刷新。

4.2 向量检索

seekdb 提供 VECTOR 数据类型、向量距离计算和近似最近邻检索能力，覆盖 HNSW、HNSW_SQ、HNSW_BQ、IVF_FLAT、IVF_PQ 等索引形态。应用可根据数据规模、精度、查询延迟、构建成本和内存预算选择索引类型及参数，而不是把所有负载固定在单一索引策略上。

典型向量查询同时包含语义距离与业务条件：

复制代码

SELECT id, title, category,
       l2_distance(embedding, :query_vector) AS distance
FROM knowledge
WHERE tenant_id = :tenant_id
  AND status = 'published'
ORDER BY distance APPROXIMATE
LIMIT 20;

这种执行方式使租户、权限、时间、类别等标量过滤不必在向量数据库之外二次处理。查询优化器可以结合谓词和索引路径组织执行，应用获得的是符合业务约束的 Top-K 结果。

4.3 全文检索

全文检索用于处理词项匹配、专有名词、编号、错误码等向量模型不一定稳定捕获的信号。seekdb 在数据库内提供全文索引、分词和基于 BM25 的相关性排序，可以与普通 SQL 谓词、排序和投影组合。全文数据与业务字段共同维护，避免将文档内容和权限元数据拆成两套事实来源。

4.4 混合检索链路

混合检索把候选生成、业务过滤、分数融合和可选重排组织成一条可控制的查询链路。

一条典型链路包含：

将用户查询转换为向量，生成语义候选；同时通过全文索引生成关键词候选。
在候选生成前或执行过程中应用租户、权限、时间、状态、JSON 属性等标量条件。
使用加权融合或 Reciprocal Rank Fusion（RRF）合并不同召回通道，避免直接比较量纲不同的原始分数。
对融合后的有限候选集调用 AI_RERANK，由外部重排模型进一步判断相关性。
返回最终 Top-K 结果及业务所需字段。

seekdb 提供 HYBRID_SEARCH(...) 查询入口与 DBMS_HYBRID_SEARCH 能力来描述候选、过滤、融合与排序。seekdb 混合检索教程 $5$ 给出了具体参数与示例。调用形式可概括为：

复制代码

SET @query = '{
  "query": { ...向量召回与全文召回... },
  "filter": { ...业务条件... },
  "rank": { ...加权融合或 RRF... }
}';
SELECT *
FROM HYBRID_SEARCH('knowledge', @query);

具体 JSON 参数由实际表结构、索引和模型配置决定。召回数、过滤位置、融合策略、重排候选数和最终 Top-K 共同影响相关性、延迟与模型调用成本，需要在查询设计中明确设置。

4.5 异步向量索引与写查平衡

持续写入场景中，同步维护复杂向量索引会把索引更新成本放入写事务关键路径。seekdb 因此同时提供同步和异步向量索引模式，相关设计与参数可参考 V1.3.0 Release Notes $6$ ：

同步模式强调提交后立即通过索引查询到最新数据，适合写入压力可控且要求强可见性的负载。
异步模式先提交基表数据，再通过变更流持续更新增量索引；查询同时搜索稳定索引与增量索引并合并 Top-K，以降低持续写入对前台查询的影响。
异步模式下，新写入数据进入向量索引存在最终一致窗口。应用可通过 DBMS_INDEX_MANAGER.REFRESH() 或 SDK 的 refresh_index() 主动推进索引追平，再执行依赖最新向量结果的操作。

**这一区分使一致性选择成为显式设计，而不是由应用在多个系统之间隐式承担。**业务状态仍以事务提交后的基表为准，异步性只作用于相应索引的查询可见时点。

5. 数据库内 AI

seekdb 将外部模型的接入与调用纳入 SQL 体系。用户可登记嵌入、重排和生成模型，并通过 AI_EMBED、AI_RERANK 和 AI_COMPLETE 在 SQL 中发起模型调用，具体用法可参考 seekdb AI 函数教程 $7$ 。模型推理由外部服务完成，seekdb 负责模型与端点管理、数据选择、请求发起和结果返回，使检索、模型调用与数据处理能够在同一条 SQL 链路中完成。

5.1 外部模型接入与管理

seekdb 通过 DBMS_AI_SERVICE 提供模型定义与访问端点管理能力：

模型定义与具体服务端点相互分离。更换服务地址、模型提供方或访问凭据时，可以更新端点配置，使用该逻辑模型名的 SQL 与索引定义无需随之修改。

5.2 AI SQL 函数

示意调用如下：

复制代码

SELECT AI_EMBED('embedding_model', content) FROM documents;
SELECT AI_RERANK('rerank_model', :query, :documents_json);
SELECT AI_COMPLETE('chat_model', :prompt, :config_json);

AI 函数与普通 SQL 表达式组合后，数据库可以直接选取目标行、构造模型输入并接收结果。实际使用时应避免对无限结果集逐行调用外部模型；更稳妥的方式是先通过索引和谓词缩小候选集，再执行重排或生成，并为调用量、超时与失败行为设置清晰边界。

5.3 从检索到生成的闭环

在 RAG 链路中，AI_EMBED 可以生成查询向量，向量与全文索引负责候选召回，标量条件实施业务约束，RRF 或加权融合统一排序，AI_RERANK 精排有限候选，最后由 AI_COMPLETE 基于证据生成答案。关系字段、文档正文、向量、检索分数和生成结果都可留在同一数据上下文中，便于记录引用、追踪输入和复用结果。

这一闭环的核心不是把所有推理都压入 SQL，而是把靠近数据的选择、过滤和编排放在数据库侧，让应用集中处理交互、业务流程和模型策略。

6. 面向 Agent 的 Fork/Diff/Merge

Agent 往往需要在真实上下文上执行多步试验：改写记忆、重组计划、生成结构化数据、调用工具后修正状态。直接修改主数据会增加误写风险；每次由应用复制完整数据又会带来时间、空间和一致性成本。

seekdb 将 Fork/Diff/Merge $8$ 作为数据库原生数据工作流，为 Agent 提供可写、隔离、可比较、可选择性合并的沙箱。

6.1 Fork：创建可写隔离空间

FORK DATABASE 用于从现有数据库创建完整的 Agent 沙箱；FORK TABLE 用于只隔离某张表。Fork 基于 Copy-on-Write（COW）共享初始数据页，不要求在创建时完整复制全部数据。Fork 后源与分支可以分别读写，后续变更相互隔离。

复制代码

FORK DATABASE agent_state TO sandbox_42;
USE sandbox_42;
UPDATE memory SET content = :new_content WHERE id = :id;
INSERT INTO plan_steps VALUES (...);

整库 Fork 适合包含多张关联表、索引和状态的完整试验；表级 Fork 适合局部数据加工或更细粒度的并行任务。

6.2 Diff：检查结果与冲突

DIFF TABLE 比较两个表的主键与行内容，识别仅一侧存在的行以及同主键不同内容的冲突。Agent 或上层应用可先检查差异，再决定是否采纳。相比只审查生成文本，数据级 Diff 能明确展示最终将发生的插入、更新或冲突。

复制代码

DIFF TABLE sandbox_42.memory AGAINST agent_state.memory;

6.3 Merge：按策略采纳结果

MERGE TABLE 将试验表的结果合入目标表，并提供三种冲突策略：

复制代码

MERGE TABLE sandbox_42.memory
INTO agent_state.memory
STRATEGY THEIRS;

未采纳的试验可以直接丢弃沙箱。由此形成"主数据 → Fork → 独立试写 → Diff → 决策 → Merge 或丢弃"的闭环。

该机制借鉴代码工作流中的分支思想，并针对数据库数据定义操作对象、冲突语义和事务边界。

6.4 Agent 场景中的控制点

Fork/Diff/Merge 解决的是数据隔离与采纳机制，并不替代应用权限与业务审批。

生产方案通常还应增加：限定 Agent 可 Fork 的源库与表；为沙箱设置所有者、生命周期和空间配额；在 Merge 前执行规则校验或人工审批；记录任务、模型、提示词、差异与采纳人；默认使用 FAIL，只在明确规则下选择覆盖策略。

7. 轻量、多形态与跨平台

seekdb 通过紧凑的资源占用、多形态运行和跨平台支持，覆盖从应用内嵌入、本地开发到独立数据服务的不同交付环境。

7.1 轻量化设计

seekdb 的轻量化同时体现在交付与运行层面。交付时，核心程序及其依赖保持紧凑，二进制与归档体积较小；运行时，空载 CPU 与内存占用维持在较低水平，并可在较短时间内完成启动、进入可连接状态。这使 seekdb 能够适应本地开发、嵌入式应用和小规格部署环境。

以下参考实测值展示 seekdb 的二进制体积、空载资源开销与启动速度：

7.2 多形态运行

seekdb 由同一数据库内核提供嵌入式与服务器两种主要运行形态：

两种形态共享同一套数据模型、SQL 语义、索引和事务能力，应用可根据部署位置、接入方式与资源管理要求进行选择。在服务器模式基础上还可采用主备部署，为数据冗余和故障恢复提供基础，相关能力见 3.5 节。

7.3 跨平台与多芯片支持

开发者可在 macOS 或 Windows 上完成本地数据建模与 AI 流程验证，再将相同的数据模型、SQL 和服务接口部署到 Linux 环境。跨平台与多芯片支持减少了不同开发、交付和生产环境之间的适配工作。

8. 性能与效率

对于持续更新的向量数据，查询性能需要结合吞吐、尾延迟、召回率以及写入期间的稳定性综合评估。本章以公开可复现的流式向量检索工作负载为例，展示 seekdb 在不同数据规模下的参考实测结果。

8.1 持续写入向量检索参考实测值

以下结果来自 VDB StreamBench 公开可复现的流式向量检索工作负载 $9$ ：Cohere 768 维数据集，HNSW 参数 M=16、ef_construction=256、ef_search=200，持续以 500 行/秒写入；分别在数据达到目标规模的 50% 和 80% 时，以 5 和 10 并发查询，查询阶段在写入后继续运行 30 秒。测试环境为 16 vCPU、64 GiB 内存。

该工作负载重点观察异步索引在"持续写入 + 并发查询"条件下的稳定性。1,000 万数据规模下，并发写入前后 P99 从 19.7 ms 变化到 21.7 ms，约为 1.1 倍，说明查询尾延迟在该配置和召回水平下保持相对稳定。

8.2 同工作负载对比

在同一公开测试框架、数据集、写入速率和机器规格下，1,000 万数据规模的参考结果如下。竞品 QPS 为按公开倍数换算后的近似值，结果适用于该流式向量工作负载。

在该测试中，seekdb 查询吞吐约为 Elasticsearch 的 3.2 倍、Milvus 的 10.7 倍，同时并发写入引起的 P99 波动更小。该结果需结合数据规模、索引参数、写入速率、并发和 Recall 解读，适用范围限定于上述测试条件。

9. 典型技术使用方式

9.1 Agent 长期记忆与知识检索

将会话、实体、事实、任务状态和向量表示保存在同一数据库中。关系字段负责时间、来源、权限和状态约束，向量与全文索引负责语义及关键词召回，JSON 保存可变元数据。Agent 可以在 SQL 中完成过滤与检索，避免长期记忆被拆分到多套存储。

9.2 RAG 与企业知识库

文档入库时保存正文、分段、结构化元数据和向量；查询时执行向量召回、全文召回、权限过滤、融合与可选重排。AI 函数可承担查询向量生成、重排和答案生成。该方案的重点是一条可审查的数据链路：最终结果能关联到原始文档、检索分数和业务条件。

9.3 嵌入式智能应用

Python、JavaScript 等语言可通过相应 SDK 以嵌入式形态使用 seekdb。该形态适合桌面 Agent、个人知识工具、边缘应用、离线数据处理和开发测试，也支持多个应用进程共享数据。当应用需要跨主机访问、独立资源管理或集中化运维时，可采用服务器模式，并继续使用相同的数据模型和查询方式。

9.4 隔离试验与结果采纳

对会修改数据的 Agent 任务，先通过 FORK DATABASE 创建完整沙箱；Agent 在分支内多轮写入和验证；任务完成后使用 DIFF TABLE 展示变化，通过规则或人工审批决定是否 MERGE TABLE。对局部表加工可使用 FORK TABLE，减少任务边界并简化审查。

参考资料 $1$

《A Relational Model of Data for Large Shared Data Banks》: https://doi.org/10.1145/362384.362685