本文作者：邱永刚，联通软件研究院OceanBase研发负责人，主要负责中国联通自研关系型数据库分布式CUDB研发、支撑、运维工作。

近年来，生成式人工智能技术取得了飞速进步，很多大模型在自然语言处理及对话系统领域的运用吸引了大量关注，如 OpenAI 的 ChatGPT、阿里巴巴的通义千问以及百度的文心一言等。尽管这些大型模型具备强大的推理能力，但在实际业务场景中，它们常因难以直接整合企业特有的数据与知识而面临应用局限。在此背景下，向量数据库作为检索增强生成（RAG）架构的关键支撑，日益凸显出其不可或缺的重要性。

RAG架构通过结合预训练的大型语言模型（LLM）和企业的实时私有数据，弥补了LLM在处理企业特定数据时的不足。借助向量数据库的强大检索能力，开发人员能够在无需重新训练模型的前提下，实现基于企业数据的实时、精准生成任务。在这篇文章中，我们将分享中国联通如何通过OceanBase的向量检索能力，在实际业务中成功实现RAG，帮助内部开发人员和DBA更高效地进行数据库基础设施相关查询和管理，从而进一步提升业务响应速度和准确性。

背景与挑战：RAG在联通软研院的应用

联通软研院数据库平台服务数百到上千内部用户，涵盖了从应用开发到运维管理的各个环节。面对如此庞大和复杂的数据库应用场景，我们长期面临许多挑战：数据库种类繁多，版本差异大，生产系统的稳定性要求高，测试环境与生产环境之间的差异影响了效率，且日常数据库运维和管理的工作负荷巨大，响应速度难以提升。

具体来说，我们需要应对如下几个主要挑战：

1.   多种数据库及版本管理：联通内部存在多款数据库产品，且版本更新和维护频繁。如何在不同版本之间保持一致性并快速定位问题，成为了运维和管理中的一大难题。

2.   生产环境的高效管理与测试环境差异：生产系统的稳定性至关重要，如何在保证生产环境稳定的同时，快速应对和解决生产系统中的问题。此外，测试环境与生产环境的差异可能导致性能偏差或潜在故障，如何高效地管理并在两者之间找到平衡，提升整体系统可靠性和响应速度，是提升数据库运维敏捷性的关键。

3.   提高工作效率与敏捷性：随着业务需求的不断变化，如何在复杂多变的数据库环境中快速获取所需信息，并及时响应，成了提升数据库运维管理效率的核心问题。

为了提升运维效率和内部敏捷性，我们尝试用RAG架构解决这些实际问题，并开发了数据库智能专家“ChatDBA”。通过结合数据库领域的专业知识和联通内部的运维数据，“ChatDBA”让开发人员和DBA可以直接用自然语言查询数据库状态、排查故障或者获取建议，减少了大量的重复工作。这样的方式，不仅提升了问题解决效率，也让团队能将精力更多地集中在关键任务上，以下是我们采用的整体方案流程示意图：

我们针对内外部的数据库通识类和特性类文档进行系统性梳理，形成文档知识库。通过文档切片和向量化模型嵌入，我们将这些文档内容转化为向量数据并存储在向量库中。这一做法使得大型语言模型（LLM）能够获得DBA领域的专业知识，大大提升了知识问答的召回率和准确性。在此基础上，我们进一步引入了RAG（检索增强生成）技术的知识问答系统。通过检索外部知识库，增强模型对特定问题的理解和回答能力，帮助生成更精准、更丰富的文本内容，从而提升了文本处理的效率和质量，最终打造了数据库智能专家“ChatDBA”， 它具备丰富的数据库知识和经验，能够为数据库使用者（应用人员）和数据库维护方（产品运维、支撑人员）提供全面的、高质量的技术咨询与解决方案服务，以降低数据库使用门槛、提升数据库运维效率。

选型与升级：从双库架构到一体化数据库

在项目初期，我们选择了MySQL作为关系型数据存储，并使用Milvus作为向量数据库。然而，随着数据量和需求的增长，我们很快发现了两个关键问题：首先，现有的数据库无法进行水平扩展，且无法应对更大规模的数据处理；其次，必须同时维护两种数据库系统，增加了管理和运维的复杂性。

