轻量级向量数据库GoVector的设计与实现

1. 为什么我们需要轻量级向量数据库？

在AI应用爆发的今天，检索增强生成（RAG）已成为构建智能应用的标准范式。但当我们尝试在桌面端或边缘设备部署RAG时，传统向量数据库的局限性就暴露无遗。

1.1 现有方案的痛点分析

当前主流向量数据库如Qdrant、Milvus等，都是为云原生和海量数据设计的。它们确实强大，但存在几个致命问题：

• 资源消耗大：启动一个Qdrant实例至少需要几百MB内存，这对于本地应用来说简直是资源浪费
• 依赖复杂：需要Docker容器支持，增加了部署复杂度
• 过度设计：分布式架构、高可用特性对于小型应用完全是冗余的

而像SQLite+pgvector这样的方案，虽然轻量，但引入了CGO依赖，导致Go项目的交叉编译变得异常困难。

1.2 理想解决方案的特征

一个理想的嵌入式向量数据库应该具备以下特点：

1. 零外部依赖：纯Go实现，无需CGO，一个go build就能搞定所有平台
2. 单文件存储：像SQLite一样将所有数据保存在单个文件中
3. 高性能检索：支持近似最近邻搜索算法，如HNSW
4. 元数据过滤：支持基于payload的条件筛选
5. API兼容性：与主流向量数据库API兼容，便于迁移

2. 架构设计与技术选型

2.1 核心组件拆解

一个完整的向量数据库可以分解为三个核心组件：

1. 存储引擎：负责数据持久化
2. 索引引擎：实现高效向量检索
3. 服务层：提供外部访问接口

2.2 技术选型详解

存储引擎：BoltDB

选择go.etcd.io/bbolt(BoltDB)的原因：

• 纯Go实现，无CGO依赖
• 基于B+树的KV存储，性能优异
• 支持ACID事务
• 单文件存储，便于管理

go复制import "go.etcd.io/bbolt"

// 初始化数据库
db, err := bbolt.Open("vector.db", 0600, nil)
if err != nil {
    return err
}
defer db.Close()

索引引擎：HNSW

HNSW（Hierarchical Navigable Small World）是目前最优秀的近似最近邻搜索算法之一。我们选择github.com/coder/hnsw这个纯Go实现，因为：

• 无CGO依赖
• 支持多种距离度量（余弦、欧式等）
• 查询复杂度接近O(log N)

go复制import "github.com/coder/hnsw"

// 创建HNSW索引
h := hnsw.New(hnsw.Config{
    Dimensions:   128,
    DistanceType: hnsw.Cosine,
    M:            16,
    EfConstruction: 200,
})

服务层：原生HTTP

使用Go标准库net/http实现REST API，避免引入第三方框架：

• 零依赖
• 性能足够
• 易于维护

3. 核心实现细节

3.1 数据模型设计

为了兼容Qdrant，我们的数据模型需要与其保持一致：

go复制type Payload map[string]interf