中国联通 ChatDBA 升级向量数据库，Milvus、Elasticsearch、OceanBase实测对比

本文整理自2025 OceanBase开发者大会演讲《中国联通如何用 OceanBase 重塑数据库的智能运维未来》，点击链接可查看视频回顾。

首先为大家推荐这个 OceanBase 开源负责人老纪的公众号 “老纪的技术唠嗑局”，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！

随着信息技术的快速发展，数据库作为企业数据管理和分析的核心，其重要性日益凸显。中国联通作为国内领先的通信服务提供商，为了应对业务发展的过程中数据量激增、业务需求多样化等挑战，积极探索数据库技术的创新应用，特别是在智能运维领域。
本文将详细探讨中国联通为何选择的向量能力，构建智能运维平台，并分享Milvus、Elasticsearch、OceanBase 的选型对比。
一、背景：数据库产品及运维体系建设

在核心技术自主可靠的大背景下，中国联通率先开启了内部系统可靠战略，计划在 2027 年完成全部的架构改造，旨在通过采用国产、自主可靠的技术和产品，提高信息系统的安全性和可靠性，减少对外部技术的依赖。
（一）自研 + 商用数据库产品体系

在以上背景下，同时为了应对 MySQL 5.7 停服风险、降低商用依赖以及提升软研院软实力等几方面综合考虑，早在三年前，中国联通选定基于 OceanBase 社区版打造自研分布式 CUDB 产品，同时补齐数据库产品生态能力。随后，中国联通 引进多款商用数据库产品，形成了自研+商用的数据库产品体系，解决了数据库核心技术问题，助力集团架构升级，完成内部系统可靠战略。

在数据库产品生态能力的建设中，为屏蔽底层数据库差异、提高运营效能，中国联通建立了泛数据库 CDAS（Cloud Database Autonomous System）工具体系，提供统一操作与运维视图，自研打造跨产品融合、全场景驾驭的数据库自治服务工具，实现数据库的全生命周期自治化管理，减少人工干预，提高数据库性能、稳定性和安全性。

（二）数据库平台智能运维建设——  ChatDBA

为了更好地服务于应用，降低数据库的使用门槛，提升运维效率，中国联通将目光聚焦于数据库 DevOps 全生命周期管理，将 AI 大模型与数据库专家经验结合，建设了数据库智能专家 ChatDBA。
ChatDBA 以大模型和微调模型为基础，构建多 Agent 编排调度引擎，集成各类成熟工具，赋能数据库的全生命周期。

• 在设计阶段，ChatDBA 规划了模型设计、结构设计，以及智能化建库建表的能力；
  
• 在开发策略阶段，ChatDBA 优先关注 SQL 的生成补全、SQL 转代码、异构 SQL 转化的能力；
  
• 在上线阶段，ChatDBA 优先关注 SQL 审核、索引检查优化等能力；
  
• 在运维阶段，ChatDBA 通过日志、监控等手段，实现根因定位和快速恢复的能力；
  
• 在后期运营阶段，ChatDBA 优先实现 SQL 调优功能。
  

上述能力可以使数据库更好地服务于应用，具体以数据库开发、数据库运维排障、DBA知识问答这三个场景为例，详细介绍。
场景一：数据库开发。
在数据库开发阶段，应用可能面临很多问题，如：手写 SQL 不仅耗时长还容易出错，新数据库的使用门槛高、SQL 质量参差不齐。为此，中国联通将大模型和 Agent 能力结合，构建了 Text2SQL、SQL 转代码、异构 SQL 转换等能力，以及通过不断调试提升生成结果的准确率，进而提升开发效率。此外，通过建设数据库智能体，结合 CDAS 工具，让智能体具备专业的行动力，能够根据指令自主进行决策和行动。