为了解决这些问题，我们开始寻找一种能够统一支持关系型数据和向量数据的解决方案。在选型过程中，我们发现OceanBase 4.x实验室版本具备强大的向量检索与混合查询能力，这促使我们对独立向量数据库、单机数据库以及分布式数据库在向量场景下的能力进行详细评估，以下是评估结果的具体对比：

RAG 应用场景的向量数据库选型评估
向量关键特性		独立向量数据库 （以Milvus为代表）	具备向量能力的单机数据库 （以PostgreSQL为代表）	有向量能力的分布式数据库 （以OceanBase为代表）
向量功能与性能	向量查询性能	高效，专为处理大规模向量数据优化	一般，性能较依赖于数据库的扩展性	高效，针对大规模数据的存储与查询进行优化，支持复杂查询
	向量混合查询	无法与传统数据库查询进行混合查询	支持基本的向量查询，无法进行复杂的混合查询	支持向量、标量等传统数据的混合查询，适用于复杂融合查询场景
	接口灵活性	主要支持SDK，不支持SQL	支持SQL，并可以通过插件支持向量查询	支持SQL和SDK，提供更灵活的接口选项
可扩展性与整合	扩展性	高，可横向扩展以处理更多向量数据	依赖单机性能，扩展性有限	高，支持分布式架构，能处理海量数据
	整合传统数据支持	无，专注于向量数据	强，能同时处理关系数据和向量数据	强，能够处理传统关系数据和向量数据的混合查询
	运维复杂度	高，需要同时管理向量数据库和其他数据库	中，需额外优化性能，手动实现向量与结构化数据的混合查询，但可复用现有运维体系	低，一个数据库支持TP、AP和AI工作负载，简化多个数据库带来的运维复杂性
高可用与容灾	高可用能力	支持容灾和高可用部署，但需独立配置	支持高可用，但传统数据库的灾备能力可能较弱	强，支持单机、分布式两种部署模式。支持双活、分布式容灾、故障自动恢复，适用于高业务连续性场景
	备份与恢复策略	定期备份，支持全量和增量备份	支持全量备份与增量备份	全量与增量备份、即时恢复

深入对比了独立向量数据库、单机数据库和分布式数据库三种选型路线后，我们更倾向于 OceanBase 的一体化技术路线，不但可以使运维团队简化技术栈，更重要的是OceanBase在性能、扩展性和管理便利性方面展现出明显优势。OceanBase当前版本支持超过16,000维的稠密向量处理，并提供多种向量距离计算方式（如曼哈顿距离、欧式距离、内积和余弦距离）。此外，OceanBase还支持创建HNSW向量索引、增量更新和删除操作，以及强大的Filter功能，能够基于向量、标量和半结构化数据进行混合过滤。结合OceanBase本身的分布式架构，这些特性使它成为一个高效且统一的平台，能够解决我们面临的数据库扩展性和管理复杂性问题。

通过对OceanBase的测试验证，我们发现其向量检索能力完全符合我们的需求，尤其是在支持应用ChatDBA方面表现出色。更重要的是，OceanBase的向量检索功能具备完整的产品配套生态，进一步增强了其在实际生产环境中的可行性。以下是我们在功能测试中对比OceanBase向量检索与Milvus开源版本的一些关键差异，OceanBase展现出了明显的优势：

1.   简易运维：OceanBase向量检索功能可以直接复用OceanBase的运维管理平台（OCP），大大简化了运维工作。OCP提供了界面化的快速部署、硬件资源管理、监控告警、备份恢复等一整套完善的产品运维功能。而Milvus仅提供基础的数据库功能，不具备完善的运维支持，且存在安全隐患。

2.   高可用与弹性扩缩：OceanBase向量检索能力继承了OceanBase原生分布式数据库的高可用性，能够实现分布式部署、弹性扩缩容，并通过Paxos协议实现单点故障时的自动快速恢复。而Milvus只能进行单点部署，缺乏高可用性及横向扩展能力，这在生产环境中无法接受。

