算秩未来基于 OceanBase：20TB 生命科学语料的混合搜索底座
算秩未来面向医疗、教育、材料与科研等场景，提供 GPU / CPU 算力与 MaaS 服务。训练语料要落库、要能被 Agent / RAG 查回来时，他们遇到一个典型难题：标量过滤、全文检索、向量语义检索如果拆到多套系统，同步成本与召回质量都会失控。
本文分享他们如何以生命科学大模型语料合成为起点，用 OceanBase 搭一套企业级混合搜索底座：约 20TB 原始数据、九张业务表，在同一引擎里覆盖 ID 查询、正则、全文与向量召回。
数据库技术栈：业务数据库走向多模数据平台
算秩未来是一家年轻的公司，面向医疗、教育、材料、科研机构、政府单位及个人开发者，提供高性能 GPU 集群、弹性无服务器的 CPU 云算力，支撑训练推理和数据生产链路。产品形态从资源交付到算法研发，包括裸金属、云原生平台、机器学习平台与 MaaS（模型即服务）平台。
业务侧要求实时交付、弹性计费，还有自动运维和异构计算；MaaS 面向开发者后，模型调用量也很大。因此数据库种类偏多，大致分三层：
- 在线交易层：数据量不大，用 MySQL 支撑账号、订单、Token 调用量、计费等表。长远看，数据量上来后 MySQL 仍会被替换。
- 缓存与消息层：Redis 缓存热点；Kafka 承担异步事件、日志传输与消息队列。
- 分析与检索层：OceanBase、Doris、NebulaGraph 支撑 OLAP、日志、实体关系、全文与向量等复杂探索。不少 AI 开源框架自带 PG 协议，因此也接入了 PostgreSQL。
所有实例容器化部署：MySQL / PostgreSQL 用 Operator，OceanBase 用 OceanBase Operator，Kafka 用 Strimzi，Redis 用官方 Helm。容器化推进很快，但坑也不少，方案仍在迭代。
对 OceanBase 的需求起点：生命科学大模型训练语料合成
我们将 OceanBase 用在「生命科学大模型语料训练」场景。垂直领域模型需要训练语料，语料原本散落在文件里；算法与算力团队希望落库后，整条训练链路能自动化。对数据库的核心要求是：既能按唯一 ID 查，又能做正则匹配、全文索引，还要具备向量检索能力。
压力主要来自三方面：
- 规模：算法侧语料约 20TB、约 31 亿条量级，生物相关文件约 14,070 个，库内设计为 9 张业务表。术语覆盖小分子 / SMILES、DNA、RNA、基因、蛋白等，来源含 NIH 等机构。核心诉求是把文件资产变成可治理、可索引、可追溯的数据资产。
- 查询形态：从人工查资料，变成 Agent / RAG 调用。除唯一索引外，还要标量过滤、全文、正则、语义向量，常常还要组合使用。高精度召回场景下，混合搜索几乎是标配。
- 结构多样：若按传统方式拆库存储，库种越多，同步与链路越碎，成本越高。
拆开用多套系统时，常见短板是：
- 正排快，但盖不住别名与非标准表述
- 全文能搜文本，却和业务主键割裂
- 向量能找相似，却缺权威业务过滤
- 纯向量库的标签过滤往往不够强
- 多库同步带来冗余、运维与成本上升
缺的是一套能扛生命科学混合检索的统一底座。 我们试过 MySQL、PostgreSQL 和其他分布式库：要么存储太贵，要么引擎性能不够。
与 OceanBase 交流后，存储引擎设计令人印象深刻：既能明显压低存储成本，性能也往往强于传统向量库；其余特性也贴合我们的选型清单。
| 选型需求 | OceanBase 如何满足 |
|---|---|
| 兼容 MySQL 协议 | 兼容 MySQL；不少向量库不支持或性能差异大，难用常见 SDK 访问 |
| 分布式性能 | 一体化架构 + LSM-Tree，高压缩；约 20TB 数据可压约 30% |
| 容器化部署 | 全云原生环境，提供体系化的容器部署能力 |
| 标量 / 全文 / 向量 | 原生混合检索，并具备部分图能力 |
| 企业级稳定 | 稳定性经市场验证 |
| 弹性扩展 | 企业级管理 + 原生混合检索，适合做统一输出底座，降低多系统复杂度 |
模型设计：从原始文档到可查询的关系模型
选型后需要对模型进行设计，将原始文档（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或其他大型数据库拼凑。对我们来说，这就是最优解。
基于OceanBase，技术落地路线从生命科学可用检索演变为智能搜索。当前，阶段1的数据入库与基础查询和阶段2的模糊与全文召回已经落地，阶段3与阶段4正在进行中。 最终目标是： 统一数据底座 + 可编排搜索链路 + 面向 AI 的高质量上下文返回。
用统一数据底座，承接 AI 时代的企业混合搜索。
OceanBase 混合搜索方案将精确查询、模糊检索和语义召回统一到企业级数据架构中，让大规模复杂数据既能被可靠管理，也能被 AI 高效调用。
添加社区小助手，加入微信交流群~