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

作者陈松算秩未来数据库技术栈业务数据库走向多模数据平台算秩未来是一家年轻的公司面向医疗、教育、材料、科研机构、政府单位及个人开发者提供高性能 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 OperatorRedis 使用官方 Helm 部署。整个容器化过程虽然时间较短但踩了很多“坑”仍在探索解决方案中。对OceanBase的需求起点生命科学大模型训练语料合成我们将 OceanBase 使用于生命科学大模型语料训练场景。这是因为垂直领域的大模型需要训练语料这些语料体现在文件中而算法和算力工程团队希望将内容落库在整个训练过程中实现自动化。所以对数据库的需求是既能支持后续通过唯一 ID 查询又能支持正则匹配、全文索引未来还需要向量检索能力。这个需求对数据库的考验非常大涉及数据规模、结构复杂性、查询多样性、应用场景复杂度。首先从算法团队提供的语料文本来看大约有 20 TB 的原始数据31 亿数据量都是生物相关文件。从计算来看包含 14,081 个文件在数据库中设计为 9 张业务表。涉及的专业术语包括小分子及其分子式表达式、DNA、RNA、基因、蛋白、等等数据来源于不同管理机构如美国国家卫生管理局。我们的核心诉求是将这些数据从文件资产转化为数据资产实现可治理、可索引、可追溯。数据库层面相对容易实现成本也更优。其次从查询方式来看从传统的人工或应用系统查资料演变为 Agent 或 RAG 查询。查询方式变化较多传统方式可能是关键字或唯一索引查找实际业务中需要标量查询、标量过滤、全文检索、正则匹配、语义和向量混合查询种类非常多。为了返回高精度、高质量数据源混合搜索成为企业 AI 数据底座的标准能力。最后从数据结构来看有很多结构样式。如果用传统方式势必导致 20 TB 数据分类需要放到不同数据库存储数据越丰富数据库种类越多搜索链路越复杂且容易割裂。传统方式存在诸多问题正排查找快但难以覆盖别名、非标准化描述、相似表达。全文检索能够覆盖文本但与业务主键割裂。向量检索能找到相似项但缺少业务过滤。单一向量数据库的标签过滤能力不强无法提供权威过滤能力。不同数据库之间需要数据同步存储冗余多运维复杂成本上升运维成本、通用成本等。本质上是缺少一个能够承载生命科学混合检索的统一数据底座难以通过一套系统解决所有问题。基于该需求当前我们只能想到 OceanBase。在此之前我们测试了 MySQL、PostgreSQL 以及其他分布式数据库结果是要么存储层成本非常昂贵要么用存储引擎的性能较差。与 OceanBase 交流后震撼于OceanBase 的存储引擎设计不仅能够极大的降低成本性能还比传统向量数据库强很多。另外OceanBase的其他特性也符合我们的选型需求。选型需求 | OceanBase特性满足需求兼容 MySQL 协议 | 兼容 MySQL 协议。很多向量数据库不支持或性能差异大无法通过 SDK 终端方法调数据分布式性能强劲 | 一体化架构LSM-Tree、高压缩率20 TB 数据压缩 30%非常可观容器化部署 | 公司背景全部是云原生无法多部署裸金属或物理机只能在容器上部署OceanBase 提供体系化部署能力标量、全文、向量检索 | 提供标量、全文、向量检索能力还具备一部分图数据库的能力企业级稳定 | 稳定性经过市场验证弹性扩展 | 企业级数据库管理弹性扩展原生混合检索能够承载统一输出底座降低运营成本和系统复杂度模型设计从原始文档到可查询的关系模型选型后需要对模型进行设计将原始文档Json 格式文本落库。借助 AI 工具提效我们能够在几十分钟内完成代码编写跑完直接落库。整个阶段需要筛选出关键字段变成结构化表结构。需要设计哪些字段单独提出、哪些字段放 Json 类型。存在多层嵌套有父子表关系拆了三张父子表。索引设计方面 OceanBase 同时支持标量、全文、向量。结构保留原始 Json保证原始数据来源source因为应用需要上下文可回溯最后返回数据时需要把原文返回给模型。以基因、蛋白、小分子为例有 Molecule以及Molecule SMILES分子表达式在不同库中的表达式不一样存在复杂关系。OceanBase主要用于处理复杂关系查询。数据属于数据资产不会归档没有按时间做分区而是用 CID 加 ID 进行全局唯一 Hash 分区每个表 32 个分区。核心原则是C 端统一分区Json 和索引保证稳定提供差异化检索服务。希望数据结构化后能够精准召回。查询实践同一数据底座覆盖三类生命科学召回查询条件涉及专业术语小分子主要通过CIDDNA、蛋白质通过 NCBI、UniProt ID 返回。基因中心法则等通过相关 Json Tag 做模糊匹配。涉及标量唯一检索、正则模糊匹配、向量检索等多种入口。四个入口结构化模型混合专业化让搜索从确定性命中到可组合调用。目前该项目还在进行中只做了前半部分。框架定义为三层。L1精确查找通过唯一 IDCID 或 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 高效调用。添加社区小助手加入微信交流群~立即试用 OceanBase 企业版体验国产数据库能力立即试用 OceanBase 企业版体验国产数据库能力