场景二：数据库运维排障。
在数据库运维阶段，运维人员可能面临日志监控等信息需要人工分析的问题，耗时长、效率低。为此，中国联通基于大语言模型和 Agent 智能体围绕故障发现、故障诊断、故障处置等核心运维场景，打造了数据库的运维排障助手。通过收集常用的运维知识，包括经验、故障等，使用向量数据库输送知识的方式，培养 Agent 的专业运维能力。此外，基于多 Agent 的编排调度，各自领域的 Agent 协同工作，提高运维效率。

场景三：DBA 知识问答。
在数据库的全生命周期中，产品人员和开发人员可能面临应用多、问题多、更新迭代快等挑战，不仅需要持续学习，还有问题被及时解决的需求。为此，中国联通复用研发大模型知识处理能力，聚焦数据库领域专业知识和产品运维支撑知识，基于 CDAS 的数据库融合生态，建设 DBA 知识问答能力。首先，收集专业知识文档，通过文档的分割、切片、生成向量等方式，使大语言模型可以获取专业的数据库领域知识；其次，通过向量检索辅助大语言模型生成更准确、更丰富的文本内容，提升文本处理任务的效率和质量。通过以上方案，最终为数据库使用者（应用人员）和数据库维护方（产品运维、支撑人员）提供一站式的高质量技术咨询与解决方案服务。

二、选择 OceanBase 赋能智能运维

（一）智能运维平台的技术挑战

在数据库智能专家 ChatDBA 的各个使用场景中都用到了一个关键的基础组件：向量数据库。
起初，中国联通在实现 ChatDBA 的过程中使用 MySQL处理数据，使用Milvus检索，但存在以下问题。

• 单点问题：由于 MySQL 是集中式数据库，只能单机进行部署，存在单点问题，Milvus 当前非 k8s 环境，也只能单机部署，导致系统可用性存在较大隐患。
  
• 扩展性问题：受限于单机部署架构，在业务上线初期，业务量较少时资源浪费严重，随着业务量增长，也无法水平扩展。
  
• 运维复杂性问题：同时运维多个数据库组件，复杂度较高，而且由于 Milvus 依赖于 Mini IO 等组件，运营成本直线上升。
  

因此，中国联通将目光投向了行业内其他功能架构更适配的向量数据库。
（二）向量数据库选型

1.行业内产品对比。
中国联通对市面上主流的向量数据库产品进行了初步调研，尤其是 Milvus、Elasticsearch 和 OceanBase 这三款关注度较高的产品。以下是详细调研情况。

• 向量基础能力：如基本向量查询，Milvus、Elasticsearch 和 OceanBase 三款数据库基本都支持。
  
• 向量维度：OceanBase 最高支持 16000 维；Milvus 最高支持 32768 维（不直接支持SQL）；Elasticsearch 支持 4096 维。
  
• 数据一致性：OceanBase 支持事务，可以保证数据的一致性，Elasticsearch 和 Milvus 不能保证。
  
• 产品部署：目前三款数据库的最新版本都支持单机和分布式部署模式，但 OceanBase 是原生的分布式架构，可以做到透明、弹性。
  
• 备份恢复：Milvus 只支持数据的全量备份；Elasticsearch 支持全备和增量备份；OceanBase 支持全备、增备和事务日志备份。此外， Milvus 和 Elasticsearch 只支持将数据恢复到备份时的时间点，而 OceanBase 支持恢复到任意时间点。
  
• 其他方面： Milvus 不具备监控巡检接口和多模态能力，且后续没有支持计划，加上权限管理支持较弱，因此整体的运维易用性不能很好的满足业务需求。
  

2.基准性能测试。
向量数据库的性能也是中国联通重点关注的方面，便对上述几款向量数据库进行了基准性能测试，测试环境为国产 ARM 环境，采用了标准数据集以及专业的向量数据库测试工具 VectorDBBench，以下是性能测试结果。
在 768 维 100 万数据集下，OceanBase 的总体性能优于 Milvus，在相同召回率下：

• 当召回率在0.74 ~ 0.98 区间时，OceanBase 的性能基本是 Milvus 的 3 倍；
  
• 当召回率为 0.98 时，OceanBase 性能甚至达到了 Milvus 的 6 倍。
  

