想让 FastGPT 更猛？试试 OceanBase 向量数据库吧！

RAG 的核心魔法之一，就是向量数据库。

一直以来，FastGPT 默认推荐大家使用 PostgreSQL (配合 pgvector 扩展) 作为 “记忆大脑”。不得不说，PostgreSQL 是非常优秀、稳健的开源数据库，绝大多数场景，它都表现得很好。

不过随着大家的应用越做越大、数据量越来越多，或者当你开始玩转更高维度的向量模型 (比如现在动不动就上千维的 embedding)、需要更复杂的检索逻辑 (比如想先按类别筛选再找相似内容) 时，会发现 PostgreSQL 在向量处理这块儿有些吃力。

我们也一直在琢磨怎么能让 FastGPT 变得更强！所以，今天给大家带来一个好消息：

PostgreSQL 的局限性

深度使用 PostgreSQL (pgvector) 的过程中，确实发现了一些让开发者们 (包括我们自己) 不是很丝滑的地方。不是说 PG 不好，而是在向量数据这种 “新物种” 面前，它这位 “老将” 有时会显得有点力不从心。

具体表现如下：

1. 向量维度限制：“高维模型放不下”
   你有没有遇到过这种情况：兴冲冲地训练好了一个效果超赞的 embedding 模型，结果发现它的维度是 2048 或者更高？当你试图把它存入 PG HNSW 索引时，傻眼了——PG HNSW 全精度只支持到 2000 维！超出的部分，要么忍痛降维 (可能会损失精度)，要么就只能望 “维” 兴叹。

2. 混合检索的 “坑”：“我想精准找，怎么这么难？”
   这可能是最让 RAG 开发者头疼的问题之一。很多时候，我们不只是想 “找最像的”，而是想在特定条件下找最像的。比如，“只在 ‘技术文档’ 这个分类下，找和 ‘数据库优化’ 最相关的几段话”。这种 “先过滤、再搜索” 的需求，就是混合检索。
   然而，PG 的 HNSW 索引 (至少在 pgvector 0.8 版本之前) 并不原生支持在索引层面直接做这种混合过滤。你可能得先用 HNSW 召回一大堆向量，然后再在应用层或者数据库层面进行二次过滤。这样做不仅效率低，更要命的是，如果你的数据删改频繁 (向量数据库里还挺常见的)，PG 的旧数据 (死元组) 可能会干扰 HNSW 的召回，导致你过滤后发现，真正想要的数据丢失了！
   就算升级到了 pgvector 0.8+ 引入了递归搜索来缓解这个问题，我们实测发现，性能可能会变慢，而且有时候原先能跑的查询，索引突然就不生效了，得费劲改 SQL，体验上确实有点 “坑”。

3. VACUUM 的 “痛”：“空间回收跟不上”
   PG 依赖 VACUUM 机制来回收那些不再使用的空间 (比如你删除或更新数据后留下的 “坑”)。对于传统的文本、数字数据，这套机制运行得挺好。但向量数据不一样，它可是个 “大块头”，一个向量动辄几 KB 甚至更多。
   当你的 RAG 应用数据量很大，并且删改操作还挺频繁时，你会发现数据库文件像吹气球一样膨胀起来。这时候，PG 的 VACUUM 可能就有点 “消化不良” 了，回收速度跟不上数据更新的速度。结果就是要不就忍受磁盘空间的浪费，要不就得手动、频繁地执行 VACUUM FULL (这玩意儿还会锁表)，或者被迫给 autovacuum 分配更多的系统资源，运维起来真心有点累。

为什么选择 OceanBase？

而 OceanBase 是这么 “对症下药” 的：

1. 轻松驾驭 4096 维，还能更高！
   OceanBase 的向量索引默认就支持高达 4096 维的向量！这已经覆盖了市面上绝大多数主流 embedding 模型的需求。而且，这个上限还是可以配置扩展的！这就意味着，你可以放心地选用更高维度的模型来追求更好的效果，再也不用为了数据库的限制而牺牲模型精度去搞降维了。

