向量数据库的内存与磁盘博弈：当数据量超过内存时怎么办

一句话总结：向量数据正在以远超内存扩容速度的方式膨胀，全内存方案正在成为成本不可承受之重，而如何在性能与成本之间找到"甜蜜点"，是每一位架构师必须面对的决策。

一、问题的本质：为什么向量数据库的内存问题格外棘手？

1.1 数据膨胀的三重压力

与传统数据库不同，向量数据库面临的是三重叠加的膨胀压力：

一个真实场景：某内容平台的图片向量库，使用 CLIP 模型生成 1024 维 float32 向量，单条 4KB。1 亿张图片就是 400GB 原始向量数据。加上 HNSW 索引，整体内存需求轻松突破 1TB。而业务还在以每月 20% 的速度增长。

1.2 全内存方案的"成本悬崖"

当数据量跨过某个阈值，成本曲线不再是线性增长，而是呈现**"成本悬崖"**。

核心矛盾：

• 向量检索是计算密集型操作，内存访问延迟直接决定 QPS
• 但向量数据又是存储密集型，内存无法无限扩容
• 磁盘虽然便宜，但随机 I/O 的延迟是内存的 10^5 倍量级

二、方案一：内存映射（mmap）—— 把磁盘伪装成内存

2.1 mmap 的工作原理与诱惑

mmap 将磁盘文件直接映射到进程虚拟地址空间，由 OS 的页缓存（Page Cache）负责按需加载。

void* addr = mmap(NULL, file_size, PROT_READ, MAP_SHARED, fd, 0);
// 之后像访问内存一样访问 addr，缺页时 OS 自动从磁盘加载

对向量数据库的吸引力：零拷贝、透明缓存、代码侵入性低。

2.2 性能真相

基于 HNSW 索引，768 维向量，ef=128 的实测数据：

关键洞察：

1. 页缺失惩罚极高：一次缺页需 0.1-1ms（SSD），而 HNSW 一次查询可能访问数千个节点，每次查询触发数十次缺页是常态。

2. 访问模式的"死亡螺旋"：HNSW 的图遍历是随机访问，与 OS 页缓存的预读机制背道而驰。

3. 量化后索引不适合 mmap：PQ 压缩后的倒排列表访问仍是随机的，mmap 收益有限。

2.3 mmap 的适用边界

• ✅ 索引结构仍常驻内存，仅原始向量 mmap
• ✅ 查询模式可预测（如固定时间窗口）
• ✅ 作为灾备/副本的降级方案
• ❌ 高并发、低延迟的在线服务
• ❌ 数据访问完全随机

三、方案二：磁盘索引——为磁盘重新设计数据结构

3.1 代表方案一：DiskANN

微软提出的 DiskANN，核心设计：

[内存层]：轻量级导航图（Vamana），只存向量 ID 和精简邻居信息
    ↓
[磁盘层]：原始向量数据按特定布局存储，配合压缩的邻居列表

关键优化：

• 一次 I/O 读取一个完整节点：将向量和邻居打包在同一磁盘页（4-8KB），减少 I/O 次数
• 扇出控制：限制出度，确保一次磁盘读取能拿到所有邻居
• 异步预取：利用查询局部性，在计算当前节点距离时异步预取下一跳

性能对比（SIFT1M 数据集）：

3.2 代表方案二：SPANN

采用分而治之策略：

• 将向量空间划分为多个聚类中心
• 每个聚类内向量存于连续磁盘块
• 查询时先定位聚类中心（内存），再顺序读取候选聚类的向量数据

优势：将随机 I/O 转化为顺序 I/O，磁盘带宽利用率大幅提升。

3.3 磁盘索引的代价

决策点：磁盘索引适合读多写少、数据量极大、对延迟有一定容忍度的场景。

四、方案三：冷热数据分层——让内存只存"值得存"的数据

4.1 分层架构

[热层]：全内存，HNSW 索引，\<10ms 延迟
    ↓ 按天/周迁移
