OceanBase 从生命科学序列数据检索出发，构建面向AI数据合成的企业级

OceanBase数据库官方博客

201人浏览 · 2026-07-08 10:13:32

OceanBase数据库官方博客 · 2026-07-08 10:13:32 发布

作者：陈松，算秩未来

数据库技术栈：业务数据库走向多模数据平台

算秩未来是一家年轻的公司，面向医疗、教育、材料、科研机构、政府单位及个人开发者，提供高性能 GPU 集群、弹性无服务器的 CPU 云算力，支撑训练推理和数据生产链路。产品形态从资源交付到算法研发，包括裸金属、云原生平台、机器学习平台与 MaaS（模型即服务）平台。

由于我们的业务特点为实时交付、弹性计费，同时有一些自动运维和异构计算需求，以及MaaS 平台创新后，也会面向开发者提供大量模型调用服务。因此，我们使用的数据库种类较多。

在线交易层数据量不大，使用 MySQL 支撑部分业务表，包括账号、订单、Token 调用量、计费等。从长远来看，当数据量增长后，MySQL 一定会被替换。
缓存与消息层使用 Redis缓存热点数据，使用 Kafka 承担异步事件和日志数据传输，并作为消息队列收集消费日志。
分析与检索层使用 OceanBase、Doris、NebulaGraph支持 OLAP 分析、日志存储，实体关系发现，全文向量等复杂关联探索。很多 AI 开源框架自带PG协议，因次，也接入了PostgreSQL。

所有数据库实例全部容器化部署，以实现自动化运维。MySQL、PostgreSQL 通过 Operator 部署；OceanBase 通过 OceanBase Operator 部署；Kafka 使用 Strimzi Kafka Operator；Redis 使用官方 Helm 部署。整个容器化过程虽然时间较短，但踩了很多“坑”，仍在探索解决方案中。

对OceanBase的需求起点：生命科学大模型训练语料合成

我们将 OceanBase 使用于"生命科学大模型语料训练"场景。这是因为垂直领域的大模型需要训练语料，这些语料体现在文件中，而算法和算力工程团队希望将内容落库，在整个训练过程中实现自动化。所以对数据库的需求是：既能支持后续通过唯一 ID 查询，又能支持正则匹配、全文索引，未来还需要向量检索能力。

这个需求对数据库的考验非常大，涉及数据规模、结构复杂性、查询多样性、应用场景复杂度。

首先，从算法团队提供的语料文本来看，大约有 20 TB 的原始数据，31 亿数据量，都是生物相关文件。从计算来看包含 14,081 个文件，在数据库中设计为 9 张业务表。涉及的专业术语包括：小分子及其分子式表达式、DNA、RNA、基因、蛋白、等等，数据来源于不同管理机构（如美国国家卫生管理局）。我们的核心诉求是将这些数据从文件资产转化为数据资产，实现可治理、可索引、可追溯。数据库层面相对容易实现，成本也更优。

其次，从查询方式来看，从传统的人工或应用系统查资料演变为 Agent 或 RAG 查询。查询方式变化较多，传统方式可能是关键字或唯一索引查找，实际业务中需要标量查询、标量过滤、全文检索、正则匹配、语义和向量混合查询，种类非常多。为了返回高精度、高质量数据源，混合搜索成为企业 AI 数据底座的标准能力。

最后，从数据结构来看，有很多结构样式。如果用传统方式，势必导致 20 TB 数据分类，需要放到不同数据库存储，数据越丰富，数据库种类越多，搜索链路越复杂且容易割裂。

传统方式存在诸多问题：

正排查找快，但难以覆盖别名、非标准化描述、相似表达。
全文检索能够覆盖文本，但与业务主键割裂。
向量检索能找到相似项，但缺少业务过滤。
单一向量数据库的标签过滤能力不强，无法提供权威过滤能力。
不同数据库之间需要数据同步，存储冗余多，运维复杂，成本上升（运维成本、通用成本等）。

本质上是缺少一个能够承载生命科学混合检索的统一数据底座，难以通过一套系统解决所有问题。

基于该需求，当前我们只能想到 OceanBase。在此之前，我们测试了 MySQL、PostgreSQL 以及其他分布式数据库，结果是：要么存储层成本非常昂贵，要么用存储引擎的性能较差。