3.   多租户资源隔离：OceanBase向量检索支持多租户资源隔离，并配合OceanBase强大的可扩展性，能够提供安全、灵活的DBaaS服务。用户可以在现有OceanBase资源池内快速开通数据库实例，并根据业务需求灵活调整资源。相比之下，Milvus缺乏资源隔离能力，尤其在物理机部署情况下，资源管理容易出现浪费或不足且无法扩展的问题。

4.   支持 SQL：OceanBase向量检索支持标准SQL操作，开发人员可以使用DBeaver、Navicat等熟悉的客户端工具与数据库交互，这降低了数据库使用门槛，提升了开发效率。Milvus则不支持SQL，只能通过API和代码操作数据，使用体验相对较差。

5.   快速迁移：OceanBase向量库能够利用OMS数据迁移工具进行同构与异构数据迁移。我们通过OMS的功能，成功将原本存储在Milvus中的测试数据迁移到OceanBase中。而Milvus本身不支持数据迁移，跨环境迁移需要重建数据，耗时且对业务影响较大。

在性能测试阶段，我们模拟了当前实际生产环境的使用场景。此前我们使用了两套独立的数据库系统，而现在关系型数据库与向量数据库共享同一个实例。与原本需要两套数据库的部署方式相比，当前实例的规格约小了30%，但在性能上完全满足了业务需求，并且资源使用率显著降低。这意味着在成本方面，我们实现了至少30%的硬件资源节省。以下是官方发布的主流向量数据库性能对比。图中展示的VSAG曲线数据来源于OceanBase与蚂蚁集团联合研发的向量索引算法VSAG，OceanBase在性能表现上明显优于其他主流向量索引库，实现了“比快更快”的性能提升。

成效与价值：构建现代化RAG数据底座

在完成OceanBase数据库向量检索功能和性能验证后，我们决定将现有的MySQL和Milvus数据库进行现代化升级，并进行了相应的适配改造。我们发现，OceanBase的引入工作量较小。对于原MySQL数据库几乎没有额外工作量，SQL语法完全兼容，甚至无需更换驱动包，只需要修改配置即可。对于Milvus向量数据库的升级，主要是更新数据库依赖包和调整数据库操作方式。由于OceanBase支持通过SQL操作向量数据，只要熟悉SQL语法，改造工作也非常简便。我们在大约一周的时间内完成了所有程序的适配改造，并在不到两周的时间内完成了所有验证工作。

在10月初，OceanBase发布支持向量检索的稳定版本4.3.3后，我们启动了生产环境的数据库现代化升级。借助前期充分验证和OceanBase的OMS工具，升级过程高效顺畅，顺利完成从Milvus到OceanBase的数据迁移，加快了整体进程。升级后，我们将多套数据库整合为一个统一的系统架构，硬件资源使用量减少约30%，业务性能全面满足需求。OceanBase原生的分布式架构不仅显著提升了系统稳定性，降低单点故障风险，还为未来业务增长提供可扩展能力。这次升级既简化了技术栈，减轻运维团队的压力，还为业务的长远发展打造灵活可靠、可扩展的技术基础。

写在最后

在联通软研院RAG实践中，我们通过引入OceanBase，完成了数据库智能专家“ChatDBA”底层架构的现代化升级。OceanBase在统一关系型和向量数据库的技术栈方面展现出卓越能力，一个数据库即可支持多种工作负载和数据处理需求。硬件资源使用率降低约30%，配合OCP、OMS等工具，极大简化了运维流程，提升了团队效率。

结合项目实践，我们意识到RAG的向量检索能力对于实现高效的知识问答系统至关重要。而OceanBase作为一体化数据库，不仅能够支持多模态数据处理和多场景融合，还在性能和稳定性上表现出色。这样的设计帮助我们显著降低系统复杂性，同时为未来更复杂的业务需求提供了更坚实的技术支持，成为构建统一、高效智能数据库解决方案的关键一步。展望未来，我们计划进一步扩大OceanBase应用范围，通过现代数据架构升级进一步简化技术栈，降低运维成本。

---

OceanBase 云数据库现已支持365天免费试用，并提供 RAG等应用的搭建教程，欢迎点击体验 >>