国产关系数据库向量能力手册（OceanBase / GaussDB / 金仓）

适用版本：OceanBase 稀疏向量自 V4.3.5 BP2 起支持（2026 最新稳定版本未核实）；GaussDB 公有云当前稳定版本未核实；金仓 KES Vector 官方细节未核实，核实于 2026-11 许可与形态：三者均为已有国产关系库内的向量能力，非独立向量库；OceanBase / GaussDB 为官方文档口径，金仓部分为第三方选型资料；许可与商业版边界以各厂商为准 一句话定位：在已有 OceanBase / GaussDB / 金仓实例上用 SQL 原生向量类型与索引做混合检索，不新增一套数据库，也不用 Milvus SDK 迁移业务。 约定：$ 普通用户、# root 或 sudo、<xxx> 为占位符；标 ⚠️ 的是高危操作。 更新时间：2026-11（版本与 API 变化快，执行前请以官方文档复核）

目录

1. 它是什么、什么时候选它
2. 版本、许可与官方入口
3. 安装与启动
4. 核心概念与数据模型
5. 快速上手：完整 CRUD 示例
6. 索引与检索进阶
7. 生产部署与运维
8. 高频故障与排障
9. 常见坑与避坑清单
10. 速查表
11. 参考与延伸

1. 它是什么、什么时候选它

1.1 定位与架构（按子产品）

OceanBase：分布式关系库内置向量能力，SQL 原生 VECTOR(n) / SPARSEVECTOR 类型 + VECTOR INDEX，向量与业务表同库，支持事务 / MVCC / 分布式扩展、稠密 + 稀疏混合检索。dense 最多 16000 维；元素仅单精度 float，禁止 NaN / Inf。另有 pyobvector 提供 Python 接入。

华为 GaussDB：企业级分布式关系库原生内置向量引擎，用 SQL 扩展做向量 + 标量混合查询，非独立向量库；类型 FloatVector / BoolVector，支持多表 JOIN，另有 BM25 全文检索 / Tokenweight 自定义分词词典。公有云开发者版可免费试用 1 个月（4U16G）。

人大金仓 KES Vector：第三方选型资料描述为内核级向量引擎，SQL 同时做多表关联与高维向量检索，支持事务一致性、信创适配；暂不支持 GPU 加速，索引构建内存占用高。官方细节未核实，以下相关内容均按第三方资料标注，勿当官方声明。

核心主题：已有国产关系库时，向量能力是加一个列、加一个索引，不是再部署 Milvus / Qdrant。三者都强调「SQL 同时做标量关联与向量检索」，这正是融合型相对专用向量库的价值。

1.2 横向对照表：定位差异（第 1 章）

1.3 适合 / 不适合（按子产品）

OceanBase 适合：已有 OceanBase 集群；需要事务 / MVCC / 分布式扩展与稠密 + 稀疏混合检索；希望用 SQL 或 pyobvector 接入。不适合：需要 100% 兼容 pymilvus（其 MilvusLikeClient 明确不是）；维度超 16000；依赖未支持的数据类型。

GaussDB 适合：已有 GaussDB / 公有云版本；需要向量 + 标量混合、多表 JOIN、BM25 / Tokenweight 全文融合；可接受 SQL 接入。不适合：需要降序排序的向量索引（不支持）；除 GsDiskANN 外要用 4096 维（其他索引最多 1024 维）；依赖 Milvus SDK（无官方兼容声明）。

金仓 KES Vector 适合（基于第三方资料，须核实）：信创环境、需要多表关联 + 高维检索 + 事务一致性。不适合（基于第三方资料，须核实）：需要 GPU 加速；内存受限、无法承受索引构建期高内存占用。

1.4 规模、链路位置与「何时该换」

链路位置：离线「文档 → Embedding → 写入业务表的向量列」；在线「query → Embedding → SELECT ... WHERE <标量/关联条件> ORDER BY <距离> LIMIT k → JOIN 取回业务字段 → 展示」。三者都位于关系查询 + 向量召回合一的层，最大价值是多表关联与事务一致性。

该换专用向量库的信号：需要 Milvus SDK / 生态 100% 兼容；需要 GPU、复杂量化族或十亿级分布式向量优化；向量检索要独立弹性扩缩而不拖累核心库；需要降序排序 / 超过索引维度上限等内核限制无法满足。

2. 版本、许可与官方入口

2.1 版本状态表

避坑：三者的版本与许可大量处于「未核实」状态。方案、CMDB、发版公告里都不要写死稳定版号或许可名称，统一写「以官方为准」。

2.2 许可与官方入口（按子产品）

