作者：苏程辉，趣丸数据库负责人

如今，大模型推动各行各业加速智能化转型已广为人知。而在实际应用过程中，#大模型 对特定领域或私有数据的无知导致其难免存在“#幻觉” 问题，催生了企业对高效、精准的“记忆系统”的迫切需求。向量数据库作为连接大模型与海量非结构化数据的核心桥梁，以其强大的相似性检索能力，迅速成为构建新一代#AI应用（如智能问答、推荐系统、语义搜索等）的基础设施，直接决定了AI应用的智能高度与用户体验。本文分享趣丸科技定制化AI助手在选型底层数据库时，对比多款向量数据库后选择OceanBase的思路和经验。

业务需求：成熟稳定、省钱好用的AI应用

趣丸科技成立于2014年，是一家集兴趣社交、人工智能、电子竞技等技术于一体的创新型科技企业，1600+的员工中有50%为技术人员，软件著作权和专利近500项，成为了中国互联网综合实力百强企业、#广州互联网企业20强。

拥抱AI，降本增效

作为一家先进的科技企业，对新技术的态度是敞开怀抱。近两年，AI 技术的成熟和应用对趣丸内部各个部门产生了积极影响，趣丸希望借助 AI 提升效率，降低人力成本，尤其在数据库中间件的日常场景和运维监控场景。

日常场景对AI 的需求可归纳为四类：

1. AI 慢日志优化。研发人员可直接与 AI 对话，由模型实时输出索引建议、重写方案及代价评估，无需再人工提单至 DBA 团队，SQL 优化效率大大提升。
2. AI 数据库磁盘资源分析。系统需要每日采集库表级增量、TOP 排行及数据趋势，可直接借助 AI 完成，并结合业务特征预测容量峰值，提前触发归档或扩容建议，提升系统稳定性。
3. AI 数据库连接分析。当连接数接近阈值时，AI 可以输出详细连接信息如业务来源，辅助快速定位异常业务。
4. AI 数据库 CPU 告警分析。CPU 告警触发后，AI 可自动关联慢日志、执行计划及系统指标，生成根因分析报告，一线人员可根据报告直接执行优化或扩容，解决告警和资源问题。

在运维监控侧，计划将 AI 能力应用于以下两个方向：

1. AI 数据库告警根因分析。一般情况下，告警会涉及多个场景，因此需要排查多个监控日志，借助 AI 可以快速定位问题，关联事务、I/O、慢查询等多维日志，输出根因结论，如大事务并发导致锁等待导致瞬时 I/O 飙升触发阻塞等，有效降低人工排障时长。
2. AI OPS 告警治理。告警范围覆盖多种数据库，包括传统数据库 MySQL、PostgreSQL、PolarDB、GaussDB 等，消息中间件 Kafka、RocketMQ 等，告警量过多，纯人工无法闭环，通过引入 AI 进行智能化治理。

基于各部门的不同需求，公司面向员工推出统一的服务入口——员工助手。每位员工都需要拥有独立的私有助手，满足定制化需求。这对底层数据库又提出四项核心需求。

1. 标量数据存储：需具备高性能、易扩展能力，以支撑高并发读写。
2. 全文检索：支持全文检索。
3. 向量存储与计算：支持向量数据的写入、索引及相似度查询。
4. HTAP 能力：会话上下文数据永久保存，并可直接在库内进行实时分析，无需额外数据链路。

AI应用开发难点：无一理想数据库

在员工助手的开发过程中，数据库团队在调研 AI 应用的行业现状、开发难度和稳定性保障等，发现现实远比想象中更具挑战。

首先，目前行业内尚未出现一个成熟、开箱即用、可支撑 AI 应用快速开发的底层数据库。

其次，要满足多种需求，可能需要同时维护 MySQL（标量检索、支持 TP）、Elasticsearch（全文检索、向量检索）、VDB/Milvus（向量数据库），至少三套系统，大幅提升了引入成本和开发难度。

最后。每个组件的稳定性都需要单独保障，包括高可用、监控、备份及故障排查等，运维工作量大，定位链路长。

选型之路：对比三种向量数据库方案

基于业务快速落地与稳定性的双重要求，数据库团队优化了选型方案，核心诉求如下。

• 标量数据：支持海量规模存储，并提供一致性与高可用保障。
• 向量数据：具备高性能向量写入、索引构建与近似查询能力，满足毫秒级召回。
• 开发接口：兼容标准 SQL，研发侧无需学习成本即可实现 AI 应用快速开发。
• 总体成本：通过存储压缩、资源池化与统一运维，显著降低硬件与人力投入。

在该目标指引下，初步选定三套数据库方案，并进行对比。

方案一：MySQL + Elasticsearch+ Milvus/VDB

如上文所述，采用该方案需要维护三套独立系统，数据同步链路长，开发、测试与发布周期成倍增加。同时硬件投入与人力运维成本均高，不符合“低成本快速上线”目标。