OceanBase 的总体性能也优于 Elasticsearch，在召回率在 0.74 ~ 0.98 区间时，OceanBase 的整体性能相比 Elasticsearch 提升 70% 左右。
在 1536 维 50 万数据集下，OceanBase 的整体性能优于 Milvus，如下图所示，当召回率在 0.87 ~ 0.99 区间时，OceanBase 的性能相比 Milvus 提升大概 60% 左右，整体性能与 Elasticsearch 相当。

3.验证总结。
综上所述，Milvus、Elasticsearch 和 OceanBase在功能、性能、产品生态的区别大致如下。

• 功能：Milvus 不支持混合查询；Elasticsearch 仅支持向量、全文索引的混合查询；而 OceanBase 支持向量、标量、GIS、全文索引和混合查询等非常全面的向量查询能力。
  
• 性能：OceanBase 整体优于 Milvus 和 Elasticsearch，在相同召回率下，OceanBase 是 Milvus 的 1.5 ~3 倍，相比 Elasticsearch 性能整体提升 40% 左右。
  
• 产品生态方面， OceanBase 具备明显优势：
  
  
  
  • OceanBase 的管理工具可以直接实现白屏化的监控告警、备份恢复等；
    
  • 由于 OceanBase 是原生分布式架构，支持单机故障的快速恢复，具备原生高可用能力以及弹性扩缩容能力，可以做到透明弹性扩缩和透明负载均衡；
    
  • OceanBase 具备多租户资源隔离能力，结合其强大的扩展性，可以提供安全灵活的 DBAS 服务，极大简化架构，便于运维。
    
  
  

基于OceanBase在对比验证中的综合优势，中国联通决定选用 OceanBase 作为目标向量数据库，并基于其多模态支持，对 MySQL 和 Milvus 进行架构升级。
（三）程序适配改造及升级效果

在架构升级过程中，中国联通首先对程序进行了适配改造。 由于 OceanBase 完全兼容 MySQL 语法，MySQL 只需要简单地修改链接地址即可完成升级。同时 OceanBase 支持 SDK 和 SQL 两种访问方式，并提供了兼容 Milvus 的 SDK 接口，替换 Milvus 的改造量也不大，因此，中国联通仅用半个月的时间就完成了所有的程序适配改造与验证工作。
在数据迁移方面，OceanBase 的官方迁移服务 OMS 支持 MySQL 到 OceanBase 全量和增量数据迁移、支持 Milvus 到 OceanBase 的全量迁移，整个迁移过程非常平滑，耗时较短。
完成架构升级后，效果显著，在资源利用、稳定性、扩展性等方面尤为明显。

• 资源利用：原来使用两个数据库支撑的业务替换为一体化的OceanBase后，规格减少了 30%，带来了 30% 的资源节省。
  
• 稳定性：OceanBase 是多节点架构，在单机故障情况下可以做到 RPO=0，RTO< 8s，规避了原来架构存在的业务可用性和数据丢失风险。
  
• 扩展性：OceanBase 可以根据业务负载情况灵活调整规格，做到了对资源的极致利用，在整个集群负载压力比较大的情况下，还可以进行横向扩展来满足需求，并且所有操作对应用来说都是完全透明的。
  

总的来说，此次架构改造不仅实现了技术升级，还带来了资源更省、稳定性更强、透明弹性扩缩容等额外效益，使中国联通内部业务人员、研发及运维人员都非常满意。
三、未来展望

未来，中国联通将建设向量数据库资源池，统一向量数据库技术栈，统一赋能知识库 RAG 场景，并探索OceanBase的向量能力。目前 OceanBase 也在继续优化和完善向量支持能力，如支持二进制距离、更多索引类型，以及进一步提升向量索引构建速度、丰富向量检索能力、支持 GPU 加速等。基于与 OceanBase 社区的深厚合作基础以及目前取得的成果，中国联通希望可以继续在向量库研发方面展开共建，进一步繁荣社区生态。


来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！