• OceanBase：2026 最新稳定版本与许可证未核实；接入可用 SQL 或 pyobvector（pip install -U pyobvector，Python 3.9+）。
• GaussDB：公有云稳定版本号未核实，是否兼容 Milvus SDK 未核实且无官方兼容声明；接入方式为 SQL / gsql。
• 金仓：许可与版本未核实，以下相关描述均来自第三方选型资料。

2.3 版本识别与近两年变更

-- 通用做法：查服务端版本（具体函数 / 视图以各产品官方文档为准）
SELECT version();

3. 安装与启动

3.1 说明与前置条件

本组产品通常已有数据库实例，「安装」实为「在已有库上启用向量能力」。官方资料未提供三者的官方安装命令、镜像 tag 与端口，部署安装以各厂商官方文档为准，勿臆测。前置条件：版本达到各自能力节点（OceanBase 稀疏向量需 V4.3.5 BP2+）；具备建表 / 建索引权限；确认向量维度在允许区间内（GaussDB 尤其要按索引类型选维度）。

避坑：金仓部分来自第三方选型资料，其具体安装 / 类型 / 索引细节官方未核实，本章不提供臆造命令，按厂商文档执行。

3.2 方式一：OceanBase（SQL 建表 + VECTOR INDEX）

-- 连接：OBClient / MySQL 客户端连接到 OceanBase 实例
CREATE TABLE t1(
    c1 INT,
    c2 VECTOR(3),
    PRIMARY KEY(c1),
    VECTOR INDEX idx1(c2) WITH (distance=L2, type=hnsw)
);

官方 SQL 示例（维度 3 便于阅读，实际常见 768 / 1024 / 1536）。distance=L2、type=hnsw 取自官方文档。

3.3 方式二：GaussDB（gsql 建表 + 检索）

-- 连接：gsql 连接到 GaussDB 实例
CREATE TABLE t1(id int, repr floatvector(4));
INSERT INTO t1 VALUES (0,'[1,2,3,4]');
SELECT id FROM t1 ORDER BY repr <-> '[1,1,3,2]' LIMIT 2;

官方 SQL 示例取自官方文档（维度 4）。类型为 floatvector(4)；<-> 类操作符与 ORDER BY 组合做近邻检索。

3.4 金仓：启用方式

金仓 KES Vector 的具体建表 / 索引语法官方资料未提供（第三方资料只描述能力），故此处不给臆造 SQL；按厂商官方文档的 SQL 方式启用，并核对「多表关联 + 高维检索」的能力边界。

3.5 目录、端口与健康检查

判定「向量能力就绪」的可靠方式是完成一次「建表 → 写入 → 近邻检索」闭环；仅能建表不能检索，说明索引 / 距离函数未正确配置。GaussDB 检索语法官方资料已给出，可直接验证；OceanBase 检索函数逐字写法官方资料未给，按官方文档构造后验证。

3.6 生产最小配置建议

认证 / TLS / RBAC / 网络暴露面沿用各库基线（通用运维见根目录手册）；建索引前评估内存（金仓第三方资料特别提示索引构建内存占用高）；维度与索引类型在建表前定稿（GaussDB 改维度 / 索引涉及重建）。

⚠️ 危险：在已有大表上加 VECTOR INDEX / 改向量列会长时间占用资源并可能影响线上业务，务必在维护窗口、有备份的前提下执行。

4. 核心概念与数据模型

4.1 术语对照（按子产品）

4.2 横向对照表：类型 / 索引 / 维度上限 / 兼容性（第 4 章，重点）

避坑：这张表是本篇最关键的对照。GaussDB 仅 GsDiskANN 支持 4096 维、索引只支持升序；OceanBase 的 MilvusLikeClient 不是 100% 兼容 pymilvus；金仓整列均为第三方资料、官方细节未核实。把三者混为一谈或把第三方结论写成官方声明，是选型文档最常见问题。

4.3 数据模型、距离方向与生命周期

三者都是「database → schema → table（标量列 + 向量列）→ 向量索引」，一行 = 一个实体，无 collection / partition / load 概念。

• OceanBase：向量元素仅单精度 float，禁 NaN / Inf；VECTOR INDEX ... WITH (distance=L2, type=hnsw) 在建表时声明；稠密 + 稀疏混合检索。距离方向官方未给出明确口径，L2 类通常越小越相似（经验性，以官方文档为准）。
• GaussDB：<-> 类操作符、cosine_distance()、hamming_bool_distance()；支持多表 JOIN；索引只支持升序排序，不支持降序；BM25 / Tokenweight 可做全文融合。
• 金仓：SQL 多表关联与高维检索（第三方资料），距离与排序细节未核实。