方案二：TiDB+ ES

• 需部署 PD、Server、KV 等多节点，部署成本较高；
• 全文检索需额外引入 Elasticsearch，进一步推高成本；

此外，TiDB需手工或通过 TiUP 组件部署，自动化与平台化程度低于 OceanBase，运维便利性不足。

方案三：OceanBase

• 具备原生 HTAP、高压缩、向量索引能力，单套集群即可同时满足标量、向量与全文检索需求；
• 兼容 MySQL 协议，零学习成本；
• 资源池化多租户，硬件利用率高，运维通过图形化平台完成，扩缩容全自动。

综合性能、兼容性、持久化、扩展性、成本、运维便利多个维度，最终选择 OceanBase 作为统一数据底座。主要出于五点原因：

1. 高兼容性。高度兼容 MySQL 语法、SQL 原生支持向量查询，可帮助快速低成本实现业务的 AI 应用需求。
2. 稳定可靠性。集群高可用能力强，可快速恢复，RTO
3. HTAP 能力。基于“同一份数据，同一个引擎”，同时支持在线实时交易及实时分析两种场景。
4. 强扩展能力。节点扩容可以在分钟级别完成、容量扩容在秒级完成，具备丝滑高效的在线扩展能力。
5. 文本的多路融合检索。OceanBase 的向量检索+全文检索的混合检索能力实现了对文本的多路融合检索，整个流程包括插入文本 (Chunk)、向量化（Embedding）、分词、向量检索、全文检索、重排序（Rerank）等步骤。

此外，在调研过程中，趣丸也发现 OceanBase 具备三个突出优势，也是其他方案不具备的能力。

一是OCP 运维平台提供图形化、自动化集群管理能力，显著降低日常运维复杂度，可实现一键扩缩容、监控告警、备份恢复、补丁升级及故障自愈等常用的运维操作。

二是副本级列存。在不增加额外组件的前提下，通过将其中一个副本以列式存储呈现，即可满足轻量级分析需求。

三是数据高压缩比。OceanBase 提供多级数据压缩能力，压缩率可达 3:1～5:1。虽然单 TB 磁盘单价较低，但当数据规模达到数十 TB 且用于长期归档时，高压缩特性可直接减少机器数量，形成可观的成本节约。

应用效果：三合一数据库底座满足多重需求

业务上线效果

目前基于 OceanBase 的员工助手已经上线，运行平稳，CPU使用率长期稳定在15%以下，抖动很小，整体平均响应时间满足业务的需求。

之所以该业务得以快速上线，关键在于开发效率提升、运维标准化、成本节省这三个方面。

提升开发效率： OceanBase 支持标量、向量、全文等混合检索，通过一条 SQL 即可解决复杂的多维查询需求，简化开发逻辑，降低编码复杂度。

运维标准化： OceanBase的迁移工具和运维平台方便易用，简化了部署与监控，可以快速上线，减少部署时间。

成本节省： 相较于三套数据库才能满足业务需求的方案，采用三合一的数据库底座，减少了资源的申请和审批流程，且大幅节省资源消耗。

OceanBase 测试注意事项

在上线OceanBase的过程中，运维团队遇到两个问题，可作为注意事项以提醒大家。

第一，OceanBase 的初始资源占用较高，在尝试验证生产环境所需的资源规格时，运维团队发现常规的资源配置如 8C16G，无法成功完成部署。尤其是在安装 OCP 等全套组件时，可能会存在资源不足的问题。因此，部署生产环境建议配置较高规格的资源如 8C32G。

第二，在性能测试中，运维团队在 OceanBase 中使用了业务中常用的租户配置，如 2C4G、4C8G，测试结果表明，在该配置下 OceanBase 的性能未能达到预期。建议使用较高规格的租户进行测试，避免产生性能不达标问题，同时也能对真实业务环境的性能表现有所把握。

对AI应用的底层数据库的期待

员工助手是趣丸内部面向员工使用的服务入口，后续将其接入其他 #AI产品 中。因此，对于AI应用的底层数据库 OceanBase，趣丸也有几点期待：

1. 分布式迁移-自动分区。目前OceanBase 4.3.5版本已经支持自动分区能力，在测试环境迁移至生产环境过程中，针对大表，提供按规则自动分区功能，减少人工拆分与校验工作量。也希望在后续的业务场景尝试这种方式，减少开发、运维工作量。
2. 共享存储。对于 I/O 敏感度较低的业务，希望引入共享存储方案，以提升存储资源利用率并简化扩容流程。
3. 存储自动冷热分离。对于不常用的冷数据，希望存储到 OSS 等低成本介质中，并可以通过策略规则（如时间字段、访问频度）自动实现，降低存储成本。

最后为大家推荐这个 OceanBase 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个Star，都是我们努力的动力。