[温层]：内存索引 + mmap 向量 / DiskANN，\<100ms 延迟
    ↓ 按月迁移
[冷层]：纯磁盘索引或对象存储，按需加载，秒级延迟
    ↓ 归档
[冰层]：压缩归档，仅合规/审计需要

4.2 热层判定策略

4.3 冷数据"唤醒"机制

• 预热策略：批量查询前预先加载相关分区
• 懒加载 + 缓存：首次查询冷数据时提升到温层，设置 TTL
• 查询路由：根据查询条件（时间范围、用户 ID 等）直接路由到对应层

def search(query_vector, filters):
    if filters.time_range > 30_days:
        return cold_storage.search(query_vector, filters)
    elif filters.user_tier == "VIP":
        return hot_cluster.search(query_vector, filters)
    else:
        return warm_cluster.search(query_vector, filters)

五、方案四：量化压缩——用精度换空间

5.1 Scalar Quantization（SQ）

原始：768 维 × 4 字节 = 3,072 字节
SQ：768 维 × 1 字节 = 768 字节
压缩率：4x

• 归一化后的向量：通常只有 0.5-2% 的召回率下降
• 未经归一化的向量：可能损失 5-10%

5.2 Product Quantization（PQ）

原始向量：768 维
切分为 M=8 个子空间，每段 96 维
每段用 k-means 聚为 256 个中心（8 bit）
存储：8 个 codebook 索引 = 8 字节
压缩率：384x

5.3 混合策略：粗量化 + 精排序

Step 1: 用 PQ/IVF_PQ 在内存中快速召回 Top-100（粗排）
Step 2: 从磁盘加载 Top-100 的原始 float32 向量（精确数据）
Step 3: 用原始向量精确计算距离，重排序返回 Top-10（精排）

收益：内存降低 10-50 倍，同时保持 95%+ 的有效召回。

六、方案五：分布式分片（Sharding）—— 水平扩展

6.1 数据分片 vs 空间分片

数据分片：按向量 ID 切，每次查询需广播到所有分片，延迟取决于最慢的分片。

空间分片（更优）：按向量空间的聚类划分，查询时先路由到 1-3 个相关分片，再局部检索。

6.2 分片与存储介质的协同

6.3 分片的陷阱

• 热点分片：需要动态再平衡
• 跨分片查询：退化为广播模式
• 数据倾斜：考虑用一致性哈希做二次分片

七、决策框架

开始
  │
  ├─ 数据量 < 内存容量？ ──→ 全内存 HNSW，简单高效
  │
  ├─ 延迟要求 < 50ms P99？
  │    │
  │    ├─ 是 → 有明确冷热模式？ ——→ 冷热分层 + 热层全内存
  │    │         └─ 访问完全随机？——→ 量化压缩 + 全内存索引
  │    │
  │    └─ 否 → 数据更新频繁？ ——→ DiskANN 类磁盘索引
  │              └─ 读多写少？ ——→ mmap 原始向量 + 内存索引
  │
  └─ 数据量 > 10TB 或需水平扩展？
       └─ 是 → 分布式分片 + 各分片独立选择存储策略

成本-性能量化参考（10亿条 768维向量）

八、总结

向量数据库的内存与磁盘博弈，本质上是**"延迟-成本-精度"的不可能三角**：

• 要低延迟？准备足够的内存预算
• 要低成本？接受磁盘 I/O 的延迟惩罚或量化精度损失
• 要高精度？保留原始向量，承受更大存储压力

真正优秀的架构，不是找到完美方案，而是设计能动态权衡的系统：

1. 可观测：知道每层数据的访问频率、延迟分布、缓存命中率
2. 可调度：能根据业务负载自动在热/温/冷层之间迁移数据
3. 可降级：在流量洪峰时，优雅降级到磁盘层而非直接崩溃

作为架构师，你的任务是理解数据访问的本质模式，然后为业务选择那个"足够好"的平衡点。

记住：在工程世界里，"完美"是昂贵的敌人，"足够好"才是可靠的朋友。