生命周期：建表即定义向量列与索引；写入随事务提交；查询由 SQL 优化器决定是否用向量索引；一致性沿用各关系库的事务 / MVCC 模型（OceanBase 明确支持事务 / MVCC，金仓为第三方资料所述事务一致性）。

5. 快速上手：完整 CRUD 示例

示例用 3～4 维便于阅读；实际常见 768 / 1024 / 1536 维。GaussDB 的 SQL 取自官方文档；UPDATE / DELETE / DROP / 加列等为关系库通用 SQL（经验性，以各产品文档为准）。

5.1 GaussDB：完整 SQL CRUD（gsql，可直接复制运行）

-- 连接：gsql 连接到 GaussDB 实例
DROP TABLE IF EXISTS t1;
CREATE TABLE t1(id int, repr floatvector(4), category varchar(32));

-- 1) 插入
INSERT INTO t1 VALUES (0,'[1,2,3,4]','tech');
INSERT INTO t1 VALUES (1,'[4,5,6,7]','tech');
INSERT INTO t1 VALUES (2,'[7,1,2,3]','life');

-- 2) 近邻检索（<->，索引只支持升序）
SELECT id, category FROM t1 ORDER BY repr <-> '[1,1,3,2]' LIMIT 2;

-- 3) 带标量过滤的检索
SELECT id, category FROM t1
WHERE category = 'tech'
ORDER BY repr <-> '[1,1,3,2]' LIMIT 2;

-- 4) 更新（通用 SQL）
UPDATE t1 SET repr = '[1,2,3,5]' WHERE id = 0;

-- 5) 删除（通用 SQL）
DELETE FROM t1 WHERE id = 2;

-- 6) 清理（通用 SQL）
DROP TABLE t1;

避坑：GaussDB 向量索引只支持升序排序，不支持降序；ORDER BY ... DESC 不要用。多表 JOIN 与 BM25 / Tokenweight 融合可在此 SQL 之上扩展（官方资料给出能力，逐字函数以官方文档为准）。

5.2 OceanBase：建表、插入与索引

DROP TABLE IF EXISTS t1;
CREATE TABLE t1(
    c1 INT,
    c2 VECTOR(3),
    c3 VARCHAR(64),
    PRIMARY KEY(c1),
    VECTOR INDEX idx1(c2) WITH (distance=L2, type=hnsw)
);
INSERT INTO t1 VALUES (1, '[1,2,3]', 'tech');
INSERT INTO t1 VALUES (2, '[4,5,6]', 'tech');
INSERT INTO t1 VALUES (3, '[7,1,2]', 'life');
-- 近邻检索：官方资料未给出 OceanBase 距离运算符 / 函数的逐字写法，
-- 请按 https://docs.oceanbase.com/oceanbase-database/V4.3.5-vector-data-type 构造 ORDER BY 子句
UPDATE t1 SET c3 = 'tech' WHERE c1 = 1;
DELETE FROM t1 WHERE c1 = 3;
DROP TABLE t1;

避坑：VECTOR INDEX idx1(c2) WITH (distance=L2, type=hnsw) 是官方写法；检索侧的运算符 / 函数名官方资料未核实，故此处不臆造查询体，按官方文档补齐后再做「写入一条 → 近邻检索返回」的闭环验证。

5.3 输出怎么读

GaussDB 的 <-> 距离方向官方未给出明确口径，通常越小越相似（经验性，以官方文档为准）；若结果异常，先核对排序方向与索引类型。

5.4 pyobvector 接入与 MilvusLikeClient 兼容性

$ python3 -m pip install -U pyobvector      # 官方安装命令，Python 3.9+

from pyobvector import MilvusLikeClient, ObVecClient

# 实例化连接参数官方资料未给出逐字签名，按 pyobvector 官方文档构造：
# client = MilvusLikeClient(...)   /   vec_client = ObVecClient(...)

UNSUPPORTED_TYPES = [
    "BINARY_VECTOR", "FLOAT16_VECTOR", "BFLOAT16_VECTOR",
    "SPARSE_FLOAT_VECTOR", "dynamic_field",
]
SQLALCHEMY_ONLY_METHODS = ["load_collection", "release_collection", "close"]

print("MilvusLikeClient 不是 100% 兼容 pymilvus")
print("不支持的类型 / 字段：", UNSUPPORTED_TYPES)
print("需经 SQLAlchemy 的方法：", SQLALCHEMY_ONLY_METHODS)
print("注意：create_collection 实际是建表，语义与 Milvus 不同")

