_{🧠 记忆锚点：HNSW 用内存换低延迟；DiskANN 把冷数据放 SSD、热导航留内存。}

💡 答案要点

DiskANN 核心定位：

• 诞生命题： HNSW 全量内存才能快，但数据太大放不下怎么办？
• 解决方案： 借助 SSD 磁盘存储 + 图索引，实现"内存级速度 + 磁盘级容量"

DiskANN 原理：

传统 HNSW（内存）：全量放内存 → 速度快，但受限于内存容量

DiskANN（磁盘）：

SSD 存储图索引（Vamana图）：
    ┌─────────────────┐
    │    图索引文件    │ ← SSD 上
    │  (几百GB没问题)  │
    └─────────────────┘
           ↓
    ┌─────────────────┐
    │   内存缓存层     │ ← 热数据放内存
    └─────────────────┘
           ↓
    ┌─────────────────┐
    │   Beam Search   │ ← 磁盘图搜索
    └─────────────────┘

搜索过程：
1. Beam Search 在 SSD 图上搜索
2. 热路径数据缓存到内存
3. SSD 延迟 ~100μs，内存延迟 ~1μs
4. 通过缓存命中加速，P99 延迟接近内存 HNSW

DiskANN vs HNSW 对比：

维度	HNSW	DiskANN
存储介质	全内存	SSD + 部分内存
数据规模	<1亿	1亿~100亿
内存需求	100% 数据	10-20% 数据
延迟	1-5ms	5-20ms
召回率	~95%	~90%
成本	高（内存贵）	低（SSD便宜）

选型建议：

数据规模	推荐方案	原因
<100万	HNSW（内存）	延迟最低，效果最好
100万-1亿	HNSW 或 IVF-PQ	内存可接受
1亿-10亿	DiskANN	内存放不下，只能磁盘
>10亿	分片 + DiskANN	需要分布式架构

Milvus DiskANN 配置：

index_params = {
    "metric_type": "IP",
    "index_type": "DISKANN",
    "params": {
        "search_list_size": 100  # Beam Search 宽度
    }
}
collection.create_index(
    field_name="embedding",
    index_params=index_params
)

面试话术：

"DiskANN 类索引把大部分索引数据放在 SSD，并用内存缓存热点与导航结构，适合内存装不下的大规模 ANN 场景。它不是亿级数据的唯一选择；应在相同数据、硬件、过滤条件和召回目标下，对比 HNSW、IVF/PQ、DiskANN 及托管方案的召回率、P95/P99 延迟、构建时间和成本。"

---

---