xb

向量数据库技术跟踪

🎯 技术选型策略

xb 当前策略:专注支持 Qdrant 一个向量数据库。

原因


📅 定期评估计划

每季度:Qdrant API 同步

时间:1 月、4 月、7 月、10 月

检查内容

  1. Qdrant Release Notes: https://github.com/qdrant/qdrant/releases
  2. API 文档变化: https://qdrant.tech/documentation/
  3. Go Client 更新: https://github.com/qdrant/go-client

关注点

行动


每半年:新兴向量数据库评估

时间:1 月、7 月

评估对象

1. LanceDB ⭐ 重点关注

地址: https://github.com/lancedb/lancedb

关注原因

评估标准

行动


2. pgvector 2.0+

地址: https://github.com/pgvector/pgvector

关注原因

评估标准

行动


3. 其他新兴产品

监控列表

评估周期:每半年快速调研


🎯 替换 Qdrant 的标准

必须满足所有条件

1. ✅ 性能明显优于 Qdrant (>30%)
2. ✅ API 更简洁或更适合 xb
3. ✅ 开源且许可友好(Apache 2.0 或 MIT)
4. ✅ 社区活跃度高(GitHub stars >5K)
5. ✅ 生产级稳定(至少 1.0 正式版)
6. ✅ 完整文档和示例
7. ✅ Go 客户端支持良好

决策流程

发现潜在替代品
  ↓
初步评估(文档、社区)
  ↓
性能测试(10M 向量)
  ↓
API 适配性分析
  ↓
满足所有标准?
  ├── ✅ 是 → 规划迁移(至少 2 个版本过渡期)
  └── ❌ 否 → 保持 Qdrant

🔄 支持第二个向量数据库的标准

何时考虑支持第二个?

只在以下情况:

1. 明确的场景差异
   示例: Qdrant(云端大规模)+ 自研(本地小规模)
   
2. 用户强烈需求
   示例: 50+ 用户请求同一个数据库支持
   
3. 维护成本可接受
   示例: API 非常相似,可复用 80% 代码

🛠️ 自研向量数据库评估

何时考虑自研?

场景:
  - 政府/大企业内部系统
  - 数据安全要求极高
  - 运行在专用 AI 电脑(非云端)
  - 需要深度定制

优势:
  ✅ 完全可控
  ✅ 深度集成 xb
  ✅ 针对特定场景优化

劣势:
  ❌ 研发成本高
  ❌ 维护负担重
  ❌ 性能可能不如成熟产品

决策:
  只有在明确需要且资源充足时才考虑

📊 当前状态 (2025-10-26)

Qdrant 状态


潜在替代品状态

数据库 版本 性能 vs Qdrant API 简洁度 评估结论
LanceDB 0.x (Beta) 未测试 SQL 支持 ⭐ 关注中
pgvector 0.5.x ~60% 完美契合 小规模可用
Chroma 0.4.x ~50% 一般 暂不考虑
Milvus 2.x ~90% 复杂 暂不考虑

下次评估时间


🎯 维护清单

Qdrant 相关文件

xb/
├── to_qdrant_json.go          ⭐ 核心实现
├── qdrant_test.go             ⭐ 测试
├── doc/
│   ├── VECTOR_DIVERSITY_QDRANT.md        使用指南
│   ├── QDRANT_NIL_FILTER_AND_JOIN.md     nil/0 过滤
│   └── QDRANT_API_SYNC_STRATEGY.md       ⭐ 本文档

每季度检查

每半年评估


💡 总结

核心策略

当前: 专注 Qdrant ⭐
  - 足够用
  - 避免过度设计
  - 降低维护成本

未来: 持续评估
  - 每季度同步 Qdrant API
  - 每半年评估新兴产品
  - 只在有明显优势时才替换

长期: 保持灵活
  - API 独立于 Qdrant
  - 用户代码不绑定特定数据库
  - 随时可以切换

务实的技术选型 + 持续的技术跟踪 = 长期成功

Qdrant 一个就够了,但要保持关注新技术! 🚀