明确列出不支持的类型 / 字段：BINARY_VECTOR、FLOAT16_VECTOR、BFLOAT16_VECTOR、SPARSE_FLOAT_VECTOR、dynamic_field。另外 load_collection / release_collection / close 需经 SQLAlchemy；create_collection 实际是建表。

避坑：旧教程 / 选型文章常写「OceanBase 兼容 Milvus SDK，可直接迁移 pymilvus 代码」。MilvusLikeClient 不是 100% 兼容：上述五类类型 / 字段不支持，且三个方法需走 SQLAlchemy，create_collection 语义是建表。存量 Milvus 业务代码必须逐项核对，不能原样搬。

第 5 章的完整可运行 CRUD 由 5.1 / 5.2 的 SQL 承担；5.4 为 Python 接入兼容性核对（import 齐全、变量有定义）。金仓的具体 SQL 官方资料未提供，不给臆造示例。

5.5 金仓 KES Vector

第三方资料描述为「SQL 同时做多表关联与高维向量检索、事务一致性、信创适配」，但官方细节未核实，无逐字 SQL 可给；按厂商官方文档接入并复核能力边界。

6. 索引与检索进阶

6.1 索引参数调优（按子产品）

6.2 横向对照表：索引 / 量化 / 维度 / 兼容性（第 6 章）

6.3 recall 与延迟取舍

官方资料未给出三者的召回 / 延迟官方参数或承诺。方法（经验）：用精确距离扫描跑 ground truth，再对同一批 query 在建索引后算 recall@k；OceanBase 可比较 HNSW / IVF / HNSW_BQ，GaussDB 可比较 GsIVFFLAT / GsDiskANN。所有结论须实测，勿套用别产品参数。

6.4 标量过滤、混合检索与多向量

• 过滤行为：三者都是「SQL WHERE + ORDER BY 距离」形态；pre/post-filter 的官方语义官方资料未给出，以各产品执行计划（EXPLAIN，通用能力）与实测为准，勿把 pgvector / ES 的结论套过来。
• 混合检索：OceanBase 支持稠密 + 稀疏混合检索（稀疏向量自 V4.3.5 BP2 起）；GaussDB 有 BM25 全文检索与 Tokenweight 自定义分词词典，可与向量标量混合查询组合；金仓为 SQL 多表关联（第三方资料）。
• 多向量 / 稀疏 / 重排：多向量列、两阶段「近似取候选 + 精确重排」为经验做法；金仓「暂不支持 GPU 加速、索引构建内存占用高」为第三方资料，须核实。

6.5 量化与容量估算（经验公式，非官方承诺）

单行向量存储 ≈ 4 × dim 字节（单精度 float）；dim=768 → 3072 B ≈ 3.0 KB / 行
OceanBase HNSW_BQ（RaBitQ）官方称可降约 95% 内存（相对基线，具体口径以官方为准）
总容量 ≈ (数据 + 索引) × (1 + 副本数) / 压缩比
GaussDB 高维（4096）只能选 GsDiskANN，索引体积与内存须单独评估
金仓第三方资料提示索引构建内存占用高，规划时预留

系数为经验区间，非官方承诺；用各库的系统表 / 监控实测后做容量规划。

7. 生产部署与运维

• 高可用 / 分片 / 副本：OceanBase 明确支持事务 / MVCC / 分布式扩展；GaussDB 为企业级分布式关系库；向量列与索引随各自集群的复制 / 备份体系。金仓为第三方资料所述事务一致性，须核实。
• 备份恢复：沿用各关系库现有备份方案；恢复后核对向量索引是否随数据恢复，必要时重建。
• 监控（沿用各库监控体系，无独立向量端点；具体视图 / 端点官方资料未提供，以官方文档为准）：

• 扩缩容：以 6.5 估算为起点；GaussDB 维度与索引类型强绑定，扩容 / 改索引需重建评估。
• 升级迁移：核对 OceanBase 稀疏向量 V4.3.5 BP2 能力节点；GaussDB 稳定版本与 Milvus 兼容声明未核实，升级前复核；金仓以厂商文档为准。
• 安全 / 日志：认证、TLS、RBAC、网络暴露面沿用各库基线（通用运维见根目录手册）；向量列同样受权限控制。日志为数据库自身日志，无独立向量日志。

⚠️ 危险：DROP TABLE / 删索引会连带删除向量数据与索引，且 GaussDB 索引只支持升序、维度上限固定，变更索引类型需重建，执行前必须确认备份与回滚方案。

8. 高频故障与排障

9. 常见坑与避坑清单

