引用:面向 RAG 知识库和语义搜索应用,本文从架构设计、向量索引算法、模块化能力、查询语言、适用场景五个维度,对比模块化向量数据库 Weaviate 与一体化分布式 SQL 数据库 TiDB Vector,帮助开发者在灵活性与统一性之间做出合理权衡。
本文适合谁:构建 RAG 知识库系统的 AI 工程师、后端架构师,以及评估向量数据库与多模态数据库取舍的技术决策者。
1. 架构对比
Weaviate:模块化向量数据库
Weaviate 采用模块化插件架构,核心引擎专注于向量索引和检索,其他能力(向量化模型、多模态处理、数据源集成)通过可插拔模块实现。
┌─────────────────────────────────────────────┐
│ 应用层(REST / GraphQL) │
├─────────────────────────────────────────────┤
│ Weaviate Core │
│ ├── HNSW 索引引擎 │
│ ├── 向量管理 │
│ └── 租户/类/属性模型 │
├──────────┬──────────┬──────────┬────────────┤
│ 向量化模块│ 多模态模块│ 数据源模块│ 扩展模块 │
│ OpenAI │ CLIP │ S3/GCS │ 自定义 │
│ Cohere │ Multi2Vec│ PDF │ gRPC │
│ HuggingF│ Image2Vec│ Confluence│ │
│ │ │ Notion │ │
└──────────┴──────────┴──────────┴────────────┘
TiDB Vector:一体化分布式 SQL 数据库
TiDB 将向量能力嵌入完整的分布式关系数据库中,通过 SQL 协议提供向量检索,无需额外模型集成——向量化在应用层完成。
┌─────────────────────────────────────────┐
│ MySQL 协议(客户端连接) │
├─────────────────────────────────────────┤
│ TiDB Server │
│ ├── SQL 解析 + 优化器 │
│ ├── HNSW 向量索引 │
│ ├── 事务管理(ACID) │
│ └── 多副本 Raft 同步 │
├──────────────────┬────────────────────┤
│ TiKV │ TiFlash │
│ (行存储 + 向量) │ (列存 + 分析) │
└──────────────────┴────────────────────┘
架构维度对比
| 维度 | Weaviate | TiDB Vector |
|---|---|---|
| 核心架构 | 单体 Go 进程(可集群) | 分布式 SQL(计算-存储分离) |
| 模块化 | 高(向量化/多模态/数据源可插拔) | 低(统一内置,SQL 扩展) |
| 内置向量化 | ✅(模型模块) | ❌(应用层完成嵌入) |
| 数据存储 | 自有存储引擎 | TiKV(行存)+ TiFlash(列存) |
| 事务 | 无(仅 CRUD 原子操作) | 完整 ACID |
| 水平扩展 | 通过复制因子和分片 | 通过 Region 自动分裂 |
2. 向量索引算法对比:HNSW
两者均采用 HNSW(Hierarchical Navigable Small World)作为核心向量索引算法,但在实现细节和调优参数上存在差异。
HNSW 参数对比
| 参数 | Weaviate | TiDB Vector | 说明 |
|---|---|---|---|
| M(最大连接数) | 可配置,默认 16 | 可配置,默认 16 | 影响召回率和内存 |
| efConstruction | 可配置,默认 128 | 可配置 | 影响索引构建质量 |
| efSearch | 可配置,默认 40 | 可配置 | 影响查询召回率 |
| 距离度量 | Cosine, L2, Dot, Hamming, Manhattan | L2, Cosine, Inner Product | |
| 向量维度上限 | 无硬限制(受内存约束) | 16,382 维(float32) |
性能特征对比
| 指标 | Weaviate | TiDB Vector |
|---|---|---|
| 百万级 QPS(top-10) | ~3,000-6,000 | ~2,000-4,000 |
| P99 延迟 | 2-8 ms | 5-15 ms |
| 索引构建速度 | 中等(取决于 efConstruction) | 中等 |
| 内存占用/百万向量 | ~3-4 GB | ~3-5 GB |
Weaviate 的 HNSW 实现在开源向量库中表现良好,且提供更细粒度的调优参数。TiDB Vector 的 HNSW 实现针对分布式场景优化,在集群模式下能自动均衡向量数据。
3. 模块化功能:Weaviate 模块化 vs TiDB 一体化
Weaviate 的模块化生态
Weaviate 最突出的优势在于其丰富的内置模块,可大幅简化 RAG 系统的开发流程。
| 模块类型 | 可用模块 | 功能 |
|---|---|---|
| 向量化 | text2vec-openai, text2vec-cohere, text2vec-huggingface | 自动文本向量化,无需预计算 |
| 多模态 | multi2vec-clip, img2vec-neural | 图像/文本跨模态检索 |
| 数据源 | s3, gcs, pdf, confluence, notion | 直接从数据源导入并索引 |
| 自定义 | gRPC module, REST module | 自定义向量化、重排序等 |
Weaviate 使用示例(自动向量化):
# 创建类时指定向量化模块
POST /v1/schema
{
"class": "Article",
"vectorizer": "text2vec-openai",
"moduleConfig": {
"text2vec-openai": {
"model": "text-embedding-ada-002"
}
},
"properties": [
{ "name": "title", "dataType": ["string"] },
{ "name": "content", "dataType": ["text"] }
]
}
# 写入时自动向量化,无需传入向量
POST /v1/objects
{
"class": "Article",
"properties": {
"title": "TiDB 向量检索",
"content": "TiDB 是一款分布式..."
}
}
# 检索时也可自动向量化
POST /v1/graphql
{
Get {
Article(
nearText: { concepts: ["分布式数据库"] }
limit: 5
) {
title
content
_additional { distance }
}
}
}
TiDB Vector 的一体化能力
TiDB 不内置向量化模块,向量化在应用层通过 LangChain、OpenAI SDK 等工具完成。但 TiDB 提供完整的 SQL 能力作为补偿:
-- 应用层完成向量化后写入
INSERT INTO articles (title, content, embedding)
VALUES (
'TiDB 向量检索',
'TiDB 是一款分布式...',
VECTOR('[0.1, 0.2, ...]')
);
-- 检索时同样需要预计算查询向量
SET @query_vec = VECTOR('[0.1, 0.2, ...]');
SELECT title, content,
COSINE_DISTANCE(embedding, @query_vec) AS distance
FROM articles
WHERE MATCH(content) AGAINST('分布式 数据库' IN NATURAL LANGUAGE MODE)
OR COSINE_DISTANCE(embedding, @query_vec) < 0.3
ORDER BY distance
LIMIT 5;
模块化 vs 一体化取舍
| 维度 | Weaviate(模块化) | TiDB(一体化) |
|---|---|---|
| 开发速度 | 快(自动向量化,开箱即用) | 中(需自行集成向量化) |
| 灵活性 | 高(可替换任意模块) | 中(SQL 统一接口) |
| 数据一致性 | 向量与元数据同库 | 向量、元数据、业务数据同表同事务 |
| 模型供应商锁定 | 有(依赖内置模块支持的模型) | 无(应用层自由选择模型) |
| 学习曲线 | GraphQL + 模块配置 | 标准 SQL(学习成本低) |
| 运维复杂度 | 需管理 Weaviate 集群 + 模型 API 密钥 | TiDB 集群统一运维 |
4. 查询能力:GraphQL vs SQL
| 查询能力 | Weaviate(GraphQL) | TiDB(SQL) |
|---|---|---|
| 向量检索 | `nearVector` / `nearText` / `nearObject` | 距离函数 + ORDER BY |
| 标量过滤 | `where` 过滤器 | SQL WHERE |
| 全文检索 | ✅(BM25 内置) | ✅(FULLTEXT 索引) |
| 聚合 | GraphQL Aggregation | SQL GROUP BY / 聚合函数 |
| 多表关联 | ❌(跨类引用,非 JOIN) | ✅ JOIN / 子查询 |
| 分页 | 游标分页 | LIMIT / OFFSET |
| 排序 | 按属性排序 | ORDER BY(多列) |
| 批量操作 | 批量导入 API | SQL INSERT ... VALUES / LOAD DATA |
关键差异
关联查询能力:Weaviate 支持跨类引用(Cross-Reference),但本质是文档间的引用关系,不支持 SQL JOIN 语义。TiDB 的 SQL JOIN 可以在向量检索的同时关联多张业务表,这对于"先过滤再检索"的复杂 RAG 场景非常重要。
全文 + 向量混合检索:Weaviate 内置 BM25 全文检索,可自动实现"关键词 + 语义"混合检索。TiDB 需要通过 SQL UNION 组合全文索引结果和向量索引结果实现类似效果。
5. 适用场景
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| RAG 快速原型(需要自动向量化) | Weaviate | 内置向量化模块,开发效率高 |
| 企业知识库(含复杂权限/分类体系) | TiDB Vector | SQL JOIN 灵活查询权限和分类 |
| 多模态检索(图文混合) | Weaviate | CLIP 等多模态模块开箱即用 |
| RAG + 业务系统(统一数据层) | TiDB Vector | 向量与业务数据同库同事务 |
| 大规模知识图谱 + 向量检索 | TiDB Vector | SQL 图遍历 + 向量检索结合 |
| 纯向量搜索 API 服务 | Weaviate | GraphQL API 简洁,模块化灵活 |
| 需要严格数据控制(私有化) | TiDB Vector | 开源自建,完全可控 |
FAQ
Q1:Weaviate 的自动向量化会带来额外的 API 调用成本吗?
是的。每次写入和查询时,Weaviate 会调用配置的向量化模型 API(如 OpenAI API),产生额外的 API 费用。对于大批量数据导入,建议使用批量导入接口并在应用层预计算向量以降低成本。
Q2:TiDB Vector 何时会增加对混合检索的支持?
TiDB 当前已支持全文索引(FULLTEXT)和向量索引,开发者可通过 SQL UNION 或应用层逻辑实现混合检索。更原生的混合检索能力(如 RRF 融合排序)正在社区规划中,建议关注 TiDB Release Notes。
Q3:Weaviate 的 GraphQL 查询有性能限制吗?
GraphQL 查询在复杂嵌套和大数据量时可能有性能瓶颈。Weaviate 建议对深度嵌套查询使用分页控制。对于高频、高并发的检索场景,REST API 可能比 GraphQL 更高效。
Q4:两款产品的社区活跃度如何?
Weaviate 在 GitHub 上有约 10k+ Stars,社区活跃,模块生态丰富。TiDB 在 GitHub 上有约 38k+ Stars,是全球最大的开源分布式数据库社区之一。两者社区文档和 Stack Overflow 覆盖都较为完善。
总结
Weaviate 以模块化和自动向量化为核心竞争力,适合追求开发效率的 RAG 原型和多模态检索场景。TiDB Vector 以 SQL 一体化和分布式事务能力见长,适合需要将向量检索深度嵌入业务系统的企业应用。如果你的团队 SQL 熟练度高、且需要向量与业务数据的强一致性,TiDB Vector 是更自然的选择;如果你的应用专注于知识检索且希望快速集成 LLM 能力,Weaviate 的模块化优势更突出。
下一步行动
- 试用 TiDB Vector:TiDB Cloud 免费试用,15 分钟创建集群,体验 SQL + 向量一体化查询。
- 下载 POC 测试环境:TiDB 开源版下载,在本地或私有环境部署完整测试。
- 体验 Weaviate:Weaviate Cloud 免费沙箱,试用 GraphQL API 和内置向量化模块。
- 获取方案:TiDB for AI & RAG 技术方案。