不同向量库索引的存储位置
一、澄清：索引和向量库的关系
“向量库”本质上就是一个专门存储向量+索引的数据库。
| 组件 | 说明 |
|---|---|
| 原始向量数据 | 每一条文本对应的浮点数数组 |
| 索引结构 | HNSW的图、IVF的聚类中心、PQ的压缩码本 — 这些都是为了加速检索而额外构建和存储的数据结构 |
| 二者关系 | 索引是向量库的一部分，就像书的目录是书的一部分 |
所以：
“建索引” = 在向量库里创建这些加速结构
“索引在内存” = 向量库把这些结构加载到 RAM 中
“索引在磁盘” = 向量库只在需要时从 SSD 读取
二、索引到底存在哪里？
向量库的存储架构（以 Milvus / Qdrant 为例）
向量库 ├── 原始向量数据 ──► 存储在磁盘（.bin/.col 文件） │ │ │ └──► 查询时：根据配置决定是否加载到内存 │ └── 索引结构 ──► 根据索引类型和配置决定存储位置 │ ├── HNSW：图结构 (邻接表) — 默认全量加载到内存（快） ├── IVF：聚类中心 + 倒排列表 — 可配置内存或磁盘 └── PQ：压缩码本 — 体积小，通常放内存
各索引类型的实际存储位置
| 索引 | 存储的物理内容 | 典型位置 | 原因 |
|---|---|---|---|
| Flat | 无索引，只有原始向量 | 磁盘（查询时顺读） | 不需要额外结构，暴力计算 |
| HNSW | 多层图（每个向量的邻居指针） | 全量内存 | 检索需要频繁随机访问邻居，磁盘太慢 |
| IVF | 聚类中心 + 每个簇的向量 ID 列表 | 可配置：内存或磁盘 | 检索时先算中心（需内存），再遍历簇（可从磁盘读） |
| IVF+PQ | 聚类中心 + 压缩码本 + 倒排 ID | 码本放内存，倒排查磁盘 | PQ 压缩后内存很小；倒排可放磁盘以节省内存 |
三、为什么 HNSW 必须放在内存？
HNSW 的检索过程是：从高层入口点开始，沿着图结构反复跳跃到最近的邻居，直到底层。
这个过程需要极其频繁的随机访问（访问某个向量的邻居列表）。如果是磁盘 I/O，一次查询可能触发几百上千次随机读，延迟会从毫秒级变成秒级甚至分钟级。
所以 HNSW 几乎总是要求全量加载到内存——这也是它内存消耗大的根本原因。
四、为什么 IVF 可以放磁盘？
IVF 的检索过程是：
计算问题向量与聚类中心的距离 → 选出 Top-1 个簇（需要内存）
在这个簇内，遍历所有向量的 ID 列表（可以从磁盘顺序读取）
关键区别：第二步是顺序遍历一个簇，不是 HNSW 那种随机跳跃。SSD 的顺序读取很快（几十微秒/条），所以 IVF 可以接受从磁盘读取向量。
配置示例（Milvus）：
# IVF 索引，数据放磁盘，查询时按需加载 index_type: IVF_FLAT index_params: { "nlist": 1024 } storage: disk # 可选：memory、disk、mmap五、实战选型时的内存估算
| 场景 | 数据量 (1536 维 float32) | Flat | HNSW | IVF | IVF+PQ |
|---|---|---|---|---|---|
| 原始向量存储 | 100 万条 | ~6.1 GB | 6.1 GB | 6.1 GB | 1.5 GB (PQ 8x 压缩) |
| 索引额外开销 | 100 万条 | 0 | ~8-12 GB(图结构) | ~0.5-1 GB (聚类中心+倒排) | ~0.5-1 GB |
| 总计内存占用 | 100 万条 | 6.1 GB (全磁盘) | ~14-18 GB | ~6.6-7.1 GB (混合) | ~2.0-2.5 GB |
| 命中延迟 | — | 200 ms | 8 ms | 50 ms | 60 ms |
选型逻辑：
内存充足（> 32 GB）、要求极低延迟 →HNSW
内存有限（16 GB）、中等延迟可接受 →IVF(混合存储)
内存极有限（4-8 GB）、海量数据 →IVF+PQ
六、一句话总结
索引是向量库的一部分，可以配置在内存或磁盘上。
HNSW 必须全量内存（快但贵），IVF/PQ 可以混合存储（省内存但稍慢）。
选型的本质是内存预算 vs 延迟要求的权衡。