成熟稳定、省钱好用的AI应用怎么开发？趣丸科技员工助手的技术实践
作者：苏程辉，趣丸数据库负责人
如今，大模型推动各行各业加速智能化转型已广为人知。而在实际应用过程中，#大模型 对特定领域或私有数据的无知导致其难免存在“#幻觉” 问题，催生了企业对高效、精准的“记忆系统”的迫切需求。向量数据库作为连接大模型与海量非结构化数据的核心桥梁，以其强大的相似性检索能力，迅速成为构建新一代#AI应用（如智能问答、推荐系统、语义搜索等）的基础设施，直接决定了AI应用的智能高度与用户体验。本文分享趣丸科技定制化AI助手在选型底层数据库时，对比多款向量数据库后选择OceanBase的思路和经验。
业务需求：成熟稳定、省钱好用的AI应用
趣丸科技成立于2014年，是一家集兴趣社交、人工智能、电子竞技等技术于一体的创新型科技企业，1600+的员工中有50%为技术人员，软件著作权和专利近500项，成为了中国互联网综合实力百强企业、#广州互联网企业20强。
拥抱AI，降本增效
作为一家先进的科技企业，对新技术的态度是敞开怀抱。近两年，AI 技术的成熟和应用对趣丸内部各个部门产生了积极影响，趣丸希望借助 AI 提升效率，降低人力成本，尤其在数据库中间件的日常场景和运维监控场景。
日常场景对AI 的需求可归纳为四类：
- AI 慢日志优化。研发人员可直接与 AI 对话，由模型实时输出索引建议、重写方案及代价评估，无需再人工提单至 DBA 团队，SQL 优化效率大大提升。
- AI 数据库磁盘资源分析。系统需要每日采集库表级增量、TOP 排行及数据趋势，可直接借助 AI 完成，并结合业务特征预测容量峰值，提前触发归档或扩容建议，提升系统稳定性。
- AI 数据库连接分析。当连接数接近阈值时，AI 可以输出详细连接信息如业务来源，辅助快速定位异常业务。
- AI 数据库 CPU 告警分析。CPU 告警触发后，AI 可自动关联慢日志、执行计划及系统指标，生成根因分析报告，一线人员可根据报告直接执行优化或扩容，解决告警和资源问题。
在运维监控侧，计划将 AI 能力应用于以下两个方向：
- AI 数据库告警根因分析。一般情况下，告警会涉及多个场景，因此需要排查多个监控日志，借助 AI 可以快速定位问题，关联事务、I/O、慢查询等多维日志，输出根因结论，如大事务并发导致锁等待导致瞬时 I/O 飙升触发阻塞等，有效降低人工排障时长。
- AI OPS 告警治理。告警范围覆盖多种数据库，包括传统数据库 MySQL、PostgreSQL、PolarDB、GaussDB 等，消息中间件 Kafka、RocketMQ 等，告警量过多，纯人工无法闭环，通过引入 AI 进行智能化治理。
基于各部门的不同需求，公司面向员工推出统一的服务入口——员工助手。每位员工都需要拥有独立的私有助手，满足定制化需求。这对底层数据库又提出四项核心需求。
- 标量数据存储：需具备高性能、易扩展能力，以支撑高并发读写。
- 全文检索：支持全文检索。
- 向量存储与计算：支持向量数据的写入、索引及相似度查询。
- 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 作为统一数据底座。主要出于五点原因：
- 高兼容性。高度兼容 MySQL 语法、SQL 原生支持向量查询，可帮助快速低成本实现业务的 AI 应用需求。
- 稳定可靠性。集群高可用能力强，可快速恢复，RTO<8s，系统稳定性得到保证。同时三副本架构下，每一个副本下都有一份完整的数据，数据无丢失风险。
- HTAP 能力。基于“同一份数据，同一个引擎”，同时支持在线实时交易及实时分析两种场景。
- 强扩展能力。节点扩容可以在分钟级别完成、容量扩容在秒级完成，具备丝滑高效的在线扩展能力。
- 文本的多路融合检索。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，趣丸也有几点期待：
- 分布式迁移-自动分区。目前OceanBase 4.3.5版本已经支持自动分区能力，在测试环境迁移至生产环境过程中，针对大表，提供按规则自动分区功能，减少人工拆分与校验工作量。也希望在后续的业务场景尝试这种方式，减少开发、运维工作量。
- 共享存储。对于 I/O 敏感度较低的业务，希望引入共享存储方案，以提升存储资源利用率并简化扩容流程。
- 存储自动冷热分离。对于不常用的冷数据，希望存储到 OSS 等低成本介质中，并可以通过策略规则（如时间字段、访问频度）自动实现，降低存储成本。
最后为大家推荐这个 OceanBase 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个Star，都是我们努力的动力。
浙公网安备 33010602011771号