与 OceanBase 交流后，震撼于OceanBase 的存储引擎设计，不仅能够极大的降低成本，性能还比传统向量数据库强很多。另外，OceanBase的其他特性也符合我们的选型需求。

模型设计：从原始文档到可查询的关系模型

选型后需要对模型进行设计，将原始文档（Json 格式）文本落库。借助 AI 工具提效，我们能够在几十分钟内完成代码编写，跑完直接落库。

整个阶段需要筛选出关键字段，变成结构化表结构。需要设计哪些字段单独提出、哪些字段放 Json 类型。存在多层嵌套，有父子表关系，拆了三张父子表。

索引设计方面 OceanBase 同时支持标量、全文、向量。结构保留原始 Json，保证原始数据来源source，因为应用需要上下文可回溯，最后返回数据时需要把原文返回给模型。

以基因、蛋白、小分子为例，有 Molecule以及Molecule SMILES分子表达式，在不同库中的表达式不一样，存在复杂关系。OceanBase主要用于处理复杂关系查询。数据属于数据资产，不会归档，没有按时间做分区，而是用 CID 加 ID 进行全局唯一 Hash 分区，每个表 32 个分区。

核心原则是：C 端统一分区，Json 和索引保证稳定，提供差异化检索服务。希望数据结构化后能够精准召回。

查询实践：同一数据底座覆盖三类生命科学召回

查询条件涉及专业术语，小分子主要通过CID，DNA、蛋白质通过 NCBI、UniProt ID 返回。基因中心法则等通过相关 Json Tag 做模糊匹配。涉及标量唯一检索、正则模糊匹配、向量检索等多种入口。四个入口+结构化模型+混合专业化，让搜索从确定性命中到可组合调用。

目前该项目还在进行中，只做了前半部分。框架定义为三层。

L1：精确查找，通过唯一 ID（CID 或 InChI）精确命中。
L2：模糊查找，通过基因名等做全文检索。
L3：语义查找，通过向量检索召回。

基因序列补充说明：每个基因序列看似简单，实际很长，一个分子的基因序列可能几百 MB 甚至几个 GB。遇到 OceanBase 大字段 500 MB 限制，需要拆分处理。L2 模糊查找通过基因名在 OceanBase 全文检索，以及其他阶段字段做小检索。接下来我们将通过向量检索对基因序列向量化并存入库，通过相似检索召回需要的基因，从确定命中到相似发现，形成可编排的企业级检索链路。

OceanBase 在L2层，既能管理业务数据，也能承接搜索所需的向量和上下文，比如将上层的数据存为多模态，向应用层或 AI 提供能力。整个 OceanBase 3 副本 1:1:1 部署，通过 OBProxy 访问。

在部署前期，我们在 OceanBase 前加了一层 OBProxy（业务从 OBProxy 进来访问OB Server），全部通过 OB Operator 管理，过程中遇到一些问题。

Dashboard 扩容 Zone 后 add server 超时偏短，Pod创建成功但OBZone / OBServer状态异常。需手动执行 alter system add server，再用 OBResourceRescue重置 OBServer状态。
扩容 Zone 只支持 nodeSelector，缺少 pod affinity 配置入口。
Dashboard 上缩容节点或 Zone 存在状态机不一致问题，容易误操作，且修复集群状态比较繁琐。
拓扑、任务进度、异常原因和恢复建议没有在同一视图中连接起来。

基于此，我们希望OceanBase能够尽快将运维体验和 AI 搜索能力一起补齐。

Dashboard + Operator 提供一键扩容：预检查、affinity、进度、失败恢复和回滚 Runbook。
增强 PostgreSQL 协议兼容，降低 PostgreSQL 生态应用、驱动和 SQL 迁移成本。
补齐图检索 / 知识图谱关系召回，与标量、全文、向量形成GraphRAG混合链路。

业务价值：一套系统解决多种问题

使用 OceanBase 后，业务的演进路线越来越清晰，价值越来越凸显。数据从文献文本变成了数据库中可查询、多维度、可精准召回的数据资产。通过数据库实现多维度的标量、唯一键、全文检索，命中率更高，链路更短。整个链路只需一套系统就能解决问题，不再需要 MySQL、Elasticsearch、 Milvus或其他大型数据库拼凑。对我们来说，这就是最优解。