2. 原生混合检索：精准、高效，一步到位！
   这绝对是 OceanBase 的一大杀手锏！它的向量索引是原生支持混合检索的。也就是说，你可以直接在查询时就告诉它：“嘿，帮我在 ‘这个分类’ 并且 ‘那个标签’ 下，找和 ‘这个描述’ 最相似的向量”。OceanBase 可以在索引层面一边进行精确的标量过滤，一边进行高效的向量相似度搜索。
   这样做的好处是显而易见的：

• 精准： 先把范围框定好再搜索，确保找到的都是你真正想要的，告别数据丢失的担忧。

• 高效： 索引层直接搞定，避免了应用层二次过滤的开销，查询速度嗖嗖的！再也不用担心索引失效或者为了绕坑写复杂的 SQL 了。

• 空间回收更 “智能”：自动管理，省心省力！
  OceanBase 底层采用了与 PG 不同的架构 (基于 LSM-Tree)。这种架构在处理数据的增删改和空间回收方面有其独到之处。它拥有更完善、更自动化的空间回收机制，对于向量这种体积大、可能更新频繁的数据类型更加友好。
  简单来说，你基本不用再像以前操心 PG 的 VACUUM 问题了。OB 会在后台更平稳、高效地处理空间回收，减少了数据库膨胀的烦恼，也大大减轻了你的运维负担。让你能更专注于业务逻辑，而不是天天和数据库空间 “搏斗”。

OceanBase 还有一些加分项：

• 单表多列索引支持： 如果你的业务场景需要在同一个表上对多个不同的向量列 (比如标题向量、内容向量) 建立索引，OceanBase 也能很好地支持。

• 分布式基因： OceanBase 天生就是分布式数据库，在高并发、大数据量下的水平扩展能力和高可用性方面有天然优势。(虽然咱们 FastGPT 可能暂时用不到那么大规模，但知道它有这个潜力总是好的嘛)

• 国产信创好伙伴： 对于有国产化、信创要求的项目来说，OceanBase 是一个非常好的选择。

总而言之，选择 OceanBase 作为 FastGPT 的向量数据库，意味着你可以：

• 拥抱更高维、更强大的模型。

• 实现更精准、更高效的混合检索。

• 从繁琐的 VACUUM 维护中解脱出来。

听起来是不是很香？?

安装部署教程

准备工作：

1. 一个可用的 Sealos Cloud 账号。

2. 了解 OceanBase 的基本部署概念和您打算使用的 OceanBase Docker 镜像版本。可能需要查阅 OceanBase 官方文档 https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002013494 中关于容器化部署或单机部署的相关说明。

部署步骤：