1. 现象：文档把 OceanBase / GaussDB / 金仓稳定版号、许可写死。原因：三项官方资料明确未核实。怎么做：统一写「以官方为准」，勿编造。
2. 现象：把金仓第三方资料结论写成官方声明。原因：金仓部分官方细节未核实。怎么做：全程标注「第三方选型资料」，选型结论向厂商复核。
3. 现象：以为 GaussDB 兼容 Milvus SDK。原因：未核实且未找到官方兼容声明。怎么做：接入方式按 SQL / gsql，勿承诺 SDK 兼容。
4. 现象：以为 OceanBase MilvusLikeClient 100% 兼容 pymilvus。原因：不是 100% 兼容。怎么做：明确列出不支持 BINARY_VECTOR / FLOAT16_VECTOR / BFLOAT16_VECTOR / SPARSE_FLOAT_VECTOR / dynamic_field。
5. 现象：load_collection / release_collection / close 报错。原因：需经 SQLAlchemy。怎么做：走 ObVecClient / SQLAlchemy 路径。
6. 现象：create_collection 行为与 Milvus 不同。原因：实际是建表。怎么做：按建表语义设计，别按 Milvus collection 语义验收。
7. 现象：GaussDB 用 ORDER BY ... DESC。原因：向量索引只支持升序、不支持降序。怎么做：一律升序。
8. 现象：GaussDB 4096 维用 GsIVFFLAT 建索引失败。原因：仅 GsDiskANN 支持 4096 维，其他索引最多 1024 维。怎么做：换 GsDiskANN 或降到 1024 维。
9. 现象：OceanBase 向量写入含 NaN / Inf。原因：元素仅单精度 float，禁止 NaN / Inf。怎么做：写入前清洗。
10. 现象：OceanBase 用了 SPARSEVECTOR 却查不到能力。原因：稀疏向量自 V4.3.5 BP2 起支持。怎么做：核对版本节点。
11. 现象：把别的产品的 pre/post-filter 结论套到国产库。原因：三者过滤官方语义官方资料未给出。怎么做：以 EXPLAIN 与实测为准，勿臆测。
12. 现象：大表加 VECTOR INDEX / 删索引拖垮业务。原因：DDL 占资源、索引结构绑定。怎么做：⚠️ 维护窗口 + 备份 + 回滚方案，可能引发线上事故。

10. 速查表（横向对照）

11. 参考与延伸

官方 / 资料链接清单

与同册其他产品的关系：已有国产关系库 → 本篇；已有 PG → pgvector.md；已有 ES / OpenSearch → Elasticsearch-OpenSearch.md；已有 Redis → Redis-Vector-Search.md；已有 ClickHouse → ClickHouse.md；需 Milvus SDK 100% 兼容 / 专用向量库 → 01-专用向量数据库 分册。

进阶阅读：OceanBase 向量类型与 VECTOR INDEX 参数、pyobvector 的 MilvusLikeClient 兼容边界；GaussDB 的 GsDiskANN / GsIVFFLAT 维度与排序限制、BM25 / Tokenweight；金仓须向厂商复核第三方资料。

本篇「未核实 / 以官方为准」事项：

1. OceanBase 2026 最新稳定版本号与许可证未核实（清单第 7 条）。
2. 华为 GaussDB 公有云当前稳定版本号未核实；是否兼容 Milvus SDK 未核实，且未找到官方兼容声明（清单第 7 条），接入方式为 SQL / gsql。
3. 金仓 KES Vector 全部细节来自第三方选型资料，官方未核实（内核级向量引擎、多表关联、高维检索、事务一致性、信创适配、暂不支持 GPU、索引构建内存占用高），不得写成官方声明。
4. OceanBase 向量检索运算符 / 函数的逐字写法未核实，5.2 未给臆造查询体，按官方文档构造。
5. pyobvector 的 MilvusLikeClient / ObVecClient 实例化签名与方法参数未核实，5.4 只给导入与兼容性核对。
6. 三者端口、安装命令、控制台 / SDK / 镜像仓库 URL、监控端点官方资料未提供，勿臆测。
7. 三者过滤 pre/post 官方语义未核实，6.4 只给经验性说明，须以执行计划与实测为准。
8. 距离方向（L2 / <-> 等）的逐值口径、SELECT version() / EXPLAIN / DESC / 通用 DML 属通用知识与经验性表述，以各产品官方文档为准。
9. 规模、QPS、容量公式、告警阈值均为经验值，非官方承诺，须实测；OceanBase HNSW_BQ 「降约 95% 内存」为官方称，具体口径以官方为准。