vectordb
vectordb-io/vectordb加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
2024 年，大模型浪潮席卷整个 AI 行业。在无数企业争相部署 RAG（检索增强生成）系统的背后，一个关键问题浮出水面：向量数据库的选择。Milvus 需要 K8s，Qdrant 需要 Docker，Chroma 性能有限——它们都很好，但都带着"现代基础设施"的包袱。
那么，有没有一个方案，能让开发者在没有 Kubernetes 集群、没有 Docker 环境的条件下，直接在服务器上编译运行一个完整的向量数据库？
这就是 VectorDB（vectordb-io/vectordb）尝试回答的问题。它用 C++ 从零构建，支持向量、图、会话、KV 等多种数据模型的统一管理，代码超过 95% 由 AI 生成。这个项目在 GitHub 获得了 48 颗星，虽然规模不大，却代表了一种独特的工程路线。
VectorDB 的开发历程本身就是一个有趣的实验。项目作者在 README 中坦言：超过 95% 的代码工作由 AI 完成，包括编码、测试、运维和客服。这一比例在开源社区极为罕见，大多数项目即便引入 AI 辅助工具，也只是用来处理部分重复性代码，而非主导整个开发流程。
项目基于另一个名为 "vraft" 的分布式架构项目构建，后者提供了 Raft 一致性协议的实现。这使得 VectorDB 在诞生之初就具备了分布式扩展的基因，而非一个单机玩具。
从时间线来看，项目启动于 2021 年 6 月，最近一次更新为 2026 年 1 月 29 日，项目处于活跃维护状态。作为对比，许多早期向量数据库项目（如 2019-2020 年间诞生的）目前已处于维护模式。
VectorDB 的源码结构清晰地划分为五个核心模块：
| 模块 | 目录 | 职责 |
|---|---|---|
| VDB | src/vdb/ | 向量索引与核心数据库操作（C++17 编写） |
| VGraph | src/vgraph/ | 图数据库引擎，基于 LevelDB |
| SEDA | src/seda/ | 分阶段异步事件驱动架构（类似 Staged Event-Driven Architecture） |
| Raft | src/raft/ | 分布式一致性协议实现 |
| Util | src/util/ | 工具库（日志、JSON 转换等） |
在 src/vdb/ 目录中，vindex.cc 负责向量索引的核心逻辑，底层依赖 HNSWlib（Hierarchical Navigable Small World）算法。HNSW 是当前最流行的近似最近邻（ANN）搜索算法之一，通过构建多层图结构实现 O(log n) 的查询复杂度，在精度与速度之间取得良好平衡。
距离计算在 distance.cc 中实现，支持欧氏距离（L2）和余弦相似度等常用度量。这是向量数据库的性能关键点，VectorDB 在此做了独立封装而非直接调用 HNSWlib 内置实现，提供了更灵活的定制空间。
VGraph 是 VectorDB 体系中的图数据库引擎，基于 LevelDB 作为底层存储。它提供 HTTP 接口，支持节点和边的增删改查、最短路径查询、N 度邻居查询等图操作。VGraph 还附带一个 Python Flask Web 可视化界面，让用户可以在浏览器中直观地操作图数据——添加节点、连接边、高亮最短路径。
不过值得注意的是，VGraph 的 Web 界面是独立部署的（需要单独启动 Python Flask 服务），与主数据库引擎是分离的两套系统，增加了部署复杂度。
src/seda/ 中的代码实现了 Staged Event-Driven Architecture，这是高性能服务器程序的经典设计模式。通过将请求处理流程拆分为多个阶段（Acceptor → Stage → ... → Handler），每个阶段通过异步队列解耦，可以有效提升并发处理能力。SEDA 在数据库系统中的典型应用场景是：将网络 I/O、协议解析、业务逻辑、存储写入等操作解耦独立处理，避免阻塞。
src/raft/ 实现了 Raft 协议的关键组件：AppendEntries（日志复制）、ClientRequest（客户端请求处理）、IndexManager（索引管理）、InstallSnapshot（快照同步）等。这为 VectorDB 的集群模式奠定了基础——多个节点可以组成 Raft 复制组，保证数据一致性与高可用。
VectorDB 在技术选型上展现了扎实的工程品味：
依赖管理采用 Git Submodule 方式，第三方库存放在 third_party/ 目录。编译系统为标准 Makefile，支持 ASAN（AddressSanitizer）内存检测和代码覆盖率统计，体现了对代码质量的重视。
VectorDB 的部署门槛主要在编译环节。项目要求 Ubuntu 24.04.2 LTS 环境，且依赖较多：
# 安装编译工具链
sudo apt install autoconf automake libtool -y
sudo apt-get install libgflags-dev libsnappy-dev zlib1g-dev libbz2-dev liblz4-dev libzstd-dev -y
# 初始化子模块
git submodule update --init
cd third_party && sh onekey.sh && cd -
# 编译
make proto && make -j4
编译完成后通过 make run 执行测试。没有容器化支持，没有预编译二进制包，这意味着每个部署环境都需要独立处理依赖版本兼容性问题。对于追求"开箱即用"的开发者来说，这是明显的短板。
另一方面，项目提供了 run_test.sh 脚本，支持传入 --model 和 --tool 参数，用于测试不同 AI 模型和工具生成的代码质量——这呼应了项目"AI 辅助开发"的主题。
VectorDB 并非万能解决方案，了解其边界很重要：
1. 缺乏成熟生态 不像 Milvus 有完整的周边工具（监控、备份、客户端 SDK），VectorDB 目前仅提供基础数据库功能。没有 Python/Go/Java 客户端 SDK，没有管理界面，没有监控指标导出。在生产环境中，这意味着大量工作需要自行实现。
2. 分布式能力未经验证 虽然代码中有 Raft 实现，但 README 和文档中未提供集群部署指南。Raft 的一致性协议本身是正确的，但分布式系统的实际可用性需要大量调优和测试，这一块尚属空白。
3. 性能数据缺失 项目明确标注 "performance to be completed"，缺乏基准测试数据（吞吐量、QPS、延迟 P99 等）。在向量数据库领域，没有性能数据的项目很难让用户建立信心。
4. 许可证存疑
项目根目录无 LICENSE 文件，/repos API 返回 license: null。这在商业使用时会带来法律风险——使用前必须与作者确认许可条款。
5. AI 生成代码的维护挑战 95% AI 生成代码是一把双刃剑。短期内可以快速迭代，但随着项目复杂度提升，AI 生成代码的可维护性、可读性、以及潜在的隐藏 bug 将成为隐患。
尽管存在诸多局限，VectorDB 的出现折射出几个值得关注的趋势：
AI 辅助全栈开发正在成为现实。 超过 95% 代码由 AI 生成，这个比例即便在 2026 年也属罕见。它证明了在特定领域（大厂基础设施之外的定制化数据库开发），AI 辅助已经可以承担主要的工程工作。当然，这也意味着需要更高水平的 AI 提示工程和代码 review 能力。
多模态数据库的统一趋势。 VectorDB 同时支持向量、图、KV、会话等多种数据模型，代表了数据库领域"大一统"的探索方向。虽然每个子模块的深度都不及专门的单模态数据库，但统一 API 和统一存储层的思路，对于简化 RAG 系统的架构设计有潜在价值。
C++ 在 AI 基础设施中的持久生命力。 在 Python 统治 AI 模型训练的时代，VectorDB 选择 C++ 作为核心语言是深思熟虑的——数据库引擎对性能极度敏感，C++ 可以提供 Python 无法企及的控制粒度。HNSWlib、RocksDB 等核心依赖也全是 C/C++ 实现。
VectorDB 是一个特色鲜明的技术项目：它用 C++ 从零构建了一个多模态数据库引擎，代码主要由 AI 生成，具备分布式扩展的架构基础，但缺乏容器化、缺少文档、性能数据空白、许可证不明确。对于想要深入理解向量数据库内部原理的开发者，这是一个值得研究的代码库；对于需要在生产环境部署向量检索能力的团队，当前的成熟度还不足以支撑关键业务。
它更像是一面镜子，映照出 AI 辅助开发的现状与未来可能。