1. 在 Sealos Cloud 控制台创建应用： 登录 Sealos Cloud (https://sealos.run)，进入 Sealos Cloud 控制台后，导航至 “应用管理” 或 “应用启动台” 功能模块，点击 “新建应用” 或 “创建无状态服务” 按钮，开始配置新的应用部署。

2. 配置应用基本信息与网络： 参考如图所示界面，进行配置



• 容器镜像 (Image Name): 输入您选择的 OceanBase 数据库 Docker 镜像名称。请确保您使用的镜像是官方或可靠来源提供的，并注明版本（例如 oceanbase/oceanbase-ce）。

• 应用名称 (App Name): 为您的 OceanBase 部署设置一个易于识别的名称。

• 计算资源 (CPU/内存): 根据 OceanBase 的资源需求和您的使用场景，配置合适的 CPU 和内存资源。

• 网络配置 (Network Configuration): 开启 TCP 协议端口暴露。点击 “添加端口”，容器端口 (Container Port) 设置为 OceanBase 数据库默认监听的服务端口，通常是 2881。设置对应的 服务端口 (Service Port) 并选择适当的 暴露方式 (Exposure Method)（例如选择公网暴露，以便外部客户端连接到您的数据库）。

3. 配置环境变量： 在 “高级设置” 或 “环境变量” 区域，根据您使用的 OceanBase Docker 镜像的官方文档，添加启动和配置 OceanBase 实例所需的环境变量。例如：

• OB_SERVER_IP: OceanBase 节点的服务 IP 地址。

• OB_TENANT_NAME: 要创建或连接的租户名称。

• OB_TENANT_PASSWORD: 租户的密码。

• OB_SYS_PASSWORD: SYS 租户的密码（用于管理）。

4. 配置持久化存储：

• 数据库的数据、日志等核心文件需要持久化存储，以防止容器重启或删除导致数据丢失。

• 在 “本地存储” 或 “持久化存储” 区域，参考下图所示的挂载配置，为 OceanBase 容器挂载持久化存储卷。

• 点击 “添加存储卷”，选择或创建一个存储卷，并将其挂载到 OceanBase 容器内部存放数据、日志和配置文件的关键路径。请务必查阅您使用的 OceanBase 镜像的官方文档，确认需要挂载哪些具体的路径。

5. 仔细检查所有配置项，包括镜像名、资源、端口、环境变量和存储挂载路径，确保信息准确无误。

• 点击页面底部的 “部署” 或 “启动” 按钮。

• Sealos 将开始拉取 OceanBase 镜像，并根据您的配置创建并启动容器。数据库启动和初始化过程可能需要一些时间。



6. 验证部署并连接数据库：

• 部署成功后，在 Sealos 控制台的应用详情页面查看您的 OceanBase 应用实例的状态。

• 查看日志输出，确认 OceanBase 数据库已成功启动并完成初始化。

• 获取 Sealos 为您分配的对外访问地址（URL）和端口。

• 您现在可以使用 OceanBase 客户端工具（如 ODC - OceanBase Developer Center 或命令行客户端 obclient）连接到该地址和端口，并使用您在环境变量中设置的用户名和密码来访问和管理您的 OceanBase 数据库。






将 FastGPT 连接到此 OceanBase 实例




 重要参考文档：




  FastGPT 官方文档：https://doc.fastgpt.cn/docs/




  FastGPT GitHub Docker 示例 (OceanBase)：https://github.com/labring/FastGPT/tree/main/deploy/docker/docker-compose-oceanbase

总结与展望

这次 FastGPT 携手 OceanBase，主要是为了给那些追求更高性能、更强功能、更省心运维的朋友们提供一个 更优的向量数据库选择。虽然 PostgreSQL (pgvector) 在很多场景下表现不错，但在处理高维向量、复杂的混合检索以及大规模数据下的空间管理时，确实会遇到一些挑战。

而 OceanBase 恰好在这些方面展现出了强大的实力：

• 轻松驾驭超高维度向量 (默认 4096 维，还能更高)，让你的模型选择不再受限。

• 原生支持高效精准的混合检索，复杂查询也能一步到位，又快又准。

• 更智能、自动化的空间回收机制，告别 VACUUM 烦恼，运维更轻松。

可以说，OceanBase 的加入，实实在在地解决了我们（和你们！）在使用 FastGPT 过程中可能遇到的一些痛点，让你的 RAG 应用在性能、功能和易用性上都能更上一层楼。

那么，到底什么时候该用 OceanBase 呢？

这里给大家一些小建议：

强烈推荐选择 OceanBase 的场景：

• 你的 embedding 模型维度比较高（比如超过 2000 维）。

• 你需要频繁进行混合检索（比如先按用户、部门、时间等条件过滤，再找相似内容）。

• 你的知识库数据量非常大，而且更新、删除操作比较频繁。

• 你对 RAG 应用的查询性能、扩展性有比较高的要求。

• 你希望尽可能减少数据库运维方面（特别是空间回收）的麻烦。

• 项目有国产化、信创方面的需求。

PostgreSQL 依然是好选择的场景：

• 你的项目规模相对较小，数据量和 QPS 不高。

• 主要进行简单的向量相似度搜索，混合检索需求不多或不复杂。

• 使用的向量维度不高 (低于 2000 维)。

• 团队对 PostgreSQL 非常熟悉，并且目前的运维压力不大。

最终的选择权，当然在你的手上！我们希望提供更多的可能性，让你能根据自己的具体需求，为 FastGPT 挑选最合适的“记忆大脑”。